fhEVM 密钥管理服务（KMS）深度解析：MPC 密钥生成、门限解密与密钥生命周期管理-港品优选

fhEVM 密钥管理服务（KMS）深度解析：MPC 密钥生成、门限解密与密钥生命周期管理

【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm

导读

KMS（Key Management Service）是 Zama fhEVM 协议中负责 FHE（全同态加密）密钥全生命周期管理的核心组件，它以去中心化 MPC（多方计算）网络的形式，为所有 host chain 提供全局 FHE 密钥生成、门限解密和零知识证明基础设施支持。本文以 docs/protocol/architecture/kms.md 为骨架，结合 host-contracts 与 gateway-contracts 中的合约源码、kms-connector 实现以及协议配置，完整讲解 KMS 的职责、安全架构、密钥生命周期与可审计的解密工作流，帮助你理解"密钥不落地、解密需共识、过程可验证"的 FHE 区块链集成方案。

KMS 是什么

KMS 是一个由多个节点（也称为 party）组成的去中心化网络，这些节点共同运行 MPC 协议，承担以下职责：

安全地生成全局 FHE 密钥；
为公开解密和面向用户的目标解密安全地解密密文；
支撑零知识证明基础设施；
以符合 NIST 规范的方式管理密钥生命周期。

KMS 完全在链下（off-chain）工作，但其所有密钥相关操作都由Gateway发起并跟踪。这种"链下计算、链上编排"的职责分离，保证了系统具有强去中心化与可审计性——正如 docs/protocol/architecture/gateway.md 所述，Gateway 本身不存储任何敏感数据或解密密钥，只负责编排与验证。

KMS 的核心职责

FHE 门限密钥生成（Threshold Key Generation）

KMS 安全地生成一套跨所有 host chain 使用的全局公钥/私钥对：

该密钥使密文具有可组合性（composability）——加密数据可以在不同合约与不同链之间共享；
FHE 私钥从不被任何单一 party 完整掌握，而是通过门限秘密共享（threshold secret sharing）拆分到各 MPC 节点手中。

从链上实现看，这一过程由 host-contracts/contracts/KMSGeneration.sol 编排，整个密钥生成被拆成prepKeygen（预处理）与keygen两阶段请求，并额外支持crsgen（CRS 生成）。三类请求通过 host-contracts/contracts/shared/Constants.sol 中定义的请求类型标签在 ID 高位进行区分：

请求类型	RequestType 枚举	ID 格式（高 8 位）	计数器基数常量
PrepKeygen	`PrepKeygen`(3)	`0x03`	`PREP_KEYGEN_COUNTER_BASE`
Keygen	`Keygen`(4)	`0x04`	`KEY_COUNTER_BASE`
Crsgen	`Crsgen`(5)	`0x05`	`CRS_COUNTER_BASE`
KmsContext	`KmsContext`(7)	`0x07`	`KMS_CONTEXT_COUNTER_BASE`
Epoch	`Epoch`(8)	`0x08`	`EPOCH_COUNTER_BASE`

ID 由高 8 位类型标签 + 31 位计数器组成（REQUEST_TYPE_SHIFT = 248），保证所有请求 ID 全局唯一，且不同类型不会重叠。keygen请求必须等待前一个 keygen 达成共识后才能发起（见 KMSGeneration.sol 中KeygenOngoing回退逻辑），从而保证密钥流的有序推进。

基于 MPC 的门限解密（Threshold Decryption）

KMS 使用门限解密协议执行解密：至少需要达到最小数量的 MPC party 参与（例如 13 个节点中的 9 个）才能稳健地解密一个值。这一设计带来两点保证：

抗合谋：没有任何单一 party 拥有完整密钥；攻击者必须控制超过门限数量的 KMS 节点才能影响系统；
双模式支持：
- 公开解密（public decryption）：例如为智能合约解密；
- 用户解密（user decryption）：结果私密返回，仅以只面向该用户重新加密（re-encryption）的形式交付。

所有解密操作的输出都由每个节点签名，输出可以在链上验证，实现全流程可审计。

