Portefeuilles MPC contre multisig

Les portefeuilles MPC comme les portefeuilles multisig promettent le même titre : aucun point unique de compromission. Tous deux tiennent parole. Mais ils y parviennent par des chemins différents, et ces chemins ont des conséquences différentes sur ce qui arrive quand les choses tournent mal — le seul moment où un modèle de sécurité compte vraiment.

Cet article est le face-à-face technique. Si vous voulez d'abord le panorama des choix d'autoconservation, comparer les options d'autoconservation couvre l'ensemble du terrain, portefeuilles matériels et simples phrases de récupération compris.

Deux réponses différentes au même problème

Le problème s'énonce de la même façon dans les deux cas : un secret unique qui contrôle tout est inacceptable, il faut donc répartir l'autorité.

Le MPC partage la clé. Il existe conceptuellement une clé privée, mais elle n'est jamais assemblée nulle part. Des parts d'elle vivent en des lieux différents, et un protocole cryptographique permet à ces parts de coopérer pour produire une signature sans qu'aucune partie n'apprenne la clé entière.

Le multisig exige plusieurs clés. Il existe véritablement plusieurs clés privées indépendantes. L'adresse encode une règle — tant de ces clés doivent signer — et la blockchain impose cette règle lors de la validation de la transaction.

La distinction paraît académique. Elle ne l'est pas. L'une est un fait de cryptographie ; l'autre un fait de blockchain. Ce que la chaîne sait détermine ce qui arrive quand une pièce du système lâche.

Comment le MPC fonctionne réellement

Le MPC — calcul multipartite, ici le plus souvent des schémas de signature à seuil — permet à plusieurs parties de calculer conjointement une signature sur un message alors que chacune ne détient qu'une part de la clé de signature. Le NIST maintient un projet de cryptographie à seuil si vous voulez le traitement formel.

La sortie est une signature unique et ordinaire. On-chain, la transaction d'un portefeuille MPC est indiscernable d'une transaction signée par une personne avec une clé. Cela présente de vrais avantages : cela fonctionne sur toutes les chaînes, coûte autant qu'une transaction à signature unique et ne révèle rien de votre dispositif de sécurité à qui observe la chaîne.

La conséquence de cette même propriété appelle la prudence. Comme la chaîne voit une signature normale, la chaîne n'impose rien non plus de votre politique. Combien de parts existent, qui les détient et combien doivent coopérer sont des faits relatifs au logiciel et aux serveurs, pas au registre. Changez le logiciel et vous changez la politique.

La deuxième chose à examiner est la garde des parts. Beaucoup de portefeuilles MPC grand public conservent une part sur l'infrastructure du fournisseur. C'est souvent ce qui rend possible l'expérience de récupération sans friction — et cela signifie aussi que l'existence et la coopération continues du fournisseur sont des éléments porteurs de votre montage. Certains designs atténuent bien cela, avec des parts exportables ou des voies de sauvegarde indépendantes. La question n'est pas de savoir si le MPC peut être bien fait ; c'est de savoir si le produit précis que vous envisagez l'a fait d'une manière que vous pouvez vérifier.

Comment le multisig fonctionne réellement

Dans le multisig, la politique fait partie de l'adresse. Sur Bitcoin et les autres chaînes UTXO, l'adresse dérive d'un script qui nomme les clés publiques et le seuil ; une dépense qui ne porte pas assez de signatures valides est simplement invalide, et tous les nœuds du réseau la rejettent. Sur les chaînes à contrats intelligents, l'équivalent est un compte dont le code n'agit pas sans les approbations requises.

Personne n'a à être digne de confiance pour appliquer la règle, parce qu'appliquer la règle est ce que fait le réseau. Si tous les logiciels de portefeuille impliqués disparaissaient demain, la règle tiendrait encore, et quiconque dispose des clés et d'un outil compatible pourrait toujours dépenser.

Les coûts sont réels aussi. Vous gérez plusieurs clés plutôt qu'une, les sauvegardes se compliquent, et la transaction est plus volumineuse — sur Bitcoin, plus de signatures signifie plus d'octets et des frais légèrement supérieurs. Votre politique est également visible on-chain, ce qui est une considération de confidentialité : un observateur peut voir qu'une adresse est en 2 sur 3 même s'il ne voit pas qui détient quoi.

Qu'est-ce que le multisig et pourquoi cela compte traite le modèle plus en profondeur.

Où se situe SSP, précisément

SSP est un multisig 2 sur 2, mais l'honnêteté impose ici un détail, car l'implémentation n'est pas identique sur toutes les chaînes.

Sur Bitcoin et les autres chaînes UTXO, c'est du multisig natif au niveau du script via BIP-48. Deux clés, un script, imposé par le consensus.

Sur Ethereum et les autres chaînes EVM, il n'existe pas de script natif équivalent, aussi SSP emploie-t-il un compte intelligent qui vérifie une signature Schnorr agrégée produite à partir des deux clés. Vos deux appareils exécutent un protocole de type MuSig2, et la chaîne voit une signature — mécaniquement, cela ressemble davantage, par la forme, au MPC qu'à un script multisig Bitcoin.

