Les portefeuilles multi-signatures sont d'une simplicité trompeuse en théorie. Deux amis souhaitant cosigner des transactions, une trésorerie DAO nécessitant l'approbation du conseil, une entreprise avec de multiples parties prenantes — le concept est simple. La partie difficile n'est ni la cryptographie ni les mécanismes on-chain. C'est la coordination.
Comment les participants découvrent-ils une session de signature en attente ? Qui diffuse la transaction finale ? Que se passe-t-il quand Alice se déconnecte en pleine signature, que le coordinateur de Bob plante, et que Charlie ne se souvient plus s'il a déjà envoyé sa signature partielle ? Les solutions traditionnelles éludent ces questions d'un revers de la main : « utilisez un serveur de confiance » ou « coordonnez hors bande » ou « gérez simplement votre propre infrastructure ».
Ce ne sont pas des solutions — ce sont des capitulations vers la centralisation ou la charge opérationnelle. Mais la coordination pair-à-pair est résoluble avec une ingénierie soignée des systèmes distribués.
Cet article décrit comment nous avons construit une coordination multi-signatures véritablement décentralisée pour Lotus, et pourquoi cela compte pour l'écosystème des cryptomonnaies au sens large.
Qu'est-ce que MuSig2 et Pourquoi Est-ce Important ?
MuSig2 est un protocole de multi-signatures pour les signatures Schnorr. Plusieurs parties collaborent pour produire une signature unique et agrégée qui est cryptographiquement indiscernable d'une transaction à signature unique.
Les gains en confidentialité et en efficacité sont substantiels. Le P2SH multi-signatures traditionnel pour trois participants nécessite 99 octets de clés publiques et 210 octets de signatures — 309 octets au total. MuSig2 avec Taproot utilise 33 octets pour la clé publique et 64 octets pour la signature — 97 octets, soit une réduction de 69 %. Plus important encore, la transaction ne fournit aucune information sur le nombre de parties impliquées ni sur le seuil de signature.
Les propriétés de sécurité sont rigoureuses. MuSig2 prévient les attaques par clé malveillante grâce à des coefficients d'agrégation de clés dérivés de toutes les clés des participants. Il prévient les attaques par réutilisation de nonce (qui divulgueraient les clés privées) grâce à une gestion soignée des sessions et une génération de nonces déterministe. Le schéma est prouvablement sûr sous l'hypothèse du logarithme discret, la même hypothèse qui sécurise les signatures Schnorr et ECDSA à signature unique.
Combiné avec Taproot, MuSig2 permet des comportements on-chain sophistiqués qui ressemblent à de simples paiements :
- Canaux de paiement avec résolution de litiges complexe — le canal de type Lightning entre Alice et Bob apparaît comme une adresse standard
- Trésoreries DAO nécessitant l'approbation unanime du conseil — un multi-sig 3-sur-3 ou 5-sur-5 apparaît comme une clé unique
- Coffres-forts avec verrouillage temporel — des fonds bloqués pendant six mois sauf si toutes les parties acceptent une libération anticipée
- Dépenses conditionnelles — « payer Bob si ces conditions sont remplies, sinon rembourser Alice »
Toutes ces opérations apparaissent on-chain comme de simples transactions à signature unique, sauf si le chemin de script est utilisé. Ce n'est pas qu'un théâtre de confidentialité. Quand les transactions sophistiquées se fondent parfaitement dans l'activité quotidienne, l'analyse de blockchain devient fondamentalement plus difficile. Tout le monde en bénéficie.
Le protocole est standardisé sous le nom BIP-327, implémenté dans Bitcoin Core, et audité par des cryptographes. Mais voici le hic : MuSig2 nécessite deux tours de communication interactive.
Le Problème de la Coordination Centralisée
MuSig2 n'est pas un contrat intelligent que l'on déploie et oublie. C'est un protocole interactif nécessitant une orchestration soignée :
Tour 1 : Échange de Nonces Chaque participant génère des nonces en utilisant la génération déterministe RFC 6979 (avec une entropie aléatoire supplémentaire par défaut pour la sécurité en production) et partage les nonces publics. Chacun doit recevoir les nonces publics de tous les autres avant de poursuivre.
Tour 2 : Échange de Signatures Partielles Chaque participant crée une signature partielle en utilisant sa clé privée, le nonce agrégé et les données de la transaction. Ces signatures partielles sont combinées pour former la signature finale.
Diffusion Quelqu'un doit soumettre la transaction au réseau. Qui ? Que se passe-t-il s'il refuse ? Que se passe-t-il s'il plante ?
Cela crée un problème de coordination avec plusieurs sous-problèmes complexes :
Découverte et Gestion des Sessions
Quand Alice veut dépenser depuis une adresse 3-sur-3 qu'elle partage avec Bob et Charlie, comment son portefeuille informe-t-il Bob et Charlie qu'une session de signature a démarré ? La blockchain ne peut pas aider — tout l'intérêt est que rien ne se passe on-chain tant que la signature n'est pas complète. Les approches traditionnelles :
- Serveur coordinateur centralisé : tout le monde se connecte à un service central qui relaie les messages. Cela fonctionne jusqu'à ce que le serveur tombe en panne, censure des transactions, soit compromis, ou que l'opérateur décide de facturer des frais.
- Coordination manuelle : « Alice envoie un e-mail à Bob et Charlie avec le hex de la transaction. Bob répond avec sa signature partielle. Charlie est en vacances et ne répond pas pendant trois jours. » Cela ne passe pas à l'échelle.
- Infrastructure auto-hébergée : chacun gère un serveur avec une IP publique et coordonne via des connexions directes. Cela exclut les portefeuilles mobiles, les utilisateurs derrière un NAT, et quiconque ne souhaite pas gérer une infrastructure serveur.
Authentification et Sécurité
Comment les participants vérifient-ils que les messages proviennent bien des cosignataires attendus ? Dans un système décentralisé sans autorité centrale, chaque pair doit vérifier indépendamment l'authenticité des messages. La solution nécessite une preuve cryptographique : les messages sont signés avec la clé privée de l'expéditeur, et les destinataires vérifient la signature par rapport à la clé publique revendiquée avant de traiter le message.
Attaques par Rejeu et Réutilisation de Nonces
Qu'est-ce qui empêche Eve d'enregistrer le nonce d'Alice lors d'une session précédente et de le rejouer ? La réutilisation de nonces avec des messages différents divulgue les clés privées. Le protocole doit imposer des transitions de phase strictes : on ne peut pas soumettre une signature partielle avant que les nonces ne soient collectés, on ne peut pas réutiliser des nonces entre sessions, et on ne peut pas signer des transactions différentes dans la même session.
Pannes de Coordinateur et Basculement
Quelqu'un doit agréger les signatures partielles et diffuser la transaction. Le choix évident est de désigner un participant comme coordinateur. Mais que se passe-t-il quand il se déconnecte ? Attend-on indéfiniment ? Les participants s'accordent-ils manuellement sur un nouveau coordinateur hors bande ?
Limitation de Débit et Protection contre les DoS
Dans un système pair-à-pair, qu'est-ce qui empêche les acteurs malveillants d'inonder les sessions de signature avec des données parasites ? Il faut de la limitation de débit, du suivi de réputation et la capacité de bannir les pairs qui se comportent mal — mais sans autorité centrale.
La Solution Lotusia
Notre approche combine trois patrons éprouvés de systèmes distribués en une couche de coordination pair-à-pair cohérente :
1. Découverte Multi-Couches
Nous utilisons l'infrastructure éprouvée de libp2p avec trois mécanismes de découverte complémentaires :
DHT (Table de Hachage Distribuée) : les annonces de session sont stockées dans la DHT Kademlia (avec une réplication k=20) en utilisant un identifiant de session dérivé des signataires participants et du message. Quand Alice crée une session de signature, elle publie une annonce dans la DHT. Bob et Charlie peuvent la découvrir en interrogeant la DHT avec l'identifiant de session. Cela fournit un stockage persistant et décentralisé sans serveur central — les sessions restent découvrables même quand le créateur est hors ligne.
GossipSub : pour la découverte de signataires en temps réel, les participants publient des annonces dans des topics PubSub organisés par type de transaction (par ex. musig2:signers:SWAP). Quand Bob annonce sa disponibilité pour les échanges atomiques, Alice reçoit la notification en 10-100 ms si elle est abonnée à ce topic. Cela fournit une découverte de pairs instantanée sans les délais d'interrogation de la DHT.
Protocole de Messages Directs : une fois que les participants se sont découverts, les messages de coordination (nonces, signatures partielles) sont envoyés via le protocole de messages de libp2p avec un routage pair-à-pair. Les messages sont chiffrés en utilisant le protocole Noise de libp2p et routés à travers le réseau vers des pairs spécifiques plutôt que diffusés globalement.
L'approche en couches gère des scénarios divers : la DHT pour le stockage persistant des sessions et la découverte de participants hors ligne, GossipSub pour l'annonce de signataires en temps réel, et la messagerie directe pair-à-pair pour les tours de signature proprement dits.
2. Sécurité Cryptographique de Bout en Bout
Chaque message du protocole est signé cryptographiquement à l'aide de signatures Schnorr. Les annonces de session, les publicités de signataires, les demandes de signature et les participations portent toutes des signatures prouvant que l'expéditeur contrôle sa clé privée revendiquée. Cette couche d'authentification empêche l'empoisonnement de la DHT, les attaques par usurpation d'identité et la falsification de messages.
L'architecture de sécurité implémente une défense en profondeur à travers plusieurs couches indépendantes :
Limitation de Débit : les pairs peuvent envoyer au plus une annonce par 60 secondes. Les violations déclenchent une escalade automatique — 10 violations entraînent un bannissement permanent.
Résistance aux Sybil : chaque pair peut annoncer au plus 10 clés publiques par défaut (50 pour les identités vérifiées, 100 pour les utilisateurs institutionnels). Cela empêche un acteur unique d'inonder le réseau avec de faux participants.
Suivi de la Réputation des Pairs : le système maintient des listes noires (bannissements permanents) et des listes grises (suspensions temporaires) basées sur le comportement. Les signatures invalides, les violations de limite de débit et les tentatives de spam contribuent toutes aux scores de réputation qui déterminent le traitement des pairs.
Application des Phases du Protocole : des machines à états assurent l'ordre correct des messages. Les nonces ne peuvent pas être soumis avant l'établissement de la session. Les signatures partielles ne peuvent pas être envoyées avant la fin de l'agrégation des nonces. Les transactions ne peuvent pas être diffusées avant la finalisation de la signature.
Protection contre le Rejeu de Messages : chaque message inclut un numéro de séquence strictement croissant par signataire par session. Les numéros de séquence dupliqués ou désordonnés déclenchent un rejet et des pénalités de réputation.
Identité Basée sur le Burn (optionnel) : les participants peuvent ancrer leur identité à des transactions blockchain en brûlant de manière prouvable des XPI dans un format LOKAD-tagged spécifique. Ces identités permettent la rotation de clés sans perte de réputation — l'identité est liée à (txId, outputIndex), pas à des clés éphémères, et nécessite des périodes de maturation (144 blocs pour l'inscription, 6 blocs pour la rotation) pour prévenir les attaques temporelles. Dans une implémentation future, cela pourrait devenir un composant obligatoire pour établir la réputation des pairs.
3. Élection Déterministe du Coordinateur
C'est la pièce qui rend le basculement élégant. Au lieu de désigner manuellement un coordinateur, tous les participants exécutent le même algorithme déterministe.
La méthode d'élection par défaut est le tri lexicographique :
function electCoordinator(signers: PublicKey[]): ElectionResult {
// Sort public keys by binary buffer comparison
const sorted = signers
.map((pk, idx) => ({
originalIndex: idx,
publicKey: pk,
buffer: pk.toBuffer(),
}))
.sort((a, b) => a.buffer.compare(b.buffer))
// First in sorted order becomes coordinator
return {
coordinatorIndex: 0,
coordinatorPublicKey: sorted[0].publicKey,
sortedSigners: sorted.map(item => item.publicKey),
// ... index mappings and election proof
}
}
Chacun fournit les mêmes clés publiques, chacun les trie de manière identique, chacun sélectionne la première — pas de vote, pas de communication, pas d'ambiguïté. Le tri correspond exactement à la façon dont l'agrégation de clés de MuSig2 ordonne les participants, assurant la cohérence tout au long du protocole.
Quand le coordinateur plante ou refuse de diffuser ? Le système bascule automatiquement vers le participant suivant dans l'ordre trié. Cela continue jusqu'à N-1 pannes, ce qui signifie qu'un multi-sig 3-sur-3 ne devient injoignable que si les trois participants sont simultanément hors ligne.
Le déterminisme est critique. Dans les systèmes distribués, le consensus coûte cher. Mais quand on peut prendre une décision sans coordination — parce que chacun calcule indépendamment la même réponse — on élimine des classes entières de modes de défaillance. L'implémentation supporte également les méthodes d'élection basées sur le hachage, le premier signataire et le dernier signataire pour des cas d'usage spécifiques.
Ce que Cela Permet
Ces patrons se combinent pour supporter des cas d'usage qui nécessitaient auparavant une infrastructure centralisée :
Trésoreries Multi-Signatures : des comptes partagés 2-sur-2 jusqu'aux trésoreries de conseil 10-sur-10 (tous n-sur-n), avec un basculement automatique du coordinateur assurant la capacité de dépense même lors de pannes partielles.
Canaux de Paiement : des canaux bipartites (Alice ↔ Bob) où chaque partie peut initier des mises à jour du canal, et le canal reste opérationnel même si le logiciel coordinateur d'une partie plante.
Échanges Atomiques : de véritables échanges inter-chaînes pair-à-pair où les participants coordonnent la signature simultanée des deux côtés de l'échange sans tiers.
Coffres-Forts à Verrouillage Temporel : des fonds nécessitant la signature de tous les participants avant un délai, une signature unique après — avec la coordination multi-sig se déroulant de manière transparente en arrière-plan.
Protocole de Confidentialité SwapSig : notre équivalent de CoinJoin où plusieurs parties se coordonnent pour créer une seule transaction avec des entrées et sorties fusionnées, brisant la traçabilité on-chain tout en maintenant la vérification individuelle des signatures. Un futur article de blog fera une analyse approfondie de SwapSig.
L'infrastructure est à usage général. Tout ce qui nécessite une signature multi-parties interactive peut l'utiliser.
Implications pour l'Écosystème des Cryptomonnaies au Sens Large
Cette implémentation est agnostique en termes de cryptomonnaie. La couche de coordination opère indépendamment du consensus blockchain — du pur réseau P2P et du passage de messages cryptographiques. Bitcoin peut l'adopter pour le multi-sig Taproot. Ethereum peut l'utiliser pour les signatures à seuil dans l'abstraction de comptes. Toute cryptomonnaie supportant les signatures Schnorr peut intégrer cette infrastructure. Les canaux Lightning, les échanges atomiques, les protocoles de confidentialité, la gouvernance DAO et les opérations DeFi nécessitent tous une coordination multi-parties interactive. La même infrastructure résout tous ces problèmes.
Plus important encore, cela prouve que la coordination décentralisée est viable pour les systèmes en production. L'industrie a opté par défaut pour des coordinateurs centralisés non pas parce que la coordination P2P est impossible, mais parce que personne n'avait livré une implémentation fonctionnelle. Quand une infrastructure réutilisable existe — comme TCP/IP pour le réseau ou TLS pour le chiffrement — les développeurs cessent de traiter le problème comme optionnel. Cela change l'attente de base : la coordination décentralisée devient la norme plutôt que l'exception.
État de l'Implémentation et Prochaines Étapes
L'implémentation est complète et fonctionnelle. Plus de 91 tests valident l'implémentation du protocole, l'élection du coordinateur, les scénarios de basculement, l'authentification des messages et la protection contre le rejeu. Le code est en développement actif depuis des semaines et gère les cas limites que nous avons découverts lors de tests approfondis.
La gestion des connexions est correctement isolée. Votre portefeuille maintient des connexions P2P générales vers le réseau Lotus, et celles-ci sont séparées des connexions de signature spécifiques à la session. Les limites de connexion du portefeuille ne bloqueront pas les sessions multi-sig, et l'activité multi-sig n'épuisera pas vos emplacements de pairs généraux.
La clé publique agrégée MuSig2 devient la clé interne Taproot. Les arbres de scripts complexes (pour les conditions de repli ou les verrouillages temporels) restent cachés sauf s'ils sont dépensés via le chemin de script, ne révélant que la branche utilisée.
L'implémentation réside dans lotus-sdk, notre SDK TypeScript moderne pour Lotus. Des exemples fonctionnels démontrent :
- La signature 2-sur-2 basique avec découverte automatique
- L'élection du coordinateur multi-parties et le basculement
- L'intégration Taproot avec les dépenses par chemin de clé et chemin de script
- La gestion des sessions et la protection contre le rejeu
La documentation technique couvre les décisions d'architecture, les considérations de sécurité, l'utilisation de l'API et les procédures de test.
La Voie à Suivre
MuSig2 a résolu le problème mathématique des signatures Schnorr multi-parties de manière élégante et prouvable, mais l'infrastructure de coordination est restée centralisée. Cette implémentation prouve que la coordination pair-à-pair est praticable. L'infrastructure est à usage général et réutilisable — construisez-la une fois, utilisez-la partout. La technologie devrait enrichir les relations humaines, pas les entraver ou les remplacer.
Vient maintenant la partie critique : l'expérimentation et l'itération. Le logiciel mûrit par l'usage réel, pas par la spéculation. Découvrez comment fonctionne la réputation communautaire en pratique sur les profils sociaux Lotusia, ou lisez comment nous classons le contenu. Installez lotus-sdk, expérimentez avec les exemples, cassez le protocole, signalez les problèmes. L'usage en conditions réelles révélera les cas limites et éclairera la prochaine itération. Lotus a toujours été une question de bien faire les choses. La Tortue Lotusienne avance lentement, mais délibérément, vers la victoire ; un pas prudent à la fois.
Ressources :
- Documentation MuSig2 P2P - Référence complète de l'API et exemples
- Dépôt lotus-sdk - Code source et suite de tests
- Spécification BIP-327 - Spécification du protocole MuSig2
- Documentation Lotus - Guides blockchain et développeur
Communauté :
- Discord - Discussion technique en temps réel
- Telegram - Discours communautaire
- GitHub Issues - Signalement de bugs et demandes de fonctionnalités