Blog · 9. November 2026

Energie für ein TRC-20-approve und andere TRON-Vertragsaufrufe

Energie ist das, was TRON für das Ausführen von Vertragscode berechnet, und ein USDT-Transfer ist ein Vertragsaufruf unter vielen. Auch ein approve gibt sie aus, und ebenso das transferFrom, das später die genehmigten Mittel bewegt. Am 28. Oktober 2026 haben wir beide auf dem USDT-Vertrag im Dry-Run ausgeführt: Ein approve brauchte 99,764 Einheiten Energie, wenn die Allowance bei null stand, und 33,764, wenn bereits eine gesetzt war, und ein transferFrom brauchte 65,123 gegen eine unbegrenzte Allowance und 89,325 gegen eine begrenzte. Aufrufe in andere Verträge haben eigene Zahlen, und gemietete Energie bezahlt jeden von ihnen so, wie sie einen Transfer bezahlt.

Eine Delegation hebt das Energielimit des Kontos an, auf dem sie landet, und jeder Vertragsaufruf, den dieses Konto signiert, gibt aus diesem Limit aus, bevor TRX verbrannt wird (was TRON-Energie ist). Nichts in einer Delegation nennt den Vertrag oder die Funktion, für die sie gedacht ist. Ein anderer Aufruf als ein Transfer unterscheidet sich darin, wie viel er ausgibt, was vom aufgerufenen Vertrag und der Funktion und vom Zustand abhängt, den er dort vorfindet, und bei manchen Verträgen darin, wie viel davon der Signierende bezahlt.

Was die USDT-Aufrufe im Dry-Run ausgaben

Ein Dry-Run ist ein Constant-Aufruf: Eine Node führt den Aufruf gegen ihre eigene Kopie der Kette aus, meldet die verbrauchte Energie und verwirft das Ergebnis. Nichts wird signiert oder übertragen, und es kostet nichts. Unsere haben wir über eine öffentliche Full Node zwischen 08:29 und 08:34 UTC am 28. Oktober 2026 gemacht. Die Owner waren echte Konten, aus den neuesten Blöcken herausgegriffen, kurz nachdem jedes eine Adresse zum Abbuchen berechtigt hatte (den Spender), und die Einzüge wurden im Dry-Run von diesen Spendern ausgeführt. Das approve von null ging an eine Adresse, die wir für unsere Septembermessung erzeugt hatten und die kein Owner genehmigt hatte. Wir haben jede Allowance und jedes Guthaben Augenblicke vor dem Aufruf gelesen. Jede Zahl unten kam von einem Aufruf zurück, der erfolgreich gewesen wäre. Der Transfer und beide Einzüge bewegten eine Einheit, ein Millionstel USDT, an dieselbe Adresse, die USDT hält.

Die beiden Arten von approve kamen vom selben Owner für denselben neuen Betrag. Ein Spender hatte noch keine Allowance und der andere eine bestehende, und der Aufruf für den ersten kostete 66,000 Einheiten mehr. Das ist derselbe Abstand wie zwischen einem Transfer an eine Adresse ohne USDT und einem an einen Halter, den wir im September mit 130,285 und 64,285 gemessen haben (die beiden Transferzahlen). In beiden Paaren überschrieb der billigere Aufruf eine Zahl, die schon da war, und der teurere schrieb über eine Null.

Sofern der Deployer des Vertrags nicht zugesagt hat, einen Teil zu tragen, wie es der von JustLend DAO getan hat (unten), bezahlt, wer einen Aufruf signiert, dessen Energie. In einem Ablauf, in dem ein Kunde den Vertrag eines Händlers genehmigt und der Händler die Mittel später einzieht, bezahlt der Kunde jedes approve, und wer den einziehenden Aufruf signiert, bezahlt ihn: das transferFrom in der Tabelle, dazu den eigenen Code des Händlervertrags, wenn der Einzug darin läuft. Die beiden Einzüge, die wir im Dry-Run ausführen konnten, unterschieden sich in ihrer Allowance. Bei einer unbegrenzten kam das transferFrom des Spenders auf 838 Einheiten mehr als ein einfacher Transfer desselben Betrags an dieselbe Adresse, und bei einer begrenzten kostete es 24,202 darüber. Das ist je ein Paar, und die Paare hatten auch verschiedene Owner und Spender.

