Comprendre les portefeuilles multisignatures et leur…

Explication des portefeuilles multisignatures : un portefeuille à multi-signature n'envoie des fonds que lorsque M des N clés autorisées approuvent la même transaction, au lieu de se fier à une seule clé privée.

Ce design transforme la garde en un modèle opérationnel, avec un flux de proposition et de révision, une logistique des frais, et des choix d'implémentation spécifiques à la chaîne qui peuvent soit garder les fonds en sécurité, soit les laisser bloqués.

Principaux enseignements

• Un portefeuille multisig nécessite deux ou plusieursclés privéespour autoriser une transaction, généralement en utilisant un seuil de m sur n tel que 2 sur 3 ou 3 sur 5.
• Le flux de travail principal est un pipeline d'approbation : un signataire propose une transaction, d'autres signataires ajoutent des signatures, le portefeuille vérifie le seuil, puis la transaction est diffusée.
• Multisig on-chain intégré dans un protocole (commeBitcoinP2SH) se comporte différemment d'uncontrat intelligentportefeuille multisig surEthereum (comme le portefeuille Safe), y compris le risque de contrat et la compatibilité des dapps via ERC-1271.
• Multisig et MPC résolvent le "contrôle partagé" différemment : multisig laisse une trace d'approbation on-chain liée à des clés distinctes, tandis que MPC produit des signatures via un calcul off-chain sans jamais assembler une clé complète.

Comment les portefeuilles multisig changent le contrôle des clés

Un portefeuille à signature unique concentre l'autorité dans une clé privée, ce qui signifie qu'un compromis ou une clé perdue peut être terminal. Multisig change cette surface de contrôle en répartissant l'autorité sur plusieurs clés et en exigeant un seuil d'approbations avant que les fonds ne bougent.

C'est pourquoi multisig apparaît si souvent dans les discussions sur la sécurité des portefeuilles et dans les conversations plus larges sur les types de portefeuilles crypto expliqués. Ce n'est pas juste "plus de clés". C'est un ensemble de règles sur qui peut autoriser quoi.

Le modèle mental important est la gouvernance, pas la cryptographie. Une configuration multisig encode une politique d'approbation qui correspond à la manière dont une équipe, une famille ou unDAO se comporte déjà. Si le processus réel est "deux personnes doivent signer", un 2 sur 2 correspond à l'intention mais crée un risque de temps d'arrêt important si l'un des signataires disparaît.

Si le processus réel est "deux personnes signent, mais il doit y avoir un chemin de récupération", 2 sur 3 est le défaut commun car il tolère une clé manquante tout en empêchant le contrôle unilatéral.

Multisig se situe également à un endroit spécifique sur le spectre de la garde. C'est toujours un[non custodialmodèle de portefeuille lorsque les signataires contrôlent les clés et qu'aucun tiers ne peut déplacer des fonds de manière unilatérale. La différence est que le « propriétaire » est maintenant une politique de groupe plutôt qu'une seule personne.

Cette politique peut être mise en œuvre nativement par une chaîne, ou appliquée par un contrat sur des chaînes de contrats intelligents. Ce choix d'implémentation est à l'origine de nombreuses surprises opérationnelles.

Le modèle M-of-N et les flux de travail

La règle du seuil est l'ensemble du jeu : N est le nombre total de clés autorisées, et M est le nombre minimum de signatures requises pour approuver une transaction. Les configurations courantes correspondent parfaitement aux processus d'approbation réels : 2 sur 2 pour des partenaires égaux, 2 sur 3 pour de petites équipes avec une clé de secours, et 3 sur 5 pour un contrôle de type comité qui peut survivre aux absences.

Le flux de travail est important car le multisig est un pipeline d'approbation qui s'exécute chaque fois que des fonds sont transférés. Un flux typique suit une séquence ordonnée :

1. Créez une proposition de transaction. Un signataire autorisé rédige la destination.adresse, montant, et toute donnée d'appel. 2. Collecter les signatures. D'autres signataires autorisés examinent la proposition et la signent avec leurs clés privées. 3. Vérifier le seuil. Le portefeuille vérifie qu'au moins M approbations de signataires valides sont présentes. 4. Diffuser et exécuter. La transaction entièrement approuvée est envoyée au réseau pour confirmation.

Deux détails opérationnels tendent à décider si le multisig semble « sécurisé » ou « bloqué ». Le premier est la disponibilité des signataires : si M signataires ne peuvent pas répondre dans la fenêtre dont l'organisation a besoin, le portefeuille devient un goulot d'étranglement. Le second est le financement des frais.

