Trustivon MPC Sentinel：企业级 MPC 签名平台（策略可控、审批可审计）

企业在做链上业务签名时，最常见的不是“能不能签”，而是“怎么放心签”。真实挑战通常落在四个维度：

• 私钥如何做到“永不出域”，同时仍能支撑业务系统稳定调用
• 签名是否可控：能限制什么、不能限制什么要可定义、可执行、可审计
• 一次签名请求是否可复盘：审批/拒绝原因、执行结果、失败定位要可追溯
• 业务系统如何低耦合接入签名能力：避免把 MPC/KMS 的差异扩散到业务侧

多方计算（MPC, Multi-Party Computation）提供了一条成熟的安全路线：通过分片与协作，让单点泄露无法直接导出完整私钥。更关键的是，MPC 只有在被产品化为“可控、可审计、可扩展”的闭环能力后，才能真正进入企业生产环境。

产品一句话

Trustivon MPC Sentinel 是面向企业内部部署的企业级 MPC（多方计算）签名平台，支持策略控制与审批流程，提供 API Key 安全下发与完整审计能力，让每一次签名都可控、可追溯、可审计。

为什么企业需要 MPC 签名平台

1. 安全边界：把风险从“钥在何处”迁移到“协作与校验”

传统签名往往把关键能力集中在单点。MPC 的价值在于：完整私钥不会落在单一系统中，攻击者即便控制某一侧，也难以直接完成签名。

2. 策略可控：让“签名动作”成为规则执行的最后一环

企业不需要“任何交易都能签”。平台需要在签名前先做确定性校验，例如：

• 允许/禁止的合约或程序地址（allowlist / denylist）
• 允许的函数方法（EVM selector）或指令类型（SVM discriminator）
• 单笔最大金额、是否允许原生交易
• 是否触发人工审批（进入 pending_approval）

这样，MPC 的协作过程只发生在“被规则允许”的请求上，降低误签与合规风险。

3. 审计可追溯：从“做了签名”到“解释为什么做了”

企业最终要的不止是签名结果，还要可解释与可追溯：

• 请求级审计落库：请求 ID、审批/拒绝原因、访问来源、最终状态
• 可查询状态机：pending / pending_approval / approved / rejected / failed
• 事后回放与定位：当出现异常时能快速定位链路与责任边界

适用场景（你可能正在遇到这些问题）

• 托管钱包与企业资金管理：需要更强的私钥安全边界与权限控制
• 合规敏感业务：审批流、留痕与审计是刚需
• 高价值资产操作：需要对地址、方法/指令、金额进行严格白名单与上限控制
• 计划把签名能力纳入风控运营闭环：需要统一 API、统一状态查询与统一审计模型

产品能力清单：MPC Sentinel 的“闭环能力”

入口鉴权与访问控制（入口层）

• API Key 校验、每 Key IP 白名单、速率限制（可选）
• 通过加密领取流程降低明文在传输与后台展示泄露风险
• 目标：保证只有被允许的系统/人能发起签名请求

策略引擎校验（签名前置层）

• 地址级：合约/进程 allowlist、denylist（黑名单优先）
• 指令/方法级：EVM 方法签名 selector / SVM 指令 discriminator 白名单
• 交易级：是否允许原生交易、单笔最大金额
• 审批级：触发 pending_approval，审批通过后才进入执行

协作签名与路由（计算/协作层）

• MPC 节点协作完成签名计算
• 与 KMS 并行支持：根据钱包类型/路由规则在平台内部选择合适路径

审计落库与状态查询（结果层）

• 请求级审计：请求 ID、审批/拒绝原因、访问来源等
• 状态查询接口：统一状态机，支持查询 pending / pending_approval / approved / rejected / failed

统一业务接入（业务层）

• 同一套 /v1/* 业务 API：MPC / KMS 按钱包类型在服务端自动路由，业务无需分叉签名逻辑
• 官方 Go SDK：封装 SignAndWait（一键等待）或分步提交 + 状态轮询；支持 NewClientFromEnv 快速初始化
• OpenAPI 联调：运行时提供 /openapi.yaml，并可通过 /api-docs 使用交互式文档；同时支持 API Key 加密领取等安全衔接

算法与链生态：覆盖 EVM 与 SVM

• secp256k1：对应 EVM 场景（如以太坊兼容链）
• ed25519：对应 SVM 场景（如 Solana）
• 同一平台内可同时服务多链：策略、审计与接入方式保持一致，扩展新链时负担更小

架构示意：从入口到协作区再到审计落库

把职责拆清楚，企业侧通常更关注两点：

• 管理层短暂不可用时，不影响已下发/已鉴权的签名调用
• 签名 API 层可横向扩展，提高可用性与稳定性
• 关键保障：签名不依赖管理后台在线，Backend 仅负责管理与配置，不提供 /v1 签名业务 API

为什么说这不是“原理证明”，而是“可上线的产品路线”

很多团队评估 MPC 时，容易把注意力放在“协作能不能算出来”。但企业生产环境要解决的是“能不能被管住”。因此 MPC Sentinel 将关键能力前置到产品结构里：

• 签名前：策略引擎把风险拦在执行之前
• 签名中：协作区只对已通过策略的请求执行
• 签名后：用状态机与审计落库实现可复盘与可运营

与 KMS 的关系：两条路径，统一一套业务接口

在企业签名体系里，MPC 与 KMS 经常是并存的：

• MPC 更适合安全边界强、合规审计要求高的场景
• KMS 更适合高并发、高吞吐的业务签名需求：密钥托管于 AWS KMS，并提供 5000+/s 的签名性能（平均间隔约 40ms）

关键是：业务系统只需调用统一的签名 API，平台内部按路由与钱包类型选择合适路径，减少业务侧复杂度。

部署与运维：企业内网的现实要求

如果目标是企业内网部署，通常会关注：

• API 层与管理层解耦
• 多实例部署与负载均衡、健康检查；异常节点可自动剔除
• 数据库用于状态落库与审计追踪
• 可用性优先：尽量让“管理不可用”不影响“已鉴权的签名能力”

当架构稳定后，再扩展协议或新增链类型会更从容，因为策略模型与审计模型具备通用性，差异集中在交易解析与规则映射层。

适合你下一步怎么做

如果你正在评估 MPC 企业签名基础设施，建议从三个问题开始对齐：

• 你要把哪些策略维度固化成可执行规则（地址/方法/金额/审批）
• 你需要怎样的审计粒度与状态机（请求级落库、可查询状态、失败定位）
• 你希望业务侧用什么方式接入（同步等待还是异步轮询，统一 /v1/* 接口）

如果你愿意，我们可以协助你梳理现有链/钱包接入方式、策略规则与审计合规落点。企业部署与授权方案咨询：admin@trustivon.com（邮件主题可写“MPC Sentinel 企业版咨询”）。你也可以先浏览我们的开发入口与资料：<https://trustivon.com/mpc-sentinel>。