Comptes intelligents contre EOA : analyse honnête des risques

Pourquoi cette question est plus difficile qu'il n'y paraît

L'argumentaire en faveur des comptes intelligents, parfois appelés account abstraction, est que le modèle du compte détenu externement (EOA) est une relique. Un EOA classique est une clé privée unique qui signe chaque transaction sur Ethereum. Si vous perdez la clé, l'ETH et les jetons disparaissent. Si la clé est victime d'un hameçonnage, même résultat. Les comptes intelligents, formalisés dans la norme ERC-4337 et les propositions associées, remplacent cette clé unique par un portefeuille en contrat intelligent. Ce contrat peut exiger plusieurs signatures, autoriser des plafonds de dépense, faire expirer des sessions, sponsoriser le gaz et permettre la récupération depuis un appareil perdu grâce à des gardiens.

Sur le papier, cela ressemble à une amélioration stricte. En pratique, chaque nouvelle fonctionnalité est aussi une nouvelle façon de perdre de l'argent. Les chercheurs en sécurité qui auditent ces systèmes utilisent une formulation directe : l'account abstraction ne réduit pas la surface d'attaque, elle la déplace. Une vulnérabilité qui se trouvait dans « veillez à ne pas perdre votre phrase de récupération » se trouve désormais dans « veillez à ne pas mal configurer votre ensemble de gardiens, faites confiance à un bundler pour qu'il ne vous fasse pas de front-run, faites confiance à un paymaster pour qu'il reste solvable, et veillez à détecter une clé de session compromise avant qu'elle ne soit utilisée ».

Cet article examine ce déplacement en toute honnêteté. Il s'adresse aux développeurs qui déploient des intégrations de comptes intelligents et aux utilisateurs avancés qui décident s'ils souhaitent y déposer de l'ETH réel. Il suppose que vous savez déjà ce qu'est une phrase de récupération et que vous avez entendu le terme « account abstraction », et il ne constitue pas un conseil financier ou de sécurité. Votre configuration, votre modèle de menace et votre tolérance aux nouvelles dépendances sont les variables qui comptent, pas les supports marketing.

Ce qu'un EOA protège réellement, et ce qu'il ne protège pas

Un EOA n'est rien d'autre qu'une clé privée, le nombre scalaire derrière une adresse Ethereum. L'adresse est une fonction à sens unique de cette clé. Signez une transaction, diffusez-la, le réseau vérifie la signature par rapport à votre adresse, et le changement d'état se produit. Il n'y a aucun contrat intelligent entre vous et la chaîne. La simplicité est le modèle de sécurité : il n'y a littéralement rien d'autre à casser.

Cette simplicité est aussi le mode de défaillance. La clé est un entier de 256 bits. Un humain ne peut pas la mémoriser, c'est pourquoi les portefeuilles l'编码ent sous forme de phrase de récupération, généralement 12 ou 24 mots issus d'une liste fixe. Quiconque possède la phrase de récupération possède le compte. Il n'y a aucune réinitialisation de mot de passe, aucun support client, aucune limite de tentatives sur les signatures erronées. Le vol, lorsqu'il se produit, est définitif. Selon des estimations de type Chainalysis largement citées dans le secteur, des milliards de dollars en crypto ont été perdus à cause du vol de phrases de récupération et de l'hameçonnage, et la chaîne elle-même est rarement en cause. L'humain, le presse-papiers, l'extension de navigateur, le faux site web, l'aperçu de transaction malveillant, voilà les surfaces qui échouent réellement.

Les portefeuilles matériels comme Ledger et Trezor déplacent la clé privée hors de votre ordinateur, de sorte qu'une infection par un logiciel malveillant sur votre ordinateur portable ne puisse pas signer une transaction que vous n'avez pas approuvée. Ils ne modifient pas le modèle en chaîne. Votre EOA reste une clé unique. Les portefeuilles multisig comme Safe ajoutent une exigence de signature m-of-n, de sorte que la perte d'une clé est récupérable. C'est utile, mais il s'agit d'un correctif au niveau du contrat par-dessus une chaîne qui ne prend en charge que les EOA. La couche de base ne sait toujours pas ce qu'est une « session » ou un « plafond de dépense ».

