Wie die TRON-Energie-Delegation funktioniert
Eine TRON-Energie-Delegation ist eine Transaktion und zwei Kontofelder. Eine Adresse, die TRX für Energie gestakt hat, ruft delegateResource auf und nennt darin einen Empfänger, und von diesem Block an gibt dieser Empfänger Energie aus, für die er nie gestakt hat, während der Staker weiterhin jedes eingefrorene TRX hält. Nichts wird übertragen, auf der Empfängerseite wird nichts genehmigt, kein Schlüssel wechselt den Besitzer. Es ist der Mechanismus, auf dem der ganze Markt für Energiemiete steht, und was folgt, ist aus den Aktuatoren von java-tron selbst gelesen, aus Live-Abfragen des Mainnets und aus zwei transaktionalen Läufen im Nile-Testnetz am 3. und 4. September 2026.
Was hinübergeht, und was bleibt
Das gestakte TRX verlässt das Konto des Besitzers nie: Delegieren verschiebt es zwischen zwei Töpfen innerhalb dieses Kontos, aus dem für Energie eingefrorenen Guthaben in ein für Energie delegiertes. TRON-Power — das Stimmgewicht — ist die Summe beider Töpfe, Verleihen kostet einen Staker also weder Stimmen noch Stimmprämien. Ein am 3. September 2026 gelesener Mainnet-Staker zeigt das besser als der Quelltext: Er gab 3,080,000 Stimmen ab, während er weniger als die Hälfte davon undelegiert hielt und den Rest verliehen hatte, und die eigene TRON-Power-Zahl der Node für ihn war die Summe der beiden Töpfe.
Der Empfänger bekommt die andere Hälfte des Handels: Energie, und sonst nichts. Das Feld, das eine Delegation auf dem empfangenden Konto schreibt, ist kein Bestandteil der TRON-Power, geliehene Energie trägt also keine Stimme mit sich — der Empfänger in derselben Abfrage hatte überhaupt keine TRON-Power-Zahl, und unserer im Nile ebenso wenig.
Was das empfangende Konto zeigt
Zwei Zahlen bewegen sich. acquired_delegated_frozenV2_balance_for_energy steigt um den delegierten Betrag, und das Energielimit des Kontos steigt mit — um das delegierte TRX mal dem TotalEnergyLimit des Netzes, geteilt durch dessen TotalEnergyWeight, abgeschnitten. Am 3. September 2026 zeigte ein Mainnet-Empfänger, der Delegationen über 31246 TRX von zwei Delegierenden hielt, ein Energielimit von 299,638, und das ist genau diese Rechnung zu dem Verhältnis, das das Netz an jenem Abend trug: 180,000,000,000 über 18,770,236,993.
Und genau hier werden Käufer von Energie überrascht: Eine Delegation lautet auf TRX und nicht auf Energie. Der Nenner ist das gesamte gestakte Gewicht des Netzes, er bewegt sich mit jedem Block, und eine anderswo gemessene Zahl reist nicht mit — derselbe Stake war in jener Woche im Nile etwa 7.7 mal so viel Energie wert wie im Mainnet.
Die Sperre, und die vier Abweisungen
Standardmäßig lässt sich eine Delegation jederzeit zurückholen. Was das verhindert, ist lock=true im Delegationsaufruf, und sonst nichts. Sie nimmt einen Parameter, lock_period, gezählt in Blöcken zu drei Sekunden — ein Feld, das sich wie eine Dauer liest und eine Anzahl ist, sodass die Bitte um 300 davon, weil man 300 Sekunden wollte, still fünfzehn Minuten kauft. Auf null gelassen oder weggelassen bedeutet er 86,400 Blöcke: drei Tage. Die Obergrenze ist ein Chain-Parameter, und im Mainnet stand sie am 3. September 2026 bei 864,000 Blöcken, also dreißig Tagen.
Eine Sperre lässt sich verlängern und nie verkürzen. Eine zweite Delegation an denselben Empfänger wird nur angenommen, wenn ihre Frist mindestens so lang ist wie die noch laufende, und sie setzt dann den Ablauf des gesamten angesammelten Guthabens neu und nicht bloß den des neuen Teils — eine gesperrte Delegation aufzustocken sperrt also alles darunter erneut. Alles Übrige weist das Netz ab. Diese vier kamen am 3. September 2026 von einer Mainnet-Node zurück, gerichtet auf ein Paar mit einer laufenden Sperre über vierundzwanzig Stunden; die Node führt beim Bauen beider Aufrufe die Prüfung des Aktuators selbst aus, alle vier sind also die Antworten des Aktuators, und nichts wurde signiert oder gesendet:
- eine Sperre über einen Block auf die laufende gesetzt —
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!, was benennt, was noch zu laufen hat, in Millisekunden; - eine Sperre über vier Stunden auf dieselbe — die identische Abweisung. Länger als eine frische Sperre ist nicht der Test; länger als das, was übrig ist, schon;
- eine Sperre einen Block über der Obergrenze —
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - das Undelegate selbst —
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0. Nicht „weniger, als Sie verlangt haben“: Solange die Sperre hält, zählt gesperrtes Guthaben als überhaupt nichts.
Ein validierter Bau ist kein Block, dasselbe wurde also mit einer eigenen Sperre gemacht. Zwei Läufe im Nile am 4. September 2026 setzten eine Sperre, baten sofort um das Undelegate, warteten die Sperre ab und fragten erneut: beide Male abgewiesen mit jenem letzten Satz, Zeichen für Zeichen, und beide Male angenommen, sobald der Ablauf vorüber war — bei fünf Minuten und bei vier Stunden. Der lange Lauf klärte außerdem, was die Einheit zählt: Zwischen den beiden Transaktionen rückte die Uhr im Header um 4,801 Drei-Sekunden-Slots vor, während die Blockhöhe um 4,785 vorrückte, sechzehn Slots brachten also keinen Block hervor, und die Sperre lief trotzdem ihre vier Stunden. lock_period zählt Slots der Blockuhr und nicht Blöcke, die tatsächlich entstehen.
Eine beenden, und sehen, dass sie beendet ist
Der Delegierende ruft undelegateResource auf, und wenn keine Sperre im Weg steht, ist es in einem Block erledigt. Keiner der beiden Aufrufe kostet etwas über Bandbreite hinaus — beide Aktuatoren bepreisen sich mit null —, und nur deshalb lässt sich Energie überhaupt in Minuten verkaufen. Gegen eine laufende Sperre gibt es kein Storno und keine Gebühr, die einen Ausweg kauft; erneut mit lock=false zu delegieren ist auch keiner, denn das schreibt eine eigene Zeile und lässt die gesperrte stehen.
Die Sperre ist an genau einer Stelle sichtbar: in der Delegationszeile für das Paar, wo expire_time_for_energy ein Zeitstempel in Millisekunden ist. Ein fehlender Schlüssel heißt keine Sperre — so sieht die Delegation eines gewöhnlichen Mietanbieters aus, und die Zeilen eines Mainnet-Pools, am 3. September 2026 gelesen, trugen überhaupt keinen Ablaufschlüssel. Lesen Sie diese Zahl, statt sie auszurechnen: Der Aktuator stempelt sie aus dem Header des vorherigen Blocks, eine Rechnung aus dem Block der Delegation selbst liegt also einen Block daneben, und eine aus dem Zeitstempel der Transaktion jedes Mal um einen anderen Betrag. Beide Nile-Läufe trafen den gespeicherten Wert auf die Millisekunde genau nach der ersten Regel und nach keiner der beiden anderen.
Endet eine Delegation, gehen die beiden Felder des Empfängers nicht auf null — sie verschwinden aus der Antwort, und die Delegationszeile kommt leer zurück. Was ein Konto abfragt, muss Fehlen als null behandeln, sonst zeigt es weiter Energie an, die vor Minuten zu ihrem Besitzer zurückgekehrt ist.
Warum die empfangende Wallet nichts signiert
All das geschieht auf der Seite des Delegierenden: Der Empfänger wird in der Transaktion genannt, auf seinem Konto wird ein Feld geschrieben, und es gibt nichts anzunehmen, zu genehmigen oder zu verbinden — weshalb eine Delegation auch nicht an das herankommt, was diese Wallet hält. Zwei Anforderungen zeigen in die andere Richtung: Die Adresse muss bereits als Konto existieren, und sie darf kein Vertrag sein, was der Aktuator rundheraus abweist. Genau das macht Energie überhaupt per API mietbar (was Energie ist und woher sie kommt).
Worauf die Miete aufbaut
Ein Verkäufer von Energie ist ein Konto mit einem Stake und der Gewohnheit zu delegieren: Es delegiert für eine Frist an Ihre Absender-Wallet, Sie geben die Energie für einen USDT-Transfer aus, und es holt die Delegation zurück. Die Fristen unterscheiden sich von Verkäufer zu Verkäufer; unsere ist 300 Sekunden, denn ein Transfer dauert Sekunden. Eine Bestellung antwortet mit send_before — dem Moment, in dem sich das Lieferfenster schließt, drei Sekunden vor Ablauf dieser Frist —, und dieses Feld ist das, wonach zu planen ist, und nicht die Uhr an der Wand.
Solange die Frist läuft, ist all das sichtbar, und das ist der nützliche Teil am Mieten auf einer öffentlichen Kette: die Delegationstransaktion auf der sendenden Wallet, das Energielimit, das darauf gestiegen ist, und die Zeile zwischen den beiden Adressen in jedem Explorer, der den Delegationszustand liest. Die Energie ist entweder auf der Adresse oder sie ist es nicht, und berechnet wird das Erste davon (was das gerade kostet). Eine Wallet, die den ganzen Tag sendet, ist derselbe Mechanismus nach Plan: Eine Auto-refill-Regel füllt sie nach jedem Transfer wieder auf, statt Sie um eine Bestellung zu bitten.
Zwei Dinge haben wir nicht gemessen, und beide gehören offen ausgesprochen. Das eine ist, was die eigene Staking-Tätigkeit des empfangenden Kontos mit einer darauf stehenden Delegation macht: Unstakt ein Empfänger mitten in der Frist oder delegiert er weiter, legt der Code des Aktuators nahe, dass es dort etwas zu finden gibt, und wir haben es nicht ausgeführt. Das andere ist eine Aufstockung: Quelltext und TIP-542 sagen beide, dass eine angenommene zweite Delegation das ganze Guthaben darunter neu sperrt, und wir haben keine durchgeführt.