L'abstraction de comptes depuis les premiers principes

Si vous avez déjà utilisé un portefeuille auto-dépositaire sur Ethereum, vous avez utilisé un compte détenu en externe — une EOA — que vous le sachiez ou non. La conversation sur l'abstraction de comptes commence par comprendre ce qu'est une EOA, pourquoi sa conception limite tout ce que vous pouvez faire on-chain, et comment l'abstraction de comptes ERC-4337 contourne ces limites sans toucher au protocole de base. Cet article est le point d'entrée d'une série qui vous mène des limites d'origine jusqu'à la façon dont SSP utilise l'abstraction de comptes pour faire fonctionner son multisig 2-sur-2 sur les chaînes EVM.

C'est la pièce fondatrice et conceptuelle. Pour un parcours centré sur le standard ERC-4337 lui-même, lisez Qu'est-ce que l'abstraction de comptes (ERC-4337) ? en complément de cet article ; ici, nous construisons l'intuition de pourquoi le standard existe.

Le compte qu'Ethereum vous a donné

Ethereum a deux types de comptes. Les comptes de contrat sont gouvernés par du code. Les EOA — les portefeuilles ordinaires que la plupart des gens utilisent — sont gouvernées par une seule clé privée. Quiconque détient cette clé peut autoriser n'importe quelle transaction depuis le compte, et le protocole valide exactement une chose : que la transaction porte une signature ECDSA valide sur la courbe secp256k1, produite par la clé qui contrôle l'adresse.

Cette règle unique est élégante, et elle est aussi l'origine de chaque limite évoquée ci-dessous. La validité d'une transaction est câblée en dur dans le protocole. Vous, propriétaire du compte, ne pouvez pas décider de ce que « valide » signifie. C'est le protocole qui décide, et il ne sait vérifier qu'un seul schéma de signature d'une seule clé.

Ce que cette conception inscrit à la racine

Quatre limites découlent directement du modèle une clé, une signature :

• Une seule clé est un point de défaillance unique. Perdez la clé et les fonds disparaissent. Divulguez-la et un attaquant a tout. Il n'y a pas de second facteur au niveau du protocole, pas de cosignataire, pas de politique qui aurait pu bloquer le vol.
• Pas de logique de validation personnalisée. Une EOA ne peut pas dire « exige deux signatures », ni « autorise ce petit paiement automatiquement mais exige une approbation supplémentaire au-delà d'un seuil », ni « laisse cette clé dépenser uniquement en semaine ». Le compte n'a pas de logique. Il a une vérification de signature.
• L'expéditeur doit détenir de l'ETH pour le gas. Chaque transaction d'une EOA paie son propre gas en ETH. Un nouvel utilisateur qui ne détient qu'un token ERC-20 mais pas d'ETH ne peut pas déplacer ce token, parce qu'il ne peut pas payer les frais. Le payeur des frais et l'expéditeur de la transaction sont forcés d'être le même compte.
• L'UX de la phrase de récupération est impitoyable. Comme la clé est le compte, l'inscription revient à noter une phrase de récupération et à la protéger pour toujours. Il n'existe aucun chemin de récupération qui ne fasse pas intervenir cette phrase, et une seule erreur est définitive.

Ce ne sont pas des bugs. Ce sont les conséquences du fait que la validation réside dans le protocole plutôt que dans le compte.

L'idée centrale : rendre le compte programmable

L'abstraction de comptes, c'est l'idée de sortir cette logique de validation du protocole et de la placer dans le compte lui-même. Au lieu que le réseau code en dur « une transaction est valide si elle a une signature ECDSA correcte », un smart account — un contrat qui détient vos fonds — décide lui-même de ce qui compte comme transaction valide.

Une fois que le compte est un contrat programmable, les quatre limites se dissolvent en choix de conception :

• Il peut exiger deux signatures au lieu d'une, ce qui est exactement la façon dont le multisig devient possible sans prise en charge native du protocole.
• Il peut implémenter des règles de récupération, de sorte qu'une clé perdue ne soit plus la fin de l'histoire.
• Il peut laisser quelqu'un d'autre payer le gas, séparant le payeur des frais de l'expéditeur.
• Il peut regrouper plusieurs actions — approuver et échanger, par exemple — en une seule opération atomique.

Le compte cesse d'être une paire de clés passive et devient une logique programmable que vous contrôlez.

Comment ERC-4337 livre cela sans hard fork

Le plus difficile, c'est que changer la façon dont Ethereum valide les transactions signifie normalement changer le protocole de base — une mise à niveau lente, controversée et à l'échelle de tout le réseau. ERC-4337 contourne cela entièrement. Il introduit l'abstraction de comptes comme une couche par-dessus le réseau existant, sans aucun changement de consensus requis.

