EIP-8141 vs. ERC-4337 : Quelle est la différence ?

La distinction essentielle entre EIP-8141 et ERC-4337 réside dans leur conception. ERC-4337 ajoute une abstraction des comptes autour du système de transactions existant d’Ethereum par le biais de portefeuilles Smart Contract, opération utilisateur (UserOperation), bundlers, un Smart Contract singleton nommé EntryPoint et des contrats paymaster optionnels. À l’inverse, EIP-8141 propose une transaction Frame au niveau du protocole, permettant validation, paiement du Gas, déploiement et exécution via plusieurs frames au sein d’une même transaction.

Les deux protocoles visent des caractéristiques similaires en matière d’abstraction des comptes : transactions sponsorisées, opérations groupées, signatures flexibles, mécanismes de récupération et une expérience utilisateur simplifiée du portefeuille. Ce qui les distingue, c’est le degré d’intégration de ces fonctions dans Ethereum.

Points clés

• ERC-4337 n’exige pas de modification du type de transaction natif d’Ethereum ; EIP-8141 introduit les transactions Frame directement dans le protocole.

• ERC-4337 utilise opération utilisateur (UserOperation), des bundlers, EntryPoint et des contrats paymaster.

• EIP-8141 s’appuie sur VERIFY, SENDER et d’autres frames pour segmenter validation, paiement du Gas, déploiement et exécution.

• Les deux protocoles permettent l’abstraction du Gas, le regroupement des transactions, les signatures alternatives et les transactions sponsorisées.

• EIP-7702 offre une solution de migration pour les comptes détenus en externe existants (EOA) afin d’accéder à des fonctionnalités Smart Contract et peut interagir avec les deux modèles d’abstraction de compte.

EIP-8141 vs. ERC-4337 : abstraction des comptes

ERC-4337 définit explicitement une opération utilisateur (UserOperation) comme une pseudo-transaction. Elle comporte des champs tels que les données d’appel, les limites de Gas, les frais maximum, la signature et les données du contrat paymaster, mais un bundler les regroupe finalement dans une transaction Ethereum standard envoyée à EntryPoint.

EIP-8141 modifie la transaction traditionnelle. Son contenu intègre plusieurs frames, des signatures, des paramètres de frais et une adresse expéditeur, autorisant à chaque frame son propre mode d’exécution et ses propres limites de Gas.

Fonctionnement des portefeuilles Smart Contract ERC-4337

Avec ERC-4337, l’utilisateur crée ou interagit via un contrat Smart Account plutôt que de recourir uniquement à un compte détenu en externe classique.

L’utilisateur signe une opération utilisateur (UserOperation) avec les données d’appel souhaitées. Un bundler collecte les opérations utilisateur (UserOperation) en attente et les soumet au EntryPoint, qui valide chaque compte et coordonne l’exécution. Un contrat paymaster peut sponsoriser le coût du Gas, permettant aux applications de définir des politiques de paiement conditionnel ou d’autoriser un paiement indirect en tokens ERC-20.

Le champ de signature étant interprété par le contrat Smart Account, et non imposé par le consensus Ethereum, ERC-4337 peut supporter les clés de session, les politiques multi-signature, la récupération et des Smart Accounts modulaires.

L’architecture d’abstraction de compte ERC-4337 actuelle offre des capacités avancées de Smart Contract sans nécessité de mise à niveau du protocole.

Impact d’une transaction Frame EIP-8141 sur le modèle

EIP-8141 intègre ces fonctionnalités dans le flux natif de transactions d’Ethereum.

Un frame de validation gère la validation. Un frame sender exécute l’opération souhaitée dans le contexte du sender. Un frame de déploiement installe le code du compte avant validation si besoin, tandis que d’autres frames gèrent le paiement ou la logique post-exécution.

L’opcode APPROVE permet au code de validation de définir un périmètre d’approbation pour l’exécution, le paiement ou les deux. Une fois l’autorisation donnée, les frames restants réalisent les opérations multi-étapes demandées.

La distinction clé entre transaction Frame et ERC-4337 : le protocole lui-même reconnaît ces étapes, sans dépendre d’un pipeline opération utilisateur (UserOperation) séparé.

Paiements et gestion du Gas

Les deux systèmes permettent à des utilisateurs ne détenant pas d’ETH pour chaque transaction de participer.

Dans ERC-4337, un contrat paymaster couvre le Gas et peut récupérer le coût en un autre token. Le fournisseur de portefeuille ou la dApp peut aussi définir des conditions de sponsoring.

Avec EIP-8141, le paiement du Gas s’intègre dans la séquence de validation de la transaction. Un contrat sponsor autorise le paiement tandis que l’expéditeur autorise l’exécution. Le payeur n’a pas besoin d’être l’expéditeur.

EIP-8141 introduit un modèle de Gas plus explicite. Chaque frame dispose de ses propres limites de Gas pour l’exécution et l’état, la transaction étant limitée par son coût maximal. Le Gas non utilisé d’un frame n’est pas simplement disponible pour le frame en cours ou les frames restants, ce qui permet de maîtriser le coût de simulation et le travail de validation.

