Les développeurs d'Ethereum et de Base ont mis fin aux travaux sur une norme commune d'abstraction de compte après l'échec des efforts visant à concilier les EIP-8141 et EIP-8130, laissant les deux réseaux poursuivre des conceptions de transactions distinctes.
Derek Chiang, développeur chez Ethlabs, a déclaré lundi que les auteurs des deux propositions avaient cessé de travailler à une spécification partagée la semaine dernière, après avoir constaté que les options techniques disponibles exigeraient qu'Ethereum ou Base compromettent leurs 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 ne détiennent d'abord de l'ETH pour les frais de gaz et en prenant en charge des méthodes d'authentification telles que les clés d'accès téléphoniques. Les équipes avaient exploré la possibilité qu'une seule conception puisse servir Ethereum Layer 1 et Base Layer 2.
« Bien que nous ayons identifié un certain nombre de solutions techniques, toutes exigeaient que l'une ou l'autre des parties fasse au moins un petit compromis sur ses objectifs principaux », a déclaré Chiang. « Nous avons donc pris des chemins séparés, faisant peser sur les portefeuilles le fardeau de gérer la fragmentation qui en découle. »
Les développeurs d'Ethereum privilégient la résistance à la censure, la confidentialité et la sécurité, tandis que Base se concentre sur l'échelle, la personnalisation et la conformité, selon Chiang. Ces différences ont finalement empêché les équipes de s'entendre sur un seul format de transaction.
Cette décision laisse les développeurs de portefeuilles face à la possibilité de devoir prendre en charge deux formats de transaction natifs si les EIP-8141 et EIP-8130 atteignent toutes 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 exécutent bien, et si la communauté des portefeuilles peut surmonter la fragmentation, nous pourrions bien aboutir à la meilleure UX possible pour les utilisateurs finaux », a-t-il dit.
Le résultat modifie l'orientation que les développeurs discutaient quelques jours auparavant. Le 7 septembre, crypto.news avait précédemment rapporté que les développeurs de l'EIP-8141 exploraient la compatibilité avec l'EIP-8130 alors qu'ils travaillaient à rendre les transactions programmables tout en facilitant l'inspection de leurs exigences d'authentification par les fournisseurs d'infrastructure.
À ce stade, Chiang avait déclaré que l'EIP-8130 pourrait fournir des structures définies autour des "frames" de l'EIP-8141. L'arrangement proposé visait à préserver la nature programmable des frames tout en offrant aux portefeuilles et aux réseaux à haut débit un format de transaction plus clair.
L'EIP-8130 utilise un "keystore" sur la chaîne où les comptes peuvent enregistrer des acteurs et des contrats d'authentification approuvés. 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.
L'EIP-8141 prend une autre voie en structurant les transactions comme des appels de contrats programmables appelés "frames". Les frames peuvent effectuer différentes fonctions au sein de la même transaction, y compris la validation, l'approbation du gaz et l'exécution.
Les équipes ont maintenant abandonné l'effort de transformer ces approches en une seule norme.
Ethereum poursuit l'EIP-8141, ou "Frame Transactions" (Transactions à Cadres), dans le cadre de sa mise à niveau Hegotá prévue.
Le cluster Protocole de la Fondation Ethereum a placé cette proposition dans sa catégorie "must-ship" (à livrer impérativement) plus tôt ce mois-ci, tandis que le document source indique que la proposition vise à rendre l'abstraction de compte native sur Ethereum et à améliorer la sécurité ainsi que la préparation post-quantique.
Les Frame Transactions divisent une transaction en une séquence de cadres programmables. Un cadre peut valider l'expéditeur, un autre peut autoriser le compte responsable du gaz, et les cadres suivants peuvent exécuter les actions demandées par l'utilisateur.
Ce modèle permettrait que le compte initiant une action et le compte la payant soient différents.
Les développeurs d'Ethereum avaient déjà programmé l'EIP-8141 pour Hegotá d'ici le 7 septembre. Les développeurs principaux ont fait passer la proposition de "Considérée pour inclusion" à "Programmée pour inclusion" lors de l'appel "All Core Developers Execution" du 27 août, donnant ainsi aux Frame Transactions une position formelle dans la mise à niveau prévue pour 2027, bien que sa spécification reste en version préliminaire.
Selon le système proposé, une application pourrait couvrir les frais de transaction d'un utilisateur ou faire en sorte que l'utilisateur paie avec un autre actif, tandis que les validateurs 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 jetons ont toujours besoin d'ETH avant de pouvoir effectuer une transaction.
Les cadres peuvent également être utilisés pour le traitement par lots des transactions. Les actions liées pourraient être regroupées de sorte qu'elles réussissent toutes ensemble ou soient annulées si l'une d'elles échoue.
Un échange de jetons, par exemple, peut actuellement nécessiter une approbation séparée permettant à une application de dépenser des jetons avant que l'échange lui-même ne soit exécuté. Les Frame Transactions pourraient placer les actions liées au sein de la même structure de transaction programmable.
L'EIP-8141 est conçue 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 un état où « un compte devient simplement une adresse avec du code ».
Vitalik Buterin, co-auteur de l'EIP-8141, a décrit la proposition en février comme un « omnibus qui regroupe et résout tous les problèmes restants que l'AA (abstraction de compte) était censée aborder ».
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 approchait de l'« optimal ».
Les développeurs ont par la suite constaté que plusieurs fonctionnalités de transaction pouvaient être exprimées par le biais de cadres EIP-8141 programmables au lieu d'étendre de manière répétée l'enveloppe de transaction d'Ethereum.
Le rapport crypto.news du 7 septembre indiquait que l'approche pourrait gérer l'expiration des transactions, l'agrégation de signatures, les preuves de confidentialité et les assertions post-transaction sous forme d'appels de contrats 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 cadres et des modèles d'appels.
La validation programmable pourrait donner aux comptes plus de contrôle sur l'authentification. L'EIP-8141 est conçue pour prendre en charge des fonctionnalités telles que les systèmes de signature alternatifs, les paiements de gaz sponsorisés, le traitement par lots des transactions et la rotation des clés.
La même architecture pourrait aider les comptes Ethereum à s'affranchir de la dépendance au système de signature utilisé par les comptes externes classiques (EOA). Un utilisateur pourrait potentiellement changer la méthode d'authentification contrôlant un compte sans avoir à transférer les actifs vers une nouvelle adresse.
Les chercheurs d'Ethereum avaient envisagé les Frame Transactions pour Hegotá avant que la proposition ne soit officiellement programmée. En août, les développeurs comparaient l'EIP-8141 à l'EIP-8130 comme 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 vaste 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 prendre en charge les applications axées sur la confidentialité. Une proposition d'août discutait des pools de confidentialité auto-financé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 relayer 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 le package préféré d'un chercheur plutôt qu'une décision finale des développeurs principaux d'Ethereum à ce moment-là.
L'EIP-8130 de Base va maintenant progresser séparément de la proposition de Frame Transactions d'Ethereum.
La conception, élaborée par Base, combine un nouveau type de transaction avec un "Keystore" sur la chaîne qui enregistre les signataires et les authentificateurs approuvés pour un compte. Elle est destinée à prendre en charge l'authentification personnalisée, le traitement par lots des appels et le parrainage des frais de gaz.
Bien que les deux propositions partagent plusieurs objectifs d'abstraction de compte, leurs structures techniques confèrent à leurs réseaux respectifs différents niveaux de contrôle sur la manière dont les transactions sont authentifiées et traitées.
Avant que les équipes ne se séparent, les développeurs d'Ethereum avaient essayé de déterminer si le système d'authentification structuré de l'EIP-8130 pouvait être combiné avec les "frames" programmables de l'EIP-8141 sans forcer les réseaux de Couche 1 ou de Couche 2 à renoncer à leurs propriétés préférées.
Ethlabs avait précédemment classé 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 mise à l'échelle continue de la Couche 1.
L'effort commun étant désormais terminé, l'EIP-8141 reste la voie d'abstraction de compte native prévue par Ethereum pour Hegotá, tandis que Base continuera à développer l'EIP-8130 autour de son type de transaction séparé et de son keystore sur la chaîne.
ETH
