Blog · 9 novembre 2026

Énergie pour un approve TRC-20 et d'autres appels de contrat TRON

L'énergie est ce que TRON facture pour exécuter le code d'un contrat, et un transfert USDT n'est qu'un appel de contrat parmi d'autres. Un approve en dépense aussi, tout comme le transferFrom qui déplace ensuite les fonds approuvés. Le 28 octobre 2026, nous avons exécuté les deux à blanc sur le contrat USDT : un approve a pris 99,764 unités d'énergie quand l'allowance valait zéro et 33,764 quand une était déjà fixée, et un transferFrom a pris 65,123 sous une allowance illimitée et 89,325 sous une allowance limitée. Les appels vers d'autres contrats ont leurs propres chiffres, et l'énergie louée paie n'importe lequel d'entre eux comme elle paie un transfert.

Une délégation relève la limite d'énergie du compte sur lequel elle arrive, et tout appel de contrat que ce compte signe dépense sur cette limite avant qu'aucun TRX ne soit brûlé (ce qu'est l'énergie TRON). Rien dans une délégation ne nomme le contrat ou la fonction auxquels elle est destinée. Un appel autre qu'un transfert diffère par ce qu'il dépense, qui dépend du contrat et de la fonction qu'il appelle et de l'état qu'il y trouve, et, sur certains contrats, par la part que le signataire en paie.

Ce que les appels USDT ont dépensé en exécution à blanc

Une exécution à blanc est un appel constant : un nœud exécute l'appel sur sa propre copie de la chaîne, rapporte l'énergie utilisée et jette le résultat. Rien n'est signé ni diffusé, et cela ne coûte rien. Nous avons fait les nôtres par un nœud complet public entre 08:29 et 08:34 UTC le 28 octobre 2026. Les propriétaires étaient de vrais comptes, relevés dans les blocs les plus récents juste après que chacun avait approuvé un spender (l'adresse autorisée à dépenser), et les prélèvements ont été exécutés à blanc depuis ces spenders. L'approve depuis zéro est allé à une adresse que nous avions générée pour notre mesure de septembre, qu'aucun propriétaire n'avait approuvée. Nous avons lu chaque allowance et chaque solde juste avant l'appel. Chaque chiffre ci-dessous est revenu d'un appel qui aurait réussi. Le transfert et les deux prélèvements ont déplacé une unité, un millionième d'USDT, vers la même adresse, qui détient des USDT.

Les deux sortes d'approve venaient du même propriétaire pour le même nouveau montant. Un spender n'avait pas encore d'allowance et l'autre en avait une en place, et l'appel pour le premier a coûté 66,000 unités de plus. C'est le même écart qu'entre un transfert vers une adresse sans USDT et un vers un détenteur, que nous avons mesuré en septembre à 130,285 et 64,285 (les deux chiffres de transfert). Dans les deux paires, l'appel le moins cher écrasait un nombre déjà présent et le plus cher écrivait sur un zéro.

À moins que le déployeur du contrat n'ait accepté d'en porter une part, comme celui de JustLend DAO (ci-dessous), celui qui signe un appel en paie l'énergie. Dans un flux où un client approuve le contrat d'un commerçant et où le commerçant prélève ensuite les fonds, le client paie chaque approve, et celui qui signe l'appel de prélèvement le paie : le transferFrom du tableau, plus le code propre du contrat du commerçant quand le prélèvement s'exécute à l'intérieur. Les deux prélèvements que nous avons pu exécuter à blanc différaient par leur allowance. Avec une illimitée, le transferFrom du spender est revenu à 838 unités de plus qu'un simple transfert du même montant vers la même adresse, et avec une limitée il a coûté 24,202 au-dessus de cela. C'est une paire de chaque, et les paires avaient aussi des propriétaires et des spenders différents.

Un peu plus des trois quarts de chaque chiffre se loge dans un champ que le nœud appelle energy_penalty, et la part est la même pour les cinq appels, un approve autant qu'un transfer.

Un contrat de prêt : les deux appels de JustLend DAO

Louer de l'énergie auprès de JustLend DAO est en soi une paire d'appels de contrat, l'un qui ouvre la position et l'autre qui la rend (ce que coûte cette location). Nous avons apparié 30 locations avec leurs restitutions à partir du registre public du contrat pour les 24 heures qui se sont achevées le soir du 2 septembre 2026, et lu ce que chaque appel avait utilisé, au total, sur son reçu.

Le tableau donne des totaux parce que le signataire n'en paie pas toujours la totalité. Le contrat est réglé pour facturer à ses appelants un dixième de l'énergie et pour couvrir le reste avec l'énergie propre de son déployeur, jusqu'à 90,000 unités par appel, tant que cette énergie dure. Notre propre location ce soir-là a utilisé 84,290 unités et son signataire en a payé 8,429. Moins de trois heures plus tôt, la location d'un tiers avait payé elle-même les 52,672, parce que l'énergie du déployeur était épuisée, et sa restitution douze secondes plus tard a payé 62,200 sur 74,135. Une exécution à blanc rapporte ce qu'un appel utilise, alors que le signataire paie n'importe quelle part, du dixième que le contrat facture à ses appelants jusqu'à la totalité, selon l'énergie du déployeur à cette seconde : dimensionnez donc l'appel pour la totalité.