Etwas mehr als drei Viertel jeder Zahl steckt in einem Feld, das die Node energy_penalty nennt, und der Anteil ist bei allen fünf Aufrufen gleich, bei einem approve ebenso wie bei einem transfer.

Ein Lending-Vertrag: die zwei Aufrufe von JustLend DAO

Energie bei JustLend DAO zu mieten ist selbst ein Paar von Vertragsaufrufen, einer, der die Position eröffnet, und einer, der sie zurückgibt (was diese Miete kostet). Wir haben 30 Mieten mit ihren Rückgaben aus der öffentlichen Aufzeichnung des Vertrags für die 24 Stunden gepaart, die am Abend des 2. September 2026 endeten, und gelesen, was jeder Aufruf insgesamt verbrauchte, aus seiner Quittung.

Die Tabelle gibt Summen an, weil der Signierende nicht immer alles bezahlt. Der Vertrag ist so eingestellt, dass er seinen Aufrufern ein Zehntel der Energie berechnet und den Rest aus der eigenen Energie seines Deployers deckt, bis zu 90,000 Einheiten je Aufruf, solange diese Energie reicht. Unsere eigene Miete an jenem Abend verbrauchte 84,290 Einheiten, und ihr Signierender bezahlte 8,429 davon. Knapp drei Stunden früher bezahlte die Miete eines Dritten alle 52,672 selbst, weil die Energie des Deployers erschöpft war, und ihre Rückgabe zwölf Sekunden später bezahlte 62,200 von 74,135. Ein Dry-Run meldet, was ein Aufruf verbraucht, während der Signierende alles zwischen dem Zehntel, das der Vertrag seinen Aufrufern berechnet, und dem Ganzen bezahlt, je nach der Energie des Deployers in dieser Sekunde, bemessen Sie den Aufruf also für das Ganze.

Einen Aufruf bemessen, den niemand für Sie gemessen hat

Keine Tabelle deckt jeden Vertrag, und die Zahlen oben bewegen sich mit dem Zustand, den ein Aufruf vorfindet. Die Zahl, der man trauen sollte, ist ein Dry-Run genau dieses Aufrufs, vom Konto, das ihn signieren wird, kurz vor dem Senden gemacht. Jede Full Node beantwortet ihn:

POST /wallet/triggerconstantcontract
{"owner_address": "T… (das Konto, das signieren wird)",
 "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
 "function_selector": "approve(address,uint256)",
 "parameter": "… (die Argumente, ABI-kodiert)",
 "visible": true}

Prüfen Sie die Antwort, bevor Sie die Zahl übernehmen, denn ein Aufruf, der zurückrollen würde, meldet trotzdem Energie. Zwei unserer ersten transferFrom-Versuche gingen an Paare, die nicht mehr zahlen konnten: Eine Allowance war in den Sekunden vor unserer Anfrage aufgebraucht worden, und ein Owner hielt überhaupt kein USDT. Sie kamen mit 5,947 und 4,845 Einheiten für Arbeit zurück, die in einem Fehlschlag endet. Ihr result.result lautete trotzdem true. Was sie unterschied, war FAILED in transaction.ret, wo ein erfolgreicher Aufruf einen leeren Eintrag hinterlässt.

Lassen Sie Luft über der Zahl, denn eine Allowance kann verbraucht und ein Empfänger geleert werden, zwischen dem Dry-Run und dem Block. Auch wir lassen auf unserer Seite Luft: Unsere Standard-Transferzahlen, 65,000 und 131,000, liegen 715 Einheiten über dem, was die beiden Transfers messen, und wenn ein signierter USDT-Transfer, den man uns in mode B übergibt, im Dry-Run über dem liegt, was ein Transfer an eine leere Adresse misst, kaufen wir die Messung plus eine Marge und beurteilen die Lieferung an der Messung selbst.

