Une adresse de portefeuille semble être une chose simple : une chaîne que l'on copie, colle, et à laquelle on envoie de l'argent. Sur Bitcoin, c'est presque aussi simple. Sur Solana, placer un portefeuille partagé — un multisig — derrière une adresse est étonnamment difficile. Cet article explique pourquoi, et pose la question à laquelle le reste de cette série répond.
Ce qu'une adresse multisig doit promettre
Un portefeuille multisig est contrôlé par plusieurs clés, dont un nombre fixe doit être d'accord avant qu'un montant ne soit déplacé. Un multisig « 2 sur 3 », par exemple, comporte trois clés et exige que deux d'entre elles approuvent un paiement. Le but est de supprimer les points uniques de défaillance : vous perdez une clé, ou une clé est volée, et vos fonds restent en sécurité.
Pour que cela soit utile, l'adresse doit tenir deux promesses. D'abord, elle doit être connue à l'avance — vous voulez remettre à quelqu'un une adresse de dépôt avant d'avoir fini de configurer quoi que ce soit. Ensuite, elle doit être honnête : quiconque envoie de l'argent à cette adresse doit pouvoir avoir confiance que seul le groupe de clés convenu, selon la règle convenue, pourra jamais y dépenser. Retenez ces deux promesses. Elles sont le fil conducteur de tout ce qui suit.
Sur Bitcoin, l'adresse est la règle
Bitcoin fait paraître cela facile. Un multisig Bitcoin est décrit par un petit script : la liste des clés publiques plus la règle « M sur N ». Pour obtenir l'adresse, vous prenez ce script et le hachez. L'adresse (une adresse P2WSH) est littéralement le hachage des règles de dépense.
Cela a une conséquence discrètement puissante. N'importe qui peut calculer l'adresse hors ligne, sur un ordinateur portable sans internet, avant qu'une seule transaction ne soit diffusée. Il n'y a pas d'étape « créer le portefeuille » — le portefeuille n'a pas besoin d'exister sur le réseau pour recevoir de l'argent. Le script n'est révélé que plus tard, lors de la dépense des fonds, et le réseau vérifie que le script révélé correspond à l'adresse et qu'il y a assez de signatures valides. Adresse connue à l'avance : oui. Honnête : oui — parce que l'adresse découle de la règle elle-même, un ensemble de clés différent produit une adresse différente.
Sur Solana, une adresse est un compte qui doit être créé
Solana fonctionne autrement. Sur Solana, tout est un compte — un emplacement de stockage on-chain avec un propriétaire. Vos fonds vivent dans des comptes, les programmes vivent dans des comptes, et la configuration d'un multisig vit elle aussi dans un compte. Surtout, les comptes n'apparaissent pas gratuitement. Un compte doit être créé et payé explicitement : quelqu'un le finance avec une petite quantité de SOL appelée « loyer » pour que le réseau stocke ses données.
Un multisig sur Solana n'est donc pas seulement une adresse — c'est un compte contrôlé par un programme contenant la liste des membres et le seuil. Et ce compte doit être créé par une transaction avant que le multisig puisse faire quoi que ce soit. C'est la racine de la difficulté : un portefeuille partagé sur Solana comporte une étape de configuration que Bitcoin n'a tout simplement pas.
Les PDA : des adresses sans clé privée
Solana dispose bien d'un outil élégant pour cela, appelé Adresse Dérivée de Programme, ou PDA. Une adresse Solana normale possède une clé privée correspondante — quiconque détient la clé contrôle l'adresse. Une PDA est délibérément construite pour être hors de la courbe : c'est une adresse d'apparence valide pour laquelle aucune clé privée n'existe et ne peut exister. Personne ne peut signer pour elle personnellement.
À la place, une PDA est dérivée de manière déterministe. Vous prenez quelques valeurs d'entrée — appelées « graines » — plus l'identifiant d'un programme, vous les passez dans une fonction à sens unique, et il en sort l'adresse. Les mêmes graines et le même programme produisent toujours la même PDA, donc n'importe qui peut la reproduire. Et comme il n'y a pas de clé privée, seul le programme propriétaire peut autoriser des actions pour cette adresse, ce qu'il fait via un mécanisme appelé invocation inter-programmes avec invoke_signed : le programme présente les graines au runtime de Solana, et le runtime lui accorde l'autorité de signature pour la PDA. Aucune signature cryptographique n'est jamais produite — le droit d'agir vient de la connaissance des graines, pas de la détention d'une clé.
Une PDA est exactement le bon foyer pour un multisig : une adresse contrôlée par la logique d'un programme plutôt que par une seule personne. Jusqu'ici, tout va bien. Le difficile, c'est ce qui est choisi comme graines.
Le problème du financement avant la création
C'est ici que les multisigs dominants de Solana rencontrent un obstacle. Contrairement au modèle déterministe de Bitcoin, les multisigs les plus utilisés de Solana — Squads V4 en est l'exemple phare, mûr et fortement audité — dérivent l'adresse du multisig d'une valeur aléatoire fraîchement générée et choisie au moment de la création, et non de l'ensemble des membres. Dans Squads V4, cette valeur s'appelle une create_key, une clé éphémère produite lorsqu'un créateur exécute la transaction de création.
Dériver l'adresse d'une create_key aléatoire est un choix de conception délibéré et raisonnable — il contourne un cas limite gênant où deux groupes différents veulent exactement la même composition de membres. Mais il a deux conséquences qu'il vaut la peine de bien comprendre :
- Vous ne pouvez pas connaître l'adresse à l'avance. La graine n'existe pas tant que quelqu'un n'a pas exécuté la transaction de création, donc l'adresse non plus. Il n'y a aucun moyen d'imprimer une adresse de dépôt et de la financer avant la configuration — le problème du financement avant la création. La première promesse se brise.
- Le créateur est un point unique de confiance lors de la configuration. Un compte spécifique doit exécuter cette transaction de création et choisir cette valeur aléatoire. Pendant la brève fenêtre de configuration, vous faites confiance à cette partie pour le faire correctement.
Rien de tout cela ne rend Squads V4 peu sûr — c'est le multisig le plus éprouvé de Solana et il sécurise des sommes très importantes. C'est simplement une forme de confiance différente de celle de Bitcoin. L'adresse n'est plus « le hachage de la règle » ; c'est « ce que la transaction de création a produit ».
Ethereum a trouvé une voie intermédiaire
Ethereum a rencontré un problème similaire et y a répondu avec une fonctionnalité appelée CREATE2. Elle permet de calculer l'adresse d'un contrat intelligent avant que le contrat ne soit déployé, à partir d'entrées fixes. Des portefeuilles comme Safe l'utilisent pour vous donner ce qu'on appelle une adresse contrefactuelle : une adresse réelle et finançable que vous pouvez partager et sur laquelle recevoir de l'argent, tandis que le contrat réel est déployé de façon paresseuse — seulement quand les fonds doivent bouger pour la première fois. La norme plus récente d'abstraction de comptes, ERC-4337, formalise la même idée. Ethereum retrouve ainsi la promesse « connue à l'avance » même si, comme Solana, elle a besoin qu'un objet on-chain finisse par exister.
La question à laquelle cette série répond
Posez les trois modèles côte à côte. Bitcoin : l'adresse est le hachage de la règle — connaissable hors ligne, honnête par construction, sans étape de création. Ethereum : une adresse contrefactuelle — connaissable à l'avance, avec un déploiement différé. Les multisigs généraux de Solana : l'adresse provient d'un aléa du moment de la création — non connaissable à l'avance, avec un créateur en qui placer sa confiance lors de la configuration.
Voici donc la question. Solana a besoin de comptes, et les comptes ont besoin d'être créés — cela ne va pas disparaître. Mais un multisig Solana doit-il renoncer à la propriété de Bitcoin ? L'adresse pourrait-elle plutôt être dérivée purement de l'ensemble des membres et du seuil — la règle elle-même — de sorte qu'elle soit connaissable hors ligne, finançable avant la configuration, et honnête parce qu'un groupe de clés différent produit une adresse différente ?
C'est exactement la propriété que l'équipe SSP a intégrée à son propre programme de multisig Solana. Le prochain article montre comment : une adresse qui est l'ensemble des membres, un coffre que vous pouvez financer avant que quoi que ce soit ne soit enregistré on-chain, et une étape d'enregistrement qui n'a besoin d'aucun créateur. Le design a été lancé en même temps que la prise en charge de Solana dans SSP Wallet — voyez l'annonce de la version — et, conformément à la manière dont SSP traite la sécurité, le programme est actuellement uniquement sur devnet et en attente d'un audit externe avant le mainnet. Si le multisig lui-même vous est encore nouveau, commencez par ce qu'est un multisig et pourquoi il compte ; sinon, poursuivez votre lecture.
