Ethereum et Base abandonnent leur standard commun d'abstraction de compte

Le développeur d'Ethlabs Derek Chiang a déclaré lundi que les auteurs des deux propositions ont cessé la semaine dernière de travailler à une spécification commune après avoir constaté que les options techniques disponibles auraient obligé Ethereum ou Base à faire des compromis sur des exigences fondamentales.

Les deux propositions visent à simplifier la manière dont les utilisateurs interagissent avec les portefeuilles crypto, notamment en permettant des transactions sans que les utilisateurs détiennent d'abord de l'ETH pour le gaz et en prenant en charge des méthodes d'authentification telles que les passkeys de téléphone. Les équipes exploraient la possibilité qu'une seule conception puisse servir la couche 1 d'Ethereum et la couche 2 de Base.

« Bien que nous ayons identifié un certain nombre de solutions techniques, elles exigeaient toutes qu'un côté ou l'autre fasse au moins un petit compromis sur ses objectifs fondamentaux », a déclaré Chiang. « Nous avons donc suivi des voies séparées, laissant aux portefeuilles la charge de gérer la fragmentation qui en découle. »

Les développeurs d'Ethereum donnent la priorité à la résistance à la censure, à la confidentialité et à la sécurité, tandis que Base se concentre sur l'évolutivité, la personnalisation et la conformité, selon Chiang. Ces différences ont finalement empêché les équipes de s'accorder sur un format de transaction unique.

Les plans d'abstraction de compte d'Ethereum et de Base se sont séparés

Cette décision laisse les développeurs de portefeuilles face à la possibilité de prendre en charge deux formats de transaction natifs si EIP-8141 et EIP-8130 atteignent tous deux la production.

Chiang a déclaré que les portefeuilles pourraient toujours offrir aux utilisateurs une expérience cohérente malgré les différences techniques entre les réseaux, selon la manière dont les développeurs gèrent les normes distinctes.

« S'ils s'exécutent bien, et si la communauté des portefeuilles parvient à combler la fragmentation, nous pourrions bien aboutir à la meilleure expérience utilisateur possible pour les utilisateurs finaux », a-t-il déclaré.

Ce résultat change la direction que les développeurs discutaient quelques jours plus tôt. Les développeurs d'EIP-8141 exploraient la compatibilité avec EIP-8130 tout en cherchant des moyens de garder les transactions programmables tout en rendant leurs exigences d'authentification plus faciles à inspecter pour les fournisseurs d'infrastructure.

À ce stade, Chiang a déclaré qu'EIP-8130 pourrait fournir des structures définies autour des frames d'EIP-8141. L'arrangement proposé visait à préserver la nature programmable des frames tout en donnant aux portefeuilles et aux réseaux à haut débit un format de transaction plus clair.

EIP-8130 utilise un keystore onchain où les comptes peuvent enregistrer des acteurs approuvés et des contrats d'authentification. Les transactions identifient la méthode d'authentification qu'elles utilisent, permettant à un réseau de déterminer le processus de validation requis avant d'exécuter le code du portefeuille.

EIP-8141 adopte une approche différente en structurant les transactions comme des appels de contrat programmables appelés frames. Les frames peuvent exécuter différentes fonctions au sein de la même transaction, notamment la validation, l'approbation du gaz et l'exécution.

Les équipes ont désormais abandonné l'effort visant à transformer ces approches en une norme unique.

EIP-8141 est devenue une proposition incontournable pour Ethereum

Ethereum poursuit avec EIP-8141, ou Frame Transactions, dans le cadre de sa mise à niveau prévue Hegotá.

Le cluster Protocol de l'Ethereum Foundation a placé la proposition dans sa catégorie « must-ship » plus tôt ce mois-ci, tandis que le document source indique que la proposition vise à rendre l'abstraction de compte native à Ethereum et à améliorer la sécurité et la préparation post-quantique.

Les Frame Transactions divisent une transaction en une séquence de frames programmables. Un frame peut valider l'expéditeur, un autre peut autoriser le compte responsable du gaz, et les frames suivants peuvent exécuter les actions demandées par l'utilisateur.

Ce modèle permettrait au compte qui initie une action et au compte qui la paie d'être différents.

Les développeurs d'Ethereum avaient déjà programmé EIP-8141 pour Hegotá au 7 septembre. Les développeurs principaux ont déplacé la proposition de « Considered for Inclusion » à « Scheduled for Inclusion » lors de l'appel All Core Developers Execution du 27 août, donnant aux Frame Transactions une position formelle dans la mise à niveau prévue pour 2027 alors que sa spécification restait à l'état de projet.

Dans le système proposé, une application pourrait couvrir les frais de transaction d'un utilisateur ou permettre à l'utilisateur de payer via un autre actif tandis que les validateurs d'Ethereum continuent de recevoir les frais de réseau en ETH.

Cette structure pourrait supprimer une exigence courante des portefeuilles selon laquelle les utilisateurs détenant des stablecoins ou d'autres tokens ont encore besoin d'ETH avant de pouvoir effectuer une transaction.

