Derek Chiang d'Ethlabs, fondateur de ZeroDev, a déclaré qu'une collaboration pour harmoniser l'EIP-8130 basé sur Base avec l'EIP-8141 Frame Transactions d'Ethereum s'est terminée la semaine dernière, laissant les deux parties poursuivre des normes natives d'abstraction de compte séparées.
Le registre officiel des propositions d'amélioration d'Ethereum liste à la fois EIP-8130 et EIP-8141 comme brouillons. Ethlabs soutient les transactions Frame pour Hegotá, qu'elle décrit comme un prochain hard fork d'Ethereum, et affirme qu'elle compte collaborer avec les Layer 2 et les wallets pour son déploiement.
En termes pratiques, les types de transactions natives incompatibles déplaceraient une partie importante du travail d'intégration vers les développeurs de wallets et d'applications. Chiang a déclaré que cet échec consistait à « transférer la charge aux wallets pour gérer la fragmentation qui en résulte », bien qu'il ait argumenté que le logiciel pourrait toujours masquer ces différences aux utilisateurs.
Comment les designs diffèrent
L'abstraction de compte permet aux comptes de contrats intelligents de définir leur propre logique de validation plutôt que de s'appuyer uniquement sur des règles fixes pour les comptes détenus externement. Le standard final ERC-4337 fournit une abstraction de compte sans modifier les règles de consensus d'Ethereum : les utilisateurs soumettent des objets `UserOperation` à un mempool séparé, et les bundlers les regroupent en transactions pour un contrat EntryPoint.
Les deux nouveaux projets intègrent les fonctions d'abstraction de compte dans la gestion native des transactions, mais ils utilisent des points de contrôle différents.
EIP-8130 combine une nouvelle transaction typée avec un keystore sur chaîne et un système de configuration de compte. Il prend en charge l'authentification personnalisée, les appels groupés et le parrainage de gaz. Chaque transaction déclarant son authentificateur, les nœuds peuvent identifier le travail de validation requis et rejeter les authentificateurs inconnus avant d'exécuter un code de wallet arbitraire.
Le projet 8130 définit un profil L1 avec une acceptation permissive des authenticateurs et un profil L2 qui limite son chemin de transaction natif à un ensemble d'authenticateurs canoniques. Cette structure vise à offrir aux chaînes à haut débit des coûts de validation prévisibles tout en préservant une base commune pour les wallets.
EIP-8141 divise plutôt une transaction en une séquence de « cadres », ou appels de contrat qui valident la transaction, approuvent le paiement du gaz et exécutent les opérations utilisateur. Sa conception permet aux comptes d'utiliser du code EVM pour définir des règles de validation et de paiement du gaz, avec prise en charge de fonctionnalités telles que la rotation des clés, les appels groupés et les paiements de frais alternatifs.
Ethlabs a décrit le compromis central : une validation sans autorisation basée sur l'EVM offre aux transactions Frame une flexibilité pour la confidentialité et les systèmes de signature futurs, mais les coûts de validation dynamiques peuvent poser des défis pour les Layer 2 à haut débit. L'EIP-8130 privilégie une validation plus prévisible en rendant l'authentificateur explicite avant l'exécution.
La portabilité monte dans la pile
Le projet d’EIP-8130 considère toujours la portabilité comme une priorité majeure. Il indique que les comptes peuvent fonctionner sur des chaînes EVM ne prenant pas en charge le type de transaction 8130 en utilisant ERC-4337 ou un autre mécanisme de transport. Il exige également que les chaînes conformes acceptent un ensemble partagé d’authentificateurs canoniques.
La séparation signalée ne rendrait donc pas nécessairement un compte 8130 inutilisable sur une autre chaîne EVM. Toutefois, elle mettrait fin à l'effort visant à établir un format de transaction natif partagé pour Ethereum et Base si les deux projets avancent séparément. Les wallets et les applications devraient sélectionner les règles de transport et de validation des transactions appropriées pour chaque chaîne.
Chiang a détaillé deux réponses possibles : élargir la coordination des ressources partagées par Ethereum et les Layer 2, ou accepter les différences de protocole et développer des wallets et des applications qui les abstraient pour les utilisateurs. Pour l'instant, le registre officiel des EIP liste les deux conceptions comme des brouillons.