Au cœur de l'architecture d'abstraction de comptes de SSP

SSP est un portefeuille auto-conservé bâti autour d'un multisig 2-de-2. Une clé réside dans l'extension de navigateur SSP Wallet, la seconde dans l'application mobile SSP Key, et aucune transaction n'est réglée tant que les deux appareils ne l'ont pas approuvée. Sur les chaînes EVM, SSP tient cette garantie grâce à l'account abstraction d'ERC-4337 : le portefeuille est un smart account dont la logique de validation accepte une unique signature Schnorr agrégée construite à partir des deux clés. Cet article parcourt cette architecture de bout en bout — chaque composant, le flux de signature exact et la propriété de sécurité qu'il produit.

Si l'account abstraction est nouvelle pour vous, commencez par L'abstraction de comptes depuis les premiers principes et l'explication ciblée d'ERC-4337. Ici, nous supposons que vous savez à peu près ce que sont un smart account et une UserOperation, et nous nous concentrons sur la façon dont SSP les relie entre eux.

Les pièces sur lesquelles SSP s'appuie

Avant de retracer le flux, il est utile de nommer les composants et le rôle de chacun :

• Le smart account. Sur les chaînes EVM, votre portefeuille SSP n'est pas une EOA contrôlée par une seule clé. C'est un smart account ERC-4337 — un contrat qui détient vos fonds et contient sa propre logique de validation. Cette logique est le cœur de la conception : elle n'accepte une transaction que lorsque la signature fournie correspond à la clé agrégée attendue du portefeuille.
• Les deux appareils. La clé 1 réside dans l'extension de navigateur SSP Wallet. La clé 2 réside dans l'application mobile SSP Key. Chaque appareil détient une part et produit une signature partielle. Aucune part ne peut autoriser quoi que ce soit à elle seule.
• La UserOperation. Au lieu d'une transaction normale, l'extension exprime votre intention sous la forme d'une UserOperation — un objet structuré décrivant ce que l'account doit faire et la signature qui l'autorise.
• Le bundler. Un bundler retire la UserOperation du mempool dédié, l'emballe dans une véritable transaction on-chain et paie le gas de la couche de base pour la soumettre.
• L'EntryPoint. Un unique contrat EntryPoint audité est l'entrée on-chain de toute opération ERC-4337. Il appelle votre smart account pour exécuter la logique de validation de cet account, puis déclenche l'exécution si la validation réussit.

Un paymaster peut, en option, couvrir le gas d'une UserOperation ; c'est un sujet à part entière, traité dans Le parrainage du gas et les paymasters expliqués.

Le flux de signature exact

Voici ce qui se passe, étape par étape, lorsque vous envoyez une transaction depuis SSP sur une chaîne EVM :

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Lu en prose :

1. Vous initiez une transaction dans l'extension de navigateur SSP Wallet, qui détient la clé 1.
2. L'extension construit une UserOperation ERC-4337 décrivant l'action.
3. La clé 1 produit une signature Schnorr partielle sur cette opération.
4. La requête est poussée vers l'application mobile SSP Key (clé 2) pour approbation.
5. La clé 2 produit sa propre signature partielle.
6. Les deux signatures partielles sont agrégées, à la manière de MuSig2 sur secp256k1, en une seule signature Schnorr.
7. La UserOperation, portant désormais cette unique signature agrégée, est prête à être envoyée.
8. Elle part vers un bundler, qui l'emballe dans une transaction et paie le gas.
9. Le bundler la soumet au contrat EntryPoint, qui invoque le smart account de SSP. L'account valide l'unique signature agrégée par rapport à la clé agrégée attendue du portefeuille et, si elle est valide, exécute l'appel.

Les deux appareils sont nécessaires pour atteindre l'étape 6, ce qui en fait un véritable 2-de-2. Retirez l'une des signatures partielles et l'agrégation ne pourra pas produire une signature que le contrat accepte.

Pourquoi la chaîne ne voit qu'une seule signature

Le détail qui rend la conception de SSP élégante est l'agrégation de l'étape 6. L'extension et le téléphone n'attachent pas chacun une signature distincte à l'opération. Leurs deux signatures Schnorr partielles se combinent — à la manière de MuSig2, sur la même courbe secp256k1 qu'Ethereum utilise déjà — en une seule signature Schnorr. Le smart account vérifie cette unique signature par rapport à une unique clé agrégée attendue.

Cela a deux conséquences sur lesquelles il vaut la peine de s'attarder :

