Délégation de ressources sur TRON : fonctionnement interne et mécanique réelle

Le modèle de ressources, point de départ indispensable

TRON ne facture pas de frais de gaz à la manière d'Ethereum. Chaque compte dispose à la place de deux réservoirs de ressources : l'Energy et la bandwidth. L'Energy est consommée lors de l'exécution des contrats intelligents. La bandwidth est consommée par toutes les transactions, qu'elles impliquent ou non un contrat. Lorsque l'un de ces deux réservoirs est vide, le réseau brûle des TRX depuis votre solde pour combler le déficit. C'est ce mécanisme de combustion qui rend les opérations coûteuses.

Les ressources se génèrent de deux façons. La première consiste à staker des TRX : en immobilisant des TRX, le réseau crédite votre compte d'une part proportionnelle du pool mondial d'Energy ou de bandwidth, renouvelée toutes les 24 heures. La seconde passe par la réception d'une délégation : un autre compte stake des TRX et affecte les ressources ainsi générées à votre adresse. Votre compte utilise ces ressources déléguées exactement comme si vous les aviez stakées vous-même. Du point de vue de la machine virtuelle, aucune distinction n'existe.

C'est le socle sur lequel repose tout le reste. La délégation n'est ni un canal de paiement, ni une couche intermédiaire. Il s'agit d'une affectation directe de droits sur des ressources on-chain, d'un compte vers un autre.

Ce que Stake 2.0 a changé en matière de délégation

L'ancien modèle de staking (Stake 1.0) vous obligeait à choisir dès le staking si vos TRX produiraient de l'Energy ou de la bandwidth, et vous ne pouviez dégeler la totalité du montant qu'après un blocage de 3 jours. La délégation existait, mais elle restait rudimentaire. Vous stagiez des TRX, ils généraient un type de ressource, et vous pouviez éventuellement orienter cette ressource vers une autre adresse.

Stake 2.0, activé sur le réseau principal à la mi-2023, a profondément restructuré ce fonctionnement. Voici les changements clés concernant la délégation :

• Répartition proportionnelle des ressources : une seule position de TRX stakés peut voir ses ressources générées réparties et déléguées à plusieurs adresses simultanément. Vous ne transférez pas de TRX, vous redistribuez la production de ressources.
• Dégel par tranches : il est désormais possible de dégeler des montants partiels sans toucher au reste de la position stakée. Cela permet aux fournisseurs de ressources de gérer leur liquidité sans perturber les délégations en cours.
• Délai de dégel de 14 jours : après l'appel à unstake, les TRX entrent dans une file d'attente de retrait. Ils sont bloqués environ 14 jours avant que vous puissiez appeler withdrawExpireUnfreeze pour les récupérer. Durant cette période, toute délégation qui reposait sur ces TRX est annulée immédiatement, et non au bout des 14 jours. La délégation prend fin au moment où vous initiez le dégel, pas lorsque vous récupérez les TRX.
• Plus de blocage lors du changement de type de ressource : avec Stake 1.0, passer de l'Energy à la bandwidth exigeait un cycle complet de dégel et de re-staking. Avec Stake 2.0, il est possible de rediriger la production de ressources d'une même position stakée vers un autre type sans dégeler, même si cela nécessite tout de même une transaction on-chain distincte.

La conséquence concrète pour quiconque reçoit de l'Energy déléguée : votre solde de ressources peut tomber à zéro en cours de journée si le délégateur initie un dégel. Aucun délai de grâce n'est prévu côté récepteur.

La mécanique on-chain d'une transaction de délégation

Lorsqu'un délégateur appelle delegateResource, la transaction enregistre trois éléments : l'adresse du délégateur, l'adresse du destinataire et la quantité d'Energy (ou de bandwidth) déléguée. Le réseau ajuste ensuite les limites de ressources affichées dans l'état du compte du destinataire.

En interne, les nœuds TRON suivent séparément les ressources déléguées et les ressources détenues en propre. Si vous interrogez un compte via wallet/getaccount sur l'API HTTP, vous verrez des champs tels que delegated_frozenV2_balance_for_energy et acquired_delegated_frozenV2_balance_for_energy. Le premier correspond à ce que vous avez envoyé. Le second correspond à ce que vous avez reçu. Aucun TRX ne se déplace dans ce processus. Les TRX restent dans le solde staké du délégateur.

La consommation de ressources lors d'une transaction fonctionne ainsi : la machine virtuelle vérifie l'Energy disponible du compte qui exécute la transaction (stakée en propre et reçue par délégation). Si elle est suffisante, elle la déduit de ce pool dans un ordre précis : les délégations reçues sont consommées en premier, puis l'Energy auto-stakée. Si le pool est épuisé, des TRX sont brûlés depuis le solde libre du compte au taux réseau en vigueur. Ce taux n'est pas fixe. Il est calculé dynamiquement en fonction de l'Energy totale du réseau et du prix de combustion défini par les paramètres on-chain.

Comment l'Energy se reconstitue après utilisation

L'Energy n'est pas un crédit à usage unique. L'Energy utilisée se reconstitue de façon linéaire sur une fenêtre de 24 heures. Si votre compte dispose d'une limite maximale de 100 000 d'Energy et que vous en consommez 65 000 lors de l'exécution d'un contrat, vous serez de nouveau au maximum au bout de 24 heures. À mi-chemin, soit après 12 heures, vous disposerez à nouveau d'environ 32 500 d'Energy.

