Qu'est-ce que l'account abstraction (ERC-4337) ?

Si vous avez passé un peu de temps autour d'Ethereum ces dernières années, vous avez probablement entendu l'expression « account abstraction » — souvent associée au nom de code ERC-4337. Cela semble académique, mais l'idée sous-jacente est véritablement pratique : votre portefeuille Ethereum devrait se comporter comme un petit logiciel personnalisable, et non comme une simple clé privée avec une interface à prendre ou à laisser.

Dans cet article, nous expliquerons ce que l'ERC-4337 change réellement, les quatre nouveaux termes de jargon qu'il introduit (UserOperation, EntryPoint, bundler, paymaster), ce qu'il permet en pratique, et comment il se rapporte à l'approche multisig propre à SSP. Aucune connaissance préalable des smart contracts n'est requise — juste de la curiosité pour le fonctionnement interne des portefeuilles crypto.

Le problème que l'ERC-4337 cherchait à résoudre

Avant l'account abstraction, chaque portefeuille Ethereum était ce qu'on appelle un compte externe — un EOA (externally-owned account). Un EOA est d'une simplicité redoutable : une clé privée contrôle une adresse, et chaque action effectuée par cette adresse doit être signée par exactement cette clé.

Cette simplicité a ses inconvénients tranchants :

• Aucune récupération. Perdez la clé, perdez les fonds. Il n'y a pas de lien « mot de passe oublié », pas de contact de confiance qui puisse se porter garant pour vous, pas de déverrouillage temporisé. La clé est le compte.
• Aucun regroupement. Vous voulez approuver un token puis l'échanger ? Cela fait deux transactions distinctes, deux signatures distinctes, deux paiements de gas distincts. Aucun moyen de dire « fais les deux ensemble ou aucun des deux ».
• Aucun multisig natif. Si vous vouliez plusieurs signataires, vous deviez déployer un contrat (comme un Safe, anciennement Gnosis Safe), puis demander à un EOA d'envoyer des transactions vers ce contrat. Le contrat était multisig, mais le compte qui interagissait avec le monde était toujours un EOA mono-clé en dessous. L'expérience utilisateur restait toujours de seconde classe par rapport à un portefeuille classique.
• Le gas toujours payé en ETH, toujours payé par l'expéditeur. Aucune dApp ne pouvait payer votre gas. Pas de paiement de gas en USDC. Aucune exception.

Les développeurs contournaient ces limites depuis des années avec des patterns de contrats élaborés. L'ERC-4337 leur a enfin offert une voie standardisée — sans nécessiter le moindre changement au protocole de base d'Ethereum.

Ce que l'ERC-4337 introduit

L'ERC-4337 ne change pas le fonctionnement d'Ethereum au niveau du protocole — c'est là son tour de force. À la place, il définit quatre nouveaux rôles qui, ensemble, simulent des « portefeuilles smart contract en tant que citoyens de première classe » entièrement dans l'espace utilisateur. Une fois que vous connaissez ces quatre mots, tout le standard prend son sens.

UserOperation. Il s'agit du nouvel objet « d'intention signée » qui remplace la transaction brute pour un portefeuille AA. Là où un EOA produit une transaction signée par sa clé unique, un portefeuille AA produit une UserOperation — une requête structurée qui dit « ce compte veut faire X, voici l'autorisation, voici comment payer ». Une UserOperation pourrait dire « transférer 100 USDC à Alice, autorisé par les signatures de ces deux appareils, et la dApp couvrira le gas ».

Contrat EntryPoint. Un smart contract unique, canonique et audité, déployé sur Ethereum, qui sait recevoir les UserOperations, les vérifier selon les règles du portefeuille AA dont elles proviennent, et exécuter les actions qui en résultent. Chaque portefeuille AA communique avec le même EntryPoint, ce qui fait du standard un véritable standard.

Bundler. Un acteur hors-chaîne (considérez-le comme une sorte de relais spécialisé) qui écoute les UserOperations dans un mempool public, en regroupe plusieurs ensemble, et soumet le lot à l'EntryPoint sous la forme d'une seule transaction Ethereum. Le bundler paie le gas réel au réseau et se fait rembourser par les UserOperations qu'il a regroupées.

Paymaster. Un contrat optionnel qui peut se porter volontaire pour payer le gas au nom d'un utilisateur. Le paymaster est ce qui rend possible « la dApp paie votre gas » ou « payer le gas en USDC plutôt qu'en ETH ». Sans paymaster, le portefeuille AA de l'utilisateur paie son propre gas ; avec un paymaster, celui-ci intervient.

C'est tout le vocabulaire. Le reste n'est que décoration.

Ce que l'account abstraction permet en pratique

Les quatre éléments ci-dessus semblent abstraits jusqu'à ce que vous voyiez ce qu'ils débloquent :