链上实现中，门限以KMS 上下文（context）为粒度存储于 host-contracts/contracts/ProtocolConfig.sol：该合约管理每上下文对应的publicDecryptionThreshold、userDecryptionThreshold、kmsGenThreshold、mpcThreshold等多类门限，并限制门限不能超过该上下文 KMS 节点总数（_checkThreshold）。而 host-contracts/contracts/KMSVerifier.sol 中的_verifySignaturesDigestForContext则实际执行签名计数校验：

签名数量少于门限时直接回退KMSSignatureThresholdNotReached；
使用 transient storage（tstore/tload）对已恢复的签名者去重，确保同一个 KMS 节点的重复提交不会被重复计数；
收集到足够不同的有效签名即返回true，并在返回前清理 transient storage，保证账户抽象场景下的可组合性。

ZK 证明支持（ZKPoK）

KMS 生成验证零知识知识证明（ZKPoK）所需的公共参考串（CRS）。当用户提交加密值时，该 CRS 用于验证：

加密输入是合法且结构良好的；
用户确实知道所提交输入密文中包含的明文。

在链上，CRS 的生成同样走共识流程：crsgenRequest指定maxBitLength与paramsType发起请求（KMSGeneration.sol 的crsgenRequest），各 KMS 节点签名响应后，crsgenResponse收集签名，一旦达到kmsGenThreshold即记录 CRS 摘要（crsDigest）并将activeCrsId更新为新生成的 CRS，随后通过ActivateCrs事件发布共识存储 URL 列表。

安全架构

基于 MPC 的密钥共享

KMS 当前由 13 个 MPC 节点组成，由不同的可信组织运营；
私钥通过门限秘密共享拆分；
节点间通信使用mTLS + gRPC加密保护。

从部署侧看，13 节点、门限、签名者地址等信息都以KmsNode（包含txSenderAddress、signerAddress、storageUrl）的形式登记在 ProtocolConfig.sol 的 KMS 上下文中。KMSGeneration 合约在验证响应时要求签名者地址与交易发送者地址必须匹配且同属请求时固定的上下文（_checkKmsContextSignerMatchesTxSender），防止跨上下文混签。

诚实多数假设（Honest Majority）

协议在至多 1/3 节点作恶时依然稳健（即 13 节点中可容忍至多 4 个恶意节点）；
即使部分节点离线或行为不当，也支持保证输出交付（guaranteed output delivery）。

这与 ProtocolConfig.sol 中mpcThreshold与各门限的设计相互印证：门限的设置必须大于节点总数的 1/3，确保诚实多数始终可以达成共识。

安全执行环境（Secure Execution Environments）

每个 MPC 节点默认运行在AWS Nitro Enclave这一安全执行环境中，连节点运营者都无法访问自己的密钥分片。该设计显著缓解了内部人风险（insider risk），例如未经授权的密钥重建或分片出售。

通过 Gateway 实现可审计性

所有操作都通过 Gateway 广播，并记录为区块链事件；
KMS 响应带有签名，智能合约和用户都可以通过密码学方式验证结果。

这构成了"链下 MPC 计算 + 链上签名共识"的闭环：KMS 节点各自签名，链上合约（KMSGeneration.sol 与 gateway-contracts/contracts/Decryption.sol）负责收集签名并判断是否达到门限，任何一方都无法单独伪造或篡改结果。

密钥生命周期管理（Key Lifecycle Management）

KMS 遵循 NIST SP 800-57 的正式密钥生命周期模型：

状态	描述
Pre-activation	密钥已创建但尚未投入使用。
Active	密钥用于加密和解密。
Suspended	轮换期间被临时替换；仍可用于解密。
Deactivated	归档；仅用于解密。
Compromised	被标记为误用；只允许解密。
Destroyed	密钥材料被永久删除。

为保障轮换期间的互操作性，KMS 支持使用 FHE 进行密钥切换（key switching），使密文可以在轮换过程中安全地在不同密钥之间迁移。链上对应实现是keygen的**迁移（migration）**模式：keygen(ParamsType paramsType, uint256 existingKeyId)传入existingKeyId时，会校验旧密钥必须是当前激活密钥、参数类型必须一致，并通过ActivateKey事件将新生成的压缩密钥集（CompressedKeySet）绑定到既有密钥上（见 KMSGeneration.sol 的_checkMigrationRequest与_checkCompressedKeySetDigest）。