La distinction qui compte n'est pas « agrégée ou non ». Ce sont ces deux faits, valables sur toutes les chaînes prises en charge par SSP :

• Les deux clés sont générées sur vos appareils et détenues par vous seul. SSP ne détient aucune part, aucune clé et aucun secret partiel. Il n'existe sur nos serveurs aucune part à perdre, à réquisitionner ou à retenir en otage.
• L'exigence est on-chain. Sur EVM, le code du compte intelligent n'autorise aucune transaction sans une signature que seules vos deux clés peuvent produire. Ce code est déployé, public et audité — ce n'est pas une politique que notre logiciel choisit d'appliquer.

Sur Solana, c'est un programme on-chain sans créateur ni clé d'administration, où l'adresse du coffre est elle-même une empreinte de l'ensemble des membres et du seuil. Mécanisme différent, même garantie.

Si la cryptographie de l'agrégation vous intéresse, signatures Schnorr et agrégation multisig explique comment une signature peut exiger deux clés.

Modes de défaillance côte à côte

On compare le mieux des modèles de sécurité en demandant ce qui casse.

Un appareil est compromis. Les deux modèles tiennent. L'attaquant a une part ou une clé et ne peut pas signer seul.

Le fournisseur disparaît. Le multisig tient — les clés et la règle on-chain suffisent. Le MPC ne tient que si vous pouvez obtenir et utiliser vos parts sans le logiciel du fournisseur, ce qui dépend entièrement de la conception.

Le fournisseur est contraint d'agir. Si un fournisseur détient une part, cette part peut potentiellement être produite sous contrainte légale, et selon le schéma cela peut suffire, avec une autre part, à déplacer des fonds. Si un fournisseur ne détient rien — comme chez SSP, où les deux clés sont les vôtres — il n'y a rien à contraindre.

Vous perdez une clé ou une part. Cela dépend du seuil, pas de la technologie. Un montage 2 sur 3, de l'un ou l'autre type, tolère une perte ; un montage 2 sur 2, de l'un ou l'autre type, non. Que se passe-t-il si l'une de vos clés est compromise parcourt spécifiquement le cas SSP.

Le logiciel du portefeuille vous ment sur ce que vous signez. Aucun modèle n'aide ici, et il faut le dire clairement. Répartir l'autorité protège d'une clé volée ; cela ne protège pas d'approuver la mauvaise transaction. C'est pourquoi la question intéressante pour les deux modèles est ce que vos appareils vérifient indépendamment avant de signer — décoder la transaction brute plutôt que se fier à la description qu'en donne un serveur.

Où chacun l'emporte

Le MPC l'emporte sur les chaînes dépourvues de bonnes primitives multisig, sur la taille de transaction et les frais, sur la confidentialité du dispositif, et souvent sur l'expérience utilisateur — en particulier la récupération, où un produit MPC bien conçu peut être nettement plus accueillant que de jongler avec plusieurs sauvegardes de phrases.

Le multisig l'emporte sur la vérifiabilité. La règle est dans le registre. Vous n'avez pas à croire une description du modèle de sécurité ; vous pouvez lire l'adresse ou le contrat et voir la politique. Il l'emporte aussi sur l'indépendance : un montage multisig avec des clés que vous détenez n'a aucune entreprise dans son modèle de confiance.

Il n'y a nulle contradiction à préférer des réponses différentes selon les usages. Un petit solde du quotidien dans un portefeuille MPC bien construit et une position longue durée dans un multisig aux clés rangées séparément forment un arrangement parfaitement cohérent.

Quoi demander avant de vous engager

Quel que soit votre penchant, ces quatre questions séparent une bonne implémentation d'une mauvaise.

1. Qui détient chaque clé ou part, et puis-je toutes les obtenir ? Si la réponse honnête comporte « le fournisseur, et non », vous avez choisi un modèle avec contrepartie.
2. Que se passe-t-il si le fournisseur disparaît demain ? Il devrait exister un chemin documenté qui ne passe pas par lui. Testez-le avant d'en avoir besoin.
3. Où vit la politique ? Dans un script ou un contrat on-chain, ou dans un logiciel ? Les deux peuvent convenir, mais un seul survit au changement du logiciel.
4. Que vérifie chaque appareil avant de signer ? Une seconde clé n'apporte rien si les deux appareils signent aveuglément ce qu'un serveur leur envoie. Modes de défaillance du multisig et comment SSP les atténue passe en revue ce point et les autres façons dont un montage à plusieurs clés peut être sapé en pratique.

Si vous voulez le modèle sur lequel SSP est bâti expliqué depuis le début, commencez par qu'est-ce que le multisig 2 sur 2. Et si l'inquiétude qui vous amène est de perdre une clé plutôt que d'en perdre le contrôle, récupération sociale contre multisig couvre l'autre famille de réponses.