fhEVM Coprocessor 架构深度解析链下 FHE 计算、Gateway 与 TKMS 协同机制【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevmfhEVMFHEVM是 Zama 推出的将全同态加密FHE与区块链深度融合的技术方案而fhEVM Coprocessor是其两大部署形态之一在不修改宿主链验证节点的情况下将繁重的 FHE 计算整体搬移到链下的协处理器中执行。本文以 architecture.md 为骨架结合当前仓库中coprocessor/fhevm-engine的 Rust 实现、host-contracts/gateway-contracts的 Solidity 合约以及 KMSTKMS文档完整讲解 Coprocessor 的组件构成、符号执行与 FHE 计算的分工、数据可用性DA层设计以及 Gateway 如何通过 TKMS 完成输入验证、解密与重加密。阅读本文后你将掌握 fhEVM Coprocessor 的整体架构蓝图、各组件间的数据流与信任边界、密钥管理TKMS在系统中的安全定位并能顺着仓库路径定位到对应的源码实现继续深入。从整体架构看 Coprocessor 的定位fhEVM 有两种部署形态相关说明见 fundamentals/overview.mdfhEVM-native宿主编排链本身运行 FHEVM每个验证节点都内嵌一个 Executor 负责真实 FHE 计算密文直接存储在链上。这意味着现有区块链若想接入全部验证节点都必须改造。fhEVM-coprocessor宿主区块链验证节点保持原样不修改由一个完全链下的Coprocessor组件承接 FHE 计算密文存放在链下本地数据库与公开的数据可用性DA层中。该形态下仍需要一个修改过的宿主链全节点作为 Coprocessor 的一部分。Coprocessor 形态的核心价值在于链上只做符号执行不触碰真实密文链下异步完成真实的 FHE 计算从而把对既有链生态的侵入降到最低。架构总览图architecture.md 用一张 Mermaid 图勾勒出 Coprocessor 与宿主链、Gateway、TKMS、DA 的完整关系关键信息流可拆解为四类dApp 与链交互dApp 通过fhevmjsJS SDK访问宿主链的区块链 API发起普通交易与 FHE 相关交易。宿主链与 Coprocessor宿主链通过 P2P 将区块同步给 Coprocessor 内嵌的修改版全节点Coprocessor 通过 DA API 将计算结果发布到 DA 层。dApp 与 GatewaydApp 通过fhevmjs调用 Gateway 的 Reencrypt API重加密与 Inputs API输入验证签名。Gateway 与 TKMSGateway 与 TKMS 之间通过 TKMS 链上的交易与事件完成密钥相关操作。值得注意的是Gateway 与宿主链也通过宿主链 API 双向连接Host -- Gateway因为 Gateway 需要监听宿主链上的解密请求事件、并回调写入解密结果详见下文解密流程。Coprocessor 的三大链下子组件原文档明确指出Coprocessor 是一个完全链下的组件它由以下子组件构成宿主区块链全节点full node执行宿主链上的所有区块。它必须是一个经过修改的 FHEVM 兼容全节点仓库中coprocessor/fhevm-engine下的host-listener、consensus-detector等即围绕全节点事件流构建。执行器executor负责真正的 FHE 计算。在原文档对应的代码仓库中该职责由 tfhe-worker 承担它读取输入密文、执行 TFHE 运算、写回结果密文。本地数据库database用于存储 FHE 密文。仓库中由 PostgreSQL 承载见 db-migration 目录下 100 个 SQL 迁移文件以及fhevm-engine-common中的数据库层实现。其运行本质可以概括为当 Coprocessor 执行区块、检测到 FHE 操作事件时执行器真正执行 FHE 计算并把 FHE 密文从本地数据库以及 DA中读取/写入。符号执行与 FHE 计算的分工Coprocessor 的区块执行被拆成两段完整描述见 fhe_computation.md 与 symbolic_execution.md符号执行链上onchain发生在 EVM 内的 FHEVMExecutor.sol 合约里。EVM 在一个区块内累积所有请求的 FHE 操作记录其输入句柄与结果句柄并以链上事件日志形式发出。符号执行只操作句柄不需要真实密文因此可以对结果句柄做确定性推导。FHE 计算链下offchainhost-listener 将事件日志摄入 Coprocessor 数据库TFHE worker 随后异步完成真实计算。由于符号执行阶段已经确定了句柄关系FHE 计算可以延迟到区块提交之后进行——只有用户需要查看明文解密或重加密时才必须拿到真实密文。原文档给出的时序图如下从源码结构看这一流程在仓库中有完整落地host-listener提供poller/consumer两种摄入模式见 host-listener/src/bin 下的main.rs、poller.rs、consumer.rs把 FHE 操作事件写入数据库tfhe-worker/src/dependence_chain.rs 实现了依赖链dependence chain调度用于判定 FHE 计算之间的依赖关系见下文并行执行。密文句柄符号执行的基础符号执行之所以不需要真实密文靠的是**密文句柄ciphertext handle**机制。句柄可视为某个 FHE 密文的唯一指针实现为一个 32 字节值由对密文或其他句柄施加哈希函数得到。符号执行同时还会对输入句柄做约束检查如访问控制列表 ACL、类型是否匹配等详见 symbolic_execution.md。FHEVMExecutor合约的一个核心职责就是确定性生成句柄对请求的 FHE 操作与输入做哈希得到结果句柄 HH keccak256(fheOperation, input1, input2, ..., inputN)其中每个输入既可以是其他句柄也可以是明文值。正因为结果句柄在链上符号计算阶段就已确定执行器/Coprocessor 才能提前分析计算之间的数据依赖进而调度并行执行。并行执行从数据依赖到多线程调度fhe_computation.md指出Coprocessor 可以从摄入的事件中提取数据依赖关系从而并行执行 FHE 计算如果计算 A 的输出或依赖于 A 输出的其他计算的输出被用作后续计算 B 的输入则 A 与 B 是**依赖dependent**关系必须按顺序执行。如果两个计算的输入与彼此的输出无关则它们是**独立independent**的可以并行调度。从源码看这一策略在 tfhe-worker/src/dependence_chain.rs 中实现为依赖链 ID机制worker 通过 SQL 查询获取/扩展依赖链锁将相互依赖的计算串成链、相互独立的计算拆到不同链上从而在多个线程间并行处理。原文档同时明确目前采用简单策略调度多线程上的 FHE 计算更优的调度策略将在未来引入并做成可配置项——这是当前实现的已知边界。数据可用性DA层原文档对 DA 层的定位非常明确Data Availability (DA) 是一个可公开验证的数据库它是 Coprocessor 本地数据库的镜像。引入它的目的是让任何人都能通过检查 Coprocessor 发布到 DA 上的结果来验证 Coprocessor 的行为是否诚实。也就是说DA 层解决的是链下计算的可验证性问题Coprocessor 的本地数据库是私有的而 DA 让结果公开可查外部观察者以及其他 Gateway、用户或审计者可以比对 DA 上的结果与链上状态确认 Coprocessor 没有作恶。需要特别说明当前仓库的状态fhe_computation.md明确写道——DA 层目前仍在开发中work in progress现阶段 Coprocessor 只把 FHE 密文插入本地数据库尚未写入 DA未来计划将 FHE 密文也同步写入 DA 层。因此本文对 DA 的描述均以原文档的设计意图为准不宜将其当作已上线的功能。Gateway输入验证、解密与重加密的入口Gateway 是连接 fhEVM 与 TKMS 的桥梁这一角色在 fundamentals/overview.md 有系统论述。它负责三类核心业务全部经由/借助 KMSTKMS完成输入验证Input Verification验证用户提交的 FHE 密文输入及其零知识证明。解密Decryption作为预言机oracle监听链上解密请求事件把密文交给 TKMS 解密再通过回调函数把明文结果写回链上。重加密Reencryption作为 Web2 服务响应用户的 HTTP 请求把密文重加密为只有指定用户私钥可解的形式。信任边界Gateway 是**不受信任untrusted**的组件。恶意 Gateway 最多只能忽略 FHEVM 与 TKMS 之间的请求影响解密/重加密的活性liveness而无法破坏系统的正确性或隐私性——因为所有关键操作都由 TKMS 完成并签名。部署多个 Gateway 且假设至少一个诚实即可缓解活性问题。输入验证ZKPoK 与 KMS 签名用户向 Coprocessor 提交的输入是指加密数据FHE 密文例如 ERC20 转账中的金额详见 inputs.md。为防恶意密文泄露 FHE 私钥信息系统引入零知识证明ZKPoK保证密文是良构的加密过程正确用户知道对应的明文值输入密文只能被用于特定的智能合约。ZKPoK 由KMS 验证并签发签名KMS_S给用户当用户将输入字节数组传入FHE.fromExternal()把密文转换为句柄时链上验证KMS_S。这样做的好处是链上只需验证一个签名比直接验证 ZKPoK 快得多。原文档给出了输入机制的三步流程获取公钥材料与 CRS用户向 Gateway 查询/keys端点获得 FHE 公钥与 CRS 及其签名可通过 KMSVerifier 合约验证。加密阶段用户用 FHE 公钥加密明文得到密文C并计算ZKPoK。C被绑定到contractAddress与callerAddress以便后续由 KMS 签名、允许在合约中使用。C 密文用区块链 FHE 公钥加密 ZKPoK 零知识证明用户侧计算 eInput 类型 索引 S 签名 struct CVerificationStructForKMS { address contractAddress; bytes32 hashOfCiphertext; address callerAddress; }使用阶段用户拿到KMS_S后即可在 FHEVM 内使用输入链上仅验证 KMS 签名。其中紧凑输入列表Compact Input Lists用einput类型指代列表中的某个密文序列化后的列表含 ZKPoK作为inputProof传入合约可大幅减小输入体积。原文档给出的合约示例// SPDX-License-Identifier: BSD-3-Clause-Clear pragma solidity ^0.8.24; import fhevm/lib/FHE.sol; contract Adder { euint32 result; function add(externalEuint32 inputA, externalEuint32 inputB, bytes calldata inputProof) public { euint32 a FHE.fromExternal(inputA, inputProof); euint32 b FHE.fromExternal(inputB, inputProof); result FHE.add(a, b); FHE.allow(result, address(this)); } }完整的 KMS 验证时序摘自 inputs.md从源码结构看输入验证相关的链上逻辑分布在 gateway-contracts/contracts/InputVerification.sol其测试见 gateway-contracts/test/InputVerification.tsFHE.fromExternal等句柄转换与 FHE 运算库位于 host-contracts/lib/FHE.sol。解密Gateway 作为预言机解密是公开的——任何人都能看到解密结果若涉及个人信息应使用重加密。Gateway 扮演预言机角色流程见 decryption.md监听来自 FHEVM 的解密请求事件事件中包含句柄h对应密文C计算存储证明P证明h即C可以被解密用h作为键从 FHEVM 取回密文C向 TKMS 发送解密请求TKMS 内部运行着一条区块链即KMS BC等待并监听来自KMS BC的decryptionResponse事件包含明文以及 KMS 的多重签名用于证明明文完整性通过回调函数把decryptionResponse返回给链上。解密请求/响应的链上合约载体见 gateway-contracts/contracts/Decryption.sol 及其测试 gateway-contracts/test/Decryption.ts。用户侧通过fhevmjs完成密文获取与解密交互SDK 位于 sdk/js-sdk。重加密Gateway 作为 Web2 服务重加密在客户端发起通过fhevmjs调用 Gateway 服务流程见 reencryption.mddApp 从 view 函数如balanceOf取回待重加密的密文dApp 为用户生成密钥对并请求用户对公钥签名dApp 调用 Gateway提交密文、公钥、用户地址、合约地址与用户签名dApp 用私钥解密收到的值。关键点在于重加密后的密文只能由用户自己的私钥解密因此适合返回个人私密数据如余额而不像公开解密那样把明文暴露给所有人。相关的链上验证逻辑位于 gateway-contracts/contracts/CiphertextCommits.sol。TKMS系统信任的根基TKMSThreshold Key Management System是 fhEVM 的密钥管理子系统秘密 FHE 密钥由 TKMS 托管任何 FHEVM 节点无论 Executor 还是 Coprocessor都接触不到。FHEVM 节点只持有公开的 bootstrap key 用于执行密文上的计算但该公钥不足以解密任何密文从而把算力与密钥彻底分离见 fundamentals/overview.md。从 tkms/architecture.md 看TKMS 由前端Frontend、后端Backend与存储Storage三部分组成前端 KMS 区块链由 ASC/ISC/Config 等智能合约 KMS 验证节点CometBFT 实现构成是 KMS 的公开接口。所有解密/重加密请求都以交易形式提交到 ASCASC 做通用校验并转发 ACL 校验给对应的 ISCISC 持有各应用的验证者集合通过状态包含证明校验 FHEVM 链上的 ACL。所有操作形成可审计的日志并为 KMS 运营方提供支付机制。KMS 区块链可以由单个验证节点运营无需去中心化时也可采用许可或非许可方式运行。后端 KMS Core Engine系统中最关键的安全部件。Core 是可信 gRPC 服务负责请求校验、签名与 FHE 密码学操作真正的 FHE 计算由 Engine 子组件承担Engine 不联网、只信任 Core 的调用Connector 负责在 KMS 区块链与后端之间转发Coordinator 负责多 Core 场景下的负载均衡。后端支持**集中式centralized与门限式threshold**两种形态分别见 centralized.md 与 threshold.md并支持 AWS Nitro 安全 enclave 与开发者模式明文落盘便于本地调试。存储存放不适合写入链上 fulfillment 交易的大块公开材料FHE 公钥、CRS 等链上只存 URI 与签名指纹。存储可以完全不受信任支持 AWS S3 与本地文件系统两种形态。安全前提TKMS 本身不内置针对选择性失败攻击的防护——攻击者可通过提交畸形密文请求解密/重加密来试探提取密钥。因此系统隐含一个信任假设只有良构密文才会被提交给 KMS即假设密文的生产者诚实这一点必须由外部如 FHEVM保证。此外门限后端的假设是经典 MPC 门限假设而非 PoS其激励层面的合理性仍是未来工作方向。端到端视角一次加密输入的完整旅程把以上模块串起来一次典型交互的完整链路是密钥准备dApp 通过fhevmjs向 Gateway/keys端点获取 FHE 公钥与 CRS含 KMS 签名。加密输入用户加密明文、计算 ZKPoK提交(C, contractAddr, callerAddr, ZKPoK)给 GatewayGateway 转发 KMS 链验证KMS Core 验证 ZKPoK 后签发KMS_S返回用户。链上符号执行用户在宿主链上调用合约如FHE.fromExternalFHE.addEVM 内的FHEVMExecutor只做句柄级别的符号执行并发出 FHE 操作事件此时真实密文不出现在链上。链下 FHE 计算host-listener 将事件摄入 Coprocessor 数据库TFHE worker 依据依赖链调度并行完成真实 FHE 计算并写回密文当前仅本地数据库DA 层仍在开发中。查看明文若需公开结果如拍卖开标合约请求公开解密Gateway 预言机经 TKMS 解密后回调写回明文若需私密结果如个人余额用户走重加密路径用自己私钥解密。安全性小结链上只处理句柄与签名链下只处理密文计算私钥全程留在 TKMS 内集中式或门限式保护Gateway 不受信任、只影响活性不影响安全DA 层开发中将提供对 Coprocessor 行为的公开可验证性。这一设计使 fhEVM Coprocessor 能以较低侵入度接入既有区块链同时把 FHE 计算、密钥管理与数据验证的职责清晰分层。深入阅读路径架构与计算分工architecture.md、fhe_computation.md、symbolic_execution.md输入机制与 ZKPoKinputs.md系统总览与信任模型overview.mdGateway 解密/重加密decryption.md、reencryption.mdTKMS 架构tkms/architecture.md源码实现链下引擎在 coprocessor/fhevm-engineTFHE worker 调度见 dependence_chain.rshost-listener 事件摄入见 host-listener/src/bin链上合约见 host-contracts/contracts/FHEVMExecutor.sol 与 gateway-contracts/contracts部署相关 Helm 模板见 charts/coprocessor。【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考