ERC-8229：FHE计算验证

摘要

我正在提出一项新的ERC，该标准定义了通过递归零知识证明（IVC）对全同态加密（FHE）计算进行链上验证的标准接口。

当智能合约对加密数据执行计算时，没有人可以检查该计算——无论是验证者、部署者还是用户。这是FHE的承诺。但这引入了一个信任问题：如果你无法看到计算过程，如何知道其执行是否正确？

本标准解决了这一问题。一个紧凑的证明（≤ 1 KB）即可为任意复杂的加密计算提供证明。在链上以O(1)复杂度完成验证。运行计算的协处理器在设计上是不可信的——该证明是唯一的信任来源。

仓库： https://github.com/Valisthea/styx-erc-fhe-verification
作者： Valisthea（@Valisthea）
相关： ERC：加密代币标准，ERC：密码遗忘接口（单独提交）

问题

FHE支持对加密数据进行计算。多个项目正在构建FHE执行环境（Fhenix、Zama fhEVM、Sunscreen、TFHE-rs）。但没有任何一个项目提出用于验证计算正确性的标准接口。

在没有验证的情况下，区块链上的FHE只是多了一步的加密云计算。你信任协处理器，就像信任AWS一样——这违背了去中心化的根本目的。

具体问题如下：

1. 协处理器的诚实性 — FHE计算被委托给专用硬件（GPU、FPGA）。这些机器位于链下。没有验证，恶意操作者可以返回任何他们想要的结果。一个加密的DeFi金库询问“这个仓位是否低于清算阈值？”——协处理器可能为了保护友好的大户而撒谎，或者为了强制清算竞争对手而撒谎。

2. 跨合约的结果完整性 — 当合约A消费合约B加密计算的输出时，A需要确保B的结果是正确的。如今，每一对合约都发明了自定义的信任假设。没有标准方式让一个合约验证另一个合约的加密计算。

3. 可审计性 — 监管机构需要验证加密金融计算（税务计算、偿付能力证明、合规检查）是否被正确执行——而无需查看底层数据。目前不存在这样的标准接口。

4. 多步骤流水线 — 复杂的DeFi协议链式使用加密计算：加密预言机喂价 → 加密风险计算 → 加密清算检查 → 加密结算。如果第2步出错，下游所有步骤都会出错。每一步的验证可以防止级联故障。

工作原理

三阶段架构

阶段1 — 电路注册。 开发者编写加密智能合约（使用SSL、fhEVM Solidity或任何兼容FHE的语言）。编译器生成一个电路（一系列FHE门）。电路的哈希和验证密钥哈希通过 registerCircuit() 注册到链上。这将特定的计算绑定到特定的验证密钥——防止证明者替换为不同的（平凡的）电路。

阶段2 — 执行和证明生成。 用户提交加密交易。FHE协处理器在加密输入上执行电路。在执行过程中，它生成一个IVC（增量可验证计算）证明：每个门级别的证明被“折叠”到一个运行中的累加器中。最终输出是一个恒定大小的SNARK——无论电路有多少个门。10个门或1000万个门：相同的证明大小，相同的验证成本。

阶段3 — 链上验证。 协处理器通过 submitProof() 提交证明。合约针对已注册的验证密钥验证该证明。如果有效，结果承诺将存储在链上。任何依赖合约在消费结果之前都可以检查 isResultVerified(executionId)。

核心接口

interface IERCZZZZ {
    // 电路注册
    function registerCircuit(bytes32 circuitHash, bytes32 verificationKeyHash, uint256 gateCount, string calldata schemeId) external;
    function isCircuitActive(bytes32 circuitHash) external view returns (bool);

    // 证明提交（executionId在链上计算，而非由调用者提供）
    function submitProof(bytes32 circuitHash, bytes32 inputCommitment, bytes32 resultCommitment, bytes calldata proof, bytes calldata verificationKey) external returns (bytes32 executionId);

    // 结果查询
    function isResultVerified(bytes32 executionId) external view returns (bool);
    function verifiedResultCommitment(bytes32 executionId) external view returns (bytes32);
    function verifyResultProvenance(bytes32 executionId, bytes32 circuitHash, bytes32 inputCommitment, bytes32 resultCommitment) external view returns (bool);

    // 争议（乐观验证）
    function disputeResult(bytes32 executionId, bytes calldata counterProof) external;
    function isDisputed(bytes32 executionId) external view returns (bool);

    // 事件
    event CircuitRegistered(bytes32 indexed circuitHash, address indexed registrant, uint256 gateCount, string schemeId);
    event ExecutionVerified(bytes32 indexed executionId, bytes32 indexed circuitHash, address indexed prover, bytes32 resultCommitment);
    event ResultDisputed(bytes32 indexed executionId, address indexed challenger, bytes32 counterProofHash);
}

