Account Abstract : Les signes du passage de l'écosystème sur chaîne au marché acheteur
TechFlow SélectionTechFlow Sélection
Account Abstract : Les signes du passage de l'écosystème sur chaîne au marché acheteur
Cet article présente l'abstraction de compte et l'ERC-4337, puis émet des hypothèses sur l'évolution future de l'infrastructure des comptes Web3 et sur la localisation des points d'entrée du trafic, en se basant sur l'application de l'abstraction de compte et sur le développement des systèmes de comptes Web2.
Dédié à des analyses Web3 approfondiesAuteurs : CloudY, Jam
Les portefeuilles sont une étape indispensable pour accéder au Web3. Depuis longtemps, le modèle UTXO du réseau Bitcoin est comparé au modèle de comptes d’Ethereum, chacun ayant ses forces et faiblesses. Il serait réducteur de dire que l’un est meilleur que l’autre ; il est plus juste de dire qu’ils conviennent mieux à certains cas d’usage.
En réalité, le compte EOA (Externally Owned Account) d’Ethereum utilisé dans ces comparaisons est un produit assez primitif. Plus précisément :
• Le contrôle du compte est centralisé : il repose uniquement sur la signature ou son absence. Que ce soit pour une transaction de 1 dollar ou de 100 millions de dollars, il faut toujours approuver puis signer. Ainsi, la différence entre une autorisation frauduleuse et une transaction normale tient à un seul clic, ce qui rend chaque nouvelle interaction angoissante. Bien que MetaMask permette désormais aux utilisateurs de définir des limites lors de l’approbation de jetons, face à des interactions fréquentes, les utilisateurs préfèrent souvent autoriser immédiatement le montant maximal plutôt que de gaspiller des frais de gaz en approbations multiples. Comparé aux systèmes Web2 qui utilisent l’authentification à deux facteurs (2FA) ou des dispositifs comme les clés U pour sécuriser les transactions importantes, tout en facilitant les petits paiements par reconnaissance faciale ou sans mot de passe, le compte EOA apparaît rigide et peu ergonomique.
• Le seuil élevé des frais de gaz (Gas Fee) écarte de nombreux nouveaux utilisateurs. Ethereum principal ainsi que des couches 2 comme Optimism ou Arbitrum utilisent ETH comme jeton de gaz, ce qui oblige les utilisateurs à convertir leur monnaie fiduciaire en stablecoin USD, puis en ETH, avant de transférer celui-ci vers leur portefeuille. Beaucoup découvrent seulement après avoir déposé des stablecoins qu’ils ont besoin d’ETH pour payer les frais, et doivent alors effectuer une seconde opération d’achat. Pire encore, des blockchains comme BSC, Polygon ou Solana utilisent chacune leur propre jeton de gaz, ce qui constitue un piège classique pour les débutants. En outre, de nombreux utilisateurs n’ont aucune envie de détenir physiquement ces jetons de gaz, mais doivent malgré tout en garder des quantités inutiles dans leurs portefeuilles à cause des besoins d’interaction sur chaîne.
Vitalik était bien conscient de ces difficultés. L’équipe d’Ethereum cherche depuis longtemps à y remédier, et l’abstraction des comptes (Account Abstraction) en est une solution. Cependant, comme il n’est pas possible de modifier le consensus fondamental d’Ethereum, c’est seulement avec la proposition de l’ERC-4337 — un portefeuille intelligent basé sur la couche applicative — que l’abstraction des comptes a véritablement attiré l’attention et est devenue un sujet brûlant.
Cet article présente brièvement l’abstraction des comptes et l’ERC-4337, puis tente de prédire, à partir de l’évolution des applications et de celle des systèmes de comptes Web2, l’avenir du système de comptes Web3 et l’appartenance des entrées de trafic.
Du point de vue de l’écosystème, auparavant, les utilisateurs devaient utiliser un EOA pour effectuer des opérations complexes sur chaîne. Comme l’écosystème actuel reste limité, les protocoles offerts sont restreints et ne répondent pas efficacement aux besoins réels des utilisateurs. L’abstraction des comptes simplifie ces opérations : l’utilisateur fournit simplement une entrée (input), obtient un résultat (output), sans avoir à cliquer constamment ni signer péniblement. On peut dire que le déploiement de l’AA fait passer l’écosystème de la chaîne d’une logique vendeur à une logique acheteur.
Abstraction des comptes (Account Abstraction) et ERC-4337
Que signifie concrètement l’abstraction des comptes (Account Abstraction, ci-après AA) ? Il s’agit d’abstraire les technologies et structures de données sous-jacentes afin de simplifier les opérations pour les utilisateurs et les développeurs. Autrement dit, « ajouter les fonctionnalités d’un compte contractuel (CA) par-dessus un EOA ».
L’ERC-4337 est devenu la norme de base pour l’AA. Il introduit l’UserOperation, une transaction spéciale représentant l’intention de l’utilisateur, permettant à un compte contractuel d’exécuter activement des actions. Ces UserOperations sont gérées par une entité appelée Bundler, qui les simule, valide et les ajoute à un pool de transactions spécial. Ensuite, le contrat EntryPoint vérifie et exécute ces opérations pour concrétiser l’intention de l’utilisateur.
Types de comptes
Ethereum comporte deux types principaux de comptes : les comptes EOA (Externally Owned Account) et les comptes contrats.
Un compte EOA possède une adresse de 20 octets, générée à partir d’une clé privée créée par l’utilisateur et d’une clé publique dérivée via un algorithme de cryptographie elliptique. Son état comprend un nonce (compteur de transactions) et un solde. L’adresse d’un compte contrat est aussi de 20 octets, calculée à partir de l’adresse de l’expéditeur et du nonce de la transaction de création. Son état inclut un nonce, un solde, un hash du code (CodeHash) et un hash de la racine du stockage (StorageRoot), correspondant au hash de la racine de l’arbre Merkle Patricia utilisé pour stocker les données du contrat.
Le type de compte et ses informations d’état sont cruciaux pour les transactions et l’exécution de contrats intelligents sur Ethereum, et constituent la différence fondamentale entre EOA et CA.
Transactions
Une transaction Ethereum contient l’adresse de l’expéditeur et du destinataire, une signature numérique, un nonce, le montant transféré, des données optionnelles, une limite de gaz et les frais associés. Les deux types de comptes engendrent deux modes de communication très différents.
Lors de la signature, les données de la transaction sont hachées puis signées numériquement. Le validateur vérifie la validité de la signature en calculant un point sur la courbe elliptique, sans jamais connaître la clé privée de l’expéditeur — seule la transaction et la clé publique suffisent. La récupération de la clé publique s’effectue grâce à la valeur « v » incluse dans la signature, assurant sécurité et efficacité.
Abstraction des comptes
La structure des transactions et le processus de vérification des signatures sur Ethereum révèlent un fait essentiel : seul un compte EOA, doté d’une paire de clés publique/privée, peut initier une transaction.
Un compte contrat, faute de clé privée, ne peut pas lancer une transaction de lui-même. Il ne réagit qu’en recevant une transaction, exécutant alors automatiquement le code de son contrat intelligent, envoyant éventuellement d’autres transactions ou créant de nouveaux contrats. Ainsi, les portefeuilles populaires comme MetaMask créent tous des comptes EOA. Mais ceux-ci présentent plusieurs défauts : risque de perte de clé privée, algorithmes de signature limités, permissions excessives accordées par signature, et contraintes liées aux frais de gaz.
Un compte contrat peut stocker du code et des données, et exécuter une logique prédéfinie pour résoudre ces problèmes. Toutefois, il ne peut pas initier de transaction seul.
L’abstraction des comptes améliore ces deux modèles, en floutant leurs frontières pour créer un compte universel capable de combiner les fonctions d’un CA et d’un EOA.
ERC-4337
L’ERC-4337 permet d’atteindre l’abstraction des comptes sans modifier la couche de consensus d’Ethereum. C’est devenu la solution retenue. Elle réalise ainsi la vision ultime : traitement hors chaîne, exécution sur chaîne.
• UserOperation
L’ERC-4337 introduit une nouvelle notion, l’UserOperation, pour permettre aux comptes contrats d’initier des actions sans changer le type de transaction fondamental d’Ethereum.
L’UserOperation ressemble à une transaction standard, mais exprime seulement l’intention de l’utilisateur, pas une action directe. Une transaction standard va dans le mempool d’Ethereum, puis est assemblée en bloc par des searchers et builders, et proposée à la blockchain, généralement selon le profit attendu. En revanche, l’UserOperation n’est pas une vraie transaction. L’ERC-4337 crée donc un nouveau mempool et introduit un rôle, le Bundler, qui exécute de manière décentralisée ces UserOperations. Cette innovation permet de traiter l’intention de l’utilisateur sans passer par le flux habituel.
• Bundler
Le Bundler commence par vérifier la validité de l’UserOperation, puis la simule pour confirmer la signature. Si la simulation réussit, l’opération est ajoutée au mempool dédié, en attente d’exécution sur chaîne. Pour garantir la cohérence entre simulation et exécution réelle, l’UserOperation ne peut accéder qu’à des données stables, notamment celles liées à l’adresse de l’envoyeur. Le Bundler peut choisir quelles opérations regrouper, priorisant celles qui offrent des frais plus élevés. Finalement, il envoie le lot d’opérations valides au contrat EntryPoint pour exécution.
• EntryPoint
EntryPoint est un contrat singleton sur Ethereum chargé d’exécuter les UserOperations. Il dispose de deux fonctions principales : handleOps et handleAggregatedOps. Toutes deux commencent par valider l’UserOperation (vérification du compte, de la signature et du paiement des frais), puis exécutent l’action en appelant le code du contrat cible avec les données fournies. Différents protocoles de portefeuille intelligent peuvent implémenter différentes méthodes d’analyse et d’exécution.
• Données
Selon le rapport semestriel de SixdegreeLab sur l’ERC-4337 :
-
Depuis le déploiement du contrat ERC-4337, plus de 687 000 portefeuilles AA ont été créés sur chaîne, avec plus de 2 millions d’appels à UserOps. Cependant, 88,24 % des portefeuilles AA ont été utilisés moins de 5 fois, principalement pour des transferts simples ou du minting de NFT.
-
Parmi 15 000 Bundlers, Pimlico détient 43,48 % du marché, tandis qu’Alchemy a généré environ 20 000 dollars, un record historique.
-
97,18 % des transactions groupées ne contiennent qu’un seul UserOp, ce qui signifie que 90 % des Bundlers ne peuvent pas être rentables.
-
117 Paymaster ont remboursé au total 465 000 dollars de frais de gaz pour 19 millions d’UserOps, dont 43,45 % par Pimlico.
-
ZeroDev domine le marché des Wallet Factory, ayant déployé 62,63 % des comptes.
-
La méthode la plus courante pour construire un portefeuille AA est LEGO, combinant différents services tiers (Paymaster, Wallet Factory, Bundler).
Ces données montrent que l’adoption de l’ERC-4337 a encore un fort potentiel de croissance, et que la construction de l’infrastructure en est à peine à ses débuts. L’avenir de l’AA est donc plein de possibilités. Avec l’émergence des couches 2 et des applications sociales, l’utilisation des portefeuilles AA devrait connaître une forte croissance.
Évolutions futures de l’abstraction des comptes
Après avoir compris les bases de l’abstraction des comptes et l’architecture de l’ERC-4337, explorons maintenant ses pistes d’évolution. Nous ne reviendrons pas sur les fonctionnalités élémentaires comme l’absence de clé privée ou la prise en charge sans gaz, mais chercherons davantage de potentialités dans ses composants :
Architecture
Abstraction native des comptes
L’ERC-4337 n’est qu’une solution de niveau applicatif, adoptée parce qu’Ethereum ne peut pas modifier son consensus de base. Bien qu’il popularise l’idée d’abstraction, il repose encore sur des contrats pour interagir. Les coûts supplémentaires en gaz, la concurrence d’autres ERC, ou l’interdiction par certains dApps d’interagir avec des comptes contrats, freinent son expansion.
L’abstraction native des comptes, surtout au niveau des couches 2, devient alors cruciale. Actuellement, seules Starknet et ZKSync supportent cette abstraction native. Comme illustré ci-dessous, ces solutions n’ont pas besoin de Bundler ni de Paymaster. Sur Starknet, le Séquenceur ordonne les transactions, paie le gaz et exécute. Sur ZKSync, l’Operator fait de même, puis invoque le bootloader.
DeBank Chain, annoncé comme basé sur OP Stack, prévoit également d’intégrer nativement un système similaire, bien que son architecture précise reste à découvrir à son lancement.
Portefeuilles contrats NFT
Les portefeuilles contrats NFT sont une autre solution d’abstraction au niveau applicatif, semblable à l’ERC-4337. Ils permettent à un EOA d’acquérir les fonctionnalités d’un CA via un NFT, sans passer par un Bundler ou EntryPoint. Deux approches dominent : ERC-6551 et le protocole A3S.
ERC-6551 permet à un utilisateur d’utiliser un NFT ERC-721 dans son portefeuille EOA comme contrôleur d’un ou plusieurs nouveaux portefeuilles intelligents. Ainsi, sans modifier le code du NFT, on lui associe un ou plusieurs comptes contrats via un « contrat externe ». Cette approche fusionne NFT existants et abstraction de compte, enrichissant les cas d’usage des NFT tout en vulgarisant l’AA.
Le protocole A3S, en revanche, utilise directement le contrat intelligent du NFT comme portefeuille. Les actifs sont donc directement sur le contrat du NFT et suivent automatiquement son transfert de propriété. Pas besoin de contrat externe comme dans ERC-6551 : chemin plus court, mais incompatible avec les NFT existants.
Pour unifier les adresses multi-chaînes, les deux solutions utilisent une valeur de sel (salt) pour obtenir la même adresse sur différentes blockchains compatibles EVM, résolvant ainsi le problème d’adresses chaotiques. Ce désordre avait causé la perte de 20 millions d’OP par Wintermute lors de transferts vers des adresses multisignatures sur différentes chaînes.
Modularité et abstraction multi-chaîne
La modularité de l’abstraction des comptes vise à réduire au minimum les coûts de développement et de maintenance, comme OP Stack, permettant aux développeurs de se concentrer sur le produit plutôt que sur l’infrastructure. L’écosystème modulaire repose sur cette modularité, qui doit donc offrir :
• La composable entre modules (l’EIP-6900 tente d’établir une norme)
• La diversité fonctionnelle (schémas de signature, confidentialité, résistance au MEV, rampes d’entrée/sortie, Intent, etc.)
• La sécurité (normes unifiées évitant les conflits de stockage)
• Abstraction multi-chaîne (Vitalik propose un contrat unique de gestion de clés pour coordonner les comptes contrats sur plusieurs chaînes)
Nous avons vu que le salt permet d’avoir des adresses identiques sur plusieurs chaînes, mais ce n’est qu’un premier pas. L’essentiel est que l’utilisateur ne perçoive plus les franchissements de chaînes — l’abstraction multi-chaîne, étape clé tant pour la modularité que pour l’AA.
Validation des signatures
Comme mentionné, toute transaction sur Ethereum dépend aujourd’hui d’un EOA qui paie en ETH. En outre, l’EOA ne peut utiliser que la signature ECDSA, rendant son usage fastidieux, limité, et exposé au risque de fuite de clé privée. Le jour où l’ordinateur quantique arrivera, les comptes EOA d’Ethereum seront vulnérables.
Algorithmes de signature
Des solutions existent déjà : signatures multiples ou récupération sociale via contrat intelligent (Gnosis Safe, Argent), ou « abstraction de signature » permettant des interactions libres après une autorisation initiale (Lens Protocol). Mais selon le principe « Not your keys, not your coins », il faut aussi regarder du côté des algorithmes eux-mêmes :
• Agrégation de signatures
Utiliser Schnorr ou BLS pour des signatures plus efficaces et compactes. Cela permet non seulement des multisignatures de base, mais aussi de réduire les frais de gaz. Chaque méthode a ses limites : besoin de tours de communication supplémentaires, inefficacité pour m et n élevés, temps de vérification important, etc.
• Signatures résistantes au quantique
Utiliser Lamport ou W-OTS, signatures à usage unique, pour empêcher qu’un attaquant utilisant un ordinateur quantique ne forge des messages à partir de parties publiques de clés privées.
UserOperation
ERC-7521 centré sur l’intention (Intent Centric)
En comparant l’abstraction des comptes, notamment l’ERC-4337, à une architecture centrée sur l’intention, on voit que le Bundler et le Solver peuvent être une seule et même entité. L’intention de l’utilisateur (« UserOperation ») peut être formulée par le Bundler, qui propose un chemin de résolution, le soumet à l’utilisateur via le contrat EntryPoint pour validation, évitant ainsi la malveillance, puis exécute le chemin validé.
La combinaison de l’AA et de l’intention permettra une abstraction simultanée du compte et de l’interaction, offrant une expérience supérieure au Web2.
L’ensemble du processus peut utiliser la preuve ZK pour assurer des paiements privés. Cela permet de prouver la validité d’une transaction sans révéler l’adresse réelle de l’expéditeur, et de regrouper plusieurs transactions en une seule preuve, réduisant ainsi la charge de calcul et améliorant considérablement l’extensibilité — bref, réduction des coûts et gain d’efficacité. Des entreprises soumises à la régulation peuvent aussi rendre certaines transactions transparentes pour les autorités, sans compromettre la confidentialité globale.
Bundler
MEV du Bundler et concurrence entre Bundlers
Le MEV du Bundler et la concurrence entre Bundlers résultent d’une infrastructure insuffisante. Le MEV provient du rôle du Bundler, similaire à celui du Searcher : il peut tirer profit en changeant l’ordre des UserOperations. La concurrence apparaît quand plusieurs Bundlers tentent de traiter la même UserOperation — comme la « guerre de gaz » entre Searchers. Celui dont la transaction n’est pas incluse dans la chaîne perd ses frais de gaz.
Ces problèmes peuvent s’inspirer d’infrastructures existantes, comme MEV-Boost, en créant des canaux de communication entre Bundlers et entre Bundlers et Block Builders. Etherspot développe un réseau pair-à-pair pour le mempool de l’AA : les UserOperations en attente circulent dans ce réseau, et sont marquées comme traitées dès qu’elles sont incluses, évitant ainsi les doublons.
Paymaster
Entrée/sortie via Paymaster
Le Paymaster peut payer les frais de gaz pour l’utilisateur, en échange de tout jeton ou monnaie fiduciaire. Couplé à un prestataire de paiement, il peut offrir un service d’entrée/sortie complet.
L’équipe Visa a déployé deux contrats expérimentaux Visa Paymaster sur le testnet Goerli d’Ethereum : l’un explore le paiement des frais avec d’autres jetons (y compris des stablecoins USD), l’autre teste le parrainage direct des frais. Intégrer le Paymaster à des jetons ERC-20 nécessite une source externe ou un oracle pour fixer le prix, et vérifier que le contrat a bien le droit de facturer l’utilisateur. Avec un tel système mature, l’accès direct à une carte Visa pour payer en monnaie fiduciaire, ou une conversion en temps réel avec des jetons ERC-20, rendrait l’entrée dans le Web3 beaucoup plus fluide pour les utilisateurs Web2.
Évolution du système de comptes Web3 et futurs points d’entrée
L’évolution des points d’entrée du trafic Web2 et de ses systèmes de comptes reflète la croissance rapide de l’internet et l’évolution des besoins des utilisateurs.
Au départ, les utilisateurs accédaient à Internet via des portails web, choisissant librement parmi les ressources listées. Puis les moteurs de recherche ont permis de trouver des résultats par mots-clés, analysant les URL pour fournir des réponses pertinentes. L’ère Web2 a vu l’essor des plateformes sociales, sur PC et mobile. Outre la recherche active, les utilisateurs pouvaient être exposés passivement via des médias PC ou accéder activement via des plateformes autonomes. Ce parcours a connu deux transitions de passif à actif, et un processus de décentralisation de l’information.
Le système de comptes Web2 a aussi évolué : des SMS/MMS avec numéro comme identifiant, aux comptes variés (QQ, WeChat, blogs, microblogs) offrant des fonctions riches et une identité personnelle distincte. Ces plateformes ont introduit profils et listes de contacts, étendant l’identité utilisateur d’une simple URL à des ID complexes et des graphes sociaux.
Avec le progrès du réseau et du matériel, deux stratégies d’écosystème se sont imposées :
-
« iOS + Apple Pay + Apple Store » et « WeChat Pay + mini-programmes » ont d’abord établi un avantage en trafic via leurs systèmes de compte et de paiement, puis ouvert un espace aux développeurs externes, retenant ainsi les utilisateurs dans leur écosystème.
-
« Taobao + Alipay » et « Douyin + Douyin Pay » ont développé leurs propres systèmes de compte et de paiement à partir du trafic généré par une application phare, puis intégré d’autres applications pour former un système unifié.
Ces deux modèles sont efficaces et dominants. WeChat satisfait la plupart des besoins dans une seule app, tandis qu’Alipay est accessible dans de nombreuses applications.
En somme, les entrées Web2 visaient à donner plus d’autonomie et de décentralisation aux utilisateurs, tandis que les systèmes de comptes sont passés du simple au riche et diversifié, évoluant via deux stratégies.
Système de comptes
L’évolution du système de comptes Web3 conserve des traces du Web2, tout en empruntant un chemin unique.
Le Web3 a vu naître plusieurs types de comptes : portefeuilles plug-in comme MetaMask, portefeuilles logiciels comme Math et Trust, « plateformes d’exploitation » comme dAppOS et Gnosis Safe, ou encore portefeuilles intégrés dans des dApps comme UniPass ou dans des exchanges comme OKX Web3 Wallet.
-
Les portefeuilles plug-in comme MetaMask sont comme les premiers SMS : ils répondent aux besoins de base, fonctionnels partout, mais trop limités.
-
Les portefeuilles logiciels comme Math ou Trust ajoutent des fonctionnalités pour améliorer l’expérience : gestion multi-compte, modules sociaux, applications annexes — comme QQ ou WeChat.
-
Les « plateformes » comme dAppOS ou Gnosis Safe vont plus loin, transformant les fonctions de base en un système avancé, semblable à Apple ou WeChat, développant autour d’elles des « mini-applications » pour enrichir l’écosystème.
-
Les portefeuilles intégrés comme UniPass ou OKX Web3 Wallet suivent la voie d’Alipay ou Douyin Pay : ils tirent parti du trafic d’applications phares pour développer leur base, formant des alliances pour construire un écosystème.
Points d’entrée du trafic
Nous avions écrit dans « Entrées de trafic Web3 » :
« Selon le parcours d’entrée dans le Web3, on peut distinguer deux grandes catégories :
-
Systèmes de comptes (entrées/sorties et gestion des fonds) : exchanges centralisés, projets indépendants d’entrée/sortie, agrégateurs, distributeurs ATM, cartes bancaires crypto, OTC ; EOA, CA, portefeuilles MPC et abstraction de comptes (AA).
-
Applications Web3 (outils, social, divertissement) : DEX, marchés NFT, domaines, DeSoc, marchés de droits d’auteur, GameFi, X to Earn. »
Nous maintenons ce point de vue, mais selon la section précédente, toutes ces entrées peuvent faire partie d’un portefeuille AA. Elles divisent inversement l’adoption de l’AA en deux voies : celle du compte et celle de l’application — l’utilisateur obtient-il d’abord un compte, puis interagit-il, ou interagit-il d’abord, puis adopte-t-il un compte ?
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