Cette reconstitution s'applique aussi bien à l'Energy auto-stakée qu'à l'Energy déléguée. Le taux de reconstitution est lié au maximum du compte, et non à une horloge mondiale fixe. Ainsi, deux comptes avec des limites d'Energy différentes se reconstituent à des vitesses absolues différentes, même si tous deux se rechargent complètement en 24 heures.

Pour les opérations à haute fréquence, ce cycle de 24 heures constitue la contrainte principale. Une délégation dimensionnée pour un seul transfert par jour ne suffira pas à couvrir dix transferts par jour, même si la quantité totale d'Energy paraît suffisante sur le papier. Il faut tenir compte du rythme de reconstitution, pas seulement de la capacité totale.

Révoquer et réaffecter des délégations

Une délégation n'est pas permanente. Un délégateur peut appeler unDelegateResource à tout moment pour reprendre ses ressources. L'effet est immédiat : l'Energy disponible du destinataire diminue du montant révoqué dès le bloc suivant. Aucun délai de carence n'est prévu côté destinataire, et aucun mécanisme de compensation n'existe au niveau du protocole.

Réaffecter une délégation, c'est-à-dire diriger la même production de ressources vers un autre destinataire, nécessite deux transactions : révoquer la délégation auprès du destinataire actuel, puis déléguer au nouveau. Il s'agit d'opérations on-chain distinctes, qui consomment elles-mêmes de la bandwidth. Avec Stake 2.0, il est possible de les regrouper plus efficacement qu'auparavant, mais elles ne sont toujours pas atomiques au sein d'une seule transaction.

Un cas particulier à connaître : si la position stakée d'un délégateur génère, disons, 200 000 d'Energy, et qu'il en a délégué 150 000 à l'adresse A, il peut déléguer les 50 000 restants à l'adresse B sans toucher à la délégation de A. La contrainte est que le total de l'Energy déléguée ne peut pas dépasser le total de l'Energy générée. Toute tentative de délégation excessive échouera au niveau de la transaction.

Ce que cela implique pour la location d'Energy

Les services de location d'Energy comme tronenergyrent.com fonctionnent entièrement dans ce modèle de délégation. Lorsque vous louez de l'Energy, le fournisseur stake des TRX, génère de l'Energy, puis appelle delegateResource en ciblant votre adresse. Du point de vue de votre compte, vous recevez acquired_delegated_frozenV2_balance_for_energy exactement comme décrit ci-dessus. Vous ne détenez pas de TRX. Vous disposez d'une allocation temporaire de ressources.

La durée de location correspond à la période pendant laquelle le fournisseur maintient cette délégation active. Une location d'un jour aux tarifs actuels coûte 8,19 TRX pour 65 000 d'Energy (ce qui suffit à couvrir un transfert standard de USDT TRC-20 nécessitant environ 65 000 d'Energy et environ 345 de bandwidth). Une location de 30 jours revient à 175,50 TRX pour le même bloc d'Energy. Vous pouvez calculer les coûts exacts selon votre volume de transferts à l'aide du calculateur.

Si les locations courtes coûtent davantage à la journée, c'est pour une raison purement mécanique : le fournisseur doit gérer la file d'attente de dégel et les frais liés à la re-délégation pour des cycles fréquents. Le délai de retrait de 14 jours immobilise le capital, quelle que soit la durée de la location.

La délégation de bandwidth suit le même modèle

Tout ce qui a été décrit ci-dessus s'applique de la même façon à la bandwidth, à une différence près concernant le comportement par défaut. Chaque compte bénéficie de 600 unités de bandwidth gratuites par jour, quelle que soit son activité de staking. Cette allocation gratuite couvre les transferts de TRX simples, mais ne suffira pas à couvrir la partie bandwidth des transferts TRC-20 à haute fréquence. Staker ou recevoir de la bandwidth déléguée augmente votre limite au-delà de ce seuil de 600.

Lorsque vous déléguez de la bandwidth à un compte, vous ajoutez à sa capacité en plus de l'allocation gratuite dont il dispose déjà. L'ordre de consommation est le suivant : bandwidth gratuite en premier, puis bandwidth déléguée, puis bandwidth auto-stakée, puis combustion de TRX. Cet ordre a son importance si vous cherchez à calculer précisément à quel moment la combustion entrera en jeu pour un compte donné.

Lire l'état des délégations via l'API

Si vous développez des outils ou souhaitez surveiller une délégation, voici les appels API pertinents :

• wallet/getaccount : renvoie l'état complet du compte, incluant les champs de ressources déléguées et reçues
• wallet/getdelegatedresourcev2 : renvoie l'enregistrement de délégation spécifique entre deux adresses, avec la quantité exacte d'Energy et la date d'expiration du verrouillage le cas échéant
• wallet/getcanwithdrawunfreezeamount : permet à un délégateur de vérifier quelle part de son dégel en attente est déjà disponible au retrait

Le point de terminaison getdelegatedresourcev2 est particulièrement utile pour vérifier qu'une délégation est bien active et correctement dimensionnée avant d'exécuter des transactions qui en dépendent. Ne partez jamais du principe qu'une délégation est en place sous prétexte qu'elle a été configurée la veille. Vérifiez toujours l'état on-chain avant de vous y fier.