Setzen Sie das fee_limit der Transaktion so, dass es die ganze Zahl zum Netzpreis von 100 sun je Einheit deckt, auch wenn die Energie gemietet ist. Eine Node deckelt einen Aufruf bei seinem fee_limit geteilt durch den Energiepreis und zählt delegierte Energie in diesen Deckel hinein, ein niedriges Limit stoppt also einen Aufruf, der jede Einheit, die er braucht, auf dem Konto hat. Bandbreite ist ein getrennter Zähler: Jeder Aufruf bezahlt auch seine Bytes, und Energie deckt sie nicht (Energie und Bandbreite).

Ein Swap über einen Exchange-Vertrag ist dieselbe Arithmetik mit einem Vertrag mehr darin: ein approve, das dem Exchange erlaubt, die Tokens zu bewegen, dann der Aufruf in den Exchange. Einen solchen haben wir nicht im Dry-Run ausgeführt.

Energie für einen Aufruf je Einheit mieten

Unsere mode A und mode B sind um einen USDT-Transfer herum gebaut, und mode B akzeptiert ein signiertes USDT-transfer und nichts sonst. Stellt sich in mode A heraus, dass der Empfänger eines Transfers ein Vertrag ist, führen wir den Dry-Run für Sie aus: Die Position kommt als kind: custom zurück, ihre energy_units sind die Messung, und eine Warnung contract_recipient sagt, warum (custom-Positionen, bevor etwas signiert wird).

Für jeden anderen Aufruf gibt es mode C. Sie nennen die Wallet und die Menge, und wir delegieren die Energie an diese Wallet, ohne dass ein Empfänger beteiligt ist (mode C im API-Durchgang). Die Menge kann energy_units sein, jede ganze Zahl von 65,000 bis 50,000,000 je Wallet, und die Position kommt als kind: bulk zurück. Mode C kennt kein custom, weil es keinen Empfänger gibt, den wir im Dry-Run prüfen könnten, die Messung ist also Ihre. Die Wallet muss on-chain aktiviert sein, und eine Bestellung für eine, die es nicht ist, kommt mit inactive_wallet abgelehnt zurück.

Die Fünf-Minuten-Miete nimmt Mengen bis 131,000. Alles Größere muss auf die Ein-Stunden-Miete, und auf der kürzeren lehnen wir es mit bulk_needs_longer_lease ab: Eine große Menge wird aus mehreren Quellen zusammengesetzt und landet in Teilen im Abstand von Sekunden. Ein approve von null passt für sich allein unter diese Linie, mit Platz für eine Marge. Folgt ihm ein Transfer an einen Halter, überschreitet das Paar die Linie, es geht also auf die Stunde. Die kleinste Menge, die wir verkaufen, deckt ein approve auf eine bestehende Allowance und lässt fast ebenso viel noch übrig.

POST /v1/estimate mit denselben energy_units beantwortet, was diese Menge in diesem Moment kosten würde, und in coverage, ob der Markt sie jetzt hat. Nach der Lieferung bleibt die Position auf ready, bis send_before erreicht ist, und steht dann auf expired, was hier bedeutet, dass die Miete ausgelaufen ist: das normale Ende. Berechnet wird die Lieferung, und Energie, die die Wallet ungenutzt lässt, geht mit der Delegation zurück.

Was wir nicht gemessen haben: einen Swap, einen Aufruf in irgendeinen anderen Vertrag als USDT und JustLend DAO, ein transferFrom an eine Adresse ohne USDT und ob diese Zahlen über Wochen halten. Jede USDT-Zahl hier ist ein Constant-Aufruf, den eine Node beantwortet hat; wir haben keine Transaktion gesendet, keine davon wurde also an einer Quittung geprüft.

Führen Sie den Aufruf im Dry-Run aus und legen Sie dann diese Menge auf die Wallet, die ihn signieren wird: mode c und energy_units bei POST /v1/orders →