Transactions groupées et opérations multiples

Les Smart Accounts ERC-4337 peuvent déjà regrouper des transactions, permettant à un utilisateur d’effectuer plusieurs opérations avec une seule action.

EIP-8141 rend ce regroupement plus explicite grâce à plusieurs frames. Un lot atomique regroupe les actions successives pour qu’elles aboutissent ou échouent ensemble. Si un frame est annulé, toutes les opérations du lot sont annulées.

Par exemple, une approbation de token et un swap peuvent être traités comme une séquence tout ou rien, évitant une approbation non utilisée si le swap échoue.

Ce traitement natif des opérations multi-étapes vise à simplifier la conception des Smart Accounts avec EIP-8141.

EIP-7702 et la migration des comptes externes

EIP-7702 permet à un compte détenu en externe (EOA) de déléguer l’exécution à un code Smart Contract tout en conservant son adresse. Cela crée un pont entre les comptes classiques et les fonctionnalités Smart Account.

ERC-4337 peut utiliser des comptes activés EIP-7702, évitant à l’utilisateur de migrer vers une nouvelle adresse de Smart Contract.

EIP-8141 va plus loin avec le code par défaut, qui donne au compte un comportement transaction Frame, même sans stockage ou code déployé. Un frame de déploiement peut installer ou déléguer du code selon les besoins.

EIP-7702, ERC-4337 et EIP-8141 s’articulent donc comme des étapes complémentaires dans la migration vers l’abstraction de compte sur Ethereum, et non comme des systèmes exclusifs.

Abstraction native des comptes : changements au niveau du protocole

L’intégration avancée d’EIP-8141 pourrait réduire la dépendance aux bundlers et infrastructures off-chain (hors chaîne) pour la majorité des opérations d’abstraction de compte.

La validation programmable se rapproche ainsi du modèle transactionnel au niveau du consensus. Selon la logique de validation, cela permet des politiques de récupération, l’agrégation future de signatures, des permissions de session ou l’authentification post-quantique.

Le compromis est la complexité. Les nœuds publics doivent évaluer une transaction Frame avant inclusion. EIP-8141 définit un préfixe de validation (validation prefix) contraint, limite l’accès à l’état, plafonne le travail de validation et distingue les contrats paymaster canoniques et non canoniques afin de limiter les risques d’invalidation massive ou de déni de service.

L’architecture globale de l’abstraction de compte sur Ethereum illustre pourquoi l’expérience utilisateur des portefeuilles évolue vers un support protocolaire plus profond.

Conclusion

En résumé, ERC-4337 construit l’abstraction des comptes autour d’Ethereum, alors qu’EIP-8141 l’intègre directement dans Ethereum.

ERC-4337 s’appuie sur des portefeuilles Smart Contract, opération utilisateur (UserOperation), bundlers, EntryPoint et contrats paymaster. EIP-8141 introduit des transactions Frame avec des étapes distinctes pour la vérification, l’expéditeur, le déploiement, le paiement et l’exécution.

ERC-4337 est précieux car il propose une infrastructure mature d’abstraction de compte sans attendre l’évolution du protocole. EIP-8141 pourrait offrir une abstraction du Gas, une validation programmable, des opérations groupées et des transactions sponsorisées de façon plus native et moins dépendante d’un pipeline transactionnel séparé.

Questions fréquentes

EIP-8141 remplace-t-il ERC-4337 ?

Non. ERC-4337 prend déjà en charge des Smart Accounts déployés et une infrastructure établie. EIP-8141 modifie les capacités natives d’Ethereum et les portefeuilles peuvent continuer à utiliser les composants ERC-4337 selon leur utilité.

EIP-8141 nécessite-t-il un EntryPoint ?

Non, aucun EntryPoint singleton n’est requis pour le flux principal des transactions Frame. Validation et exécution sont directement représentées par les frames, sans passer par des opérations utilisateur (UserOperation) routées par EntryPoint.

Les deux systèmes permettent-ils des paiements de Gas sponsorisés ?

Oui. ERC-4337 utilise des contrats paymaster pour sponsoriser des opérations utilisateur (UserOperation). EIP-8141 permet à la validation de la transaction d’autoriser séparément l’expéditeur et le payeur, permettant à un contrat sponsor de prendre en charge le Gas.

ERC-4337 prend-il en charge les comptes détenus en externe (EOA) existants ?

Oui, notamment grâce à EIP-7702. Un compte détenu en externe (EOA) peut déléguer des fonctionnalités Smart Contract tout en conservant son adresse, limitant le besoin de migration complète.

Pourquoi EIP-8141 est-il qualifié d’abstraction native des comptes ?

Parce que validation, autorisation de paiement, déploiement et exécution sont intégrés dans un nouveau format de transaction Ethereum, plutôt que dans une infrastructure opération utilisateur (UserOperation) externe.

Ce contenu est fourni exclusivement à des fins éducatives. Les standards Ethereum, les évolutions du protocole, les portefeuilles et les spécifications EIP sont susceptibles de changer.