O Keychain expõe uma interface base SolanaSigner única em todos os backends, pelo que,
na maioria deles, a escolha é operacional, não arquitetural: pode alterá-la
mais tarde através da configuração. A exceção é o formato da transação. A Crossmint
e o modo automático nativo da Fordefi assinam e transmitem no servidor, e o modo manual nativo
da Fordefi reescreve a transação antes de a assinar, pelo que passar para um deles, ou deixar
de o usar, altera a forma como chama o signer. Por isso, comece pelos seus
requisitos, não por um produto. Duas perguntas resolvem a maior parte: onde reside
a chave privada e quem está autorizado a aprovar uma assinatura com ela?
Todos os backends, exceto o Ledger, estão disponíveis nas quatro linguagens (Rust, TypeScript,
Python e Go). O Ledger é apenas para Rust, atrás da funcionalidade opcional ledger.
Não existe um único melhor backend. Cada um adequa-se melhor a um determinado conjunto de restrições: a nuvem em que já opera, se quer operar infraestrutura de chaves e que controlos de custódia e de aprovação é obrigado a ter. O fluxo abaixo associa essas restrições a um backend.
Este guia aborda a assinatura no backend (lado do servidor). Quando os seus utilizadores finais assinam as suas próprias transações num navegador, utilize antes uma carteira através do Wallet Standard. Consulte Assinatura em produção.
Fluxo de decisão
O desenvolvimento local e os testes não precisam de nada disto: utilize o backend Memory para prototipagem e depois passe para um dos backends de produção acima através da configuração.
Percorra as perguntas
Está a assinar para a sua própria aplicação ou para os seus utilizadores finais?
Se provisiona carteiras que pertencem aos utilizadores finais e são por eles operadas (aplicações de consumo, fluxos de integração), utilize um backend de carteira incorporada / gerida: Privy, Turnkey, CDP, Crossmint ou Openfort. Estes gerem carteiras e autenticação por utilizador em seu nome.
Se está a assinar como a sua própria aplicação (um fee payer, uma tesouraria, automatização de backend), continue abaixo.
Precisa de aprovação multipartes, custódia institucional ou controlos regulamentares?
Se as assinaturas têm de passar por uma política de aprovação, um limite de gastos ou um fluxo de conformidade antes de serem produzidas, ou se precisa de um custodiante regulado que guarde as chaves, utilize um backend de custódia MPC / institucional: Fireblocks, Dfns, Para, Utila ou Fordefi. Estes dividem ou custodiam a chave e cossignam de acordo com a sua política.
Se só precisa de uma chave que assine a pedido, continue abaixo.
Quer guardar a chave por si ou deixar que um fornecedor a guarde?
Se um fornecedor de nuvem deve guardar a chave em infraestrutura com suporte de hardware e a sua política de IAM controla quem pode assinar, utilize o KMS dessa nuvem:
- A correr na AWS → AWS KMS
- A correr na GCP → GCP KMS
Se quer operar a infraestrutura de chaves por si, ou se usa várias nuvens ou on-prem, utilize o HashiCorp Vault. A operação e a auditoria ficam consigo; a chave permanece dentro do motor Transit e assina a pedido.
Modelos de custódia
Os backends agrupam-se em seis modelos de custódia. O fluxo acima encaminha-o para um deles.
- Autocustódia (em processo): a sua aplicação guarda a chave privada em bruto. Conveniente para desenvolvimento, mas inadequada para produção. Backend: Memory.
- Autocustódia (carteira de hardware): a chave nunca sai do dispositivo Ledger, e uma pessoa confirma cada assinatura no respetivo ecrã. Adequada para assinatura interativa por operadores, não para serviços autónomos. Apenas Rust, opcional e não coberta pela auditoria. Backend: Ledger.
- Gestão de chaves auto-hospedada: opera a infraestrutura de chaves; a chave permanece dentro dela e assina a pedido. Backend: HashiCorp Vault.
- KMS / HSM na nuvem: um fornecedor de nuvem guarda a chave em infraestrutura com suporte de hardware; a chave nunca sai do serviço e a sua política de IAM controla quem pode assinar. Backends: AWS KMS, GCP KMS.
- Custódia MPC e institucional: a chave é dividida ou custodiada por um fornecedor, que cossigna de acordo com a sua política (aprovações, limites). Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Carteiras incorporadas e geridas: um fornecedor gere carteiras em seu nome, frequentemente para integrar utilizadores finais. Backends: Privy, Turnkey, CDP, Crossmint, Openfort.
Comparação de backends
| Backend | Modelo de custódia | Ideal para | Notas |
|---|---|---|---|
| Memory | Autocustódia (em processo) | Desenvolvimento local, testes, CI | Chave em bruto no processo; não utilizar em produção |
| Ledger | Autocustódia (carteira de hardware) | Assinatura interativa por operadores a partir de ferramentas Rust | Apenas Rust, funcionalidade opcional ledger, não auditada; cada assinatura é confirmada no dispositivo |
| HashiCorp Vault | Gestão de chaves auto-hospedada | Equipas com infraestrutura própria de chaves | Motor Transit; você opera e audita |
| AWS KMS | KMS / HSM na nuvem | Backends a correr na AWS | Chave nunca sai do KMS; IAM controla a assinatura |
| GCP KMS | KMS / HSM na nuvem | Backends a correr na GCP | Chave nunca sai do KMS; IAM controla a assinatura |
| Fireblocks | Custódia MPC / institucional | Tesourarias, exchanges, custódia regulada | Motor de políticas e fluxos de aprovação |
| Dfns | Infraestrutura de carteiras MPC | Carteiras programáticas com controles de política | Assinatura Ed25519 |
| Para | Carteiras MPC | Apps que pretendem carteiras com suporte MPC | Chave API + ID da carteira |
| Utila | Custódia MPC + co-assinante | Carteiras Solana geridas pelo Utila | signMessage não suportado; você transmite a tx |
| Fordefi | Custódia MPC / institucional | Custódia institucional com controles de política | Black box: o envio é feito por si. Automático nativo: a Fordefi reescreve e envia. Manual nativo: a Fordefi reescreve e o envio do resultado é feito por si |
| Privy | Carteiras embutidas | Apps de consumo a integrar utilizadores em carteiras | Carteiras embutidas geridas pela app |
| Turnkey | Gestão de chaves não custodial | Assinatura programática com controlo por políticas | Gestão de chaves não custodial |
| CDP | Carteira gerida (Coinbase) | Apps na Plataforma de Desenvolvimento Coinbase | signMessage aceita apenas payloads UTF-8 |
| Crossmint | Carteiras geridas | Marketplaces e apps com carteiras geridas | Apenas envio: transmite no servidor, pode reescrever para patrocínio de gas; signMessage não é suportado |
| Openfort | Carteiras backend embutidas | Carteiras do lado do servidor | Chaves armazenadas em TEE |
Formato de capacidades
Além da custódia, cada backend tem um formato de transação, que determina a forma como chama o signer:
- Assinar: o fornecedor assina os bytes que construiu e a transmissão fica a seu cargo. A maioria dos backends, incluindo o Ledger e o modo black box da Fordefi.
- Reescrever e assinar: o fornecedor reescreve a transação e depois assina-a sem a transmitir. Continue a partir da transação devolvida. Modo manual nativo da Fordefi.
- Assinar e transmitir: o fornecedor assina e transmite no servidor, pelo que uma falha não implica que nada tenha sido confirmado na rede. Crossmint e modo automático nativo da Fordefi.
A tabela de capacidades do signer no README de cada linguagem lista o formato de cada backend; o modelo de segurança explica o que cada formato garante.
Cenários empresariais
Uma única aplicação precisa muitas vezes de mais do que um destes ao mesmo tempo. Como a interface é partilhada, pode executar um backend diferente por função sem alterar os pontos de chamada, desde que os backends partilhem o mesmo formato de capacidades.
- Operações de tesouraria — separe um signatário operacional "quente" de um signatário "frio" de tesouraria. Proteja a tesouraria com custódia MPC ou um HSM em nuvem e exija políticas de aprovação antes de assinaturas de alto valor.
- Fluxos de aprovação — os backends MPC e de custódia (ex.: Fireblocks) impõem aprovação de múltiplas partes antes que uma assinatura seja produzida.
- Conformidade e auditoria — o KMS em nuvem (AWS/GCP) e o Vault emitem logs de auditoria de assinatura; custodiantes institucionais adicionam aplicação de políticas e relatórios.
- Ambientes regulamentados — mantenha o material de chaves em um HSM, KMS ou custodiante institucional para que as chaves brutas nunca toquem a sua aplicação.
Consulte Melhores práticas de produção para operar esses backends com segurança.
Is this page helpful?