Keychain 在所有后端中提供统一的 SolanaSigner 基础接口，因此对大多数后端而言，选择属于运维层面的决策，而非架构层面：您可以随时通过配置进行更改。例外在于交易形态：Crossmint 和 Fordefi 原生自动模式会在服务端签名并广播，而 Fordefi 原生手动模式会在签名前重写交易，因此切换到其中任何一个或从中切换出来，都会改变您调用签名器的方式。因此，请从您的需求出发，而非从产品出发。 决定大部分选择的关键在于两个问题：私钥存储在哪里，以及谁有权使用它授权签名？
除 Ledger 外，所有后端均提供全部四种语言版本（Rust、TypeScript、Python 和 Go）。Ledger 仅支持 Rust，需通过可选启用的 ledger 功能使用。
不存在唯一最佳的后端。每种后端都更适合特定的约束条件：您当前使用的云平台、您是否希望自行运维密钥基础设施，以及您必须具备哪些托管和审批控制。下方流程会将这些约束条件对应到相应的后端。
本指南介绍后端（服务端）签名。如果您的终端用户在浏览器中自行签署交易，请改为通过 Wallet Standard 使用钱包。请参阅 生产环境中的签名。
决策流程
本地开发和测试无需这些：原型开发时请使用 Memory 后端，然后通过配置切换到上述任一生产环境后端。
逐步解析各问题
您是为自己的应用签名，还是为终端用户签名？
如果您要配置由终端用户拥有并操作的钱包（消费类应用、用户接入流程），请使用嵌入式 / 托管钱包后端：Privy、Turnkey、CDP、Crossmint 或 Openfort。这些后端会代您管理每位用户的钱包和身份验证。
如果您是以自己的应用身份签名（手续费支付方、资金库、后端自动化），请继续往下看。
您是否需要多方审批、机构级托管或合规控制？
如果签名在生成之前必须通过审批策略、支出限额或合规流程，或者您需要由受监管的托管机构持有密钥，请使用 MPC / 机构级托管后端：Fireblocks、Dfns、Para、Utila 或 Fordefi。这些后端会拆分或托管密钥，并按照您的策略联合签名。
如果您只需要一个按请求签名的密钥，请继续往下看。
您想自己持有密钥，还是交由服务商持有？
如果希望由云服务商在硬件支持的基础设施中持有密钥，并由您的 IAM 策略控制谁可以签名，请使用对应云平台的 KMS：
- 运行于 AWS → AWS KMS
- 运行于 GCP → GCP KMS
如果您希望自行运维密钥基础设施，或者使用多云或本地部署，请使用 HashiCorp Vault。由您自行运行和审计；密钥始终保留在 Transit 引擎内部，并按请求签名。
托管模式
这些后端分为六种托管模式。上面的流程会将您引导至其中一种。
- 自托管（进程内）：由您的应用持有原始私钥。便于开发，但不适合生产环境。后端：Memory。
- 自托管（硬件钱包）：密钥永不离开 Ledger 设备，每次签名都需由人在其屏幕上确认。适用于交互式的操作员签名，不适用于无人值守的服务。仅支持 Rust，需自行选择启用，且不在审计范围内。后端：Ledger。
- 自托管密钥管理：由您运维密钥基础设施；密钥始终保留在其中，并按请求签名。后端：HashiCorp Vault。
- 云端 KMS / HSM：云服务商将密钥存储在硬件支持的基础设施中；密钥永不离开该服务，并由您的 IAM 策略控制谁可以签名。后端：AWS KMS、GCP KMS。
- MPC 与机构级托管：密钥在服务商处被拆分或托管，由服务商按照您的策略（审批、限额）联合签名。后端：Fireblocks、Dfns、Para、Utila、Fordefi。
- 嵌入式与托管钱包：由服务商代您管理钱包，通常用于接入终端用户。后端：Privy、Turnkey、CDP、Crossmint、Openfort。
后端对比
| 后端 | 托管模式 | 最适用于 | 备注 |
|---|---|---|---|
| Memory | 自托管（进程内） | 本地开发、测试、CI | 进程内为原始密钥；请勿用于生产环境 |
| Ledger | 自托管（硬件钱包） | 通过 Rust 工具进行交互式操作员签名 | 仅支持 Rust，需选择启用 ledger 功能，未经审计；每次签名均在设备上确认 |
| HashiCorp Vault | 自托管密钥管理 | 运营自有密钥基础设施的团队 | 使用 Transit 引擎；由您自行运维和审计 |
| AWS KMS | 云端 KMS / HSM | 运行于 AWS 的后端 | 密钥永不离开 KMS；由 IAM 控制签名权限 |
| GCP KMS | 云端 KMS / HSM | 运行于 GCP 的后端 | 密钥永不离开 KMS；由 IAM 控制签名权限 |
| Fireblocks | MPC / 机构级托管 | 资金库、交易所、合规托管场景 | 提供策略引擎和审批工作流 |
| Dfns | MPC 钱包基础设施 | 具备策略控制的程序化钱包 | Ed25519 签名 |
| Para | MPC 钱包 | 需要 MPC 支持的钱包应用 | API 密钥 + 钱包 ID |
| Utila | MPC 托管 + 联署方 | 现有 Utila 托管的 Solana 钱包 | signMessage 不支持；需自行广播交易 |
| Fordefi | MPC / 机构级托管 | 具备策略控制的机构托管 | 黑盒模式：由您发送。原生自动模式：Fordefi 重写并发送。原生手动模式：Fordefi 重写，由您发送结果 |
| Privy | 嵌入式钱包 | 面向用户的消费类钱包接入应用 | 应用托管的嵌入式钱包 |
| Turnkey | 非托管密钥管理 | 程序化、策略门控的签名场景 | 非托管密钥管理 |
| CDP | 托管钱包（Coinbase） | 基于 Coinbase 开发者平台的应用 | signMessage 仅接受 UTF-8 载荷 |
| Crossmint | 托管钱包 | 市场平台及托管钱包应用 | 仅发送：在服务端广播，可能为赞助 gas 费而重写交易；不支持 signMessage |
| Openfort | 嵌入式后端钱包 | 服务端钱包 | 密钥存储于 TEE 中 |
能力形态
除托管方式外，每个后端都有一种交易形态，它决定了您调用签名器的方式：
- 签名：服务商对您构建的字节进行签名，由您自行广播。大多数后端均属此类，包括 Ledger 和 Fordefi 黑盒模式。
- 重写并签名：服务商重写交易后签名，但不广播。请基于其返回的交易继续操作。适用于 Fordefi 原生手动模式。
- 签名并广播：服务商在服务端签名并广播，因此失败并不意味着交易没有上链。适用于 Crossmint 和 Fordefi 原生自动模式。
每种语言 README 中的签名器能力表列出了各后端的形态；安全模型则说明了每种形态所提供的保证。
企业应用场景
单个应用往往需要同时使用其中多种后端。由于接口是共享的，只要这些后端具有相同的能力形态，您就可以为不同角色运行不同的后端，而无需更改调用位置。
- 资金库操作 — 将操作性"热"签名者与"冷"资金库签名者分离。使用 MPC 托管或云 HSM 为资金库提供支持，并在高价值签名前要求审批策略。
- 审批工作流 — MPC 和托管后端（如 Fireblocks）在生成签名前强制执行多方审批。
- 合规与审计 — 云 KMS（AWS/GCP）和 Vault 生成签名审计日志；机构托管方增加策略执行和报告功能。
- 受监管环境 — 将密钥材料保存在 HSM、KMS 或机构托管方中，确保原始密钥永不接触您的应用程序。
请参阅生产最佳实践，了解如何安全运行这些后端。
Is this page helpful?