Ce qu'un smart account apporte réellement, et ce que ça coûte

L'ERC-4337, la norme Ethereum pour l'abstraction de compte, introduit quatre nouveaux acteurs et un nouveau flux. Au lieu qu'un utilisateur signe une transaction directement, un utilisateur de smart account signe une UserOperation, un message structuré décrivant ce qu'il souhaite faire, incluant le paiement du gas, la signature, et toute éventuelle prise en charge par un paymaster. Cette UserOperation arrive dans un mempool, et un bundler en empaquette une ou plusieurs dans une véritable transaction on-chain qui appelle le contrat EntryPoint, qui appelle ensuite le contrat smart account de chaque utilisateur pour valider et exécuter l'opération.

Trois nouveaux éléments comptent pour la sécurité. Premièrement, le contrat smart account lui-même, généralement déployé depuis une factory comme Create2, avec la logique pour valider les signatures, vérifier les nonces, imposer des session keys et gérer la récupération. Deuxièmement, le bundler, un service off-chain qui décide quelles UserOperations inclure, dans quel ordre et à quel prix du gas. Troisièmement, le paymaster, un contrat qui peut accepter de payer le gas pour le compte de l'utilisateur selon des règles qu'il définit lui-même.

Le coût, c'est le graphe de dépendances. Vous faites désormais confiance au code de votre contrat de compte, au code de l'EntryPoint, au comportement d'ordonnancement du bundler, ainsi qu'à la solvabilité et aux règles du paymaster. Un EOA traditionnel fait confiance à un seul élément cryptographique. Un smart account fait confiance à une pile. Cette pile est auditable, mais c'est aussi une pile, avec tous les modes de défaillance que les piles apportent : dérive de versions, factories abandonnées, versions d'EntryPoint obsolètes, paymasters qui disparaissent, et bundlers qui se font pirater ou sanctionner.

Session keys : la fonctionnalité qui élargit silencieusement votre rayon d'impact

Les session keys sont l'une des fonctionnalités les plus utiles du smart account et l'une des plus faciles à détourner. Une session key est une clé temporaire, souvent limitée à un contrat spécifique, à un plafond de dépenses et à une fenêtre de temps, qui permet à une dapp de signer des UserOperations à votre place sans vous demander une signature complète à chaque fois. Les studios de jeux et les applications de trading les utilisent, car personne ne veut signer une transaction à chaque action on-chain dans une boucle rapide.

Le risque est structurel. Vous avez en pratique miné un nouvel EOA, l'avez financé avec une allowance délimitée, et l'avez remis à une dapp. Si le frontend de la dapp est compromis, l'attaquant détient désormais cette clé limitée. Si la session key est mal délimitée, l'allowance peut être vidée pendant la fenêtre. Si la révocation exige que vous détectiez la fuite et soumettiez une UserOperation de révocation, l'attaquant doit perdre une course contre vous, et le bundler doit être disposé à inclure votre révocation avant le drain de l'attaquant.

Plusieurs incidents réels ont démontré ce schéma avant même que l'ERC-4337 ne devienne courant. Fin 2023, une version malveillante du Ledger Connect Kit, distribuée via un compte d'éditeur npm détourné, a brièvement injecté un drainer dans des dapps dont SushiSwap et Zapper. Les utilisateurs avec des EOAs qui ont signé la transaction malveillante ont perdu des fonds depuis leur compte principal. Les utilisateurs dont les smart accounts avaient accordé de larges allowances de session ont subi un drain similaire, dans la limite de ce que l'attaquant pouvait exploiter. Le rayon d'impact était entièrement déterminé par ce que l'utilisateur avait signé auparavant, et non par la distinction EOA contre smart account.

