Une transaction ne s'exécute que si elle porte une
signature valide de
chaque signataire requis. En développement local, vous détenez généralement
cette clé sous forme de Keypair
et signez directement. En production, la question importante est différente :
où réside la clé privée, et qui est autorisé à signer avec elle ?
N'intégrez jamais de clés privées dans du code côté client, ne les incluez pas dans un frontend, et ne les enregistrez pas dans le contrôle de version. Quiconque obtient une clé prend le contrôle total des fonds de ce compte.
Approches de signature
| Approche | Où réside la clé | Qui signe | Idéal pour |
|---|---|---|---|
| keypair local | Un fichier ou une variable d'environnement sur la machine | Votre code, directement | Développement local, tests, CI |
| Portefeuille navigateur | Le portefeuille de l'utilisateur final (ex. Phantom, Solflare) | L'utilisateur final, par transaction | dApps frontend où les utilisateurs signent leurs propres transactions |
| KMS / HSM cloud | Un service de clés sécurisé par matériel (AWS KMS, GCP KMS, Vault) | Votre backend demande une signature au service | Services backend, opérations de trésorerie, environnements réglementés |
| Portefeuilles gérés / MPC | Répartis ou en garde chez l'infrastructure d'un fournisseur | Le fournisseur co-signe selon votre politique | Portefeuilles intégrés, workflows d'approbation, garde institutionnelle |
Le keypair local est la seule approche qui place le matériel de clé brut directement dans votre application. Toutes les approches de production conservent la clé dans une infrastructure dédiée et demandent à cette infrastructure de signer en votre nom.
Signature côté serveur
Lorsqu'un serveur doit signer — payer des frais, envoyer des transactions de
programme ou gérer une trésorerie — utilisez un backend de gestion de clés dédié
plutôt qu'un keypair brut. La Solana Foundation maintient
Keychain, une bibliothèque de signature unifiée (Rust et
TypeScript) qui expose une interface SolanaSigner unique pour chaque backend
du tableau ci-dessus : Memory, HashiCorp Vault, AWS KMS, GCP KMS, Fireblocks,
Privy, Turnkey, CDP, Crossmint, Dfns, Para, Openfort et Utila.
Étant donné que l'interface est identique pour tous les backends, vous pouvez
développer localement avec une clé en mémoire et basculer vers un backend de
production via la configuration, sans réécrire le code de l'application.
Keychain est compatible avec @solana/kit
et le SDK Rust.
Keychain
Signature unifiée pour les clés locales, KMS, HSM et les backends de portefeuilles gérés.
Choisir un backend
Comparez les modèles de garde et choisissez le backend de signature adapté à votre application.
Pour la liste de contrôle complète en production — gestion des clés, sécurité RPC et surveillance — consultez Préparation à la production.
Is this page helpful?