O Keychain expõe uma única interface base SolanaSigner em todos os backends, pelo que,
para a maioria dos backends, a escolha é operacional e não arquitetural: pode alterá-la
mais tarde através de configuração. A exceção é o formato da transação. Crossmint
e o modo automático nativo da Fordefi assinam e transmitem no lado do servidor, e o modo
manual nativo da Fordefi reescreve a transação antes de a assinar, pelo que migrar 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 decidem a maior parte da escolha: onde
vive a chave privada e quem pode autorizar 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 melhor backend único. Cada um adapta-se melhor a um determinado conjunto de restrições: a cloud em que já trabalha, se pretende operar a infraestrutura de chaves e que controlos de custódia e aprovação é obrigado a ter. O fluxo abaixo associa essas restrições a um backend.
Este guia aborda a assinatura em backend (no 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 mude para um dos backends de produção acima através de 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 a utilizadores finais e são por eles operadas (aplicações de consumo, fluxos de onboarding), utilize um backend de carteira embutida / gerida: Privy, Turnkey, CDP, Crossmint ou Openfort. Estes gerem carteiras por utilizador e a autenticação por si.
Se está a assinar como a sua própria aplicação (um pagador de taxas, uma tesouraria, automação de backend), continue abaixo.
Precisa de aprovação multiparte, custódia institucional ou controlos regulamentares?
Se as assinaturas têm de cumprir uma política de aprovação, um limite de despesa ou um fluxo de conformidade antes de serem produzidas, ou se precisa de um custodiante regulado que guarde as chaves, utilize um backend de MPC / custódia institucional: Fireblocks, Dfns, Para, Utila ou Fordefi. Estes dividem ou mantêm a chave em custódia 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 cloud deve guardar a chave em infraestrutura suportada por hardware e a sua política de IAM controla quem pode assinar, utilize o KMS dessa cloud:
- Execução na AWS → AWS KMS
- Execução na GCP → GCP KMS
Se pretende operar a infraestrutura de chaves por si, ou se utiliza várias clouds ou on-prem, utilize o HashiCorp Vault. É você quem o executa e audita; 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 leva-o a 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 de um dispositivo Ledger, e uma pessoa confirma cada assinatura no respetivo ecrã. Adequada para assinatura interativa por operadores, não para serviços sem supervisão. Apenas Rust, opcional e não abrangida pela auditoria. Backend: Ledger.
- Gestão de chaves autoalojada: é você quem opera a infraestrutura de chaves; a chave permanece dentro dela e assina a pedido. Backend: HashiCorp Vault.
- Cloud KMS / HSM: um fornecedor de cloud guarda a chave em infraestrutura suportada por hardware; a chave nunca sai do serviço e a sua política de IAM controla quem pode assinar. Backends: AWS KMS, GCP KMS.
- MPC e custódia institucional: a chave é dividida ou mantida em custódia por um fornecedor, que cossigna de acordo com a sua política (aprovações, limites). Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Carteiras embutidas 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 | Caixa preta: você envia. Automático nativo: a Fordefi reescreve e envia. Manual nativo: a Fordefi reescreve, você envia o resultado |
| 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 lado do 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
Para além da custódia, cada backend tem um único formato de transação, que determina como chama o signer:
- Assinar: o fornecedor assina os bytes que construiu e você transmite-os. A maioria dos backends, incluindo o Ledger e o modo caixa preta 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 lado do servidor, pelo que uma falha não significa que nada foi registado. Crossmint e modo automático nativo da Fordefi.
A tabela de capacidades do signer no README de cada linguagem indica 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 de 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?