L'EIP-86 a mis en lumière un point de douleur concret au début de l'histoire d'Ethereum : les opérations multisig peuvent nécessiter plusieurs transactions de ratification, et les participants peuvent avoir besoin d'ETH pour les frais afin de soumettre ces approbations. Ce n'est pas une note de bas de page théorique.

C'est le genre de friction qui apparaît lorsqu'une équipe essaie de déplacer des fonds sous pression temporelle et découvre que les signataires ne peuvent même pas payer pour approuver.

Multisig sur chaîne et contrat intelligent

Le multisig de style Bitcoin et le multisig de style Ethereum peuvent sembler similaires de l'extérieur, mais ils échouent différemment car ils sont construits différemment. Le multisig on-chain est un support natif du protocole, avec Bitcoin P2SH comme exemple canonique. Les conditions de dépense vivent dans les règles de script de la chaîne.

L'avantage est une surface d'attaque plus petite car il n'y a pas de code de contrat séparé à faire confiance. L'inconvénient est que l'ensemble des fonctionnalités est contraint par ce que le protocole de base prend en charge.

Le multisig de contrat intelligent est un animal différent. Sur Ethereum et des chaînes similaires, un multisig est souvent un portefeuille de contrat intelligent, avec le portefeuille Safe comme référence largement utilisée. Le contrat détientactifset applique les règles d'approbation dans le code. Cela débloque de la flexibilité, mais cela introduit un risque contractuel et un travail de compatibilité.

La compatibilité est là où le multisig d'Ethereum devient moins une question de signatures et plus une question de normes. De nombreuses applications s'attendent à un message signé d'un compte externe. Un contrat ne peut pas produire une signature ECDSA normale car il n'a pas de clé privée.

L'ERC-1271 est la poignée de main qui corrige cela : il définit une méthode isValidSignature(hash, signature) que les applications peuvent appeler lorsque le « signataire » est un contrat, et il exige de retourner la valeur magique 0x1626ba7e lorsque la validation réussit. Lorsqu'une dapp prend en charge l'ERC-1271, elle peut traiter les approbations d'un portefeuille de contrat comme une véritable autorisation.

Lorsqu'elle ne le fait pas, le multisig peut être bloqué dans des flux de travail qui dépendent de messages signés, comme les systèmes de commande hors chaîne.

Où le multisig est utilisé

Multisig apparaît chaque fois que le besoin réel est un contrôle partagé avec unauditLes trésoreries d'entreprise et de projet utilisent le multisig pour exiger des approbations explicites pour les transferts, de sorte qu'aucun opérateur unique ne puisse déplacer des fonds unilatéralement.

Les DAO et les fonds communautaires utilisent le multisig comme une couche de contrôle pragmatique, surtout lorsque le groupe souhaite une responsabilité visible pour qui a approuvé quoi.

Les arrangements similaires à un séquestre sont un autre ajustement naturel. Un schéma 2 sur 3 peut attribuer une clé à un acheteur, une à un vendeur et une à un arbitre neutre. Les fonds ne sont transférés que lorsque deux parties sont d'accord, ce qui réduit le besoin de faire confiance à un seul intermédiaire.

La même structure peut être utilisée pour des fonds de partenariat où aucune des parties ne souhaite que l'autre ait des droits de retrait unilatéraux.

Les configurations de sécurité personnelle sont un cas d'utilisation plus discret et souvent mal compris. Un 2-sur-3 peut répartir les clés entre différents appareils et emplacements, ou ajouter une sauvegarde par une partie de confiance pour la récupération. L'objectif n'est pas de créer un rituel de signature compliqué. L'objectif est de séparer les domaines de défaillance.

Si toutes les clés résident dans le même écosystème d'appareils, ou si toutes les clés sont détenues par la même personne "pour des raisons de commodité", l'étiquette multisig ne fait que du marketing, pas de la gestion des risques.

C'est également ici que la thèse du modèle opérationnel entre en jeu. Le bon m de n est celui qui correspond au processus d'approbation et au temps d'arrêt acceptable si un signataire disparaît. Un 2 sur 2 peut être parfait pour un compte joint jusqu'à ce qu'une clé soit perdue. Un 3 sur 5 peut être parfait pour la continuité jusqu'à ce que le groupe réalise que les approbations nécessitent désormais une planification.

Avantages en matière de sécurité et compromis opérationnels

Le bénéfice en matière de sécurité du multisig est simple : compromettre une clé ne suffit pas à déplacer des fonds. Cela réduit l'impact des attaques de phishing, des logiciels malveillants sur un seul appareil ou d'un seul initié devenant malveillant.

Cela crée également une responsabilité plus claire, car les approbations sont liées à des clés de signataire distinctes et peuvent être auditées dans le cadre de l'historique d'exécution du portefeuille.

