ERC：FHE 計算驗證標準 — 透過遞迴零知識證明實現加密計算的無須信任驗證

摘要

我正在提議一項新的 ERC，旨在定義一個透過遞迴零知識證明（IVC）對鏈上全同態加密（FHE）計算進行驗證的標準介面。

當智能合約在加密數據上執行時，任何人都無法檢查其計算過程——無論是驗證者、部署者還是用戶。這是 FHE 的承諾。但這也引入了一個信任問題：如果你看不見計算過程，你如何知道計算是否正確執行？

本標準解決了這個問題。單個緊湊的證明（≤ 1 KB）即可證明任意複雜度的加密計算。鏈上驗證時間為 O(1)。運行計算的協處理器（co-processor）在設計上是不可信的——證明是唯一的真相來源。

代碼庫： https://github.com/Valisthea/styx-erc-fhe-verification
作者： Valisthea (@Valisthea)
相關提案： ERC：加密代幣標準、ERC：加密失憶介面（分開提交）

問題所在

FHE 實現了對加密數據的計算。目前有多個項目正在構建 FHE 執行環境（Fhenix, Zama fhEVM, Sunscreen, TFHE-rs）。但目前還沒有人提出一個用於驗證計算正確性的標準介面。

如果沒有驗證，區塊鏈上的 FHE 就只是增加了額外步驟的加密雲端運算。你對協處理器的信任程度與對 AWS 的信任程度無異——這違背了去中心化的初衷。

具體問題包括：

• 協處理器的誠實性 — FHE 計算被委託給專用硬件（GPU、FPGA）。這些機器位於鏈下。如果沒有驗證，惡意運算方可以返回任何他們想要的結果。例如，一個加密的 DeFi 保險庫詢問「該倉位是否低於清算閾值？」，協處理器可能會為了保護友好的巨鯨而撒謊，或為了強制清算競爭對手而撒謊。

• 跨合約的結果完整性 — 當合約 A 使用合約 B 加密計算的輸出時，A 需要確保 B 的結果是正確的。目前，每對合約都自行發明自定義的信任假設。合約之間缺乏驗證彼此加密計算的標準方式。

• 可審計性 — 監管機構需要驗證加密的財務計算（稅務計算、償付能力證明、合規檢查）是否正確執行，同時又無需查看底層數據。目前不存在用於此目的的標準介面。

• 多步驟流水線 — 複雜的 DeFi 協議會串聯加密計算：加密預言機餵價 → 加密風險計算 → 加密清算檢查 → 加密結算。如果第 2 步出錯，下游的一切都會出錯。每一步的驗證可以防止連鎖反應式的失敗。

運作原理

三階段架構

第一階段 — 電路註冊。 開發者編寫加密智能合約（使用 SSL、fhEVM Solidity 或任何兼容 FHE 的語言）。編譯器生成電路（FHE 邏輯門序列）。電路的哈希值和驗證密鑰哈希值通過 registerCircuit() 註冊在鏈上。這將特定的計算與特定的驗證密鑰綁定，防止證明者替換成另一個（簡單的）電路。

第二階段 — 執行與證明生成。 用戶提交加密交易。FHE 協處理器在加密輸入上執行電路。執行時，它會生成一個 IVC（增量可驗證計算）證明：每個門級別的證明都被「摺疊」進一個運行中的累加器中。最終輸出是一個單一的、固定大小的 SNARK——無論電路有多少個門。10 個門或 1000 萬個門：證明大小相同，驗證成本也相同。

第三階段 — 鏈上驗證。 協處理器通過 submitProof() 提交證明。合約根據註冊的驗證密鑰對其進行驗證。如果有效，結果承諾（result commitment）將存儲在鏈上。任何依賴合約在讀取結果前都可以檢查 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);
}

擴展功能

證明者註冊表 — 為協處理器建立的質押與罰沒（stake-and-slash）機制。證明者需質押抵押品進行註冊。提交錯誤證明會被罰沒，並獎勵給挑戰者。這使協處理器的激勵機制與誠實計算保持一致。

計算鏈接 — isChainedExecution(executionA, executionB) 用於驗證 B 的輸入可證明是 A 的已驗證輸出。verifyExecutionChain(executionIds[]) 則以原子方式驗證整個流水線。

關鍵設計決策

鏈上存儲驗證密鑰哈希，證明時提供完整密鑰。 IVC 電路的驗證密鑰可能高達 1-10 MB。將其存儲在鏈上會超過區塊 Gas 限制。我們僅在鏈上存儲哈希值；證明者在提交證明時提供完整密鑰，合約會將其與存儲的哈希值進行比對。這是 Aztec、zkSync 和 RiscZero 使用的標準方法。