备份与恢复（Backup & Recovery）

在 MPC 稳健性之外，KMS 还提供托管式备份系统：

每个 MPC 节点将自己的密钥分片拆分成加密片段，分发给独立托管方（custodian）；
若某个分片丢失，达到法定人数（quorum）的托管方可协作恢复该分片，即使多个 MPC 节点离线也能完成恢复；
该方法保障业务连续性与面对宕机的韧性；
所有恢复操作都需要运营者达到法定人数，并且在链上完全可审计。

工作流示例：公开解密（Public Decryption）

原文档给出了公开解密的完整链路，结合合约源码可以进一步还原每个步骤的链上行为：

智能合约通过预言机请求解密：预言机调用 Gateway 链上的 Decryption.sol 的publicDecryptionRequest(ctHandles, extraData)，合约从CiphertextCommits获取 SNS 密文材料、校验同一批次 handle 属于同一keyId，并生成全局唯一的publicDecryptionId，同时**将请求时的 KMS 上下文固定（pin）**到该请求上。
Gateway 校验权限并发出事件：Decryption.sol校验 ACL 权限（该合约持有 ACL 的同步副本），并向 KMS 节点广播PublicDecryptionRequest事件，事件中包含ctHandles与extraData。
KMS 节点取回密文、验证并运行 MPC 解密协议：各 KMS 节点共同计算明文，并对PublicDecryptVerification(ctHandles, decryptedResult, extraData)结构体做 EIP-712 签名。
达成法定人数后发布签名结果：KMS 节点（经由 KMS Connector）调用publicDecryptionResponse提交各自签名。合约按签名摘要（digest）分组存储签名，verifiedPublicDecryptSignatures[decryptionId][digest]只在多个节点提交相同解密结果时才可能达到门限——这天然过滤了恶意节点的错误结果（见 Decryption.sol 的publicDecryptionResponse）。达到门限后触发PublicDecryptionResponse事件。
预言机将明文回传上链，合约验证 KMS 签名：host chain 上的 KMSVerifier.sol 提供verifyDecryptionEIP712KMSSignatures，解析decryptionProof（格式为1 + 65*numSigners字节的签名区 + extraData），用 EIP-712 摘要恢复签名者并对照上下文内的签名者集合与门限进行验证。合约（如FHEVMExecutor）据此确认明文真实可信。

用户解密（user decryption）走类似流程，区别在于：响应中交付的是用用户公钥重新加密后的部分解密分片（userDecryptedShare），且用户解密响应的签名列表按请求 ID 聚合（digest 使用零值），以便跨节点收集不同分片后再由用户本地重组。

落地实现：KMS Connector 如何连接链上与链下

KMS 节点（KMS Core）与 Gateway 之间由 kms-connector 连接，它是一个由三个 Rust 微服务组成的组件（详见 kms-connector/docs/architecture.md）：

GatewayListener：监听 Gateway 事件并写入 Postgres 数据库。可部署多个实例，各自连接不同 RPC 节点（含备用 RPC），写入时使用ON CONFLICT DO NOTHING保证只有一条生效，从而"绝不丢失 Gateway 事件"；
KmsWorker：一个或多个工作进程，收到数据库通知后取出请求、通过 gRPC 转发给 KMS Core，并把响应写回数据库。处理中的请求标记under_process = TRUE加锁，失败则复位解锁；
TransactionSender：唯一的交易发送者，把数据库中的 KMS 响应以交易形式提交回 Gateway，成功后删除记录。

该架构通过"数据库持久化 + 通知 + 轮询兜底"（见decryption_from_block_number、kms_operation_from_block_number等恢复选项）保证即使宕机也能追平遗漏的事件与响应，为海量解密吞吐（架构文档中提到的目标是每秒数千次解密）提供可靠性保障。三个服务的配置文件（kms-connector/config/gw-listener.toml、kms-connector/config/kms-worker.toml、kms-connector/config/tx-sender.toml）支持 TOML 文件与环境变量两种配置方式，且环境变量优先级最高；签名钱包既支持十六进制私钥（仅限开发），也支持 AWS KMS 钱包（生产推荐）。

企业官网建设流程全解析