TRON-Ressourcendelegation im Detail: So funktioniert sie wirklich

Das Ressourcenmodell als Grundlage der Delegation

TRON berechnet keine Gasgebühren im Sinne von Ethereum. Stattdessen verfügt jedes Konto über zwei Ressourcenpools: Energy und bandwidth. Energy wird bei der Ausführung von Smart Contracts verbraucht. bandwidth wird bei jeder Transaktion verbraucht, unabhängig davon, ob ein Contract beteiligt ist oder nicht. Wenn einem Konto eines der beiden ausgeht, verbrennt das Netzwerk TRX aus dem Guthaben, um den Fehlbetrag zu decken. Genau dieser Verbrennungsmechanismus macht Transaktionen teuer.

Ressourcen entstehen auf zwei Wegen. Erstens durch das Staken von TRX: Wer TRX sperrt, erhält vom Netzwerk einen proportionalen Anteil am globalen Energy- oder bandwidth-Pool, der alle 24 Stunden erneuert wird. Zweitens durch eine Delegation: Ein anderes Konto staked TRX und weist die daraus entstehenden Ressourcen einer fremden Adresse zu. Das empfangende Konto nutzt die delegierten Ressourcen genauso, als hätte es selbst gestaked. Aus Sicht der virtuellen Maschine gibt es dabei keinen Unterschied.

Das ist das Fundament, auf dem alles andere aufbaut. Eine Delegation ist weder ein Zahlungskanal noch eine Art Verpackung. Sie ist eine direkte Zuweisung von On-Chain-Ressourcenansprüchen von einem Konto auf ein anderes.

Was Stake 2.0 an der Delegation verändert hat

Das ursprüngliche Staking-Modell (Stake 1.0) verlangte, beim Staken zu entscheiden, ob die TRX Energy oder bandwidth erzeugen sollen. Außerdem konnte man nur den gesamten Betrag auf einmal entsperren, und das erst nach einer dreitägigen Sperrfrist. Delegation war zwar möglich, aber unflexibel: Man staked TRX, es entstand genau ein Ressourcentyp, und optional konnte man diesen auf eine andere Adresse lenken.

Stake 2.0, das Mitte 2023 im Mainnet aktiviert wurde, hat dieses System grundlegend überarbeitet. Die wichtigsten Änderungen für die Delegation:

• Anteilige Ressourcenteilung: Die aus einer einzigen gestakten TRX-Position generierten Ressourcen können gleichzeitig auf mehrere Adressen aufgeteilt und delegiert werden. TRX wird dabei nicht verschickt, sondern lediglich der Ressourcenausstoß weitergeleitet.
• Unstaking in Teilbeträgen: Es können Teilmengen entsperrt werden, ohne die restliche gestakte Position anzutasten. Das gibt Ressourcenanbietern die Möglichkeit, ihre Liquidität zu steuern, ohne aktive Delegationen zu unterbrechen.
• 14-tägige Unstaking-Verzögerung: Nach dem Aufruf von unstake gelangt TRX in eine Warteschlange und ist rund 14 Tage gesperrt, bevor withdrawExpireUnfreeze aufgerufen werden kann. Entscheidend dabei: Jede Delegation, die auf diesem TRX basiert, wird sofort beendet, nicht erst nach 14 Tagen. Die Delegation endet in dem Moment, in dem das Unstaking eingeleitet wird, nicht wenn das TRX zurückkommt.
• Kein Sperrwechsel mehr beim Ressourcentyp: In Version 1.0 erforderte der Wechsel von Energy zu bandwidth ein vollständiges Unstaking und erneutes Staking. In Version 2.0 kann der Ressourcenausstoß derselben gestakten Position auf einen anderen Ressourcentyp umgeleitet werden, ohne zu unstaken. Allerdings ist dafür nach wie vor eine separate On-Chain-Transaktion notwendig.

Für alle, die delegierte Energy empfangen, hat das eine wichtige praktische Konsequenz: Das Ressourcenguthaben kann mitten am Tag auf null fallen, wenn der Delegator ein Unstaking einleitet. Auf der Empfängerseite gibt es keine Übergangsphase.

