Les développeurs d'Ethereum ont récemment révélé de nouveaux progrès dans la conception de l'EIP-8141. Cette proposition tente d'implémenter certaines fonctions de transaction sous forme d'appels de contrats programmables, appelés « frames », plutôt que de modifier le format d'encapsulation des transactions Ethereum à chaque ajout de fonctionnalité.
La fonction de trading est désormais accessible par appel programmable
Cette approche couvre les fonctionnalités suivantes : l'expiration des transactions, la signature agrégée, les racines Merkle liées aux pools de confidentialité et les vérifications d'assertions après l'exécution de la transaction. Les développeurs estiment que si cette interface est suffisamment générique, lors de l'introduction de nouveaux mécanismes de validation par Ethereum à l'avenir, les portefeuilles, les navigateurs, les appareils de signature et les Layer 2 n'auront pas besoin de s'adapter à chaque nouveau conteneur de transaction.
Le projet d'EIP-8141 définit une Frame Transaction comme une séquence d'appels de contrat. Différents frames peuvent être chargés de vérifier les conditions de la transaction, d'approuver le paiement du gaz ou d'exécuter des opérations utilisateur.
Le projet de document liste actuellement trois modes : DEFAULT, VERIFY et SENDER. Le frame VERIFY est utilisé pour vérifier si une condition est remplie, tandis que le frame SENDER représente l'exécution d'une opération au nom de l'expéditeur de la transaction. Plusieurs frames peuvent également être regroupés en un traitement atomique, qui réussit entièrement ou est annulé dans son ensemble.
Réduire les coûts de coordination des portefeuilles et de l'infrastructure
Le point de vue central de l'ingénieur Derek Chiang est que les nouvelles fonctionnalités futures n'ont pas nécessairement besoin de concevoir un nouvel ensemble d'encapsulations de trading ; il est possible d'étendre les capacités tout en maintenant la stabilité de la structure de base, en utilisant de nouveaux objectifs de frame et des modèles d'appel.
Chaque modification du format d'encapsulation de transaction d'Ethereum n'affecte pas uniquement les clients d'exécution. Les portefeuilles, les Layer 2, les explorateurs de blocs, les appareils de signature matériels, les bibliothèques logicielles et divers fournisseurs d'infrastructure doivent tous comprendre et prendre en charge le nouveau format.
Chiang a déclaré que les mises à niveau d'Ethereum se produisent environ tous les neuf mois, et que des modifications fréquentes du paquetage de transaction entraîneraient des coûts de coordination élevés. En revanche, si le format frame pouvait devenir une interface plus stable, de nouvelles méthodes de validation pourraient être davantage déléguées aux contrats ou aux composants de protocole désignés.
Cependant, cela ne signifie pas que toutes les fonctionnalités futures pourront contourner les mises à jour du réseau. L'EIP-8141 modifie toujours les règles de consensus d'Ethereum et nécessite une implémentation par les clients. Si des nouveaux opcodes, des contrats précompilés ou des règles de gas sont impliqués, un hard fork pourrait toujours être nécessaire.
EIP-8130 et la direction de la validation parallèle
Les développeurs reconnaissent également qu'avec une abstraction des transactions accrue, il deviendra plus difficile pour les portefeuilles et les séquenceurs d'analyser les transactions avant exécution. À cet effet, l'équipe étudie la manière dont l'EIP-8141 peut être combinée avec un autre projet d'abstraction de compte, l'EIP-8130.
EIP-8130 propose une structure keystore sur chaîne permettant d'enregistrer préalablement les participants et les contrats d'authentification, et de spécifier clairement la méthode d'authentification dans les transactions. Ainsi, les nœuds peuvent déterminer avant l'exécution de tout code de portefeuille quel processus d'authentification est requis. Pour les Layer 2, cela aide à limiter les méthodes d'authentification à un ensemble de coûts plus prévisibles.
Vitalik Buterin a également expliqué la direction associée dans un autre message. Il a divisé les transactions en deux parties : « actions » et « conditions dépendantes ». La première est chargée de modifier l'état d'Ethereum, tandis que la seconde inclut des préconditions telles que les signatures, les preuves Merkle ou les preuves à connaissance nulle. Si ces dépendances sont indépendantes les unes des autres, il sera possible à l'avenir de les vérifier en parallèle, réduisant ainsi le coût de traitement de certaines transactions.
Listé sur Hegotá, mais la date d'activation n'est pas encore déterminée
L'EIP officiel Hegotá Meta a listé les Frame Transactions comme l'une des mises à jour prévues, ce qui signifie que leur statut a progressé par rapport à précédemment. Toutefois, l'EIP-8141 reste actuellement un projet de base, et les détails techniques ne sont pas encore finalisés.
Les travaux à poursuivre incluent : la mise à jour des spécifications, la finalisation de l’implémentation du client d’exécution, la mise en place d’un réseau de développement, ainsi que des tests d’interopérabilité avec les portefeuilles et les systèmes Layer 2. Les développeurs doivent également évaluer les risques de déni de service sur le memory pool, car la vérification programmable pourrait augmenter le coût de calcul pour filtrer les transactions invalides.
Actuellement, les heures d'activation de Hegotá sur Sepolia, Hoodi et le réseau principal sont encore vides. L'EIP-8141 est incluse dans le plan de mise à niveau, mais il reste une phase d'implémentation et de tests avant son déploiement final.