Keychain expose une seule interface de base SolanaSigner pour tous les backends, de sorte que, pour la plupart d'entre eux, le choix est opérationnel et non architectural : vous pouvez en changer plus tard 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, modifie donc la façon dont vous appelez le signataire. Pour cette raison, partez de vos besoins, pas d'un produit. Deux questions déterminent l'essentiel du choix : où se trouve la clé privée, et qui est autorisé à valider une signature avec celle-ci ?
Tous les backends, à l'exception de Ledger, sont disponibles dans les quatre langages (Rust, TypeScript, Python et Go). Ledger est uniquement disponible en Rust, via la fonctionnalité optionnelle ledger.
Il n'existe pas de meilleur backend dans l'absolu. Chacun convient mieux à un ensemble particulier de contraintes : le cloud sur lequel vous êtes déjà, le fait de vouloir ou non exploiter vous-même une infrastructure de clés, et les contrôles de garde et d'approbation que vous êtes tenu de mettre en place. Le schéma ci-dessous associe ces contraintes à un backend.
Ce guide traite de la signature côté backend (serveur). Lorsque vos utilisateurs finaux signent eux-mêmes leurs 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 vos utilisateurs finaux possèdent et utilisent (applications grand public, parcours d'onboarding), utilisez un backend de wallet embarqué / géré : Privy, Turnkey, CDP, Crossmint ou Openfort. Ils gèrent les wallets par utilisateur ainsi que l'authentification pour votre compte.
Si vous signez en tant que votre propre application (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étient les clés, utilisez un backend de MPC / garde institutionnelle : Fireblocks, Dfns, Para, Utila ou Fordefi. Ils fractionnent la clé ou en assurent la garde, et cosignent selon votre politique.
Si vous avez simplement 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 adossée à du matériel dédié 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 en multicloud ou on-premise, utilisez HashiCorp Vault. Vous l'exploitez et l'auditez ; la clé reste à l'intérieur du 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'eux.
- Autogarde (en processus) : votre application détient la clé privée en clair. Pratique pour le développement, mais inadapté à la production. Backend : Memory.
- Autogarde (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é reste à l'intérieur et signe à la demande. Backend : HashiCorp Vault.
- KMS cloud / HSM : un fournisseur cloud stocke la clé dans une infrastructure adossée à du matériel dédié ; la clé ne quitte jamais le service et votre politique IAM contrôle qui peut signer. Backends : AWS KMS, GCP KMS.
- MPC et garde 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 embarqués et gérés : un fournisseur gère les wallets pour votre compte, souvent pour l'onboarding 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é en clair dans le processus ; à ne pas utiliser en production |
| Ledger | Autogarde (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 façon 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 qu'il renvoie. Mode manuel natif de Fordefi.
- Signer et diffuser : le fournisseur signe et diffuse côté serveur ; un échec ne signifie donc pas qu'aucune transaction n'a abouti. Crossmint et mode auto natif de Fordefi.
Le tableau des capacités des signataires 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 backends à la fois. Comme l'interface est partagée, vous pouvez exécuter un backend différent selon le rôle sans modifier les points d'appel, tant que les backends partagent la même forme de capacités.
- 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?