Solana dans SSP

Solana est rapide, bon marché et, de plus en plus, l'endroit où les stablecoins circulent réellement. C'est aussi la chaîne où le multisig en autoconservation a historiquement été le plus difficile à réussir — non pas parce que la cryptographie est ardue, mais parce que le modèle de comptes de Solana fait d'« une adresse contrôlée par plusieurs parties » un objet bien plus étrange qu'il ne l'est sur Bitcoin.

SSP conserve le SOL et les jetons SPL dans le même multisig 2 sur 2 que vous utilisez déjà pour Bitcoin et Ethereum : une clé dans l'extension de navigateur, une clé sur votre téléphone, les deux requises pour chaque transaction. Cet article explique ce que cela signifie sur Solana en particulier — comment l'adresse est dérivée, qui paie les frais, ce que vos appareils vérifient, et quelles parties diffèrent véritablement des chaînes que vous connaissez déjà.

Ce qu'est Solana vu depuis l'autoconservation

Solana est une machine à états globale unique qui traite les transactions en parallèle plutôt qu'une par une. Pour qui détient ses propres fonds, trois propriétés comptent davantage que le débit affiché en gros titre.

D'abord, tout est un compte. Votre solde, le mint d'un jeton, le code d'un programme et les données qu'il stocke vivent tous dans des comptes dotés d'une adresse et d'un propriétaire. Ensuite, les comptes coûtent un loyer : pour exister on-chain, un compte doit détenir un solde minimal en SOL proportionnel à sa taille. Ce dépôt est remboursable à la fermeture du compte, mais c'est de l'argent réel qui doit venir de quelque part. Enfin, les transactions expirent vite — une transaction Solana ordinaire référence un blockhash récent et devient invalide au bout d'une minute environ.

Chacun de ces points a une conséquence directe sur la signature à deux appareils, et chacun est traité explicitement dans SSP plutôt que dissimulé. La documentation de référence de Solana est la source primaire sur le modèle de comptes et de loyer si vous voulez la version brute.

Une adresse sans créateur

Dans la plupart des conceptions de multisig Solana, le portefeuille doit être créé. Quelqu'un envoie une transaction qui l'établit, et l'adresse obtenue dépend d'entrées choisies pendant cette transaction — typiquement une clé aléatoire à usage unique. En pratique, l'adresse n'existe pas tant qu'un créateur ne l'a pas fait naître, et elle ne peut rien recevoir avant cela.

Le programme on-chain de SSP fonctionne autrement. L'adresse de votre coffre est une empreinte de l'ensemble ordonné des membres et du seuil d'approbation, et rien d'autre. Quiconque connaît les membres et le seuil peut calculer l'adresse hors ligne, avant que quoi que ce soit ne touche la chaîne. L'enregistrement est sans permission : le programme vérifie seulement que les membres que vous présentez produisent bien le hachage de l'adresse revendiquée, si bien qu'enregistrer ne change rien à qui peut dépenser.

C'est pourquoi il n'y a aucun créateur à qui faire confiance, aucun enregistreur privilégié et aucune clé d'administration. La dépense est régie uniquement par la vérification du seuil à l'intérieur du programme. Pour le tableau complet, pourquoi les adresses multisig Solana sont difficiles traite du problème sous-jacent, le multisig Solana auto-initié traite du programme, et SSP face à Squads V4 constitue la comparaison point par point.

Si le modèle 2 sur 2 lui-même vous est nouveau, commencez par qu'est-ce que le multisig 2 sur 2.

Pourquoi deux appareils avaient besoin d'un nonce durable

Voici le problème que crée l'expiration. Votre extension construit et signe une transaction. Votre téléphone doit ensuite l'approuver. Si vous quittez la pièce, déjeunez et revenez, le blockhash référencé par la transaction est mort depuis longtemps et tout doit être reconstruit.

SSP résout cela avec un compte de nonce durable dérivé de votre adresse multisig. Au lieu d'un blockhash récent, la transaction référence un nonce qui n'avance que lorsque la transaction est effectivement confirmée. La fenêtre de signature cesse d'être un chronomètre. Vous pouvez approuver sur votre téléphone des minutes ou des heures plus tard et la transaction reste valide — mais elle ne peut toujours servir qu'une seule fois, car son exécution fait avancer le nonce.

Le compte de nonce est créé lors de votre premier envoi, et c'est l'un des deux comptes dont le loyer apparaît dans le coût de ce premier envoi. Nonces durables et signature à deux appareils va plus loin.

