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é à l'utiliser pour signer ?
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 validez pas dans le contrôle de source. Quiconque obtient une clé acquiert le contrôle total des fonds du compte associé.
Approches de signature
| Approche | Emplacement de 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 |
| Cloud KMS / HSM | 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 | Fractionnée ou en garde auprès de l'infrastructure d'un fournisseur | Le fournisseur co-signe selon votre politique | Portefeuilles intégrés, flux d'approbation, garde institutionnelle |
Le keypair local est la seule approche qui place le matériel de clé brut dans votre application. Toute approche de production conserve la clé dans une infrastructure dédiée et demande à cette infrastructure de signer en votre nom.
Signature côté backend
Lorsqu'un serveur doit signer (pour 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'une
keypair brute. La Solana Foundation maintient Keychain, une
bibliothèque de signature unifiée (Rust, TypeScript, Python et Go) qui expose une seule
interface SolanaSigner pour tous les backends du tableau ci-dessus : Memory,
HashiCorp Vault, AWS KMS, GCP KMS, Fireblocks, Privy, Turnkey, CDP, Crossmint,
Dfns, Para, Openfort, Utila et Fordefi.
Comme l'interface est partagée entre les backends, vous pouvez développer en local avec une
clé en mémoire, puis passer à un backend de production via la configuration, sans
réécrire le code de votre application (les backends qui diffusent les transactions à votre place, comme Crossmint,
sont appelés via un flux de signature et d'envoi). Keychain est compatible avec
@solana/kit, le
SDK Rust, solders (Python) et solana-go v2
(Go).
Keychain
Signature unifiée pour les clés locales, KMS, HSM et 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 Production Readiness.
Is this page helpful?