Dimensionner un appel que personne n'a mesuré pour vous

Aucun tableau ne couvre tous les contrats, et les chiffres ci-dessus bougent avec l'état qu'un appel trouve. Le chiffre qui fait foi est une exécution à blanc de cet appel exact, depuis le compte qui le signera, faite peu avant l'envoi. N'importe quel nœud complet y répond :

POST /wallet/triggerconstantcontract
{"owner_address": "T… (le compte qui signera)",
 "contract_address": "TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t",
 "function_selector": "approve(address,uint256)",
 "parameter": "… (les arguments, encodés en ABI)",
 "visible": true}

Vérifiez la réponse avant de retenir le nombre, car un appel qui ferait un revert rapporte quand même de l'énergie. Deux de nos premières tentatives de transferFrom sont allées vers des paires qui ne pouvaient plus payer : une allowance avait été consommée dans les secondes avant que nous demandions, et un propriétaire ne détenait aucun USDT. Elles sont revenues avec 5,947 et 4,845 unités pour un travail qui finit en échec. Leur result.result disait quand même true. Ce qui les distinguait était FAILED dans transaction.ret, là où un appel qui réussit laisse une entrée vide.

Laissez de la marge au-dessus du chiffre, car une allowance peut être dépensée et un destinataire vidé entre l'exécution à blanc et le bloc. Nous en laissons aussi de notre côté : nos chiffres de transfert standard, 65,000 et 131,000, se tiennent 715 unités au-dessus de ce que mesurent les deux transferts, et quand un transfert USDT signé qui nous est remis en mode B dépasse, à l'exécution à blanc, ce que mesure un transfert vers une adresse vide, nous achetons la mesure plus une marge et jugeons la livraison par rapport à la mesure elle-même.

Réglez le fee_limit de la transaction pour couvrir tout le chiffre au prix du réseau de 100 sun l'unité, même quand l'énergie est louée. Un nœud plafonne un appel à son fee_limit divisé par le prix de l'énergie et compte l'énergie déléguée dans ce plafond : une limite basse arrête donc un appel qui a sur le compte toutes les unités dont il a besoin. La bande passante est un compteur distinct : chaque appel paie aussi ses octets, et l'énergie ne les couvre pas (énergie et bande passante).

Un swap par un contrat d'échange suit la même arithmétique avec un contrat de plus : un approve qui laisse l'échange déplacer les jetons, puis l'appel dans l'échange. Nous n'en avons pas exécuté à blanc.

Louer de l'énergie pour un appel à l'unité

Nos modes A et B sont construits autour d'un transfert USDT, et le mode B accepte un transfer USDT signé et rien d'autre. En mode A, quand le destinataire d'un transfert se révèle être un contrat, nous faisons l'exécution à blanc pour vous : l'élément revient en kind: custom, ses energy_units sont la mesure, et un avertissement contract_recipient en dit la raison (les éléments custom, avant que rien ne soit signé).

Pour tout autre appel, il y a le mode C. Vous nommez le portefeuille et le volume, et nous déléguons l'énergie à ce portefeuille sans aucun destinataire en jeu (le mode C dans le parcours de l'API). Le volume peut être energy_units, n'importe quel nombre entier de 65,000 à 50,000,000 par portefeuille, et l'élément revient en kind: bulk. Le mode C n'accepte pas custom, car il n'y a pas de destinataire que nous puissions exécuter à blanc : la mesure est donc à vous. Le portefeuille doit être activé sur la chaîne, et une commande pour un portefeuille qui ne l'est pas revient refusée avec inactive_wallet.

La location de cinq minutes accepte des volumes jusqu'à 131,000. Tout volume plus grand doit aller sur la location d'une heure, et nous le refusons sur la plus courte avec bulk_needs_longer_lease : un gros volume est assemblé à partir de plusieurs sources et arrive en morceaux espacés de quelques secondes. Un approve depuis zéro tient seul sous cette ligne, avec de la marge. Faites-le suivre d'un transfert vers un détenteur et la paire passe la ligne : elle va donc sur l'heure. Le plus petit volume que nous vendons couvre un approve sur une allowance en place, avec presque autant encore en réserve.

POST /v1/estimate avec les mêmes energy_units indique combien ce volume serait facturé à cet instant et, dans coverage, si le marché l'a maintenant. Une fois livré, l'élément reste ready jusqu'à send_before puis passe à expired, ce qui veut dire ici que la location est arrivée à son terme : la fin normale. La facturation porte sur la livraison, et l'énergie que le portefeuille laisse inutilisée repart avec la délégation.

Ce que nous n'avons pas mesuré : un swap, un appel vers un contrat autre que l'USDT et JustLend DAO, un transferFrom vers une adresse sans USDT, et si ces chiffres tiennent sur des semaines. Chaque chiffre USDT ici est un appel constant auquel un seul nœud a répondu ; nous n'avons envoyé aucune transaction : aucun n'a donc été vérifié sur un reçu.

Exécutez l'appel à blanc, puis mettez ce volume sur le portefeuille qui le signera : le mode c et energy_units sur POST /v1/orders →