Côté smart account, la leçon est que la révocation doit être peu coûteuse, rapide et idéalement pré-armée. Révoquer une session ne devrait pas exiger qu'un paymaster accepte de sponsoriser le gas, qu'un bundler accepte d'inclure votre tx, ou qu'un gardien cosigne. Si l'un de ces éléments est dégradé, la révocation peut stagner et le drain l'emporte.

Paymasters et bundlers : nouvelle confiance, nouvelle censure

Un paymaster est un contrat qui paie le gas pour les UserOperations à la place des utilisateurs. L'argument produit, c'est que les utilisateurs peuvent transiger sans détenir d'ETH, un vrai gain d'UX. L'argument sécurité, c'est que le paymaster fixe les règles. Il peut rejeter votre UserOperation, blacklister votre adresse ou refuser de sponsoriser certains types d'appels. Il peut aussi manquer de fonds et casser votre flux en pleine session. Un paymaster que vous n'opérez pas est une contrepartie que vous n'aviez pas avec un EOA.

Les bundlers sont la contrepartie équivalente côté inclusion. Avec un EOA, vous pouvez toujours soumettre une transaction directement au réseau, payer le base fee et être inclus (hors censure au niveau de la base layer, qui est un sujet à part). Avec l'ERC-4337, vous dépendez d'un bundler qui récupère votre UserOperation. Le bundler choisit l'ordre, et c'est dans cet ordre que vit le MEV. Un bundler malveillant ou compromis peut front-runner votre trade, sandwicher votre swap ou simplement vous ignorer.

Des bundlers à confiance minimisée existent, notamment des réseaux décentralisés qui font tourner les proposers et utilisent des schémas de commit-reveal pour réduire le front-running. Ils ne sont pas gratuits. Ils ajoutent de la latence, du coût et de la complexité opérationnelle. Un bundler solo que vous gérez vous-même est ce qui se rapproche le plus des hypothèses de confiance d'un EOA, et c'est aussi un point unique de défaillance que vous devez désormais opérer, surveiller et patcher. Le résumé honnête, c'est que l'ERC-4337 est un système multi-parties, et chaque nouvelle partie est une nouvelle façon pour le système de tomber en panne ou de censurer.

Des incidents dans des piles adjacentes confirment ce schéma. Des relais MEV-Boost ont été observés en train de censurer des adresses sanctionnées par l'OFAC, et l'ensemble des relais a dû être diversifié. La même dynamique s'applique aux bundlers. Un petit marché de bundlers signifie une petite surface de censure, et une petite surface qu'un acteur unique peut dominer. Le système est plus résistant à la censure en théorie, mais seulement si l'ensemble des bundlers est large, décentralisé et activement surveillé.

Récupération sociale : une cible lorsqu'elle est mal configurée

La récupération sociale remplace « perdez votre seed phrase, perdez tout » par « perdez votre appareil, demandez à vos gardiens de vous restaurer ». Un smart account peut désigner N gardiens et exiger un quorum, par exemple 3 sur 5, pour faire tourner la clé de signature. Ça ressemble à une nette amélioration. En termes de modèle de menace, ça change qui peut prendre le contrôle de votre compte : de « quiconque vole la seed » à « tout quorum de gardiens qu'un attaquant peut compromettre ».

Une récupération sociale mal configurée effondre la propriété de sécurité. Si les cinq gardiens sont des membres de la famille sur le même compte iCloud, un seul identifiant Apple compromis suffit à une prise de contrôle du compte. Si trois des cinq sont des hot wallets sur un téléphone que vous utilisez aussi pour vous connecter à des exchanges, l'attaquant qui phishing votre connexion à l'exchange détient désormais deux votes sur trois. Si un gardien est un smart contract que l'utilisateur ne comprend pas entièrement, un chemin de mise à jour dans ce contrat gardien est un chemin de rotation dans votre compte. La sécurité du flux de récupération, c'est la sécurité du gardien le plus faible plus la sécurité du seuil de quorum moins un.

