Keychain expose une interface de base SolanaSigner unique pour tous les backends, donc
pour la plupart d'entre eux, le choix est opérationnel, et non architectural : vous pouvez le modifier
ultérieurement via la configuration. L'exception concerne la forme de la transaction. Crossmint
et le mode auto natif de Fordefi signent et diffusent côté serveur, et le mode manuel natif de Fordefi
réécrit la transaction avant de la signer ; passer à l'un d'eux ou le quitter
change donc la manière d'appeler le signataire. C'est pourquoi partez de vos
besoins, pas d'un produit. Deux questions déterminent l'essentiel : où réside
la clé privée, et qui est autorisé à valider une signature avec elle ?
Tous les backends, sauf Ledger, sont disponibles dans les quatre langages (Rust, TypeScript,
Python et Go). Ledger n'est disponible qu'en Rust, via la fonctionnalité optionnelle ledger.
Il n'existe pas de meilleur backend dans l'absolu. Chacun correspond mieux à un ensemble particulier de contraintes : le cloud sur lequel vous êtes déjà, votre souhait ou non d'exploiter une infrastructure de clés, et les contrôles de garde et d'approbation que vous devez mettre en place. Le schéma ci-dessous associe ces contraintes à un backend.
Ce guide porte sur la signature côté backend (côté serveur). Lorsque vos utilisateurs finaux signent leurs propres transactions dans un navigateur, utilisez plutôt un wallet via le Wallet Standard. Consultez Signing in Production.
Arbre de décision
Le développement local et les tests n'ont besoin de rien de tout cela : utilisez le backend Memory pour le prototypage, puis passez à l'un des backends de production ci-dessus via la configuration.
Parcourir les questions
Signez-vous pour votre propre application ou pour vos utilisateurs finaux ?
Si vous provisionnez des wallets que des utilisateurs finaux possèdent et utilisent (applications grand public, parcours d'intégration), utilisez un backend de wallet intégré / géré : Privy, Turnkey, CDP, Crossmint ou Openfort. Ils gèrent les wallets par utilisateur et l'authentification pour votre compte.
Si vous signez en tant qu'application propre (payeur de frais, trésorerie, automatisation backend), poursuivez ci-dessous.
Avez-vous besoin d'une approbation multipartite, d'une garde institutionnelle ou de contrôles réglementaires ?
Si les signatures doivent passer une politique d'approbation, une limite de dépenses ou un workflow de conformité avant d'être produites, ou si vous avez besoin d'un dépositaire réglementé qui détienne les clés, utilisez un backend de garde MPC / institutionnelle : Fireblocks, Dfns, Para, Utila ou Fordefi. Ils fractionnent ou conservent la clé et cosignent selon votre politique.
Si vous avez seulement besoin d'une clé qui signe à la demande, poursuivez ci-dessous.
Souhaitez-vous détenir la clé vous-même ou la confier à un fournisseur ?
Si un fournisseur cloud doit détenir la clé dans une infrastructure matérielle sécurisée et que votre politique IAM contrôle qui peut signer, utilisez le KMS de ce cloud :
- Exécution sur AWS → AWS KMS
- Exécution sur GCP → GCP KMS
Si vous souhaitez exploiter vous-même l'infrastructure de clés, ou si vous êtes multi-cloud ou on-prem, utilisez HashiCorp Vault. Vous l'exploitez et l'auditez ; la clé reste dans le moteur Transit et signe à la demande.
Modèles de garde
Les backends se répartissent en six modèles de garde. Le schéma ci-dessus vous oriente vers l'un d'entre eux.
- Auto-garde (in-process) : votre application détient la clé privée brute. Pratique pour le développement, mais inadaptée à la production. Backend : Memory.
- Auto-garde (hardware wallet) : la clé ne quitte jamais l'appareil Ledger, et une personne confirme chaque signature sur son écran. Adapté à la signature interactive par un opérateur, pas aux services sans surveillance. Rust uniquement, optionnel, et non couvert par l'audit. Backend : Ledger.
- Gestion de clés auto-hébergée : vous exploitez l'infrastructure de clés ; la clé y reste et signe à la demande. Backend : HashiCorp Vault.
- KMS cloud / HSM : un fournisseur cloud stocke la clé dans une infrastructure matérielle sécurisée ; la clé ne quitte jamais le service et votre politique IAM contrôle qui peut signer. Backends : AWS KMS, GCP KMS.
- Garde MPC et institutionnelle : la clé est fractionnée ou conservée chez un fournisseur, qui cosigne selon votre politique (approbations, limites). Backends : Fireblocks, Dfns, Para, Utila, Fordefi.
- Wallets intégrés et gérés : un fournisseur gère les wallets pour votre compte, souvent pour intégrer des utilisateurs finaux. Backends : Privy, Turnkey, CDP, Crossmint, Openfort.
Comparaison des backends
| Backend | Modèle de garde | Idéal pour | Remarques |
|---|---|---|---|
| Memory | Auto-garde (in-process) | Développement local, tests, CI | Clé brute dans le processus ; ne pas utiliser en production |
| Ledger | Auto-garde (hardware wallet) | Signature interactive par un opérateur depuis des outils Rust | Rust uniquement, fonctionnalité optionnelle ledger, non audité ; chaque signature est confirmée sur l'appareil |
| HashiCorp Vault | Gestion de clés auto-hébergée | Équipes gérant leur propre infrastructure de clés | Moteur Transit ; vous l'exploitez et l'auditez |
| AWS KMS | KMS cloud / HSM | Backends fonctionnant sur AWS | La clé ne quitte jamais KMS ; IAM contrôle la signature |
| GCP KMS | KMS cloud / HSM | Backends fonctionnant sur GCP | La clé ne quitte jamais KMS ; IAM contrôle la signature |
| Fireblocks | Garde MPC / institutionnelle | Trésoreries, exchanges, garde réglementée | Moteur de politiques et workflows d'approbation |
| Dfns | Infrastructure de wallets MPC | Wallets programmatiques avec contrôles de politique | Signature Ed25519 |
| Para | Wallets MPC | Applications souhaitant des wallets adossés à MPC | Clé API + ID de wallet |
| Utila | Garde MPC + co-signataire | Wallets Solana gérés par Utila | signMessage non pris en charge ; vous diffusez la tx |
| Fordefi | Garde MPC / institutionnelle | Garde institutionnelle avec contrôles de politique | Boîte noire : vous envoyez. Auto natif : Fordefi réécrit et envoie. Manuel natif : Fordefi réécrit, vous envoyez le résultat |
| Privy | Wallets intégrés | Applications grand public intégrant des wallets | Wallets intégrés gérés par l'application |
| Turnkey | Gestion de clés non-custodiale | Signature programmatique avec contrôle de politique | Gestion de clés non-custodiale |
| CDP | Wallet géré (Coinbase) | Applications sur la plateforme développeur Coinbase | signMessage accepte uniquement les charges utiles UTF-8 |
| Crossmint | Wallets gérés | Marketplaces et applications à wallets gérés | Envoi uniquement : diffuse côté serveur, peut réécrire pour le sponsoring des frais de gas ; signMessage non pris en charge |
| Openfort | Wallets backend intégrés | Wallets côté serveur | Clés stockées dans un TEE |
Forme des capacités
Au-delà de la garde, chaque backend a une forme de transaction unique, qui détermine la manière dont vous appelez le signataire :
- Signer : le fournisseur signe les octets que vous avez construits et vous les diffusez. La plupart des backends, y compris Ledger et le mode boîte noire de Fordefi.
- Réécrire et signer : le fournisseur réécrit la transaction, puis la signe sans la diffuser. Poursuivez à partir de la transaction renvoyée. Mode manuel natif de Fordefi.
- Signer et diffuser : le fournisseur signe et diffuse côté serveur ; un échec ne signifie donc pas que rien n'a été pris en compte. Crossmint et mode auto natif de Fordefi.
Le tableau des capacités du signataire dans le README de chaque langage indique la forme de chaque backend ; le modèle de sécurité explique ce que chaque forme garantit.
Scénarios d'entreprise
Une même application a souvent besoin de plusieurs de ces options à la fois. Comme l'interface est partagée, vous pouvez exécuter un backend différent par rôle sans modifier les points d'appel, tant que les backends partagent la même forme de capacité.
- Opérations de trésorerie — séparez un signataire opérationnel « chaud » d'un signataire de trésorerie « froid ». Protégez la trésorerie avec une conservation MPC ou un HSM cloud et exigez des politiques d'approbation avant les signatures de haute valeur.
- Flux d'approbation — les backends MPC et de conservation (ex. Fireblocks) imposent une approbation multi-parties avant qu'une signature soit produite.
- Conformité et audit — les KMS cloud (AWS/GCP) et Vault émettent des journaux d'audit de signature ; les dépositaires institutionnels ajoutent l'application des politiques et les rapports.
- Environnements réglementés — conservez le matériel de clé dans un HSM, un KMS ou un dépositaire institutionnel afin que les clés brutes ne touchent jamais votre application.
Consultez Bonnes pratiques de production pour exploiter ces backends en toute sécurité.
Is this page helpful?