2-of-2 vs 2-of-3 vs m-of-n multisig : choisir le bon seuil

Dans l'article précédent nous avons couvert ce qu'est le multisig : une règle de dépense où m clés sur n doivent signer avant que l'argent ne bouge. SSP vous met par défaut sur un 2-of-2 — deux appareils, les deux requis, pas de quorum à discuter. Ce default est correct pour la plupart des utilisateurs solo entre « premier millier de dollars » et « c'est devenu de l'argent réel pour moi ». Il n'est pas correct pour tout le monde.

Cet article est le sélecteur. Trois configurations couvrent l'écrasante majorité des setups multisig du monde réel : 2-of-2, 2-of-3 et 3-of-5 (ou plus). Chacune est sincèrement meilleure que les autres dans des conditions spécifiques, et sincèrement pire dans d'autres. À la fin de cet article vous devriez pouvoir répondre : quel m-of-n correspond à ce que j'essaie réellement de protéger ?

TL;DR

• 2-of-2 est le default du stack personnel. Le mieux pour un utilisateur avec deux appareils, faible surcoût de coordination, montants modestes. Tout le produit SSP est construit autour de cela.
• 2-of-3 est le mouvement quand un utilisateur veut planifier la perte d'une clé — perdre un téléphone, perdre un backup, scénarios de transmission familiale. La version « avec redondance » du multisig solo.
• 3-of-5 ou plus est la réponse quand plus d'une personne doit signer, quand la géographie compte, ou quand les fonds appartiennent à une société / DAO / family office plutôt qu'à une personne.
• Monter m n'ajoute pas que de la sécurité — cela ajoute du risque de liveness (plus de clés qui doivent être disponibles) et un coût de coordination. Le bon m-of-n minimise la somme des deux.
• Aller au-delà de 2-of-3 pour un utilisateur unique est généralement une erreur. La protection marginale est petite ; la peine opérationnelle, grande.

Les trois questions qui décident du m-of-n

Mettez de côté le threat modeling formel une seconde. En pratique, trois questions décident quelle configuration convient :

1. Qui doit signer ? Une personne ? Deux personnes ? Une équipe qui tourne ? Une organisation où les signataires vont et viennent ?
2. Quelle est la défaillance dominante contre laquelle vous vous protégez — perte ou vol ? Le multisig gère les deux, mais le bon rapport entre m et n favorise l'un par rapport à l'autre. Un n plus élevé signifie plus de redondance contre la perte ; un m plus élevé (par rapport à n) signifie plus de résistance au vol.
3. Quel est le coût opérationnel de perdre un signataire ? Si la réponse est « je ne peux pas accéder à mon téléphone pendant un jour », le coût est léger. Si la réponse est « le CFO est dans un avion alors que la paie doit partir », le coût est énorme.

Ces trois lignes se mappent assez proprement sur les trois configurations ci-dessous.

2-of-2 : le default solo-avec-redondance

Setup : Deux clés existent. Les deux doivent signer. Default de SSP — une clé dans votre extension de navigateur, une clé dans l'app mobile SSP Key.

Le mieux pour : Une personne, un portefeuille, deux appareils qui ne partagent pas une surface d'attaque (un laptop Mac et un iPhone, un Android et une machine Windows, etc.). La protection vient de la séparation des appareils : un malware sur le laptop ne peut pas atteindre le téléphone, et vice-versa.

Forces :

• Le plus bas coût de coordination de tous les multisig. Les deux appareils sont à vous, les deux sont généralement dans votre poche ou sur votre bureau.
• Élève massivement la barre pour le vol. Un attaquant qui a totalement compromis un de vos deux appareils ne peut toujours pas bouger d'argent. Il doit compromettre l'autre — presque toujours un OS différent, une chaîne d'attaque différente — pour gagner.
• Vous force à conserver deux seeds, dans deux endroits, avec deux backups distincts. C'est une bien meilleure posture par défaut que le typique setup seed-unique-sur-papier-dans-un-tiroir.

Faiblesses :