De véritables attaques ont frappé cette couche. En 2017, le bug de la bibliothèque Parity Wallet a gelé plusieurs centaines de millions de dollars d'ETH en tuant le contrat de bibliothèque dont dépendaient les wallets multisig. Ce n'était pas un incident de « récupération sociale » au sens ERC-4337, mais la forme est la même : un smart contract qui contrôle la récupération devient un point unique de défaillance. En 2024 et 2025, plusieurs incidents impliquant des frontends compromis et des éditeurs npm ou d'extensions de navigateur détournés ont montré que la supply chain dont dépend un gardien fait partie du modèle de menace. Si votre gardien est un hardware wallet, vous devez aussi faire confiance au fabricant, au chemin de mise à jour du firmware, et à la supply chain qui l'a livré.

La discipline opérationnelle est la même que pour un multisig : diversité des gardiens entre classes d'appareils, juridictions géographiques et légales, et idéalement entre familles de fournisseurs. Le temps de récupération, mesuré en jours, est la métrique qui compte. Une récupération qui prend deux semaines est une récupération qu'un attaquant peut attendre ou contourner par ingénierie sociale, surtout s'il peut faire pression directement sur les gardiens.

Ce que cela implique pour les développeurs et les utilisateurs avancés

Si vous construisez au-dessus de comptes intelligents, les implications pratiques découlent des modes de défaillance évoqués plus haut. Configurez par défaut les clés de session avec la portée la plus réduite possible et la durée de vie la plus courte possible. Faites de la révocation une action en un clic qui ne dépend pas de la bonne volonté du paymaster ou du bundler. Considérez le paymaster comme une contrepartie contractuelle dans votre modèle de menace, y compris sa solvabilité et sa politique de liste noire. Documentez les hypothèses relatives au bundler sur lesquelles votre application s'appuie, et exécutez votre propre bundler si vos utilisateurs ne peuvent pas tolérer le front-running.

Pour les audits, la pile du compte intelligent comporte plus d'endroits où chercher des failles qu'une intégration EOA. Le contrat de compte lui-même, la version d'EntryPoint que vous ciblez, la factory à partir de laquelle vous déployez, la logique du paymaster, le choix du bundler, la validation des clés de session, l'ensemble des gardiens et le flux de récupération doivent tous faire l'objet d'une revue séparée. Considérer « nous utilisons ERC-4337 » comme un argument de sécurité revient à considérer « nous utilisons HTTPS » comme un argument de sécurité dans une application web de 2010. C'est un point de départ, pas une réponse.

Pour les utilisateurs avancés qui détiennent de l'ETH réel, la question n'est pas « compte intelligent ou EOA ». C'est « à quels risques suis-je actuellement exposé, et quel nouvel ensemble de risques est plus petit pour moi ». Un utilisateur qui garde un portefeuille matériel dans un coffre et n'interagit jamais avec des dapps présente un profil de risque restreint et bien compris. Un utilisateur qui trade quotidiennement sur des DEX, signe des autorisations de session et bridge entre chaînes a un profil de risque bien plus large et plus chaotique, et peut réellement tirer parti de fonctionnalités de compte intelligent comme les sessions à portée limitée et le sponsoring de gas, tout en acceptant les nouvelles dépendances. L'erreur serait de considérer cette migration comme une mise à niveau gratuite. C'est une réallocation du risque, et ces nouveaux risques nécessitent leurs propres mesures d'atténuation.

Suivez le risque des comptes intelligents de manière intelligente

La sécurité des comptes intelligents évolue vite, et l'actualité qui l'entoure aussi. Suivre manuellement les rug pulls de paymasters, les pannes de bundlers, les exploits de clés de session et les divulgations d'audits est une bataille perdue d'avance. Zippfeed met en avant les titres liés aux comptes intelligents et à la sécurité Ethereum avec une notation de sentiment (haussier, neutre ou baissier) ainsi qu'un score d'importance, afin que vous puissiez repérer les véritables évolutions de risque avant qu'elles n'atteignent votre portefeuille. Considérez le flux d'actualité comme une alerte précoce, et non comme un signal de trading, et combinez-le avec le modèle de menace présenté dans cet article. smart account security vs eoa est exactement le type de question où le signal se trouve dans les rapports d'incidents, pas dans le marketing.