• L'empreinte on-chain reste petite. La UserOperation porte une signature, pas deux. Il n'y a pas de liste de signataires à stocker ni à parcourir, ni de boucle de vérification par signataire. Le contrat effectue la même quantité de travail de validation que pour un signataire unique.
• La chaîne ne peut pas savoir qu'il s'agit de multisig. Ce qui arrive à l'EntryPoint ressemble à une opération signée ordinaire. L'application du 2-de-2 réside dans la façon dont la signature a été produite — à travers deux appareils — et non dans une quelconque structure multipartite visible sur la chaîne. Pour un observateur extérieur, le portefeuille se comporte comme n'importe quel autre smart account.

C'est là la différence entre l'approche de SSP et un multisig naïf qui publie N signatures distinctes et vérifie chacune. La mécanique consistant à faire du multisig de cette façon sur EVM est approfondie dans Le multisig EVM à la manière de l'abstraction de comptes.

Ce que chaque appareil protège réellement

Il vaut la peine d'être précis sur la propriété de sécurité, car c'est toute la raison d'être de l'architecture.

• Aucune clé seule ne peut déplacer des fonds. La clé 1 dans l'extension peut construire une UserOperation et signer sa moitié, mais une demi-signature s'agrège en quelque chose que le contrat n'acceptera pas. La clé 2 sur le téléphone peut approuver et signer sa moitié, mais elle ne peut ni initier ni achever un transfert à elle seule.
• Compromettre un seul appareil ne suffit pas. Un attaquant qui contrôle entièrement votre extension de navigateur ne peut toujours pas dépenser, car il ne peut pas produire la signature partielle de la clé 2 sans le téléphone. L'inverse vaut aussi. Le modèle de menace qu'une EOA à clé unique ne peut pas surmonter — une clé fuitée, perte totale — ne s'applique pas ici.
• L'approbation est explicite et sur un second écran. Comme l'étape 4 pousse la requête vers l'application SSP Key, vous voyez et approuvez l'opération sur un appareil physiquement distinct avant qu'elle ne puisse être agrégée et envoyée.

C'est la même propriété 2-de-2 décrite dans Qu'est-ce que le multisig 2-de-2 ?, réalisée sur les chaînes EVM par l'abstraction de comptes plutôt que par un opcode multisig natif.

Les avantages, récapitulés

En réunissant les fils, l'architecture offre aux utilisateurs de SSP une combinaison précise difficile à obtenir autrement :

• Une sécurité multisig sur chaque chaîne EVM prise en charge. La même conception 2-de-2 tourne sur Ethereum, Polygon, Base, BNB Smart Chain et Avalanche, parce qu'ERC-4337 est une norme au niveau du contrat et non une fonctionnalité propre à une chaîne.
• Une petite empreinte on-chain. Une seule signature agrégée signifie que le smart account valide comme un signataire unique, ce qui maintient la vérification légère.
• Une UX proche de celle d'un signataire unique. De votre côté, cela revient à approuver une transaction sur deux appareils, et non à constituer un comité. Il n'y a pas d'adresses de cosignataires à gérer ni de contrat multisig distinct à configurer à chaque transfert.
• Aucune modification de protocole requise. Comme tout repose sur ERC-4337, SSP obtient tout cela sans attendre que l'abstraction de comptes au niveau de la couche de base soit déployée.

Une note sur l'audit

Une architecture de sécurité ne vaut que par son examen. Les smart contracts de SSP ont été audités par Halborn en 2025. Un audit externe ne rend aucun système infaillible, mais c'est un signal de confiance significatif pour la logique du contrat qui applique la règle 2-de-2 décrite plus haut.

Où aller ensuite

Cet article a retracé l'abstraction de comptes de SSP de bout en bout. Pour approfondir la norme et les concepts environnants :

• L'abstraction de comptes depuis les premiers principes — pourquoi les EOA sont limitantes et ce que signifie l'abstraction de comptes.
• Qu'est-ce que l'abstraction de comptes (ERC-4337) ? — la norme prise isolément, y compris les rôles de la UserOperation, du bundler et de l'EntryPoint.
• Le parrainage du gas et les paymasters expliqués — comment un paymaster peut couvrir le gas d'une UserOperation.
• Le multisig EVM à la manière de l'abstraction de comptes — la mécanique du multisig sur EVM plus en détail.

Pour la spécification formelle, voir EIP-4337 ; pour l'effort plus large, la feuille de route de l'abstraction de comptes d'Ethereum suit la direction prise. À retenir : SSP transforme la promesse abstraite d'un account programmable en un portefeuille 2-de-2 concret, où deux appareils produisent une signature et où la chaîne ne voit qu'une opération valide.