Qui paie les frais

Sur Solana, le compte qui règle les frais d'une transaction est le fee payer, et il doit signer. Cela crée un problème d'amorçage délicat pour un multisig tout neuf : le coffre a besoin de SOL pour payer la transaction qui déplacerait son SOL, et les comptes qui réclament un loyer n'existent pas encore.

SSP utilise un paymaster. Le relais SSP exploite un compte qui signe en tant que fee payer, avance les frais de réseau et tout loyer, puis se fait rembourser par votre coffre à l'intérieur de la même transaction. Il n'y a pas d'étape séparée, aucun crédit accordé et aucun moyen que le remboursement ait lieu sans vos deux signatures — il voyage dans la proposition que vos appareils approuvent.

Deux conséquences méritent d'être retenues :

• Vous n'avez pas besoin de préfinancer une adresse en SOL pour le gas. Recevez du SOL, envoyez du SOL. C'est lors du premier envoi que les comptes sont créés.
• Votre premier envoi coûte plus cher que les suivants. Il acquitte le loyer permanent du compte multisig et du compte de nonce ; les envois ultérieurs ne paient guère plus que les frais de réseau. Les chiffres exacts figurent dans l'article de cette série consacré aux frais.

Si la notion de paymaster ne vous dit rien, le parrainage de gas et les paymasters, expliqués couvre le schéma général — SSP applique déjà la même idée sur les chaînes EVM, comme décrit dans Ethereum dans SSP.

Ce que vous pouvez détenir

Solana dans SSP prend en charge le SOL natif et les jetons SPL. D'origine, cela inclut le mint USDC officiel de Circle et FLUX sur Solana, et SSP résout les autres jetons SPL qu'il trouve dans votre coffre.

La distinction qui fait trébucher : sur Solana, vous ne détenez pas un jeton à votre adresse principale. Chaque jeton vit dans son propre compte de jeton associé, détenu par votre adresse, un par mint. Ce compte réclame lui aussi un loyer, ce qui explique qu'envoyer un jeton SPL à quelqu'un qui n'a jamais détenu ce jeton coûte un peu plus : vous payez pour faire exister son compte de jeton. SSP le crée automatiquement dans le cadre du transfert plutôt que d'échouer sur une erreur, et l'article de cette série consacré aux comptes de jetons en détaille les rouages.

Ce que vos appareils vérifient avant que vous signiez

Les transactions Solana sont opaques d'une manière que celles de Bitcoin ne sont pas. Ce que fait une transaction réside dans les données d'instruction, et un portefeuille doit décoder ces données avant de pouvoir vous en dire quoi que ce soit de vrai. Un portefeuille qui se contente d'afficher ce qu'un serveur lui a dit vous demande de faire confiance au serveur.

SSP décode la transaction sur vos propres appareils, octet par octet, à l'aide de la bibliothèque open source @runonflux/solana-multisig. Le destinataire, le montant et le mint du jeton sont lus dans les octets bruts et comparés à ce qui est affiché. En cas de désaccord, la signature est purement et simplement bloquée — un écart à ce stade signale une attaque en cours, pas un défaut d'affichage. Pour les transferts SPL, les décimales du jeton sont intégrées à l'instruction signée elle-même, de sorte qu'un mint annonçant d'autres décimales fait rejeter la transaction par le programme on-chain.

Le même principe régit le programme : les builds mainnet sont reproductibles à partir des sources publiées, si bien que le bytecode déployé à l'adresse SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r peut être reconstruit et comparé de façon indépendante. Une affirmation de sécurité ne vaut que ce que vaut votre capacité à la vérifier vous-même.

Pour commencer

Mettez à jour SSP Wallet et SSP Key vers la dernière version, puis activez Solana depuis le sélecteur de chaînes. Avec la synchronisation par lots de la v2, vous pouvez l'activer en même temps que n'importe quelles autres chaînes avec une seule approbation sur votre téléphone. Si vous n'avez pas encore configuré SSP, configurer votre premier portefeuille SSP est le point de départ.

Ensuite, Solana se comporte comme toute autre chaîne dans SSP : elle compte dans le total de votre portefeuille, les envois suivent le même parcours composer → vérifier → approuver avec l'adresse complète du destinataire à l'écran, et chaque transaction est cosignée par vos deux appareils. L'annonce du lancement sur mainnet détaille ce qui a été livré et quand.