Keychain espone un'unica interfaccia di base SolanaSigner per tutti i 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, e 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 decidono la maggior parte della scelta: dove
risiede la chiave privata e chi è autorizzato ad approvare una firma con essa?
Ogni backend tranne Ledger è disponibile in tutti e quattro i linguaggi (Rust, TypeScript,
Python e Go). Ledger è disponibile solo per Rust, dietro la feature opzionale 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 l'infrastruttura delle chiavi e quali controlli di custodia e approvazione sei tenuto ad avere. Il flusso qui sotto associa questi 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 Signing in Production.
Flusso decisionale
Lo sviluppo locale e i test non richiedono nulla di tutto questo: usa il backend Memory per il prototipo, poi 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 effettui il provisioning di wallet che appartengono agli utenti finali e che essi gestiscono (app consumer, flussi di onboarding), usa un backend di wallet embedded / gestito: Privy, Turnkey, CDP, Crossmint oppure Openfort. Questi gestiscono per tuo conto i wallet per singolo utente e l'autenticazione.
Se firmi come la tua applicazione (un fee payer, una tesoreria, un'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 workflow di compliance prima di essere prodotte, oppure se hai bisogno di un custode regolamentato che detenga le chiavi, usa un backend MPC / custodia istituzionale: Fireblocks, Dfns, Para, Utila oppure Fordefi. Questi dividono la chiave o la custodiscono e co-firmano in base alla tua policy.
Se ti serve soltanto una chiave che firma su richiesta, continua qui sotto.
Vuoi custodire la chiave in prima persona o lasciare che la custodisca un provider?
Se un cloud provider deve custodire la chiave in un'infrastruttura basata su hardware e la tua policy IAM controlla chi può firmare, usa il KMS di quel cloud:
- Se operi su AWS → AWS KMS
- Se operi su GCP → GCP KMS
Se vuoi gestire in autonomia l'infrastruttura delle chiavi, oppure sei in multi-cloud o on-prem, usa HashiCorp Vault. Lo gestisci e lo sottoponi ad audit tu; la chiave resta all'interno del Transit engine 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.
- Self-custody (in-process): la tua applicazione detiene la chiave privata in chiaro. Comodo per lo sviluppo, ma non adatto alla produzione. Backend: Memory.
- Self-custody (hardware wallet): la chiave non lascia mai il dispositivo Ledger, e una persona conferma ogni firma sul suo schermo. Adatto alla firma interattiva da parte di operatori, non ai servizi non presidiati. Solo Rust, opzionale e non coperto dall'audit. Backend: Ledger.
- Gestione delle chiavi self-hosted: gestisci tu l'infrastruttura delle chiavi; la chiave resta al suo interno e firma su richiesta. Backend: HashiCorp Vault.
- Cloud KMS / HSM: un cloud provider conserva 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.
- MPC e custodia istituzionale: la chiave viene divisa o custodita presso un provider, che co-firma in base alla tua policy (approvazioni, limiti). Backend: Fireblocks, Dfns, Para, Utila, Fordefi.
- Wallet embedded e gestiti: un provider gestisce i wallet per tuo conto, spesso per fare 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 | Self-custody (hardware wallet) | Firma interattiva da parte dell'operatore da tool Rust | Solo Rust, feature ledger opzionale, non sottoposto ad audit; ogni firma viene 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 lo sponsoring 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 un'unica forma di transazione, che determina come chiami il signer:
- Sign: 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.
- Rewrite and sign: il provider riscrive la transazione, poi la firma senza trasmetterla. Prosegui dalla transazione che restituisce. Modalità native manual di Fordefi.
- Sign and broadcast: il provider firma e trasmette lato server, quindi un errore non significa che non sia stato inviato nulla. Crossmint e modalità native auto di Fordefi.
La tabella delle capacità del 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 una di queste contemporaneamente. Poiché l'interfaccia è condivisa, puoi usare un backend diverso per 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?