鏈上計算 ExecutionId。 早期的設計接受調用者提供的執行 ID。這會產生搶跑（front-running）向量：攻擊者預測未來的 executionId，並預先提交一個帶有不同結果的證明。通過鏈上計算（keccak256(circuitHash, inputCommitment, resultCommitment, msg.sender, block.number)）使 ID 不可預測。

帶有爭議機制的樂觀驗證。 一旦證明通過驗證，結果立即被信任。但爭議機制允許在隨後發現驗證器錯誤或證明系統缺陷時挑戰結果。這借鑒了樂觀捲軸（optimistic rollup）模型：快速最終性輔以安全網。isResultVerified(id) && !isDisputed(id) 是完整的信任檢查。

證明與證明者地址綁定。 證明的公共輸入包含證明者的地址。由證明者 A 生成的證明不能由證明者 B 提交。這防止了 MEV 搜索者從內存池中提取證明並搶跑合法的證明者。

批量提交是原子的。 在多步驟流水線中，部分驗證比不驗證更糟糕。如果 5 個步驟中的第 3 步失敗，整個批次都會回滾。全有或全無。

與其他標準的交互

這是 STYX 協議棧的驗證層（Prism / L2）：

與加密代幣標準配合： 每次 blindTransfer() 都涉及 FHE 計算（同態餘額更新）。餘額更新電路在此註冊。協處理器為每次轉帳生成 IVC 證明。加密代幣合約在應用餘額更改前會檢查 isResultVerified()。

與加密失憶介面配合： 在失憶儀式銷毀加密密鑰後，這些電路的驗證密鑰仍然有效。歷史證明仍可被驗證（保留審計追蹤），但無法進行新的計算（因為加密密鑰已消失）。這是刻意設計的：你可以證明過去的計算是正確的，但你無法解密數據。

先前技術

我目前尚未知曉任何標準化 FHE 計算驗證的 ERC。ZK 驗證領域的相關工作包括：

• ERC-7520 (zk-SNARK 驗證器標準) — 專注於通用的 SNARK 驗證，而非 FHE 特有的計算。未解決電路註冊、結果使用或計算鏈接問題。

• Axiom — 用於歷史以太坊狀態證明的鏈上 ZK 協處理器。範疇不同（讀取歷史數據，而非 FHE 計算）。

• Brevis — ZK 證明市場。屬於應用層，而非標準介面。

• RiscZero Bonsai — 帶有鏈上驗證的鏈下 ZK 計算。屬於私有 API，而非標準。

上述項目都沒有定義包含電路註冊、計算鏈接和爭議機制的 FHE 專用驗證標準。

社群問題

• 證明系統強制性 — 標準是否應該推薦特定的 IVC 系統（如 Nova），還是保持完全不可知（agnostic）？不可知論更具靈活性，但會使互操作性複雜化（不同的證明者可能對同一電路使用不同的證明系統）。

• 驗證密鑰存儲 — 鏈上哈希（我們的方法） vs. 為每個電路部署驗證器合約（如某些 zkRollups）。驗證器合約方法部署成本較高，但每次驗證成本較低。社群更傾向於哪種模型？

• 爭議窗口 — 是否應該有一個強制的爭議窗口（例如 7 天），在此期間可以挑戰結果？還是爭議應該是永久性的（永遠可以挑戰）？永久性更安全，但會給依賴合約帶來無限的不確定性。

• Gas 成本透明度 — 無論電路複雜度如何，submitProof() 是否應該具有可預測的恆定 Gas 成本？IVC 摺疊保證了證明的恆定大小，但某些實現可能有變動的驗證成本。恆定 Gas 應該是「必須（MUST）」還是「應該（SHOULD）」？

• 電路可升級性 — 草案包含了 registerCircuitUpgrade() 用於修復有缺陷的電路，同時保留歷史驗證。這是過度設計，還是生產部署所必需的？

• 跨標準依賴 — 本標準與加密代幣標準和加密失憶介面有深度交互。這三者是否應該在 requires 字段中正式互相引用，還是應該保持獨立並僅在「原理（Rationale）」中描述交互？

如果 Fhenix、Zama、Sunscreen 或 Inco 團隊的成員正在閱讀此文——我特別希望能聽聽你們對 FHE 特定方面的意見。

— Valisthea

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-fhe-computation-verification-standard-trustless-verification-of-encrypted-computation-via-recursive-zk-proofs/28217)