Le 18 juillet 2024, SSP Wallet v1.6.0 a ajouté Ethereum — et SSP est devenu le premier portefeuille à livrer de véritables comptes Schnorr-multisig sur Ethereum en utilisant Account Abstraction ERC-4337. D'autres portefeuilles s'autoproclament « Ethereum multisig » en empilant un unique compte à propriété externe derrière une interface. SSP a choisi la voie difficile, pour que le même modèle 2-sur-2 qui protège Bitcoin dans SSP protège désormais aussi ETH.
TL;DR
- Ethereum (ETH) rejoint SSP comme chaîne de première classe.
- Les comptes sont des contrats intelligents conformes à ERC-4337, pas des EOA — l'application 2-sur-2 vit donc sur la chaîne.
- Deux signatures Schnorr s'agrègent en une seule avant d'atteindre Ethereum, gardant le gas prévisible.
- La bibliothèque de signature est open source sur npm :
@runonflux/aa-schnorr-multisig-sdk. - Le support des tokens ERC-20 est l'étape suivante ; cette version livre ETH lui-même plus les fondations AA qui sont en dessous.
Ce qui a atterri : le support d'Ethereum, par la voie difficile
La plupart des portefeuilles « supportent Ethereum » en générant un compte à propriété externe (EOA) — une seule clé privée, une seule signature, un seul point de défaillance. Ajouter du multisig par-dessus signifie généralement une politique logicielle côté portefeuille, pas une règle imposée sur la chaîne. La chaîne ne voit toujours qu'une clé, et celui qui la détient peut bouger les fonds seul.
SSP a refusé ce raccourci. Tout l'intérêt du modèle 2-sur-2 de SSP est que ni SSP Wallet sur l'ordinateur ni SSP Key sur le téléphone ne peuvent bouger les fonds tout seul — la cosignature est une propriété du compte, pas une convention d'interface. Pour préserver cela sur Ethereum, une EOA n'allait jamais suffire. Le compte Ethereum devait être un contrat intelligent qui exige deux signatures par construction. C'est exactement ce qui a été livré dans v1.6.0.
Ce que Schnorr multisig signifie ici
Les scripts UTXO de Bitcoin peuvent exprimer 2-sur-2 nativement — c'est ainsi que les chaînes existantes de SSP imposent la cosignature. Le modèle de comptes d'Ethereum ne le peut pas, pas sans aide. SSP comble ce fossé avec les signatures Schnorr.
Schnorr est un schéma de signature avec une propriété qui compte ici : deux signataires peuvent chacun produire une signature partielle, et ces partielles peuvent être combinées en une unique signature valide qui se vérifie sous une seule clé publique agrégée. Pour quiconque observe la chaîne, on dirait qu'un seul signataire a signé une seule fois. Pour SSP, deux appareils ont dû s'accorder. La profondeur cryptographique — agrégation de clés, coordination des nonces, rondes de style MuSig2 — est traitée dans notre article académique sur les signatures Schnorr et l'agrégation multisig si vous la voulez. Le résumé côté utilisateur est court : le même apairage SSP Wallet + SSP Key que vous utilisez déjà, désormais exprimé comme une signature Schnorr agrégée sur Ethereum.
Account Abstraction ERC-4337
Account Abstraction (AA) est le terme générique pour laisser les comptes Ethereum se comporter comme des portefeuilles programmables plutôt que de simples paires de clés. Dans le modèle standard d'Ethereum il existe deux types de compte : les EOA, contrôlés par une seule clé privée, et les contrats, qui ne peuvent pas initier de transactions par eux-mêmes. AA dissout cette distinction au niveau applicatif.
ERC-4337 est le standard Ethereum qui livre AA sans modifier Ethereum lui-même. Au lieu d'un hard fork, il définit un objet de transaction de plus haut niveau appelé UserOperation, un bundler qui les transforme en transactions Ethereum normales, et un contrat EntryPoint qui les valide. Votre « compte » est un contrat intelligent qui décide comment il veut authentifier les dépenses — pour SSP, cette règle d'authentification est : une signature Schnorr agrégée de SSP Wallet et SSP Key, ou rien. Pas de hard fork L1, pas d'opérateurs de nœuds spéciaux, pas d'hypothèses de confiance au-delà de ce qui est déjà déployé sur mainnet.
La bibliothèque open source
La couche de signature Schnorr-multisig n'est pas enterrée à l'intérieur de l'app SSP. Nous l'avons extraite comme bibliothèque réutilisable et publiée sous la même posture open source que le reste de SSP. Le SDK TypeScript vit sur npm sous le nom @runonflux/aa-schnorr-multisig-sdk ; les contrats Solidity d'Account Abstraction auxquels il s'apparie vivent dans le dépôt @runonflux/account-abstraction sur GitHub.
Si vous êtes développeur de portefeuilles, chercheur en sécurité ou simplement curieux de voir comment AA Schnorr-multisig se compose réellement sur Ethereum, les deux projets sont là pour être lus, forkés, et améliorés. Les pull requests et les issues sont les bienvenues — nous préférons durcir une bibliothèque partagée avec plus de regards plutôt que de laisser chaque portefeuille qui veut cette primitive la réinventer.
Ce que cela débloque
Pour v1.6.0 en particulier, la chaîne proposée est Ethereum lui-même — soldes ETH, transferts ETH, le même bouton du panneau Chains que vous utilisez pour toutes les autres pièces, désormais avec un compte AA derrière. La plomberie que pose cette version est la partie la plus difficile. Une fois que les comptes Schnorr AA 2-sur-2 existent et fonctionnent, tout solde de forme Ethereum devient atteignable.
Le support des tokens ERC-20 est l'étape naturelle suivante, et il est déjà sur la feuille de route — nous le couvrirons dans son propre post de newsroom à sa sortie. Pour aujourd'hui, le titre est qu'Ethereum est dans SSP, qu'il est dans SSP de la bonne manière, et que les fondations cryptographiques et de contrats intelligents en dessous sont open source sur npm et GitHub pour que quiconque puisse les inspecter.
Source : notes de version SSP Wallet v1.6.0.