TRON propose une mise à niveau vers Mainnet 4.8.0 pour prendre en charge la compatibilité Ethereum Cancun, désormais ouverte à la discussion

Proposition pour la TRON La mise à jour de la version 4.8.0 du réseau principal a été introduite au sein de la communauté blockchain de preuve d'enjeu. Cette proposition vise à implémenter des instructions spécifiques alignant la machine virtuelle TRON (TVM) sur les avancées récentes de la machine virtuelle Ethereum (EVM), et à améliorer les fonctionnalités de la couche de consensus sur la blockchain.

La mise à niveau Ethereum Cancun, déployée le 13 mars, a apporté plusieurs améliorations. TRON prévoit d'adopter ces changements afin de préserver la compatibilité EVM et de garantir un environnement de développement cohérent sur toutes les plateformes. L'intégration des nouvelles instructions de la mise à niveau Cancun est jugée nécessaire pour assurer l'harmonisation opérationnelle, tout en optimisant les performances des contrats intelligents et l'efficacité énergétique.

Cette proposition vise à activer les opcodes de mise à niveau de Cancun sur TRON, renforçant l'alignement EVM et contribuant à l'interopérabilité entre différents environnements blockchain.

L'activation de ces opcodes dans une capacité d'espace réservé devrait maintenir la compatibilité TVM-EVM, faciliter le développement inter-chaînes, faciliter la transition des contrats intelligents basés sur EVM vers TRON et étendre les avantages d'économie d'énergie aux développeurs travaillant au sein de l'écosystème TRON.

L'activation d'une vérification améliorée au niveau du consensus vise à renforcer le réseau en corrigeant les vulnérabilités susceptibles de survenir lors des périodes de maintenance. Plus précisément, elle vise à empêcher la création de blocs et d'en-têtes de blocs invalides dont l'horodatage n'est pas un multiple exact de trois secondes. De plus, des mises à jour de l'algorithme de classement Super Representative sont incluses pour garantir sa fiabilité dans des conditions inhabituelles.

Afin de prendre en charge les futures fonctionnalités multiplateformes et d'améliorer la compatibilité avec une gamme plus large de versions du kit de développement Java, Java-Tron devrait passer de l'utilisation de la classe java.lang.Math à une bibliothèque mathématique qui fournit des résultats de calcul cohérents dans différents environnements.

Alors que le réseau TRON continue de se développer, l'amélioration de la sécurité et de l'efficacité opérationnelle demeure une priorité. Bien que des mesures de protection soient actuellement en place pour limiter certains types de transactions, comme celles impliquant des charges utiles importantes, des résultats multiples, des dates d'expiration proches ou des activations de compte, ces contrôles n'ont pas encore été intégrés à la couche de consensus. L'absence de telles mesures à ce niveau peut engendrer des problèmes de performance, même si elles ne compromettent pas la sécurité des actifs ni la cohérence des données sur la chaîne.

Cette proposition est conçue pour intégrer des éléments de la mise à niveau d'Ethereum Cancun et appliquer des améliorations supplémentaires à la couche de consensus, dans le but d'améliorer à la fois la stabilité et les performances du réseau TRON.

Le calendrier proposé comprend une date de création de demande de vote au 23 juin et une date d'entrée en vigueur au 26 juin.

Spécifications techniques : codes d'opération de stockage, copie de mémoire et instructions de code d'opération

Deux nouveaux opcodes liés au stockage transitoire sont programmés pour l'activation : TLOAD (0x5c) pour la lecture depuis le stockage transitoire, et TSTORE (0x5d) pour l'écriture. Le stockage transitoire offre une solution plus économe en énergie pour gérer les données temporaires lors d'une transaction. Il constitue une alternative à la mémoire traditionnelle en permettant la persistance des données entre les appels internes d'une même transaction, sans conservation des données une fois la transaction terminée. Des informations techniques complémentaires sont présentées dans le document TIP-650.

L'opcode MCOPY (0x5e) sera également introduit, offrant une méthode efficace de copie de données entre les régions mémoire. Cette instruction améliore l'efficacité énergétique dans les scénarios où les contrats intelligents effectuent des opérations mémoire intensives. Des détails sur cet ajout sont disponibles dans la documentation TIP-651.

Des améliorations supplémentaires à la vérification de la couche consensus sont également incluses. Elles impliquent la définition de limites à la taille des transactions de création de compte afin de mieux gérer l'utilisation de la bande passante. La vérification des tailles de transaction proches du seuil supérieur est renforcée afin de garantir que les blocs individuels ne dépassent pas leur capacité de transaction. La longueur des listes de résultats de transaction est désormais soumise à une validation plus stricte, garantissant ainsi l'adéquation avec le nombre de contrats invoqués, bien que les écarts n'affectent pas directement le consensus. Un mécanisme plus strict de gestion des transactions expirées est également mis en œuvre afin de réduire le risque que des transactions proches de leur expiration n'occupent des ressources réseau précieuses. Ces mises à jour sont décrites dans le TIP-694.

De plus, les opcodes BLOBHASH (0x49) et BLOBBASEFEE (0x4a) seront introduits comme espaces réservés. Ces instructions renverront une valeur par défaut de zéro et ne sont pas destinées à offrir toutes les fonctionnalités à ce stade. Leur inclusion temporaire vise à préserver la compatibilité avec le bytecode Ethereum. Plus d'informations sont disponibles dans la TIP-745.