Le développeur d’Ethereum, Derek Chiang, a déclaré le 7 septembre que les auteurs de l’EIP-8141 avaient trouvé un moyen d’exprimer plusieurs fonctionnalités de transaction sous forme d’appels de contrat programmables au lieu de les ajouter séparément à l’enveloppe de transaction d’Ethereum.
Chiang, co-auteur de l’EIP-8141 et contributeur d’Ethlabs, a décrit le développement comme une « percée en matière de conception » dans un article discutant des travaux récents des auteurs de la proposition. L’approche traite l’expiration des transactions, les signatures globales, les racines Merkle du pool de confidentialité et les assertions post-transaction comme des appels appelés « frames ».
Le projet de spécification officiel définit une transaction de trame comme une séquence d’appels de contrat. Différentes trames peuvent valider une transaction, approuver son paiement de gaz ou exécuter des opérations utilisateur. La proposition propose actuellement trois modes : DEFAULT, VERIFY et SENDER.
Une trame VERIFY peut vérifier si une condition requise est satisfaite. Une trame SENDER exécute une opération à partir du compte identifié comme l’expéditeur de la transaction. Les images peuvent également être regroupées en lots atomiques, ce qui signifie que chaque opération d’un lot réussit ensemble ou que l’ensemble du groupe revient.
La proposition définit toujours une enveloppe de transaction de base contenant des champs tels que l’identifiant de la chaîne, le nom occasionnel, l’expéditeur, les frais, les signatures et la liste des trames. Le point de Chiang est plus restreint : les développeurs peuvent être en mesure d’introduire plus de fonctionnalités via de nouvelles cibles de trame et de nouveaux modèles d’appel sans créer un autre format d’enveloppe pour chaque fonctionnalité.
Une enveloppe stable pourrait réduire le travail de coordination
La modification d’une enveloppe de transaction Ethereum affecte bien plus que les clients d’exécution. Les portefeuilles, les réseaux de layer 2, les explorateurs de blocs, les dispositifs de signature, les bibliothèques de logiciels et les fournisseurs d’infrastructure doivent tous comprendre le nouveau format.
Chiang a déclaré que les mises à niveau d’Ethereum ont lieu environ tous les neuf mois, ce qui rend les changements d’enveloppe répétés lents et difficiles à coordonner. Un format de trame suffisamment général pourrait servir d’interface stable tandis que les contrats ou les composants de protocole désignés fourniraient de nouvelles méthodes de validation.
Cela ne signifie pas que les fonctionnalités futures ne nécessiteront jamais une mise à niveau du réseau. EIP-8141 lui-même modifie les règles de consensus d’Ethereum et nécessite une implémentation par le client. Les nouveaux opcodes, précompilations ou règles de gaz pourraient également nécessiter des hard forks. L’avantage proposé est que les développeurs n’auraient pas nécessairement besoin de reconcevoir le conteneur de transactions à chaque fois.
La spécification EIP-8141 répertorie l’abstraction de compte natif parmi ses principaux objectifs. Il pourrait prendre en charge la rotation des clés, les systèmes de signature alternatifs, les paiements de gaz sponsorisés et le regroupement des transactions. Il vise également à réduire la dépendance des comptes Ethereum à l’égard du système de signature secp256k1 utilisé par les comptes externes conventionnels.
Comme crypto.news l’a rapporté dans sa couverture de la refonte des transactions Ethereum proposée par Vitalik Buterin, la validation programmable pourrait éventuellement aider Ethereum à adopter de nouveaux systèmes d’authentification sans remplacer un système de signature fixe par un autre.
L’EIP-8130 pourrait faciliter l’inspection des cadres
Chiang a également reconnu un compromis. Les transactions hautement abstraites peuvent devenir difficiles à analyser pour les portefeuilles, les séquenceurs et autres infrastructures avant leur exécution. Un séquenceur de layer 2 peut, par exemple, vouloir accepter uniquement des méthodes de signature spécifiées car leurs coûts de calcul sont prévisibles.
Les développeurs explorent donc comment les frames pourraient fonctionner avec EIP-8130, un autre projet de proposition d’abstraction de compte. EIP-8130 crée un magasin de clés en chaîne dans lequel les comptes enregistrent les acteurs et les contrats d’authentification. Les transactions identifient explicitement leur méthode d’authentification.
Cette structure permet à un nœud de déterminer le processus de validation requis par une transaction avant d’exécuter un code de portefeuille arbitraire. Dans le cadre du profil de layer 2 proposé par EIP-8130, une chaîne pourrait limiter son chemin de transaction à un ensemble canonique d’authentificateurs à coût fixe tout en laissant d’autres méthodes d’authentification disponibles via l’exécution EVM ordinaire.
Chiang a déclaré que l’EIP-8130 pourrait imposer des structures définies sur les trames EIP-8141. La collaboration pourrait préserver la flexibilité des frames tout en donnant aux portefeuilles et aux chaînes à haut débit un format de transaction plus lisible. La conception combinée n’a pas été finalisée et les deux spécifications restent sujettes à révision.
Une couverture antérieure de crypto.news a examiné la concurrence entre EIP-8141 et EIP-8130 au cours du processus initial de définition de la portée de Hegotá. Les derniers commentaires suggèrent que les développeurs recherchent désormais des éléments compatibles plutôt que de traiter les propositions uniquement comme des alternatives mutuellement exclusives.
Buterin connecte les trames avec une validation parallèle
Vitalik Buterin a développé la direction technique dans un article séparé, en distinguant les « actions » et les « dépendances » des transactions. Une action modifie l’état d’Ethereum, comme le transfert d’ETH. Une dépendance est une condition qui doit être remplie, comme une signature, une preuve Merkle ou une preuve de connaissance nulle.
Buterin a fait valoir que les dépendances indépendantes pouvaient être vérifiées en parallèle. Les conditions qui n’accèdent pas à l’état Ethereum pourraient potentiellement être traitées une fois par le pool de mémoire au lieu d’être répétées pendant l’exécution. Plusieurs contrôles pourraient éventuellement être représentés par une preuve STARK récursive, bien que cela reste une direction de recherche plutôt qu’une fonctionnalité approuvée.
Cette distinction pourrait également aider les clients à distinguer les transactions prévisibles des opérations nécessitant l’environnement d’exécution entièrement dynamique d’Ethereum. Buterin a déclaré que des activités plus analysables de manière statique pourraient bénéficier de coûts de gaz inférieurs et évoluer davantage. Aucune grille tarifaire de ce type n’a été approuvée.
Le modèle frame fournit une interface potentielle pour cette approche car la validation et l’exécution apparaissent comme des appels identifiables. Ethereum conserverait une exécution flexible des contrats tout en permettant aux transactions plus simples de déclarer plus d’informations sur leurs exigences.
L’EIP-8141 est programmé, mais les dates restent ouvertes
L’EIP officiel Hegotá Meta répertorie désormais les transactions Frame et FOCIL comme prévu pour leur inclusion dans la mise à niveau Hegotá d’Ethereum. Cela représente un statut plus fort que les considérations précédentes, mais cela ne fige pas la conception technique actuelle de l’EIP-8141.
EIP-8141 reste marqué comme un projet de proposition de base. Ses auteurs peuvent réviser les modes de trame, la gestion des signatures, la comptabilité des gaz et la relation avec EIP-8130 à mesure que le travail de mise en œuvre se poursuit. Le document Hegotá laisse également les champs d’activation Sepolia, Hoodi et mainnet vides.
Les prochaines étapes mesurables comprennent des spécifications mises à jour, des implémentations de clients d’exécution, des réseaux de développement et des tests d’interopérabilité avec les portefeuilles et les systèmes de layer 2. Les développeurs doivent également examiner les risques de déni de service du pool de mémoire, car la validation programmable peut rendre le rejet de transactions non valides plus coûteux en termes de calcul.
Les tests détermineront si la combinaison proposée de cadres flexibles et d’authentificateurs structurés peut répondre aux besoins de la couche de base d’Ethereum et des chaînes EVM plus rapides. Jusqu’à ce que les paramètres d’activation soient publiés, EIP-8141 reste une partie programmée mais inachevée de Hegotá.