• Parrainage du gas. Une dApp peut payer le gas pour les nouveaux utilisateurs afin qu'ils n'aient pas besoin d'acquérir de l'ETH avant de faire quoi que ce soit. C'est énorme pour l'onboarding — les nouveaux utilisateurs peuvent s'inscrire, minter un NFT ou passer leur premier trade sans devoir d'abord passer par une rampe fiat-vers-ETH. Argent, Safe et ZeroDev prennent tous en charge des flux de parrainage aujourd'hui.
• Récupération sociale. Vous pouvez configurer votre portefeuille de sorte que si vous perdez votre clé principale, un quorum de « gardiens » (amis, famille, un appareil matériel dans un coffre) puisse faire tourner la clé en votre nom. La logique de récupération réside dans votre contrat de portefeuille — aucun dépositaire centralisé ne détient votre argent, mais votre argent n'est pas perdu définitivement si un seul appareil tombe en panne.
• Clés de session. Une dApp peut demander à votre portefeuille une clé à permission limitée, restreinte à une seule application et à un ensemble d'actions, valable quelques heures. Vous signez une fois avec votre clé principale pour accorder la session, puis la dApp peut agir dans son bac à sable sans vous solliciter à chaque clic. Les studios de jeux adorent ce pattern.
• Actions groupées. « Approuver ce token ET l'échanger » devient une seule signature, une seule UserOperation, une seule exécution. Si une étape échoue, tout le lot est annulé — finis les transactions à moitié terminées coincées dans un état incohérent.
• Schémas de signature personnalisés. Vous voulez un portefeuille qui utilise des passkeys, ou une enclave matérielle, ou un schéma à seuil 2-sur-3 ? La logique de vérification réside dans le contrat de portefeuille, vous pouvez donc utiliser n'importe quelle cryptographie de votre choix, pas seulement le standard EOA secp256k1 ECDSA.

Comment cela se rapporte au modèle multisig de SSP

SSP Wallet emprunte une voie différente pour atteindre nombre des mêmes objectifs. SSP utilise un multisig 2-of-2 BIP48 — deux clés indépendantes, sur deux appareils indépendants, toutes deux requises pour signer toute transaction. L'ERC-4337 et le multisig BIP48 sont des mécanismes différents s'attaquant à un problème commun : aucun appareil ne devrait être un point de défaillance unique.

Quelques comparaisons honnêtes :

• Ce qu'ils partagent. Tous deux éliminent le mode d'échec « une clé, une chance » d'un portefeuille classique mono-signature. Perdez un facteur, et vous pouvez récupérer avec l'autre. Compromettez un facteur (un malware sur un ordinateur portable, un téléphone perdu), et un attaquant ne peut toujours pas déplacer les fonds seul.
• En quoi ils diffèrent. BIP48 est un standard multisig enraciné dans Bitcoin qui fonctionne à travers les chaînes prises en charge par SSP — Bitcoin, Ethereum, Litecoin et plusieurs autres — en utilisant les primitives multisig natives de chaque chaîne. L'ERC-4337 est exclusif à Ethereum et réside au niveau du smart contract, il est donc livré avec des capacités que BIP48 n'a pas nativement (parrainage du gas, clés de session), mais au prix d'une portée Ethereum-only et d'un surcoût d'exécution de contrat.
• Où se situe SSP aujourd'hui. SSP est construit autour du modèle BIP48. Les portefeuilles ERC-4337 et le multisig façon SSP ne sont pas ennemis — ce sont des outils complémentaires — et en principe, une clé multisig BIP48 pourrait être utilisée comme signataire dans un portefeuille AA. Ce n'est pas la voie principale de SSP actuellement, et nous préférons être clairs sur le produit d'aujourd'hui plutôt que de promettre des intégrations que nous n'avons pas livrées.

Si vous vous demandez « devrais-je utiliser un portefeuille AA ou un multisig matériel ? », la réponse honnête est qu'ils résolvent des problèmes qui se recoupent avec des compromis différents — et la bonne réponse dépend des chaînes qui vous intéressent.

Les compromis honnêtes

L'account abstraction est un véritable pas en avant, mais ce n'est pas gratuit, et quiconque vous dit le contraire essaie de vous vendre quelque chose.

• Les coûts de gas sont plus élevés. Chaque UserOperation exécute du code de contrat dans l'EntryPoint et dans votre contrat de portefeuille. C'est strictement plus de calcul qu'une transaction signée par un EOA, ce qui signifie plus de gas. Le bundling en amortit une partie, mais à l'unité d'action, vous paierez généralement plus qu'avec un EOA.
• La récupération ne vaut que ce que vaut le contrat de récupération. La récupération sociale et les schémas de gardiens sont des fonctionnalités puissantes — et constituent aussi une nouvelle surface d'attaque. Un bug dans la logique de récupération, ou un ensemble de gardiens qui s'avère trop petit, peut être tout aussi catastrophique que la perte d'une clé EOA. Tenez-vous-en à des implémentations de portefeuille auditées.
• Les paymasters créent une relation de confiance. « La dApp paie le gas » sonne très bien, mais cela signifie que le paymaster voit vos UserOperations et peut en principe refuser de parrainer certaines transactions. C'est un modèle de confiance différent de « vous payez votre propre gas, personne ne peut vous bloquer ».
• Moins éprouvé à grande échelle. Les EOA ont sécurisé des billions de dollars sur plus d'une décennie. L'ERC-4337 est entré en service en mars 2023 et arrive encore à maturité. Pour du stockage à froid de grande valeur, la réponse conservatrice (portefeuille matériel, multisig, contrats audités) a toujours le plus long historique.

Pour aller plus loin

Pour la perspective côté SSP de la façon dont la sécurité multi-clés fonctionne sans smart contracts, lisez Qu'est-ce qu'un multisig 2-of-2 ?.

Pour la spécification technique canonique — y compris la structure exacte de l'UserOperation, l'interface de l'EntryPoint, et le raisonnement derrière chaque décision de conception — l'EIP lui-même est la source primaire : https://eips.ethereum.org/EIPS/eip-4337.