Les compromis sont principalement opérationnels et se manifestent sous forme de modes de défaillance. La coordination est l'évidente, mais les problèmes les plus coûteux sont généralement procéduraux. Un examen informel conduit à signer la mauvaise charge utile, à envoyer à la mauvaise destination ou à approuver le mauvais nonce. Le multisig facilite la création d'une culture de liste de contrôle, mais ne l'impose pas par défaut.

La logistique des frais est l'autre piège récurrent. L'EIP-86 a explicitement souligné que les multisig peuvent nécessiter plusieurs transactions de ratification et que les participants peuvent avoir besoin d'ETH pour les frais. Cela soulève une question de politique à laquelle chaque groupe multisig doit répondre : qui est responsable de maintenir les signataires financés pour les approbations, et que se passe-t-il lorsqu'ils ne le sont pas.

Les approches de contrat de compte ont été motivées en partie par le désir que le contrat détienne de l'ETH et paie les frais, précisément parce que « chaque signataire a besoin degaz« est une hypothèse opérationnelle fragile. »

Le choix du seuil est le compromis final, et il n'est pas résolu en ajoutant plus de signataires. 2 sur 2 maximise le contrôle mutuel mais peut geler définitivement des fonds si une clé est perdue. 2 sur 3 est populaire car il intègre une redondance grâce à une clé de sauvegarde. 3 sur 5 est de niveau gouvernance lorsque la continuité en cas d'absences est plus importante que la rapidité.

Un N plus élevé peut augmenter l'échec de coordination, ce qui signifie que "plus de signataires" peut réduire la probabilité que le portefeuille puisse agir quand il en a besoin.

Comment le multisig se compare-t-il à l'MPC ?

Multisig et MPC visent tous deux à réduire le risque lié à une clé unique, mais ils le font avec des propriétés de responsabilité et d'opération différentes. Multisig utilise plusieurs clés complètes détenues par différents signataires, et le portefeuille combine les approbations sur la chaîne pour autoriser une transaction.

La traçabilité des approbations est explicite et liée à des identités de signataires distinctes, c'est pourquoi multisig est souvent préféré lorsque la transparence et l'auditabilité sont des exigences.

MPC divise une clé de signature en fragments et génère des signatures via un calcul hors chaîne, sans qu'aucune partie ne détienne jamais la clé complète. Cette architecture peut supporter une automatisation plus fluide et peut être plus agnostique vis-à-vis de la blockchain, ce qui est important pour les opérations multi-chaînes.

Le compromis est que le processus d'approbation n'est pas intrinsèquement une traçabilité d'audit sur la chaîne, signataire par signataire, comme c'est le cas avec multisig.

Le cadre de décision n'est pas 'lequel est le plus sécurisé' en tant que revendication universelle. Il s'agit de 'ce qui doit être prouvable sur la chaîne, et ce qui doit être rapide et opérationnellement fluide.' Si l'exigence est la gouvernance et une responsabilité claire pour les approbations, multisig s'adapte naturellement.

Si l'exigence est un débit opérationnel à travers de nombreuses chaînes avec une automatisation pilotée par des politiques, MPC s'adapte souvent mieux.

C'est aussi là que les détails d'implémentation comptent. Un multisig sur une chaîne avec un support natif se comporte différemment d'un multisig basé sur un contrat qui dépend de la compatibilité ERC-1271 pour les flux de travail de messages signés. Cette différence fait partie des types de portefeuilles expliqués, et c'est pourquoi deux produits peuvent tous deux être appelés 'multisig' tout en échouant de manières complètement différentes.

La prise

J'ai vu des équipes traiter le multisig comme une case à cocher, puis découvrir qu'elles avaient construit un pipeline d'approbation fragile. Le moment coûteux n'est pas le jour où le portefeuille est créé. C'est le jour où un signataire est en voyage, un appareil est hors service, et le groupe réalise que le seuil qu'ils ont choisi implique un budget de temps d'arrêt très réel.

La posture propre est de concevoir le multisig comme un système de contrôle de bureau : proposition, révision, signatures, vérification du seuil, diffusion, avec propriété pour le financement des frais et un plan pour la disparition des signataires. 2 sur 2 est maximal en contrôle et sujet à gel, 2 sur 3 est le défaut pratique car il a un chemin de récupération, et 3 sur 5 est ce qui est utilisé lorsque la continuité compte plus que la vitesse. Le nombre de signataires n'est pas la fonctionnalité. Le modèle opérationnel l'est.

Sources

• Cobo
• Propositions d'Amélioration d'Ethereum
• Propositions d'Amélioration d'Ethereum
• Moyen