Keychain espone un'unica interfaccia di base SolanaSigner su ogni backend, quindi per
la maggior parte dei backend la scelta è operativa, non architetturale: puoi cambiarla
in seguito tramite configurazione. L'eccezione è la forma della transazione. Crossmint
e la modalità native auto di Fordefi firmano e trasmettono lato server, mentre la modalità native
manual di Fordefi riscrive la transazione prima di firmarla, quindi passare a uno
di questi o abbandonarlo cambia il modo in cui chiami il signer. Per questo motivo, parti dai tuoi
requisiti, non da un prodotto. Due domande risolvono gran parte della questione: dove risiede
la chiave privata e chi è autorizzato a firmare con essa?
Ogni backend, tranne Ledger, è disponibile in tutti e quattro i linguaggi (Rust, TypeScript,
Python e Go). Ledger è solo Rust, dietro la feature opt-in ledger.
Non esiste un backend migliore in assoluto. Ognuno si adatta meglio a un determinato insieme di vincoli: il cloud su cui già operi, se vuoi gestire in prima persona l'infrastruttura delle chiavi e quali controlli di custodia e approvazione sei tenuto ad avere. Il flusso qui sotto associa tali vincoli a un backend.
Questa guida riguarda la firma lato backend (server-side). Quando i tuoi utenti finali firmano le proprie transazioni in un browser, usa invece un wallet tramite il Wallet Standard. Consulta Firma in produzione.
Flusso decisionale
Lo sviluppo locale e i test non richiedono nulla di tutto questo: usa il backend Memory per il prototipo, quindi passa a uno dei backend di produzione indicati sopra tramite configurazione.
Percorri le domande
Firmi per la tua applicazione o per i tuoi utenti finali?
Se fornisci wallet di cui sono proprietari e che gestiscono gli utenti finali (app consumer, flussi di onboarding), usa un backend di wallet embedded / gestito: Privy, Turnkey, CDP, Crossmint o Openfort. Questi gestiscono per tuo conto i wallet e l'autenticazione dei singoli utenti.
Se firmi come tua applicazione (un fee payer, una tesoreria, automazione backend), continua qui sotto.
Hai bisogno di approvazione multi-parte, custodia istituzionale o controlli normativi?
Se le firme devono superare una policy di approvazione, un limite di spesa o un flusso di conformità prima di essere prodotte, oppure ti serve un custode regolamentato che detenga le chiavi, usa un backend di custodia MPC / istituzionale: Fireblocks, Dfns, Para, Utila o Fordefi. Questi dividono o custodiscono la chiave e co-firmano secondo la tua policy.
Se ti serve solo una chiave che firmi su richiesta, continua qui sotto.
Vuoi detenere tu la chiave o lasciarla a un provider?
Se un cloud provider deve detenere la chiave in un'infrastruttura basata su hardware e la tua policy IAM controlla chi può firmare, usa il KMS di quel cloud:
- In esecuzione su AWS → AWS KMS
- In esecuzione su GCP → GCP KMS
Se vuoi gestire tu stesso l'infrastruttura delle chiavi, oppure sei multi-cloud o on-prem, usa HashiCorp Vault. Lo gestisci e lo sottoponi ad audit tu; la chiave resta all'interno del motore Transit e firma su richiesta.
Modelli di custodia
I backend si raggruppano in sei modelli di custodia. Il flusso qui sopra ti porta a uno di essi.
- Auto-custodia (in-process): la tua applicazione detiene la chiave privata in chiaro. Comoda per lo sviluppo, ma inadatta alla produzione. Backend: Memory.
- Auto-custodia (hardware wallet): la chiave non lascia mai il dispositivo Ledger e una persona conferma ogni firma sul suo schermo. Adatta alla firma interattiva da parte di operatori, non a servizi non presidiati. Solo Rust, opt-in e non coperta dall'audit. Backend: Ledger.
- Gestione chiavi self-hosted: gestisci tu l'infrastruttura delle chiavi; la chiave resta al suo interno e firma su richiesta. Backend: HashiCorp Vault.
- KMS cloud / HSM: un cloud provider archivia la chiave in un'infrastruttura basata su hardware; la chiave non lascia mai il servizio e la tua policy IAM controlla chi può firmare. Backend: AWS KMS, GCP KMS.
- Custodia MPC e istituzionale: la chiave è divisa o custodita presso un provider, che co-firma secondo la tua policy (approvazioni, limiti). Backend: Fireblocks, Dfns, Para, Utila, Fordefi.
- Wallet embedded e gestiti: un provider gestisce i wallet per tuo conto, spesso per l'onboarding degli utenti finali. Backend: Privy, Turnkey, CDP, Crossmint, Openfort.
Confronto tra backend
| Backend | Modello di custodia | Ideale per | Note |
|---|---|---|---|
| Memory | Auto-custodia (in-process) | Sviluppo locale, test, CI | Chiave in chiaro nel processo; non usare in produzione |
| Ledger | Auto-custodia (hardware wallet) | Firma interattiva da parte dell'operatore con strumenti Rust | Solo Rust, feature opt-in ledger, non sottoposto ad audit; ogni firma è confermata sul dispositivo |
| HashiCorp Vault | Gestione chiavi self-hosted | Team che gestiscono la propria infrastruttura di chiavi | Motore Transit; sei tu a gestirlo e verificarlo |
| AWS KMS | Cloud KMS / HSM | Backend in esecuzione su AWS | La chiave non lascia mai KMS; IAM controlla la firma |
| GCP KMS | Cloud KMS / HSM | Backend in esecuzione su GCP | La chiave non lascia mai KMS; IAM controlla la firma |
| Fireblocks | Custodia MPC / istituzionale | Tesorerie, exchange, custodia regolamentata | Motore di policy e flussi di approvazione |
| Dfns | Infrastruttura wallet MPC | Wallet programmatici con controlli di policy | Firma Ed25519 |
| Para | Wallet MPC | App che desiderano wallet basati su MPC | Chiave API + ID wallet |
| Utila | Custodia MPC + co-firmatario | Wallet Solana gestiti da Utila | signMessage non supportato; sei tu a trasmettere la tx |
| Fordefi | Custodia MPC / istituzionale | Custodia istituzionale con controlli di policy | Black box: invii tu. Native auto: Fordefi riscrive e invia. Native manual: Fordefi riscrive, tu invii il risultato |
| Privy | Wallet integrati | App consumer per l'onboarding degli utenti ai wallet | Wallet integrati gestiti dall'app |
| Turnkey | Gestione chiavi non custodiale | Firma programmatica con gate di policy | Gestione chiavi non custodiale |
| CDP | Wallet gestito (Coinbase) | App sulla Coinbase Developer Platform | signMessage accetta solo payload UTF-8 |
| Crossmint | Wallet gestiti | Marketplace e app con wallet gestiti | Solo invio: trasmette lato server, può riscrivere per la sponsorizzazione del gas; signMessage non supportato |
| Openfort | Wallet backend integrati | Wallet lato server | Chiavi archiviate in TEE |
Forma delle capacità
Oltre alla custodia, ogni backend ha una sola forma di transazione, che determina come chiami il signer:
- Firma: il provider firma i byte che hai costruito e tu li trasmetti. La maggior parte dei backend, inclusi Ledger e la modalità black box di Fordefi.
- Riscrittura e firma: il provider riscrive la transazione, quindi la firma senza trasmetterla. Prosegui dalla transazione che restituisce. Modalità native manual di Fordefi.
- Firma e trasmissione: il provider firma e trasmette lato server, quindi un errore non significa che nulla sia stato registrato. Crossmint e modalità native auto di Fordefi.
La tabella delle capacità dei signer nel README di ciascun linguaggio elenca la forma di ogni backend; il modello di sicurezza spiega cosa garantisce ciascuna forma.
Scenari enterprise
Una singola applicazione spesso ha bisogno di più di uno di questi contemporaneamente. Poiché l'interfaccia è condivisa, puoi usare un backend diverso per ciascun ruolo senza modificare i punti di chiamata, purché i backend condividano la stessa forma di capacità.
- Operazioni di tesoreria — separare un firmatario operativo "hot" da un firmatario "cold" della tesoreria. Supportare la tesoreria con custodia MPC o un cloud HSM e richiedere politiche di approvazione prima delle firme ad alto valore.
- Flussi di approvazione — i backend MPC e di custodia (es. Fireblocks) impongono l'approvazione multi-parte prima che venga prodotta una firma.
- Conformità e audit — cloud KMS (AWS/GCP) e Vault emettono log di audit della firma; i custodi istituzionali aggiungono l'applicazione delle policy e la reportistica.
- Ambienti regolamentati — mantenere il materiale delle chiavi in un HSM, KMS o custode istituzionale in modo che le chiavi raw non tocchino mai l'applicazione.
Consulta Best practice per la produzione per operare questi backend in modo sicuro.
Is this page helpful?