Signatures Schnorr et agrégation multisig

Dans l'article précédent nous avons parcouru comment SSP construit réellement un portefeuille multisig on-chain : chemins BIP48, deux xpubs en ordre lexicographique, un redeem script que la chaîne vérifie. Toute cette mécanique est bâtie sur un schéma de signature particulier — ECDSA sur la courbe secp256k1, le même schéma avec lequel Bitcoin est sorti en 2009 et que la plupart des chaînes ont hérité.

Cet article porte sur l'autre schéma de signature — Schnorr — et ce qui change quand vous construisez du multisig au-dessus. Le gros titre, c'est que Schnorr supporte l'agrégation : sous le bon protocole, n signatures de n cosigners peuvent être combinées en une seule signature qui, on-chain, ressemble à une signature normale d'une clé unique. Le portefeuille se comporte comme un portefeuille multisig, mais la chaîne ne voit jamais la « multi-ité ». Ça a des conséquences réelles pour les frais, la confidentialité et les types de multisig qui deviennent économiquement viables.

TL;DR

• ECDSA est ce avec quoi la plupart du multisig actuel (y compris SSP aujourd'hui) signe. Chaque cosigner produit une signature séparée ; la chaîne les vérifie toutes. Coût et empreinte croissent avec n.
• Schnorr est un schéma de signature différent, activé sur Bitcoin via la mise à jour Taproot de 2021. Il a une propriété mathématique — la linéarité — qui manque à ECDSA. La linéarité permet d'additionner plusieurs signatures Schnorr en une seule signature valide pour une clé combinée.
• MuSig2 est le protocole moderne et pratique qui transforme cette propriété mathématique en protocole multisig utilisable. n cosigners exécutent un court protocole interactif, chacun contribuant à un tour de nonces et à une signature partielle ; le résultat est une seule signature Schnorr indiscernable d'une signature à clé unique.
• C'est un gain net du côté vérification — frais, gonflement de la blockchain et confidentialité y gagnent tous. Ce n'est pas un gain gratuit côté signature : l'agrégation demande un traitement soigneux des nonces, et une implémentation buggée peut fuiter des clés privées.
• SSP aujourd'hui utilise BIP48 + multisig ECDSA sur les chaînes qu'il supporte. La roadmap est d'ajouter des chemins Schnorr/MuSig2 là où la chaîne le supporte, sans casser le modèle 2-of-2 existant que les utilisateurs ont déjà.

Petit rappel : ce que fait une signature

Une signature numérique prouve deux choses à un vérificateur : ce message exact a été signé par quelqu'un détenant la clé privée pour cette clé publique. On-chain, le « message » est un hash de transaction, la « clé publique » est l'adresse (ou ce qui dérive l'adresse), et le « vérificateur » est chaque nœud du réseau. Si la signature passe, la transaction est valide ; sinon, elle est rejetée.

ECDSA — le schéma que Bitcoin et la plupart des chaînes EVM utilisent — est bien compris, conservateur et marche bien pour le cas d'un seul signataire. Le problème, c'est ce qui se passe quand vous voulez que plusieurs signataires autorisent la même transaction. ECDSA n'a aucun moyen de combiner les signatures. Si vous voulez du two-of-two, la chaîne doit stocker les deux signatures et vérifier les deux. Three-of-five, cinq signatures. La transaction grandit avec le nombre de cosigners.

What is multisig décrit la partie protocole — m clés sur n, règles de redeem, la chaîne imposant le seuil. Ce que cette pièce précédente ne s'attarde pas à expliquer, c'est le coût : sous ECDSA, toutes ces signatures vivent dans la transaction. Une transaction P2WSH 2-of-2 est sincèrement plus grande et plus chère à diffuser qu'une transaction single-sig avec le même effet.

Ce que Schnorr change

Les signatures Schnorr, originellement proposées à la fin des années 80, ont été évitées dans le design originel de Bitcoin en raison d'incertitudes liées aux brevets à l'époque. Elles sont mathématiquement plus propres qu'ECDSA sur un point précis : elles sont linéaires. Si s1 est une signature valide sur un message sous la clé P1, et s2 est une signature valide sur le même message sous la clé P2, alors s1 + s2 est une signature valide sur ce message sous P1 + P2. Tant les clés que les signatures s'additionnent.

Pourquoi c'est important : il devient soudain possible de combiner des signatures avant qu'elles touchent la chaîne. Au lieu de stocker deux signatures dans la transaction, vous en stockez une — la somme. Le vérificateur vérifie l'unique signature contre la somme des deux clés publiques, que les deux signataires peuvent calculer à l'avance. Du point de vue de la chaîne, la transaction résultante paraît indiscernable d'une transaction signée par une seule clé.

ECDSA ne peut pas faire ça. Les maths d'ECDSA impliquent un inverse multiplicatif qui casse la linéarité ; les sommes de signatures ECDSA ne sont pas des signatures valides. C'est pourquoi le multisig basé sur ECDSA doit expédier toutes les signatures individuelles on-chain. La chaîne inspecte chacune séparément.

Bitcoin a livré les signatures Schnorr (via BIP340) dans le cadre du soft fork Taproot de 2021. Les signatures elles-mêmes sont légèrement plus petites que les signatures ECDSA (64 octets contre ~71), mais l'enjeu bien plus important est ce que cette linéarité débloque quand vous la combinez au multisig.

MuSig2 — du multisig qui ressemble à une seule signature on-chain

La version honnête de « vous pouvez additionner des signatures Schnorr » est qu'il faut le faire avec soin. L'approche naïve — laisser chaque cosigner choisir un nonce, partager sa signature partielle, tout additionner — fuit du matériau de clé sous signatures répétées et est vulnérable à une classe d'attaques de « clé renégate ». Un protocole d'agrégation pratique doit se défendre des deux.

MuSig2 est le fruit d'environ une décennie de raffinement sur ce problème. C'est le standard de facto pour le multisig Schnorr n-of-n : au moment de la signature, les cosigners échangent deux tours de nonces, chacun produit une signature partielle, et l'un d'eux additionne les partielles en une signature agrégée finale. Le résultat est une seule signature Schnorr, valide contre une seule clé publique agrégée, indiscernable on-chain d'une signature à clé unique.

Quelques points importants sur MuSig2 :

• C'est actuellement n-of-n. Pour obtenir un vrai m-of-n (par ex. 2-of-3) sous agrégation, il faut de la machinerie additionnelle — FROST est la proposition de tête — et ça se met encore en production. Donc en 2026, ce que SSP agrégerait proprement, c'est le default 2-of-2. Les configurations 2-of-3 et plus du billet sélecteur utilisent encore principalement la visibilité on-chain à la ECDSA.
• Il faut toujours les deux cosigners en ligne pour signer. L'agrégation ne réduit pas le nombre de signataires nécessaires ; elle compresse juste la sortie finale. L'UX est la même qu'aujourd'hui — deux appareils signent la même transaction — mais l'empreinte on-chain du résultat est plus petite.
• Une implémentation MuSig2 buggée peut fuiter des clés. La gestion des nonces est subtile. Les déploiements en production s'appuient sur des bibliothèques bien auditées (le module MuSig2 de libsecp256k1, la pile rust-bitcoin, etc.) pour cette raison.

Ce que ça signifie pour SSP aujourd'hui

SSP aujourd'hui, sur chaque chaîne qu'il supporte, utilise du multisig ECDSA dérivé de BIP48. Deux appareils, deux clés privées, deux signatures séparées on-chain. C'est correct, c'est audité (par Halborn — voir la référence inside-ssp-2025-halborn-audits dans la pièce 2-of-2 existante), et c'est interopérable avec tout autre portefeuille compatible BIP48. L'inconvénient, c'est que vous payez le coût on-chain complet du 2-of-2.

La roadmap à partir d'ici, en clair : ajouter un chemin de code Schnorr/MuSig2 pour Bitcoin (où Taproot est actif et stable) qui signe le même portefeuille 2-of-2 en utilisant l'agrégation à la place. La sémantique de seuil du portefeuille ne change pas — les deux appareils doivent toujours signer. Les octets on-chain rétrécissent, et la transaction résultante ressemble à une dépense single-sig.

Pour l'utilisateur, ça se traduit surtout par :

• Frais Bitcoin légèrement plus bas par transaction.
• Confidentialité améliorée — le portefeuille arrête de crier « je suis un portefeuille multisig » aux analyses on-chain.
• Réconciliation plus rapide pour l'UI du portefeuille (un peu moins de données à récupérer et parser par adresse).

Ce n'est pas — et il vaut le dire clairement — une mise à niveau de sécurité. La cryptographie est de difficulté comparable, juste structurée différemment. La raison de l'adopter, c'est l'efficacité et la confidentialité, pas la sécurité brute.

Ce que ça signifie pour le coût, la confidentialité et l'UX

Trois endroits où ça atterrit une fois que l'agrégation est largement déployée sur une chaîne :

Coût. Bitcoin facture les frais à peu près à la taille de la transaction en vbytes. Une transaction ECDSA P2WSH 2-of-2 est significativement plus grande que la transaction Taproot-MuSig2 équivalente. Pour les portefeuilles à faible solde envoyant de petits montants, l'économie relative de frais peut être de 20–30 %. Pour les entreprises à haut throughput, les économies absolues annuelles sur les frais représentent du vrai argent.

Confidentialité. Aujourd'hui, quand un portefeuille diffuse une dépense P2WSH 2-of-2, ce fait est visible à toute personne consultant un explorateur de blockchain. Les sociétés d'analyse de chaîne sophistiquées clustérisent les adresses par schéma de dépense, et « cette adresse est multisig » est un signal de cluster fort. Une dépense Schnorr-agrégée ressemble exactement à une dépense single-sig. Le signal de cluster disparaît.

UX. L'UX de signature dans SSP — signez dans le navigateur, puis confirmez sur le téléphone — ne change pas. Les deux appareils produisent encore des signatures partielles ; le portefeuille les combine simplement avant de diffuser au lieu de diffuser les deux. Du point de vue de l'utilisateur, le seul changement visible, c'est « le portefeuille semble moins coûteux à utiliser ».

Il y a un gain d'UX plus profond à l'horizon, aussi. Une fois que l'agrégation m-of-n (via FROST ou similaire) est prête pour la production, vous pourriez imaginer un portefeuille SSP 2-of-3 — comme le setup solo de récupération que l'article précédent décrit — qui on-chain ressemble à un portefeuille single-sig normal. La troisième clé « de récupération » est vraiment une troisième clé de signature, mais la chaîne n'a jamais besoin de le savoir.

Ce que ça signifie pour vous

Trois conclusions :

1. Vous n'avez pas à penser à Schnorr pour utiliser SSP correctement. Le setup 2-of-2 que vous avez aujourd'hui est bâti sur du multisig ECDSA bien audité, et ça reste ainsi quelle que soit la façon dont l'agrégation atterrit. Le prochain article de la série (social recovery vs multisig) ignore délibérément l'agrégation parce que la question de qui peut dépenser est indépendante de à quoi ressemble la signature on-chain.
2. L'agrégation est un upgrade de « frais et confidentialité », pas de « sécurité ». Si vous voyez un jour un portefeuille vendre « MuSig2 = plus sûr », soyez sceptique. La sécurité cryptographique d'un MuSig2 bien implémenté est comparable à un multisig ECDSA bien implémenté ; les gains sont ailleurs.
3. Surveillez le support des chaînes, pas le marketing des portefeuilles. Schnorr est actif sur Bitcoin et est adopté dans le monde EVM via account abstraction. Les chaînes qui le supportent bien sont celles où SSP déploiera d'abord le multisig agrégé ; ailleurs, BIP48 + ECDSA reste le default correct et sûr.

L'article suivant dans cette série, Social recovery vs multisig, bascule le focus de la cryptographie aux opérations : quand opte-t-on pour le multisig et quand le social recovery l'emporte-t-il ? Les deux protègent contre la perte de clés ; ils répondent à des questions différentes. Pour un rappel rapide des appareils que SSP utilise aujourd'hui et pourquoi, Meet SSP Wallet reste le point de départ.