Le portefeuille multisig Solana dont l'adresse est l'ensemble des membres
Un portefeuille multisig a besoin de deux clés ou plus pour approuver toute dépense. Sur Bitcoin, l'adresse du portefeuille est simplement un hachage de ses propres règles : la liste des clés publiques et le nombre de « combien de signatures sont requises ». Vous pouvez calculer cette adresse sur un bloc-notes, la distribuer et recevoir des fonds bien avant que quiconque ne touche la blockchain.
Solana, traditionnellement, ne peut pas faire cela. Comme l'explique le premier article de cette série, les multisigs dominants de Solana vous demandent d'exécuter une transaction de création avec une part d'aléa choisie par le créateur avant même que l'adresse du portefeuille n'existe. Le propre programme multisig Solana de SSP adopte plutôt l'approche de Bitcoin. Il est auto-initialisé : l'adresse du portefeuille est l'ensemble des membres.
Une remarque d'emblée : le programme multisig Solana de SSP est open source (RunOnFlux/Solana-Multisig) et fonctionne actuellement uniquement sur le devnet — le réseau de test de Solana. Un déploiement sur le mainnet dépend d'un audit de sécurité externe.
Deux adresses : la multisig et le vault
La conception de SSP utilise deux adresses distinctes pour chaque portefeuille multisig.
L'adresse multisig détient les règles — la liste triée des clés des membres, le seuil (le M de « M-sur-N ») et un compteur de transactions proposées. Elle appartient au programme de SSP.
L'adresse du vault détient l'argent — SOL et tokens SPL. Elle appartient au System Program intégré de Solana et ne stocke aucune donnée propre. Le vault est l'adresse de dépôt : celle que vous donnez à quiconque veut vous payer.
Les deux sont une Program Derived Address, ou PDA — une adresse sans clé privée, délibérément placée hors de la courbe cryptographique pour qu'aucune clé ne puisse jamais la contrôler. Seul le programme qui l'a dérivée peut autoriser des mouvements depuis elle. Ce détail compte à la fin.
Comment l'adresse est calculée à partir des membres
C'est précisément cette partie qui rend le portefeuille auto-initialisé. Pour dériver l'adresse multisig, en langage simple : prenez l'étiquette littérale multisig, un hachage SHA-256 de la liste triée des membres et le seuil ; puis introduisez cela, avec l'ID de programme de SSP, dans la fonction de dérivation d'adresses de Solana. Trois détails méritent l'attention.
Les membres sont d'abord triés et dédoublonnés. Un portefeuille 2-sur-3 avec les membres A, B, C produit exactement la même adresse, que vous les listiez C, A, B ou B, C, A. L'ordre n'importe pas ; seul l'ensemble importe.
Le hachage complet de 32 octets est utilisé — jamais une version raccourcie. Tronquer le hachage ouvrirait une attaque réelle : un attaquant pourrait rechercher un ensemble de membres différent qui hache vers la même valeur raccourcie, puis enregistrer ses propres membres à votre adresse et vider tout fonds que vous auriez préchargé. Le hachage complet de 32 octets rend cette recherche astronomiquement coûteuse, donc cela n'arrive jamais.
Le seuil fait partie de l'adresse. Un portefeuille 2-sur-3 et un 3-sur-3 avec exactement les mêmes membres sont des portefeuilles différents à des adresses différentes. Les règles sont gravées dans l'identité.
L'adresse du vault est ensuite dérivée de l'adresse multisig plus un petit numéro d'index (SSP utilise toujours l'index 0), de sorte que le vault aussi est entièrement déterminé par l'ensemble des membres et le seuil.
Le résultat pratique : n'importe qui peut calculer les deux adresses hors ligne, avant l'envoi d'une seule transaction. Vous pouvez distribuer l'adresse du vault et recevoir des fonds dans un portefeuille qui, sur la chaîne, n'existe pas encore — la propriété de Bitcoin, apportée à Solana.
Enregistrement sans permission : n'importe qui peut l'activer
L'adresse du portefeuille existe dès l'instant où vous connaissez les membres. Mais pour dépenser depuis elle, les règles doivent finir par être écrites sur la chaîne — le programme appelle cette étape initialize.
Sur la plupart des multisigs Solana, seul un créateur privilégié peut faire l'étape équivalente. Dans le programme de SSP, l'initialisation est sans permission : n'importe qui peut la faire. Pas de compte créateur, pas de signature de membre, pas de permission spéciale. En général, le service de relay de SSP paie la petite redevance de loyer et active le portefeuille, mais peu importe vraiment qui le fait.
Cela semble alarmant jusqu'à ce que vous voyiez la vérification de sécurité. Quand quelqu'un initialise le portefeuille, le programme recalcule le hachage SHA-256 de la liste des membres fournie et rejette la transaction sauf si ce hachage correspond à celui gravé dans l'adresse. Le cadre de comptes de Solana lie indépendamment l'adresse à ce même hachage. Ensemble, ces deux vérifications signifient que l'adresse canonique ne peut contenir que l'ensemble canonique de membres. Personne ne peut enregistrer votre adresse avec une liste de membres de son choix — le hachage ne correspondrait pas et la transaction échoue.
Pourquoi un inconnu qui initialise votre portefeuille ne peut pas vous nuire
Passons en revue ce qu'un attaquant pourrait réellement tenter.
Il initialise avec un ensemble de membres différent. Un ensemble différent hache vers une valeur différente, qui dérive une adresse différente. L'attaquant a simplement créé son propre portefeuille sans rapport, ailleurs sur Solana — aucune connexion avec votre vault, aucune revendication sur vos fonds.
Il initialise avec votre ensemble de membres. Le hachage correspond, donc la transaction réussit — mais tout ce qu'il a fait, c'est payer votre redevance de loyer à votre place. Le portefeuille est désormais enregistré avec exactement les règles que vous attendiez, et l'attaquant n'est pas membre, il ne peut donc rien proposer, approuver ni exécuter. L'argent ne se trouve jamais à l'adresse multisig elle-même — il se trouve dans le vault, qui appartient au système et ne peut être détourné. Quel que soit celui qui initialise le portefeuille, et quel que soit le moment, le résultat est le même portefeuille canonique aux règles correctes.
Le seuil est vérifié quand vous dépensez, pas quand vous enregistrez
C'est le même modèle que celui qu'utilise la multisig P2WSH de Bitcoin, et il vaut la peine de le dire clairement : le seuil M-sur-N n'est appliqué que lorsque les fonds bougent — jamais à l'enregistrement.
L'enregistrement note simplement « voici les membres, voici le seuil ». Il ne demande aucune signature parce qu'il ne peut causer aucun dommage. La véritable barrière est le flux de dépense, où le programme compte les approbations et refuse d'agir tant qu'un nombre suffisant de membres n'a pas donné son accord. L'adresse est le hachage des règles ; n'importe qui peut la financer ; seules des signatures valides peuvent dépenser. Pour un rappel de ce que signifie « M-sur-N », voir 2-sur-2 vs 2-sur-3 vs M-sur-N multisig.
Le cycle de vie complet, du début à la fin
En assemblant les pièces, voici la vie d'un portefeuille multisig Solana de SSP :
- Dériver. N'importe qui calcule les adresses multisig et du vault hors ligne à partir des membres et du seuil. Pas de blockchain, pas de coût.
- Préfinancer. N'importe qui envoie des SOL ou des tokens à l'adresse du vault — cela fonctionne même avant l'enregistrement du portefeuille.
- Initialiser. N'importe qui, en général le relay de SSP, soumet la transaction d'enregistrement sans permission. Le programme vérifie le hachage des membres et écrit les règles canoniques sur la chaîne.
- Proposer. Un membre crée une proposition de transaction, stockée de façon compacte sur un compte de proposition dédié.
- Approuver. Chaque membre approuve la proposition, une fois chacun. Les approbations s'accumulent sur la chaîne.
- Exécuter. Une fois que les approbations atteignent le seuil, n'importe qui peut déclencher l'exécution. Le programme marque d'abord la proposition comme exécutée — une protection délibérée pour qu'elle ne s'exécute jamais deux fois — puis réalise chaque instruction, le vault lui-même agissant comme signataire.
Cette dernière étape est là où l'adresse de vault sans clé porte ses fruits. Comme le vault est une PDA sans clé privée, ni un humain ni un programme ne peut déplacer ses fonds en signant de la manière ordinaire. La seule issue est que le programme de SSP exécute une proposition approuvée ayant atteint le seuil — il « signe » pour le vault en présentant la recette de dérivation du vault au runtime de Solana, une permission qu'il obtient uniquement parce qu'il est propriétaire de l'adresse.
Aucun créateur, aucun admin, aucune rotation de clés sur place
Deux dernières propriétés relient la conception.
L'ensemble des membres et le seuil sont immuables. Une fois un portefeuille initialisé, aucune instruction du programme ne peut changer ses membres ni son seuil — il n'existe pas de chemin de code pour cela. Pour changer qui contrôle un portefeuille — ce que d'autres systèmes appellent vaguement « rotation des clés » — vous créez une nouvelle multisig avec le nouvel ensemble de membres et y déplacez les fonds. L'ancienne adresse conserve ses anciennes règles pour toujours.
Il n'y a aucun rôle de créateur ni aucune clé d'admin, jamais. Beaucoup de conceptions multisig conservent un compte privilégié qui peut passer outre les membres ou changer la configuration. Le programme de SSP n'en a aucun — rien à compromettre, aucune clé d'admin à hameçonner, aucun créateur à contraindre. Les membres et le seuil sont toute l'histoire.
Ce minimalisme est un compromis délibéré : SSP a construit une primitive petite et déterministe plutôt qu'une plateforme de gouvernance riche en fonctionnalités. Le prochain article, La multisig Solana de SSP face à Squads, compare honnêtement cette conception à Squads V4 — la multisig Solana mature, auditée et dominante. Pour le contexte produit, l'annonce de lancement de la prise en charge de Solana couvre ce qui est arrivé dans SSP Wallet v1.39.0.
L'idée centrale est assez petite pour tenir dans la tête : sur la multisig Solana de SSP, l'adresse du portefeuille est une empreinte de ses propres règles. Connaissez les membres et le seuil, et vous connaissez l'adresse. Rien d'autre n'est nécessaire, et rien d'autre n'est de confiance.