Le mécanisme repose sur quelques pièces :

• UserOperations. Au lieu d'envoyer une transaction normale, un smart account exprime son intention sous la forme d'une UserOperation — un objet structuré décrivant ce que le compte veut faire et comment il doit être validé.
• Une mempool alternative. Les UserOperations vivent dans leur propre mempool, séparée des transactions ordinaires.
• Bundlers. Un bundler collecte des UserOperations depuis cette mempool, les empaquette ensemble et les soumet à la chaîne comme une vraie transaction, en payant le gas de la couche de base.
• Le contrat EntryPoint. Un unique contrat EntryPoint audité est le point d'étranglement on-chain. Il appelle chaque smart account pour exécuter la logique de validation propre à ce compte, puis exécute l'opération si la validation passe.
• Paymasters. Un contrat paymaster optionnel peut accepter de couvrir le gas d'une UserOperation, ce qui rend possibles les flux sans gas et de paiement en token.

Mis ensemble, cela permet à n'importe quel contrat d'agir comme un compte entièrement programmable, validé par ses propres règles, tandis que le protocole Ethereum sous-jacent reste exactement tel qu'il était. Le standard est spécifié dans l'EIP-4337, et la propre feuille de route d'abstraction de comptes d'Ethereum suit la direction que prend l'effort plus large.

Pourquoi cela compte pour les utilisateurs de l'auto-conservation

Pour quelqu'un qui détient ses propres clés, l'abstraction de comptes n'est pas un détail abstrait de protocole — elle change ce qu'un portefeuille peut faire en toute sécurité :

• Multisig sans prise en charge native. Un smart account peut exiger plus d'une signature, de sorte qu'un portefeuille peut requérir que deux appareils indépendants approuvent chaque transfert. C'est la brique sur laquelle SSP s'appuie, expliquée plus en détail dans Le multisig EVM à la manière de l'abstraction de comptes.
• Options de récupération. La validation programmable ouvre la porte à des flux de récupération qui ne se réduisent pas à une seule phrase de récupération fragile.
• Parrainage du gas. Les paymasters signifient que les frais peuvent être découplés de l'expéditeur, lissant la pire friction d'inscription.
• Regroupement. Plusieurs étapes peuvent se régler comme une seule opération, réduisant à la fois les clics et le risque d'échouer à mi-chemin.

La différence pratique entre une EOA à clé unique et un smart account programmable est assez grande pour mériter son propre traitement — voir EOA contre smart account : les différences qui comptent.

Où SSP s'inscrit

SSP est un portefeuille auto-dépositaire construit autour du multisig 2-sur-2. Une clé vit dans l'extension de navigateur SSP Wallet ; la seconde vit dans l'application mobile SSP Key. Chaque transaction est construite dans l'extension et cosignée sur le téléphone, de sorte qu'aucun appareil seul ne peut déplacer des fonds.

Sur les chaînes EVM, SSP livre ce 2-sur-2 en utilisant ERC-4337. Le portefeuille est un smart account ERC-4337 dont la logique de validation exige les deux clés, et les deux signatures partielles se combinent — à la manière de MuSig2 sur secp256k1 — en une unique signature agrégée de Schnorr que le contrat vérifie on-chain. Les smart contracts de SSP ont été audités par Halborn en 2025. La conception complète fait l'objet de L'architecture d'abstraction de comptes de SSP.

Autrement dit, la capacité abstraite décrite ci-dessus — un compte qui impose sa propre règle de signature multiple — est exactement ce que SSP transforme en un portefeuille fonctionnel sur Ethereum, Polygon, Base et les autres chaînes EVM prises en charge.

Le reste de cette série

Cette pièce a posé le problème et l'idée centrale. La série bâtit à partir d'ici :

1. L'abstraction de comptes depuis les premiers principes — cet article : pourquoi les EOA sont limitantes et ce que signifie l'abstraction de comptes.
2. EOA contre smart account : les différences qui comptent — une comparaison directe des deux modèles de compte.
3. L'architecture d'abstraction de comptes de SSP — comment SSP câble ERC-4337 dans un portefeuille 2-sur-2.
4. Le parrainage du gas et les paymasters expliqués — comment les paymasters découplent celui qui paie de celui qui envoie.
5. L'abstraction de comptes sur les chaînes non-Ethereum — comment la même idée voyage au-delà d'Ethereum.

Commencez par l'explication d'ERC-4337 si vous voulez le standard isolément, puis revenez ici pour la vue d'ensemble. À partir de là, le compte cesse d'être une contrainte et commence à être quelque chose autour de quoi vous pouvez programmer.