• Les deux clés sont porteuses. Perdez l'un ou l'autre appareil et sa seed et le portefeuille est mort. C'est pourquoi la check-list Self-Custody Fundamentals met tant de poids sur la sauvegarde des deux seeds séparément. Ce n'est pas optionnel en 2-of-2.
• Pas de quorum pour « voter contre » un mauvais signataire. Si les deux signataires sont vous, ce n'est pas un problème ; si vous partagiez un jour une clé avec une autre personne dans un 2-of-2, vous auriez chacun un pouvoir d'otage.

C'est la configuration que le post existant What is 2-of-2 multisig? déballe en détail. Lisez-le après celui-ci pour la mécanique propre à SSP ; cet article ne fait que calibrer quand c'est le bon choix.

2-of-3 : quand un utilisateur veut planifier la perte

Setup : Trois clés existent. N'importe lesquelles deux doivent signer. Disposition courante pour un utilisateur solo : une sur un appareil « chaud » pour l'usage quotidien, une sur un hardware wallet gardé à la maison, une sur un appareil de récupération gardé ailleurs (un coffre, la maison d'un parent, un coffre bancaire — quelque part de géographiquement séparé).

Le mieux pour : Une personne, mais quelqu'un qui a basculé dans « si un seul objet brûle, je veux quand même pouvoir récupérer ». Les utilisateurs self-custody entre ~10 000 $ et ~100 000 $ migrent souvent ici.

Forces :

• Survit à la perte (ou destruction) de n'importe quelle clé. Un incendie de maison mange votre hardware wallet ? Vous avez encore laptop + appareil distant — assez pour le quorum 2-of-3.
• Le vol de n'importe quelle clé n'est toujours pas suffisant — l'attaquant devrait compromettre deux sur trois. La séparation géographique rend la troisième clé bien plus difficile à atteindre.
• Fournit un chemin propre de transmission. Vous pouvez laisser la troisième clé à un membre de la famille ou à un avocat, d'une manière qu'ils ne peuvent pas agir unilatéralement (ils n'ont qu'une sur trois) mais peuvent la combiner avec une de vos clés restantes pour récupérer le portefeuille dans un scénario défini.

Faiblesses :

• Plus de clés à provisionner, sauvegarder, tester. Chacune a besoin d'une seed unique et d'un lieu de stockage unique. Seed phrase best practices est une lecture nécessaire avant de faire ça.
• Surface d'attaque légèrement plus grande — trois clés signifient trois endroits où un attaquant peut tenter de compromettre, même s'il doit en compromettre deux.
• Répétition de récupération plus complexe. Vous devriez périodiquement tester que vous pouvez réellement combiner deux des trois clés pour dépenser. C'est une corvée opérationnelle.

Un raccourci mental utile : le 2-of-2 vous protège contre l'attaque au prix d'être fragile à la perte. Le 2-of-3 vous protège contre les deux, au prix de plus de clés à gérer.

3-of-5 (et au-delà) : quand les équipes et trésoreries entrent en scène

Setup : Cinq clés existent, n'importe lesquelles trois doivent signer. Utilisé par les entreprises, partenariats, DAOs, family offices. Les cinq clés sont généralement distribuées entre des personnes, des rôles et des géographies.

Le mieux pour : Des fonds qui n'appartiennent pas à un seul humain. Partout où deux personnes ou plus doivent légitimement autoriser une dépense, et où le scénario « le signataire unique est en vacances » ne devrait pas pouvoir geler les opérations.

Forces :

• Aucune personne seule ne contrôle l'argent. Deux signataires compromis ou rebelles ne peuvent toujours pas bouger de fonds.
• Continuité opérationnelle. N'importe quelle personne peut être indisponible (malade, en voyage, licenciée) et les quatre autres ont toujours le quorum.
• Supporte naturellement la séparation des fonctions — un controller, un CFO, un CEO, un auditeur externe et un signataire chaud peuvent être autant de rôles distincts. Le seuil peut être ajusté pour correspondre à la gouvernance de l'entreprise.

Faiblesses :

• Le surcoût de coordination est réel. Faire signer effectivement trois humains sur cinq une transaction dans une fenêtre définie est sincèrement plus difficile que de faire signer un ou deux appareils dans votre propre poche.
• Chaque nouveau signataire ajoute de la surface d'attaque. Cinq clés signifient cinq appareils distincts, cinq procédures de backup distinctes, cinq plans de succession distincts pour quand un signataire part.
• Workflows custom. La plupart des portefeuilles grand-public ne livrent pas 3-of-5 par défaut ; vous passez généralement à des outils spécialisés (Safe, Casa, setups multisig custom) une fois ce seuil franchi. SSP Wave 1 est construit autour de 2-of-2 et n'est pas le bon endroit pour cette échelle.

Une variante courante — 2-of-3 avec signataires sociaux — se situe entre le 2-of-3 solo et le 3-of-5 corporate. Vous détenez deux clés ; un membre de la famille de confiance ou un avocat détient la troisième. Ils ne peuvent pas dépenser seuls (une clé ne suffit pas), mais ils peuvent vous aider à récupérer si vous perdez l'une des vôtres.

Ce que la taille corrige — et ne corrige pas

Passer de 2-of-2 à 2-of-3 à 3-of-5 n'est pas un curseur linéaire de « plus de sécurité ». Certaines propriétés s'améliorent ; d'autres empirent.

Augmenter n aide pour :

• La résilience à la perte (plus de clés veut dire plus de redondance).
• La planification de transmission.
• La disponibilité opérationnelle avec plusieurs humains.

Augmenter n nuit à :

• La quantité de travail d'hygiène de seed-phrase que vous devez continuer à faire pour toujours.
• Le nombre d'endroits où un attaquant doit échouer à attaquer, mais aussi le nombre d'endroits où il doit réussir — ce qui est parfois pire si les clés ne sont pas véritablement indépendantes.

Augmenter m (le seuil) aide pour :

• La résistance au vol (un attaquant a besoin de plus de clés).
• La minimisation de confiance entre signataires (n'importe quel sous-ensemble sous m ne peut pas agir).

Augmenter m nuit à :

• La liveness. Si m clés doivent être disponibles pour dépenser, alors avoir n - m + 1 clés hors-ligne fige le portefeuille. Un 4-of-5 qui demande à quatre humains de se coordonner est célèbre pour sa fragilité.

L'art est de choisir m et n pour que le coût de disponibilité d'avoir besoin de m signataires corresponde au bénéfice de sécurité d'avoir besoin de m signataires. Pour la plupart des utilisateurs solo, 2-of-2 tombe sur le point optimal. Pour la plupart des équipes, 3-of-5. Le cas intermédiaire — 2-of-3 pour l'utilisateur solo qui planifie la perte — est la configuration la plus sous-utilisée du self-custody retail.

Ce que cela signifie pour vous

Trois conclusions :

1. Default en 2-of-2 pour l'usage solo sous cinq chiffres. C'est pour cela que SSP est construit, ce que Meet SSP Wallet explique, et le setup à plus faible friction qui élève matériellement votre posture de sécurité.
2. Passez à 2-of-3 quand le coût de perdre une clé dépasse le coût de gérer trois. En gros : quand vous avez basculé dans « c'est de la vraie richesse », quand vous avez une question de transmission claire, ou quand vous avez déjà vécu une frayeur de récupération de justesse.
3. N'allez pas vers 3-of-5+ sauf à protéger des fonds qui appartiennent à plus d'une personne. C'est la bonne réponse pour les orgs et pas vraiment pour les individus — même ceux à patrimoine élevé tendent à utiliser 2-of-3 avec un assistant custodial plutôt qu'un vrai 3-of-5.

L'article suivant de cette série, BIP48 explained: the derivation path behind SSP, entre dans la façon dont un portefeuille 2-of-2 (ou 2-of-3) est réellement construit on-chain — le standard qui permet à plusieurs clés de coopérer et la raison pour laquelle la plupart des portefeuilles multisig modernes sont interopérables.