Die On-Chain-Mechanik einer Delegationstransaktion

Wenn ein Delegator delegateResource aufruft, speichert die Transaktion drei Angaben: die Adresse des Delegators, die Adresse des Empfängers sowie die Menge an Energy (oder bandwidth), die delegiert wird. Anschließend passt das Netzwerk die im Kontostatus des Empfängers angezeigten Ressourcenlimits entsprechend an.

Intern führen TRON-Knoten delegierte Ressourcen getrennt von den selbst gestakten Ressourcen. Wer ein Konto über wallet/getaccount in der HTTP-API abfragt, sieht Felder wie delegated_frozenV2_balance_for_energy und acquired_delegated_frozenV2_balance_for_energy. Das erste zeigt, was man selbst delegiert hat. Das zweite zeigt, was man empfangen hat. TRX wird dabei in keinem Fall bewegt. Es verbleibt stets im gestakten Guthaben des Delegators.

Der Ressourcenverbrauch während einer Transaktion läuft folgendermaßen ab: Die virtuelle Maschine prüft die verfügbare Energy des ausführenden Kontos, also selbst Gestaktes plus empfangene Delegationen. Ist ausreichend vorhanden, wird in einer bestimmten Reihenfolge davon abgezogen: zuerst empfangene Delegationen, dann selbst gestakte Energy. Ist der Pool erschöpft, wird TRX aus dem freien Guthaben des Kontos zum jeweils aktuellen Netzwerksatz verbrannt. Dieser Satz ist nicht fest. Er wird dynamisch berechnet, basierend auf der gesamten Netzwerk-Energy und dem durch On-Chain-Parameter festgelegten Verbrennungspreis.

Wie sich Energy nach der Nutzung erholt

Energy ist kein einmaliges Guthaben. Verbrauchte Energy erholt sich gleichmäßig über einen Zeitraum von 24 Stunden. Hat ein Konto ein maximales Energy-Limit von 100.000 und werden 65.000 davon für einen Contract verbraucht, ist das Konto nach 24 Stunden wieder vollständig aufgefüllt. Nach der Hälfte der Zeit, also nach 12 Stunden, stehen wieder rund 32.500 zur Verfügung.

Diese Erholung gilt sowohl für selbst gestakte als auch für delegierte Energy. Die Erholungsrate richtet sich nach dem Maximum des jeweiligen Kontos, nicht nach einem globalen Takt. Zwei Konten mit unterschiedlichen Energy-Limits erholen sich daher mit unterschiedlichen absoluten Raten, auch wenn beide sich vollständig innerhalb von 24 Stunden auffüllen.

Für häufige Transaktionen ist dieser 24-Stunden-Zyklus der entscheidende Engpass. Eine Delegation, die auf eine einzige Überweisung pro Tag ausgelegt ist, reicht nicht für zehn Überweisungen täglich, selbst wenn das Gesamtvolumen an Energy auf dem Papier ausreichend erscheint. Es kommt nicht nur auf die Gesamtkapazität an, sondern auch auf den Erholungsrhythmus.

Delegationen widerrufen und neu zuweisen

Eine Delegation ist nicht dauerhaft. Ein Delegator kann jederzeit unDelegateResource aufrufen, um Ressourcen zurückzuziehen. Die Wirkung tritt sofort ein: Die verfügbare Energy des Empfängers sinkt im nächsten Block um den widerrufenen Betrag. Auf der Empfängerseite gibt es keine Übergangsfrist und keinen Ausgleichsmechanismus auf Protokollebene.

Wer eine Delegation neu zuweisen, also denselben Ressourcenausstoß an eine andere Adresse lenken möchte, benötigt zwei Transaktionen: erst den Widerruf beim bisherigen Empfänger, dann die Neudelegation an die neue Adresse. Das sind zwei separate On-Chain-Vorgänge, die selbst bandwidth verbrauchen. In Stake 2.0 lassen sich diese effizienter bündeln als zuvor, aber aus Sicht einer einzelnen Transaktion sind sie nach wie vor nicht atomar.