Les frames peuvent également être utilisés pour le regroupement de transactions. Des actions liées pourraient être groupées de sorte qu'elles réussissent toutes ensemble ou soient annulées si l'une échoue.

Un échange de tokens, par exemple, peut actuellement nécessiter une approbation distincte permettant à une application de dépenser des tokens avant que l'échange lui-même ne soit exécuté. Les Frame Transactions pourraient placer des actions liées au sein de la même structure de transaction programmable.

Les frames programmables étendent les contrôles de compte d'Ethereum

EIP-8141 est conçu pour déplacer davantage de logique de validation de compte vers du code programmable au lieu d'exiger que les comptes Ethereum conventionnels dépendent d'un processus d'authentification fixe.

La proposition décrit son état final comme celui où « un compte devient simplement une adresse avec du code ».

Vitalik Buterin, co-auteur d'EIP-8141, a décrit la proposition en février comme un « omnibus qui règle et résout tous les problèmes restants que l'AA était censée traiter ».

Le 5 septembre, Buterin a déclaré que la proposition avait fait « beaucoup de progrès importants » au cours des mois précédents et qu'elle était « proche de l'optimal ».

Les développeurs ont ensuite constaté que plusieurs fonctionnalités de transaction pouvaient être exprimées via des frames programmables EIP-8141 au lieu d'étendre à plusieurs reprises l'enveloppe de transaction d'Ethereum.

Cette approche pourrait gérer l'expiration des transactions, l'agrégation de signatures, les preuves de confidentialité et les assertions post-transaction comme des appels de contrat programmables. Les Frame Transactions nécessiteraient toujours des modifications des règles de consensus d'Ethereum, mais les fonctions individuelles pourraient être construites via des cibles de frame et des modèles d'appel.

La validation programmable pourrait donner aux comptes plus de contrôle sur l'authentification. EIP-8141 est conçu pour prendre en charge des fonctionnalités telles que des systèmes de signature alternatifs, des paiements de gaz sponsorisés, le regroupement de transactions et la rotation des clés.

La même architecture pourrait aider les comptes Ethereum à s'éloigner de la dépendance au système de signature utilisé par les comptes externes conventionnels. Un utilisateur pourrait potentiellement changer la méthode d'authentification contrôlant un compte sans transférer les actifs vers une nouvelle adresse.

Les chercheurs d'Ethereum envisageaient les Frame Transactions pour Hegotá avant que la proposition ne soit formellement programmée. En août, les développeurs comparaient EIP-8141 et EIP-8130 comme des approches concurrentes de l'abstraction de compte native tout en réduisant la portée de la mise à niveau de 2027.

À l'époque, les propositions faisaient partie d'un processus de sélection plus large pour Hegotá couvrant la résistance à la censure, la confidentialité, la tarification du gaz, l'économie des validateurs et la mise à l'échelle de la couche 1.

Les chercheurs d'Ethereum avaient examiné séparément comment les Frame Transactions pourraient soutenir les applications axées sur la confidentialité. Une proposition d'août discutait de pools de confidentialité autofinancés dans lesquels des paiements de frais programmables pourraient permettre à un pool de confidentialité de couvrir son propre gaz au lieu de dépendre d'un relais externe.

Ce travail associait les Frame Transactions à d'autres changements proposés, notamment les Keyed Nonces, les Recent Roots et les Transaction Assertions. La proposition de pool de confidentialité restait à l'époque un ensemble préféré par un chercheur plutôt qu'une décision finale des développeurs principaux d'Ethereum.

Base continuera avec EIP-8130

L'EIP-8130 de Base se poursuivra désormais séparément de la proposition Frame Transactions d'Ethereum.

La conception rédigée par Base combine un nouveau type de transaction avec un « Keystore » onchain qui enregistre les signataires et authentificateurs approuvés pour un compte. Elle vise à prendre en charge l'authentification personnalisée, le regroupement d'appels et le parrainage de gaz.

Bien que les deux propositions partagent plusieurs objectifs d'abstraction de compte, leurs structures techniques donnent à leurs réseaux respectifs différents niveaux de contrôle sur la manière dont les transactions sont authentifiées et traitées.

Avant la séparation des équipes, les développeurs d'Ethereum tentaient de déterminer si le système d'authentification structuré d'EIP-8130 pouvait être combiné avec les frames programmables d'EIP-8141 sans forcer les réseaux de couche 1 ou de couche 2 à abandonner leurs propriétés préférées.

Ethlabs avait précédemment placé les Frame Transactions parmi ses principales priorités pour la mise à niveau Hegotá, citant l'abstraction de compte native aux côtés de la résistance à la censure, des blocs plus rapides et de la poursuite de la mise à l'échelle de la couche 1.

L'effort conjoint étant désormais terminé, EIP-8141 reste la voie d'abstraction de compte native prévue par Ethereum pour Hegotá, tandis que Base continuera à développer EIP-8130 autour de son type de transaction distinct et de son keystore onchain.