Si vous avez suivi cette série, vous avez construit une image du multisig comme règle de dépense : m clés sur n signent, la chaîne impose le seuil, l'argent bouge. Nous avons parlé du protocole, des chemins de dérivation, et de l'horizon d'agrégation Schnorr. À chaque étape, la question à laquelle on répondait était : qui doit signer pour que l'argent bouge ?
Cet article porte sur une autre question : que se passe-t-il si l'un de ces signataires disparaît définitivement ? Multisig a une réponse. La social recovery en a une autre. Elles se ressemblent en termes marketing — toutes deux impliquent « plus d'une personne » — mais résolvent des problèmes différents. Cette pièce est la mise en regard, pour que vous arrêtiez de les confondre.
TL;DR
- Le multisig répond à qui peut dépenser en ce moment. Chaque transaction nécessite le seuil de cosigners pour signer. La blockchain elle-même l'impose.
- La social recovery répond à qui peut m'aider à revenir si je perds ma clé. Le portefeuille a un signataire normal (vous). Un ensemble séparé de « gardiens » peut collectivement approuver une transaction de récupération qui ré-attache le portefeuille à une nouvelle clé.
- Le multisig est actif à chaque dépense. La social recovery est passive jusqu'à ce que vous l'invoquiez — et même là, ce qu'elle fait c'est remplacer la clé de dépense, pas co-signer vos dépenses.
- Les deux vous protègent contre la perte d'accès. Seul le multisig vous protège réellement contre un attaquant qui gagnerait l'accès, parce que seul le multisig exige plusieurs signatures pour la dépense normale.
- Elles ne sont pas mutuellement exclusives. Les setups les plus résilients en pratique combinent une règle de dépense multisig avec un mécanisme de rotation de clé style social-recovery au cas où l'une des clés cosignataires serait perdue.
Ce que « social recovery » signifie vraiment
La social recovery, au sens que l'écosystème Ethereum a popularisé, vient des portefeuilles smart-contract — Argent a été la première preuve de concept, Safe et l'écosystème ERC-4337 l'ont rendue mainstream. Mécaniquement : votre portefeuille est un smart contract, contrôlé en fonctionnement normal par une clé de signature. Le contrat dispose aussi d'une fonction recoverWallet(newKey) qui ne peut être invoquée que par un quorum de gardiens que vous avez nommés à la création.
Les gardiens ne co-signent pas vos transactions quotidiennes. Ils ne peuvent pas dépenser en votre nom. Leur pouvoir est plus étroit : si vous dites un jour « j'ai perdu ma clé de signature, aidez-moi à la réinitialiser », ils peuvent collectivement signer une transaction de récupération qui change la clé contrôlante du portefeuille — de la perdue à une nouvelle. Après ça, vous repartez en dépenses normales avec la nouvelle clé.
Un setup typique pourrait avoir 5 gardiens, avec un seuil 3-of-5 pour la récupération. Le 3-of-5 est un seuil de récupération, pas un seuil de dépense. Pour les dépenses quotidiennes, il vous faut toujours juste votre seule clé.
Le péché originel de la social recovery est qu'elle exige un smart contract — ce qui veut dire qu'elle marche nativement sur Ethereum et les chaînes EVM (notamment via account abstraction / ERC-4337), mais ne se porte pas facilement sur Bitcoin ou autres chaînes UTXO. L'analogue le plus proche sur Bitcoin est un multisig où l'un des cosigners est « un service de récupération ou une personne de confiance » au lieu de votre propre appareil. C'est structurellement similaire mais conceptuellement différent — la personne de confiance signe chaque dépense dans la version Bitcoin, pas juste la récupération.
La mécanique : comment chacun gère « j'ai perdu une clé »
Imaginez le pire scénario en termes concrets : vous avez fait tomber votre téléphone dans l'océan, le papier de seed pour ce téléphone était dans votre portefeuille (lui aussi dans l'océan), et vous n'avez pas de sauvegarde fonctionnelle de la clé perdue.
Sous un multisig 2-of-2 (le default SSP) : le portefeuille est figé. Les deux signatures sont requises pour toute dépense, et il ne vous reste qu'un signataire. Aucun tour de smart-contract ne le sauvera ; la règle de dépense on-chain est 2-of-2, point final. Votre voie de récupération est la deuxième seed — la check-list self-custody rend les deux seeds porteuses précisément à cause de ce scénario.
Sous un multisig 2-of-3 (le setup solo-avec-redondance du billet sélecteur) : le portefeuille reste opérationnel. Vous avez deux clés sur trois ; la chaîne accepte cela comme quorum valide. Vous pouvez dépenser, vous pouvez déplacer les fonds vers un nouveau portefeuille 2-of-3 avec une troisième clé neuve, et la vieille clé perdue devient sans importance.
Sous un portefeuille de social-recovery : le portefeuille est aussi opérationnel, mais par un autre chemin. Vous n'avez pas un quorum de clés de signature — vous avez une clé de signature (la perdue). À la place, vous contactez vos gardiens et leur demandez de signer une transaction de récupération. Une fois leur seuil atteint, le portefeuille est ré-attaché à une nouvelle clé de dépense que vous contrôlez. Vous repartez ensuite en dépense à une clé.
Les deux récupérations se ressemblent superficiellement — « demander à un quorum de parties de confiance de répondre de moi » — mais elles font des choses différentes. La récupération multisig utilise un quorum existant qui a toujours été là. La social recovery active un quorum latent qui n'existe que pour gérer ce cas précis.
Contre quoi elles protègent (et contre quoi non)
Les deux architectures protègent contre la perte d'accès : on peut récupérer quand on perd une clé.
Là où elles divergent franchement, c'est sur la protection contre la dépense non autorisée.
Le multisig protège contre le vol de n'importe quelle clé unique. Si un attaquant phishe votre laptop, vide votre hot wallet, ou vole votre hardware — il a une clé sur n et ne peut pas bouger l'argent. Le seuil complet de dépense n'est pas atteint. Le post sur les sept modes de défaillance de la série précédente décrit à quel point ça compte vraiment : la compromission d'une seule clé est le vecteur d'attaque dominant en self-custody retail, et le multisig en est la réponse.
La social recovery ne protège pas du tout contre le vol d'une seule clé. Dans le modèle standard de social-recovery, votre unique clé de signature signe chaque transaction. Si cette clé est compromise, un attaquant vide votre portefeuille immédiatement — et le processus de social recovery n'aide pas, parce que les fonds sont déjà partis avant que les gardiens ne puissent intervenir. La récupération est un outil pour la perte, pas pour le vol.
On peut les empiler : un portefeuille smart-contract peut implémenter à la fois une règle de dépense multisig et un mécanisme de rotation social-recovery. La pile moderne ERC-4337 (voir l'explication account abstraction pour le contexte protocole) rend cela composable. Mais la social recovery pure, à elle seule, est une histoire de récupération — pas une histoire de sécurité.
Une comparaison pragmatique
| Propriété | Multisig (2-of-2 / 2-of-3) | Social recovery |
|---|---|---|
| UX quotidienne | Signer sur chaque appareil cosignataire | Signer sur un seul appareil |
| Résiste au vol d'une seule clé | Oui | Non |
| Résiste à la perte d'une seule clé | 2-of-2 : non ; 2-of-3 : oui | Oui (via gardiens) |
| Marche sur Bitcoin | Oui | Non (nécessite un smart contract) |
| Marche sur Ethereum / EVM | Oui (BIP48 / Safe) | Oui (Argent, Safe, ERC-4337) |
| Temps de récupération | Immédiat (signer avec le quorum restant) | Heures à jours (coordination des gardiens) |
| Hypothèse de confiance | Appareils/personnes détenant les clés cosignataires | Gardiens, à qui vous faites confiance pour ne pas comploter malicieusement |
| Visibilité on-chain | Visible comme output multisig (sauf si Schnorr-agrégé) | Ressemble à un portefeuille à clé unique la plupart du temps |
Deux schémas à remarquer dans ce tableau :
D'abord, le multisig est l'outil le plus large. Il marche sur plus de chaînes, résiste à plus de types d'attaque, et est actuellement mieux audité au niveau protocole. La social recovery est plus agréable côté UX quand c'est une option, mais elle est plus étroite.
Ensuite, les hypothèses de confiance sont différentes. Le multisig fait confiance au fait que les appareils détenant vos clés cosignataires ne sont pas tous compromis simultanément. La social recovery fait confiance au fait qu'un nombre suffisant de vos gardiens ne va pas comploter pour vous voler. Les deux sont des modèles de confiance raisonnables pour le bon utilisateur, mais ce ne sont pas les mêmes modèles.
Quand vouloir lequel
- Vous êtes un utilisateur solo avec un appareil, le reste du monde est un désert UX. La social recovery gagne. Le flux Argent / Safe / smart-account est sincèrement l'option self-custody à plus faible friction, et le scénario de perte de clé est celui que la plupart des débutants vivent vraiment. L'inconvénient — pas de protection contre le vol — est un que vous acceptez consciemment, idéalement en échange de soldes sous cinq chiffres.
- Vous êtes un utilisateur solo avec des avoirs non triviaux. Le multisig gagne. Le default 2-of-2 de SSP élève la barre contre le vol, la variante 2-of-3 ajoute la résilience à la perte, et les deux reposent sur des standards ouverts plutôt que sur une plateforme smart-contract spécifique. La friction est réelle mais proportionnée aux enjeux.
- Vous êtes une organisation, un partenariat ou un family office. Le multisig est obligatoire ; la social recovery est un complément ergonomique. Vous voulez un vrai contrôle conjoint sur chaque dépense, pas seulement sur la récupération. La plupart des orgs atterrissent sur une règle de dépense multisig avec une procédure séparée et soigneuse de rotation de clé quand un signataire part.
- Vous êtes quelque part au milieu, sur Ethereum. Empilez les deux. Un portefeuille smart-contract façon Safe peut faire tourner une règle de dépense multisig 2-of-3 et un flux de rotation social-recovery par-dessus. C'est là que va l'écosystème account abstraction.
Pour le setup SSP 2-of-2 spécifique que la plupart des lecteurs de cette série utilisent, la social recovery n'est pas une feature aujourd'hui — par design. Les deux cosigners sont les vôtres, l'histoire de récupération c'est « utilisez la deuxième seed », et la valeur est dans la résistance au vol peu coûteuse à acquérir. La social recovery résout un autre problème, celui qui vient après « je suis à l'aise avec la custody, maintenant facilitez-la ».
Ce que ça signifie pour vous
Trois conclusions à classer :
- Ce ne sont pas des substituts. Si un portefeuille vend « on a la social recovery, donc vous n'avez pas besoin de multisig », c'est du marketing, pas de l'ingénierie. La récupération protège contre la perte ; le multisig protège contre le vol. Les questions auxquelles ils répondent ne se chevauchent pas.
- Votre setup SSP 2-of-2 est un produit de règle de dépense. La perte d'un appareil se récupère depuis votre deuxième seed, pas depuis un quorum de gardiens. L'article de clôture de cette série — Modes de défaillance multisig et comment SSP les atténue — parcourt exactement comment cette récupération se déroule par mode de défaillance.
- Construisez vers l'avant, pas latéralement. Une fois que votre pile dépasse vraiment le 2-of-2, l'étape suivante est en général le multisig 2-of-3 avec une clé géographiquement séparée, pas la social recovery à la place du multisig. L'article 2-of-3 de cette série (sélecteur) prépare cette migration ; la pièce single-signer multisig qui suit explique comment SSP fait que ce setup futur ressemble à un seul portefeuille.
