Le multisig EVM à la manière de l'abstraction de comptes

Le multisig est simple à décrire — exiger plus d'une signature pour déplacer des fonds — mais la façon dont il est construit diffère nettement d'une blockchain à l'autre. Sur Bitcoin, le multisig est intégré au protocole lui-même. Sur Ethereum et les autres chaînes EVM, ce n'est pas le cas, et ce seul fait façonne le fonctionnement de tout portefeuille multisig sérieux sur Ethereum, SSP compris. Cet article explique pourquoi le multisig sur EVM est différent, propose un parcours en langage clair à travers les outils d'account abstraction qui le rendent possible, et montre exactement comment SSP fournit un véritable 2-of-2 sur Ethereum.

Si vous arrivez ici depuis le début de la série EVM, Ethereum dans SSP pose les fondations ; cet article est la plongée en profondeur dans la mécanique de sécurité qui se trouve dessous. Le niveau de lecture ici monte d'un cran — intermédiaire — car rendre justice au sujet implique d'aborder honnêtement ERC-4337 et l'agrégation de signatures plutôt que de les éluder.

Pourquoi le multisig sur EVM diffère du multisig sur Bitcoin

La manière la plus claire de comprendre SSP sur Ethereum est de voir d'abord pourquoi l'approche de Bitcoin ne peut pas simplement être recopiée.

Bitcoin dispose d'un multisig de script natif. Le protocole inclut un opcode qui permet de verrouiller des fonds derrière une règle telle que « deux quelconques de ces trois clés publiques doivent signer ». Une adresse multisig sur Bitcoin n'est qu'une adresse à laquelle cette règle de dépense est attachée, et le réseau l'applique directement. SSP utilise cela sur Bitcoin et les autres chaînes UTXO via le multisig de script BIP-48 : deux clés, un script, les deux signatures requises. Si ce modèle de base vous est nouveau, qu'est-ce que le multisig 2-of-2 est le point de départ.

Ethereum n'a pas d'équivalent. Sur une chaîne EVM, il n'existe que deux types de comptes. Le premier est un EOA — un compte détenu en externe, contrôlé par exactement une clé privée. Une clé, un signataire, point final ; il n'existe aucun opcode natif pour exiger deux signatures sur un EOA. Le second est un compte de contrat intelligent, qui possède du code au lieu d'une unique clé de contrôle et fait ce que ce code dit.

Ainsi, sur Ethereum, « multisig » a toujours signifié un portefeuille de contrat intelligent : un contrat programmé pour ne libérer des fonds que lorsque sa règle de signatures multiples est satisfaite. C'est le modèle qu'ont défriché des portefeuilles comme Gnosis Safe / Safe, et il fonctionne bien. Le compromis est que les contrats multisig on-chain classiques stockent généralement la signature de chaque propriétaire et les vérifient une par une on-chain, ce qui coûte du gas et croît avec le nombre de signataires. L'account abstraction offre une voie plus nette, et c'est la voie qu'emprunte SSP.

Une introduction brève et honnête à ERC-4337

L'account abstraction est l'idée que votre portefeuille devrait être un contrat intelligent — un compte programmable — plutôt qu'une simple paire de clés. ERC-4337 est la norme qui réalise cela sur Ethereum sans modifier le protocole de base. Vous n'avez pas besoin de la maîtriser pour utiliser SSP, mais quelques termes font que le reste de cet article se met en place. Pour le traitement complet, lisez qu'est-ce que l'account abstraction (ERC-4337) ; voici la carte au niveau de l'utilisateur.

• Smart account. Vos fonds résident dans un smart account dont le code définit ce qui compte comme une transaction valide. Parce que c'est du code, le compte peut appliquer des règles personnalisées — y compris « exiger une signature 2-of-2 valide ».
• UserOperation. Au lieu de soumettre une transaction normale, un smart account exprime son intention sous la forme d'une UserOperation : une requête structurée qui indique ce qu'il veut faire et porte les données de signature qui l'autorisent.
• Bundler. Un bundler est un service qui rassemble les UserOperations, les enveloppe dans une véritable transaction on-chain et les soumet. Il paie le gas d'avance et est remboursé ; il n'obtient jamais la capacité de déplacer vos fonds.
• EntryPoint. Un unique contrat EntryPoint audité est le coordinateur de confiance on-chain. Il reçoit les UserOperations groupées et appelle chaque smart account pour valider puis exécuter son opération.
• Paymaster. Un contrat paymaster optionnel peut parrainer le gas ou permettre que les frais soient payés dans un token plutôt que dans la monnaie native. Il est optionnel et indépendant du multisig lui-même.

L'idée clé : avec un smart account, la règle qui détermine « qui peut autoriser une transaction » est un logiciel que vous contrôlez, et non un comportement figé du protocole. C'est exactement la liberté dont le multisig a besoin sur une chaîne dépourvue de multisig natif.

Comment SSP réalise le 2-of-2 sur EVM

SSP tient la même promesse sur chaque chaîne qu'il prend en charge : deux clés sur deux appareils, et aucun ne peut à lui seul déplacer votre argent. La clé 1 réside dans l'extension de navigateur SSP Wallet ; la clé 2 réside dans l'application mobile SSP Key. Vous construisez et signez une transaction dans l'extension, puis vous l'approuvez sur votre téléphone via un push — les deux signatures sont requises.