Ein besonderer Fall, den man kennen sollte: Wenn das gestakte TRX eines Delegators etwa 200.000 Energy erzeugt und davon 150.000 an Adresse A delegiert wurden, können die verbleibenden 50.000 an Adresse B delegiert werden, ohne die Delegation an A zu berühren. Die Bedingung ist dabei, dass die gesamte delegierte Energy die erzeugte Energy nicht übersteigen darf. Ein Versuch, mehr zu delegieren als erzeugt wird, schlägt auf Transaktionsebene fehl.

Was das für gemietete Energy bedeutet

Energy-Vermietungsdienste wie tronenergyrent.com arbeiten vollständig innerhalb dieses Delegationsmodells. Wer Energy mietet, erhält vom Anbieter Energy, der TRX staked und dann delegateResource auf die Zieladresse aufruft. Aus Sicht des Empfängerkontos kommt acquired_delegated_frozenV2_balance_for_energy an, genau wie oben beschrieben. Es wird kein TRX gehalten, sondern eine zeitlich begrenzte Ressourcenzuteilung.

Die Mietdauer entspricht dem Zeitraum, in dem der Anbieter die Delegation aktiv hält. Eine eintägige Miete kostet zum aktuellen Preis 8,19 TRX pro 65.000 Energy, was ausreicht, um eine Standard-TRC-20-USDT-Überweisung abzudecken, die etwa 65.000 Energy und rund 345 bandwidth benötigt. Eine 30-tägige Miete für denselben Energy-Block schlägt mit 175,50 TRX zu Buche. Die genauen Kosten für das eigene Transaktionsvolumen lassen sich mit dem Rechner ermitteln.

Dass kurzfristige Mieten pro Tag teurer sind, hat einen rein mechanischen Grund: Der Anbieter muss die Unstaking-Warteschlange und den Aufwand für häufige Neudelegationen verwalten. Die 14-tägige Auszahlungsverzögerung bedeutet, dass Kapital gebunden bleibt, unabhängig davon, wie kurz die Mietdauer war.

bandwidth-Delegation folgt demselben Modell

Alles oben Beschriebene gilt in gleicher Weise für bandwidth, mit einem Unterschied im Standardverhalten. Jedes Konto erhält täglich 600 bandwidth kostenlos vom Netzwerk, unabhängig vom Staking. Diese kostenlose Zuteilung reicht für einfache TRX-Überweisungen, deckt aber nicht den bandwidth-Anteil bei häufigen TRC-20-Überweisungen ab. Durch Staking oder empfangene bandwidth-Delegationen erhöht sich das Limit über diesen Basiswert von 600 hinaus.

Wer bandwidth an ein Konto delegiert, erhöht dessen Kapazität zusätzlich zu einer bereits vorhandenen kostenlosen Zuteilung. Die Verbrauchsreihenfolge lautet: zuerst kostenlose bandwidth, dann delegierte bandwidth, dann selbst gestakte bandwidth, dann TRX-Verbrennung. Diese Reihenfolge ist wichtig, wenn man genau berechnen möchte, ab wann für ein bestimmtes Konto TRX verbrannt wird.

Den Delegationsstatus über die API auslesen

Wer Werkzeuge entwickelt oder eine Delegation überwacht, nutzt folgende relevante API-Aufrufe:

• wallet/getaccount: gibt den vollständigen Kontostatus zurück, einschließlich der Felder für delegierte und empfangene Ressourcen
• wallet/getdelegatedresourcev2: gibt den konkreten Delegationseintrag zwischen zwei Adressen zurück, inklusive der genauen Energy-Menge und einer etwaigen Sperrfrist
• wallet/getcanwithdrawunfreezeamount: zeigt einem Delegator, welcher Teil seines wartenden Unstakings bereits abhebbar ist

Der Endpunkt getdelegatedresourcev2 ist besonders nützlich, um vor der Ausführung von Transaktionen, die auf eine Delegation angewiesen sind, zu prüfen, ob diese aktiv und korrekt bemessen ist. Man sollte nicht davon ausgehen, dass eine Delegation noch besteht, nur weil sie gestern eingerichtet wurde. Den On-Chain-Status sollte man stets vor der Nutzung bestätigen.