IOBC Capital : L'abstraction des comptes Ethereum et ERC-4337
TechFlow SélectionTechFlow Sélection
IOBC Capital : L'abstraction des comptes Ethereum et ERC-4337
Alors qu'il est désormais acquis qu'Ethereum se concentre sur le développement des couches 2, les plans ultérieurs de Vitalik pour la mise à niveau d'Ethereum commencent à s'orienter vers l'abstraction des comptes.
Dédié à des analyses Web3 approfondies
Auteur : Madoka Kaname, IOBC Capital
Il existe deux types de comptes dans le système Ethereum :
-
Le premier type est le compte contrôlé par clé externe (externally-owned account, EOA), comme les comptes présents dans nos portefeuilles. Ces comptes possèdent chacun un solde. Le propriétaire peut créer et signer une transaction pour envoyer un message depuis son propre compte ;
-
Le second type est le compte contrat (contract account), contrôlé par du code déployé sur la blockchain. Ce code, exécuté par la machine virtuelle Ethereum (EVM), réside dans ce qu’on appelle parfois un « portefeuille intelligent ». Lorsqu’un compte contrat reçoit un message, son code interne s’active et lui permet de lire ou écrire dans sa mémoire de stockage, ou encore de créer de nouveaux contrats.
Selon le protocole actuel d’Ethereum, seuls les comptes externes peuvent initier des transactions, et seul le propriétaire d’un compte peut modifier l’état de ce dernier.
Qu’est-ce que l’abstraction des comptes ?
L’abstraction des comptes vise à améliorer ces deux types de comptes en brouillant leurs distinctions, pour aboutir à un type universel de compte intégrant une logique complexe, doté à la fois des fonctionnalités d’un compte contrat et d’un compte contrôlé par clé externe.
Cela revient à définir un compte externe selon le format d’un contrat, permettant aux utilisateurs d’intégrer dans leur portefeuille intelligent toute logique de validation souhaitée. Un compte contrôlé par clé peut ainsi bénéficier du soutien d’un code informatique.
Les différentes propositions d’abstraction des comptes
L’abstraction des comptes a toujours été une vision centrale au sein de la communauté des développeurs Ethereum. Diverses propositions ont été avancées, telles que EIP-86, EIP-2938, etc.
EIP-86 prépare techniquement le terrain pour l’abstraction des comptes. Il définit un nouveau type de compte permettant aux utilisateurs de créer des comptes basés sur des contrats intelligents.
Le protocole Ethereum exige actuellement que toutes les opérations soient encapsulées dans des transactions émanant d’un compte externe (EOA) sécurisé par ECDSA. Chaque action utilisateur doit donc être emballée dans une transaction provenant d’un EOA, ce qui entraîne un coût fixe de 21 000 gas. L’utilisateur doit posséder des ETH dans un EOA séparé pour payer les frais de gaz.
EIP-86 proposait un nouveau type de transaction destiné à l’abstraction des comptes. Contrairement aux transactions traditionnelles qui nécessitent un EOA comme expéditeur, ces nouvelles transactions n’auraient pas d’expéditeur défini. Cependant, cette approche compromettait l’unicité du hachage des transactions. Initialement prévu pour la mise à jour Metropolis, EIP-86 a été repoussé en raison de ces problèmes techniques.
EIP-2938 propose une solution d’abstraction des comptes en modifiant partiellement le protocole Ethereum afin de permettre aux comptes contrats d’initier des transactions, tout comme les EOA. Toutefois, cette proposition nécessitant des changements au niveau de la couche consensus, elle n’a pas obtenu un large soutien.
Une nouvelle proposition ultérieure, le protocole ERC-4337, tente d’atteindre un résultat similaire à EIP-2938 sans modifier le protocole de consensus. Cette méthode, plus sûre, suscite désormais davantage d’intérêt au sein de la communauté.
Comment fonctionne ERC-4337 ?
ERC-4337 ne cherche pas à modifier le consensus du protocole, mais recrée plutôt la fonctionnalité du mempool au sein du système.
L’utilisateur envoie un objet appelé opération utilisateur (UserOperation), contenant son intention, sa signature et d’autres données.
Les opérations utilisateur sont stockées dans un mempool dédié. Les nœuds connectés à ce mempool effectuent une validation spécifique ERC-4337 afin de filtrer les opérations et garantir qu’ils ne traitent que celles qui paient des frais.
Les mineurs ou les services de regroupement comme Flashbots rassemblent ensuite ces opérations utilisateur, les regroupent en une seule transaction groupée (bundle transaction) et l’intègrent à un bloc Ethereum. Le regroupeur paie les frais de gaz à la place de l’utilisateur, puis se rembourse en percevant les frais payés par chaque UserOperation individuelle. Le choix des opérations à inclure suit une logique de priorité basée sur les frais perçus.
L’objet UserOperation ressemble à une transaction, mais il s’agit d’une structure codée ABI comprenant les champs suivants :
1. Expéditeur : le portefeuille effectuant l’opération ;
2. Nonce et signature : paramètres transmis à la fonction de validation du portefeuille afin qu’il puisse vérifier l’opération ;
3. initCode : code d’initialisation utilisé pour créer le portefeuille s’il n’existe pas encore ;
4. callData : données utilisées pour exécuter l’appel aux étapes finales dans le portefeuille.
Chaque portefeuille est un contrat intelligent qui doit implémenter deux fonctions :
1. validateUserOp : prend une UserOperation en entrée. Cette fonction doit valider la signature et le nonce inclus dans l’opération. En cas de succès, elle paie les frais et incrémente le nonce. En cas d’échec, elle lève une exception ;
2. Fonction d’exécution de l’opération : analyse les callData pour traduire l’opération en une ou plusieurs instructions exécutables par le portefeuille.
Les changements apportés par ERC-4337
Si cette proposition est largement adoptée, la validation des signatures sera transférée à la machine virtuelle Ethereum (EVM). La fonction validateUserOp permettra d’intégrer une logique de validation arbitraire pour les signatures et les nonces, rendant ainsi cette validation bien plus flexible.
Cette flexibilité permettra d’utiliser de nouveaux outils cryptographiques lors de la signature des transactions, offrant aux portefeuilles de nouvelles fonctionnalités, telles que :
-
Signatures multi-signatures ;
-
Récupération sociale ;
-
Algorithmes de signature plus efficaces et plus simples (par exemple Schnorr, BLS) ;
-
Algorithmes de signature résistants aux ordinateurs quantiques (par exemple Lamport, Winternitz) ;
-
Portefeuilles mis à jour.
Ce schéma ouvre également la voie à diverses méthodes de gestion des autorisations de transaction, notamment le paiement des frais de gaz via un contrat intelligent.
Actuellement, les frais de gaz (gas fee) pour interagir sur Ethereum doivent être payés en ETH directement depuis le portefeuille externe. Si votre portefeuille ne contient que des jetons ERC-20 sans ETH, vous ne pouvez pas transférer ces jetons. Avec ERC-4337, les utilisateurs pourront payer les frais avec des jetons ERC-20. Un nœud mineur agira alors comme intermédiaire, payant les frais en ETH sur la chaîne en échange des jetons ERC-20 de l’utilisateur.
Une fois l’abstraction mise en œuvre, la méthode unique consistant à signer et diffuser une transaction depuis un compte externe ne sera plus la seule façon d’initier une transaction. Cela rend possible l’utilisation d’Ethereum comme relais pour des métatransactions. À l’heure actuelle, de nombreuses applications reposent sur des relais pour publier les transactions des utilisateurs, moyennant des frais. Si les portefeuilles peuvent intégrer des contrats plus complexes, certains relais deviendront inutiles, évitant ainsi de payer des frais supplémentaires.
Bien qu’apportant de nombreux avantages, cette nouvelle approche soulève aussi certaines difficultés.
La principale difficulté concerne le coût élevé en gaz : une opération ERC-4337 de base consomme environ 42 000 gas, contre 21 000 gas pour une transaction classique. Les raisons sont les suivantes :
1. Coût important lié aux lectures/écritures individuelles en stockage, coûts qui, dans le cas d’un EOA, sont regroupés dans un forfait de 21 000 gas :
(1) Modification du slot de stockage contenant la clé publique + nonce (~5 000) ;
(2) Coût des données d’appel de l’opération utilisateur (~4 500, réductible à ~2 500 grâce à la compression) ;
(3) ECRECOVER (~3 000) ;
(4) Première accès au portefeuille lui-même (~2 600) ;
(5) Premier accès au compte du destinataire (~2 600) ;
(6) Transfert d’ETH vers le compte du destinataire (~9 000) ;
(7) Modification du stockage pour payer les frais (~5 000) ;
(8) Accès au slot de stockage contenant le proxy (~2 100), puis accès au proxy lui-même (~2 600) ;
2. Outre ces coûts liés au stockage, le contrat doit exécuter une « logique métier » (décodage de UserOperation, hachage, manipulation de variables, etc.) ;
3. Des frais de gaz sont nécessaires pour les journaux (logs), que les EOA ne produisent pas ;
4. Coût unique de création du contrat (~32 000 gas, plus 200 gas par octet de code dans le proxy, plus 20 000 gas pour configurer l’adresse du proxy).
En résumé, chaque étape d’un compte abstrait est calculée individuellement, consommant davantage de ressources et augmentant les coûts associés.
Heureusement, cette situation n’est pas sans solution.
Les Rollups, excellents en compression de données, s’accordent naturellement bien avec les schémas complexes d’abstraction des comptes.
Dans la dernière proposition de Vitalik, le traitement des données générées par l’abstraction des comptes via la couche 2 (layer 2) est envisagé. L’amélioration consiste à regrouper en lots des fonctions auparavant exécutées étape par étape, tout en garantissant la validité des transactions via la technologie SNARK.
En combinant ERC-4337 avec la technologie Rollup, il devient possible de compresser les données et de réduire les coûts en gaz, exploitant ainsi pleinement les avantages de l’abstraction des comptes.
Conclusion
Alors qu’Ethereum concentre désormais ses efforts sur le développement de la couche 2, Vitalik oriente progressivement les mises à jour futures vers l’abstraction des comptes.
Les dernières propositions illustrent clairement la voie technique Rollup + abstraction des comptes. De nombreux fournisseurs de Rollup ont déjà lancé de nouvelles versions compatibles avec l’abstraction des comptes.
En juin dernier, zkSync a publié sa mise à jour V2, ajoutant la fonctionnalité d’« abstraction des comptes » et renforçant la compatibilité avec l’EVM d’Ethereum.
En octobre, ERC-4337 a publié une nouvelle version intégrant la fonction d’agrégation de signatures via l’algorithme BLS. Cette agrégation permet aux validateurs et aux soumissionnaires de lots de regrouper également les signatures (par exemple BLS, SNARKs), réduisant considérablement les données sur la chaîne et abaissant ainsi les coûts de données pour les rollups.
Nous avons donc de bonnes raisons de croire que les changements induits par l’abstraction des comptes recèlent un fort potentiel de croissance pour l’écosystème. Avec le développement des Rollups, les solutions d’abstraction des comptes capables de s’y intégrer devraient rapidement évoluer vers des architectures plus optimisées et plus fines.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@iobc_capital