Sur Bitcoin, cette garantie provient du multisig de script BIP-48. Sur les chaînes EVM, SSP la recrée sous la forme d'un smart account ERC-4337 qui vérifie une signature 2-of-2 agrégée de Schnorr. Voici l'idée à haut niveau, gardée générale là où les détails internes exacts du contrat ne sont pas l'essentiel.

Chacune de vos deux clés produit une signature partielle sur la transaction. Plutôt que d'envoyer les deux signatures séparément à la chaîne, les deux appareils les combinent — au moyen d'une agrégation de signatures de style MuSig2 — en une seule signature compacte. Le smart account est programmé pour n'accepter une UserOperation que lorsque cette signature agrégée se vérifie face à la clé attendue du portefeuille. La chaîne voit donc une signature d'apparence ordinaire, et pourtant cette signature est mathématiquement impossible à produire sans la participation des deux clés.

Cette conception présente de réels avantages par rapport au stockage et à la vérification de N signatures séparées on-chain :

• Empreinte on-chain plus réduite. Une signature agrégée est moins coûteuse à vérifier et à stocker que deux signatures indépendantes, ce qui tend à signifier moins de gas pour la sécurité obtenue.
• UX identique à celle d'un portefeuille à signataire unique. Comme la chaîne valide une seule signature, votre smart account se comporte comme n'importe quel compte normal du point de vue du réseau. Envoyer de l'ETH, déplacer des tokens ERC-20 ou interagir avec la DeFi se ressentent de la même façon — la seconde signature se produit discrètement entre vos deux appareils.
• Le même modèle partout. Schnorr et cette approche d'agrégation reposent sur une cryptographie bien étudiée sur secp256k1, et la même conception de smart account se transpose aux chaînes EVM que SSP prend en charge, dont Ethereum, Polygon, Base, BNB Smart Chain et Avalanche.

Les contrats intelligents de SSP derrière tout cela ont été audités par Halborn en 2025. Pour la mécanique plus profonde de l'account abstraction — comment l'EntryPoint, le bundler et l'étape de validation s'imbriquent — reportez-vous à l'explication sur l'account abstraction (ERC-4337) plutôt que de traiter ici un quelconque détail isolé de contrat comme canonique.

Ce que cela signifie pour vous en tant qu'utilisateur

La cryptographie est intéressante, mais ce qui compte au quotidien, c'est la protection qu'elle achète.

• Les deux appareils sont requis pour déplacer des fonds. Une transaction n'est valide qu'une fois que l'extension et la SSP Key ont chacune apporté leur part. Posséder un seul appareil — ou une seule clé — ne suffit pas.
• Perdre un appareil n'est pas perdre votre argent. Comme aucun appareil seul ne peut signer, un téléphone perdu ou effacé ou un navigateur réinstallé ne remettent à personne le contrôle de vos fonds. Restaurer l'accès est un sujet distinct doté de ses propres garde-fous ; la récupération est traitée dans ses propres guides, pas ici.
• Une seule clé compromise n'est pas un point de défaillance unique. Si un logiciel malveillant ou un phishing capture ce qui se trouve sur un appareil, il ne peut toujours pas produire la signature 2-of-2 agrégée que le smart account exige. Un attaquant devrait compromettre vos deux appareils à la fois — une barre bien plus haute que vider un portefeuille à clé unique.

Ce sont des protections générales, et non des garanties absolues ; une bonne hygiène de la phrase de récupération et la sécurité de l'appareil restent importantes. Mais le point structurel tient : deux facteurs indépendants doivent s'accorder avant que la valeur ne bouge.

Une comparaison neutre avec les portefeuilles EOA à clé unique

La plupart des portefeuilles Ethereum sont des EOA à clé unique. Ils sont simples et largement pris en charge, et pour de nombreux utilisateurs ils conviennent. Le compromis est qu'une seule clé privée résume tout : quiconque la détient peut tout déplacer, de sorte qu'une seule phrase de récupération divulguée ou une seule machine compromise peut être fatale.

Un multisig de contrat intelligent change ce profil de risque en exigeant un accord entre deux clés plutôt qu'en faisant confiance à une seule. D'autres portefeuilles multisig de contrat intelligent existent — Safe en est un exemple bien connu — et ils résolvent le même problème central à leur manière. Le choix particulier de SSP est de fournir le 2-of-2 via ERC-4337 avec une signature Schnorr agrégée, de sorte que vous obtenez la sécurité du multisig avec l'empreinte on-chain et le ressenti quotidien d'un compte à signataire unique.

Où aller ensuite

Si vous voulez les bases conceptuelles, lisez qu'est-ce que l'account abstraction (ERC-4337) et l'incontournable qu'est-ce que le multisig 2-of-2. Pour voir comment cela s'inscrit dans le tableau Ethereum plus large dans SSP, revenez à Ethereum dans SSP. Et pour la norme elle-même, les sources canoniques sont la spécification ERC-4337 et l'aperçu de l'account abstraction de l'Ethereum Foundation. Le fil conducteur est le même que celui qui traverse chaque chaîne prise en charge par SSP : deux clés, deux appareils, une signature — et vous aux commandes.