L’échec des négociations relatives à l’abstraction de compte conjoint (AA) entre les développeurs principaux d’Ethereum et les ingénieurs de Base marque un découplage architectural significatif entre les modèles d’exécution de la couche 1 (L1) et de la couche 2 (L2).
Comme l’a confirmé le chercheur d’Ethlabs Derek Chiang, des discussions visant à fusionner l’EIP-8141 (Frame Transactions) d’Ethereum et l’EIP-8130 de Base en une seule norme de transaction inter-chaînes ont finalement échoué, en raison d’objectifs réseau fondamentalement incompatibles.
Le conflit central : EIP-8141 vs. EIP-8130
Les deux initiatives visent à intégrer directement dans la couche de base des capacités natives de portefeuille de contrats intelligents — telles que les transactions sans frais (gasless), les opérations groupées, la rotation des clés et l’authentification par passeport (passkey). Toutefois, leurs approches techniques sous-jacentes divergent :
L’approche d’Ethereum (EIP-8141 / Frame Transactions) : les Frame Transactions découpent l’exécution en appels de contrats dynamiques et programmables (« frames »), en traitant séparément la validation, le sponsoring du gaz et la logique utilisateur. Cette conception privilégie la résistance à la censure, la flexibilité maximale au niveau EVM, des preuves de confidentialité avancées et des garanties de sécurité post-quantique nécessaires au règlement sur la L1.
L’approche de Base (EIP-8130 / Keystore) : rédigée par des ingénieurs de Coinbase/Base, l’EIP-8130 s’appuie sur un système de Keystore on-chain associé à des authentificateurs pré-déclarés. Ce modèle fournit une surcharge de validation prévisible, adaptée aux environnements à haut débit, à l’exécution L2 sur mesure et aux exigences de conformité en entreprise.
Tableau Fonction / ObjectifEthereum (EIP-8141)Base (EIP-8130)
Objectif principalRésistance à la censure, confidentialité, préparation quantiqueHaute capacité de débit, sponsoring du gaz, conformité
Modèle de transactionExécution dynamique multi-frames sur des appelsKeystore on-chain et authentificateurs explicites
Surcharge de validationDynamique (plus flexible, coût de calcul L2 plus élevé)Statique/Prévisible (optimisé pour les séquenceurs)
Priorité de mise en œuvrePriorité « doit être livré » pour l’upgrade HegotáDéploiement natif sur les devnets Base / OP Stack
Différences techniques clés.
Comme l’a confirmé le chercheur d’Ethlabs Derek Chiang, des discussions visant à fusionner l’EIP-8141 (Frame Transactions) d’Ethereum et l’EIP-8130 de Base en une seule norme de transaction inter-chaînes ont finalement échoué, en raison d’objectifs réseau fondamentalement incompatibles.
Le conflit central : EIP-8141 vs. EIP-8130
Les deux initiatives visent à intégrer directement dans la couche de base des capacités natives de portefeuille de contrats intelligents — telles que les transactions sans frais (gasless), les opérations groupées, la rotation des clés et l’authentification par passeport (passkey). Toutefois, leurs approches techniques sous-jacentes divergent :
L’approche d’Ethereum (EIP-8141 / Frame Transactions) : les Frame Transactions découpent l’exécution en appels de contrats dynamiques et programmables (« frames »), en traitant séparément la validation, le sponsoring du gaz et la logique utilisateur. Cette conception privilégie la résistance à la censure, la flexibilité maximale au niveau EVM, des preuves de confidentialité avancées et des garanties de sécurité post-quantique nécessaires au règlement sur la L1.
L’approche de Base (EIP-8130 / Keystore) : rédigée par des ingénieurs de Coinbase/Base, l’EIP-8130 s’appuie sur un système de Keystore on-chain associé à des authentificateurs pré-déclarés. Ce modèle fournit une surcharge de validation prévisible, adaptée aux environnements à haut débit, à l’exécution L2 sur mesure et aux exigences de conformité en entreprise.
Tableau Fonction / ObjectifEthereum (EIP-8141)Base (EIP-8130)
Objectif principalRésistance à la censure, confidentialité, préparation quantiqueHaute capacité de débit, sponsoring du gaz, conformité
Modèle de transactionExécution dynamique multi-frames sur des appelsKeystore on-chain et authentificateurs explicites
Surcharge de validationDynamique (plus flexible, coût de calcul L2 plus élevé)Statique/Prévisible (optimisé pour les séquenceurs)
Priorité de mise en œuvrePriorité « doit être livré » pour l’upgrade HegotáDéploiement natif sur les devnets Base / OP Stack
Différences techniques clés.