扩展

证明者注册表 — 用于协处理器的质押与罚没机制。证明者使用抵押品注册。不良证明将被罚没，挑战者获得奖励。使协处理器激励与诚实计算保持一致。

计算链式组合 — isChainedExecution(executionA, executionB) 验证B的输入可证明是A的已验证输出。verifyExecutionChain(executionIds[]) 原子性地验证整个流水线。

关键设计决策

链上存储验证密钥哈希，证明时提供完整密钥。 IVC电路的验证密钥可能达到1-10 MB。将其存储在链上会超过区块Gas限制。我们只在链上存储哈希；证明者在提交证明时提供完整密钥，合约会将其与存储的哈希进行比对。这是Aztec、zkSync和RiscZero采用的标准方法。

ExecutionId在链上计算。 早期设计接受由调用者提供的执行ID。这会产生一个抢先交易向量：攻击者预测未来的executionId并提前提交一个包含不同结果的证明。在链上计算（keccak256(circuitHash, inputCommitment, resultCommitment, msg.sender, block.number)）使得ID不可预测。

带有争议机制的乐观验证。 一旦证明被验证，结果立即被信任。但争议机制允许在后续发现验证器错误或证明系统缺陷时对结果提出挑战。这类似于乐观Rollup模型：快速最终性加上安全网。isResultVerified(id) && !isDisputed(id) 是完整的信任检查。

证明绑定到证明者地址。 证明的公开输入包含证明者的地址。由证明者A生成的证明不能被证明者B提交。这防止了MEV搜索者从内存池中提取证明并抢先于合法证明者提交。

批量提交是原子性的。 在多步骤流水线中，部分验证比没有验证更糟糕。如果5步中的第3步失败，整个批次将回滚。全有或全无。

与其他标准的交互

这是STYX协议栈的验证层（Prism / L2）：

与加密代币标准的交互： 每个 blindTransfer() 都涉及一个FHE计算（同态余额更新）。余额更新电路在此注册。协处理器为每次转账生成一个IVC证明。加密代币合约在应用余额变更之前检查 isResultVerified()。

与密码遗忘接口的交互： 在遗忘仪式销毁加密密钥后，这些电路的验证密钥仍然有效。历史证明仍然可以被验证（保留审计线索），但无法执行新的计算（加密密钥已消失）。这是有意为之：你可以证明过去的计算是正确的，但无法解密数据。

现有工作

据我所知，目前没有ERC标准化FHE计算验证。ZK验证空间中的相关工作：

• ERC-7520（zk-SNARK验证器标准）——专注于通用SNARK验证，而非特定于FHE的计算。不涉及电路注册、结果消费或计算链式组合。
• Axiom —— 用于历史以太坊状态证明的链上ZK协处理器。范围不同（读取历史数据，而非FHE计算）。
• Brevis —— ZK证明市场。应用层面，而非标准接口。
• RiscZero Bonsai —— 链下ZK计算与链上验证。专有API，非标准。

这些都没有定义针对FHE特定验证的标准，包括电路注册、计算链式组合和争议机制。

社区问题

1. 证明系统强制要求 —— 标准是否应该推荐特定的IVC系统（Nova），还是完全保持中立？中立更灵活，但会使互操作性复杂化（不同的证明者可能为同一电路使用不同的证明系统）。

2. 验证密钥存储 —— 链上哈希（我们的方法）与部署每个电路的验证器合约（如某些zkRollups所做）。验证器合约方法部署成本更高，但每次验证成本更低。社区偏好哪种模型？

3. 争议窗口 —— 是否应该设置一个强制的争议窗口（例如7天），在此期间结果可以被挑战？还是应该永久可争议（永远可挑战）？永久更安全，但会给依赖合约带来无限的不确定性。

4. Gas成本透明性 —— submitProof() 是否应该具有可预测的、恒定的Gas成本，与电路复杂度无关？IVC折叠保证了恒定的证明大小，但某些实现可能具有可变的验证成本。恒定Gas应该是MUST（必须）还是SHOULD（应该）？

5. 电路可升级性 —— 草案中包含 registerCircuitUpgrade() 用于修补有缺陷的电路，同时保留历史验证。这是过度设计，还是生产部署所必需的？

6. 跨标准依赖关系 —— 本标准与加密代币标准和密码遗忘接口紧密交互。这三个标准是否应该在 requires 字段中相互正式引用，还是应该保持独立，仅在Rationale中描述交互关系？

如果Fhenix、Zama、Sunscreen或Inco团队的任何人正在阅读本文——我将特别重视你们在FHE相关方面的意见。

— Valisthea

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～