ERC-8039：智能帳戶的零知識證明驗證（利用 ZK 電路編寫智能帳戶邏輯）

類別： 標準軌道 (Standards Track)、帳戶抽象 (Account Abstraction)、零知識證明 (Zero-Knowledge Proofs)

作者： Walid Khemiri, Ismail Amara

狀態： 討論中 (Discussion)

相關連結： [ERC-8039 草案]( Add ERC: ZK Proof Verification for Smart Accounts by khemiriwalid · Pull Request #1238 · ethereum/ERCs · GitHub )

首次實作： GitHub - MicrochainLabs/microchain-zk-signers · GitHub

摘要 (Abstract)

智慧帳戶透過鏈上代碼實現了可程式化的帳戶邏輯。零知識證明（ZK Proofs）為智慧帳戶開啟了兩大超能力：

1. 隱私性：在執行邏輯的同時隱藏敏感資訊（私密輸入、隱藏狀態）。
2. 簡潔性：透過極小的鏈上證明來驗證複雜的離鏈計算。

目前缺失的一環？一個讓智慧帳戶在鏈上驗證 ZK 證明的標準化介面。

我們推出了 ERC-8039：智慧帳戶的 ZK 證明驗證 —— 這是一個與證明系統無關（proof-system-agnostic）的介面，使智慧帳戶能夠使用零知識電路來編寫身分驗證、授權、復原及任何與帳戶相關的邏輯。遵循已驗證的 ERC-1271 模式，ERC-8039 提供了一個統一介面，可與任何證明系統（Groth16、PLONK、HONK 等）協作，實現：

隱私使用案例：

私密身分驗證：證明簽章有效性，但不洩露簽署者身分或門檻要求。

隱私保護策略：執行支出限制、Gas 價格、時間鎖定，同時保持約束條件隱藏。

機密復原：透過隱藏的監護人和機制進行帳戶復原。

憑證驗證：在不洩露數據的情況下證明年齡、身分或信用評分。

簡潔性使用案例：

複雜策略驗證：在離鏈執行複雜規則，並在鏈上進行廉價驗證。

歷史狀態驗證：證明關於過去區塊鏈狀態的屬性（協處理器模式）。

信任最小化計算：在離鏈執行任意邏輯並進行鏈上驗證。

基礎設施：

證明系統無關：無需更改帳戶邏輯即可切換或支援多種證明系統。

向前相容：適用於任何 ZK 框架（Noir、Circom、SP1、RISC0）及未來的證明系統。

架構圖：

引入「可證明所有權」 (Provable Ownership)

ERC-8039 的一個核心應用是可程式化所有權 —— 透過零知識電路邏輯而非鏈上代碼來定義帳戶所有權。正如智慧合約從「可程式化貨幣」演進為「可程式化所有權」（多簽、時間鎖、DAO 治理），ERC-8039 開啟了下一個演進階段：可證明所有權。

演進歷程：

傳統 EOA： 所有權 = 私鑰
（單點故障）
↓
可程式化所有權： 所有權 = 智慧合約代碼
（多簽、策略、治理）
但所有邏輯皆為公開
↓
可證明所有權： 所有權 = ZK 電路代碼
（具備相同能力，且完全隱私）
由 ERC-8039 實現 ✓

範例：

所有權模型	傳統（公開）	可證明（透過 ERC-8039 實現隱私）
多重簽章	5 分之 3 簽署者在鏈上可見	5 分之 3 簽署者隱藏在 ZK 電路中
加權投票	「Alice: 40%, Bob: 30%」公開	權重隱藏，僅證明達到門檻
時間鎖定	「區塊 X 前不可提款」可見	時間約束在達成前保持隱藏
基於角色	「CEO: 無限制, 員工: 1k」公開	角色與額度完全隱私

為何這很重要：

傳統的可程式化所有權犧牲了隱私 —— 競爭對手可以看到你的簽署者，攻擊者知道該針對誰，組織結構完全暴露。透過 ERC-8039 實現的可證明所有權在提供相同程式化能力的同時，確保了完全的機密性 —— 證明授權有效，而不必洩露是誰、如何或為何授權。

動機 (Motivation)

問題所在：使用 ZK 電路編寫智慧帳戶邏輯需要標準化的驗證方式

智慧帳戶透過讓帳戶邏輯可程式化，徹底改變了以太坊。但它們面臨兩個根本性的限制：

1. 隱私性：所有邏輯都是公開的 —— 簽署者、門檻、策略和復原機制在鏈上清晰可見。
2. 計算成本：複雜邏輯成本高昂 —— 每項計算消耗的 Gas 與其複雜度成正比。

零知識電路解決了這兩個問題：

鏈上邏輯： 若 (邏輯 == 鏈上代碼) { 可程式化 && 公開 && 昂貴 }
ZK 電路邏輯： 若 (邏輯 == ZK 電路代碼) { 可程式化 && 隱私 && 簡潔 }

使用案例維度 1：隱私（隱藏資訊）

ZK 電路透過將敏感資訊保留在離鏈，實現了私密帳戶邏輯：

• 私密身分驗證（可證明所有權）
  • 傳統：簽署者公開的 3-of-5 多簽。
  • ZK 電路：簽署者、權重和門檻皆隱藏的 3-of-5 多簽。
• 隱私保護策略
  • 傳統：每日最高支出 $10k（競爭對手可見的公開限制）。
  • ZK 電路：每日最高支出 $10k（私密限制，保護企業隱私）。
• 機密復原
  • 傳統：2-of-3 監護人（公開地址，易受社交工程攻擊）。
  • ZK 電路：2-of-3 監護人（隱藏身分，透過隱匿實現安全）。
• 憑證驗證
  • 傳統：將憑證存儲在鏈上（公開，永久暴露）。
  • ZK 電路：在不洩露憑證的情況下證明憑證（隱私，選擇性揭露）。

使用案例維度 2：簡潔性（高效驗證）

ZK 電路實現了對複雜離鏈計算的 Gas 高效驗證：

• 複雜策略驗證（離鏈計算）
  • 傳統：在鏈上評估 50 條策略規則（約 50 萬 Gas）。
  • ZK 電路：在離鏈證明 50 條規則皆滿足（驗證約需 35 萬 Gas）。
  • 優勢：Gas 節省隨複雜度增加（100 條規則 = 便宜 10 倍）。
• 歷史狀態驗證（協處理器模式）
  • 傳統：無法訪問舊狀態（僅當前狀態可用）。
  • ZK 電路：證明關於任何歷史狀態的屬性（例如：「帳戶在第 1M 區塊時餘額 > X」）。
  • 優勢：無需鏈上狀態歷史即可開啟基於時間的策略。
• 信任最小化計算
  • 傳統：在鏈上執行複雜算法（可能超過區塊 Gas 上限）。
  • ZK 電路：在離鏈執行，在鏈上證明正確性（始終符合區塊要求）。
  • 優勢：任意計算複雜度，固定驗證成本。

核心洞察：簡潔性在以下情況最有價值：

• 邏輯複雜（規則多、計算深）。
• 需要歷史數據（過去狀態、時間序列）。
• 計算量超過區塊 Gas 上限。

關鍵依賴

ZK 電路邏輯無法獨立運作 —— 證明必須由智慧合約在鏈上驗證。這是使隱私和簡潔性具備去信任特性的關鍵依賴。

挑戰： 每個證明系統都有不同的驗證介面：

// Groth16 (Circom)
function verifyProof(
uint256[2] calldata a,
uint256[2][2] calldata b,
uint256[2] calldata c,
uint256[] calldata input
) external view returns (bool);

// PLONK (各種實作)
function verify(
bytes calldata proof,
uint256[] calldata publicInputs
) external view returns (bool);

// UltraHonk (Noir/Barretenberg)
function verify(
bytes calldata proof,
bytes32[] calldata publicInputs
) external view returns (bool);

// SP1 zkVM
function verifyProof(
bytes32 programVKey,
bytes calldata publicValues,
bytes calldata proofBytes
) external view;

若沒有標準介面：

• 帳戶合約與特定證明系統高度耦合。
• 無法在不更改合約的情況下升級證明系統。
• 無法支援多種證明系統。
• 每種帳戶類型都需要自定義驗證器整合。
• 生態系統工具無法跨實作運作。

有了 ERC-8039：

• 帳戶可與任何證明系統協作。
• 透過適配器合約升級證明系統。
• 同時支援多種證明系統。
• 所有帳戶採用統一的整合模式。
• 生態系統工具具備通用性。

這些證明可以使用以下技術生成：

• Groth16（驗證最快，證明最小）。
• PLONK（通用設置，可更新）。
• HONK（無需信任設置，高效）。
• STARKs（後量子安全，透明）。
• zkVMs（SP1, RISC0 - 任意程式執行）。

ERC-8039 使智慧帳戶能夠：

1. 為每個使用案例選擇最佳證明系統（隱私 vs 簡潔性）。
2. 隨證明系統進步而升級（更好的性能，更低的 Gas）。
3. 支援混合方案（針對不同操作使用不同證明）。
4. 保持與新興技術的未來相容性。
5. 在單個應用中結合隱私與簡潔性。

解決方案：ERC-8039

ERC-8039 遵循已驗證的 ERC-1271 簽章驗證模式：

// ERC-1271: 簽章驗證
interface IERC1271 {
function isValidSignature(
bytes32 hash,
bytes memory signature
) external view returns (bytes4 magicValue);
// 回傳: 0x1626ba7e 若有效
}

// ERC-8039: 證明驗證
interface IERC8039 {
function verifyProof(
bytes calldata publicInputs,
bytes calldata proof
) external view returns (bytes4 magicValue);
// 回傳: 0x534f5876 若有效
}

為何此模式有效：

1. 開發者熟悉：智慧帳戶開發者已理解 ERC-1271。
2. 不回退 (Non-reverting)：回傳魔術值而非直接 revert（Gas 高效、具組合性）。
3. 證明系統無關：透過適配器支援任何證明格式。
4. 生態系統相容：遵循既有的標準慣例。

核心介面

/**

• @title IERC8039

• @notice 智慧帳戶驗證 ZK 證明的標準介面

• 魔術值: bytes4(keccak256("verifyProof(bytes,bytes)")) = 0x534f5876
  /
  interface IERC8039 {
  /*

  • @notice 驗證零知識證明
  • @dev 證明無效時絕不可 revert；應回傳 0x00000000
  • @param publicInputs 公開輸入 (instance)
  • @param proof 序列化的證明 (evidence)
  • @return magicValue 若有效回傳 0x534f5876，否則回傳 0x00000000
    */
    function verifyProof(
    bytes calldata publicInputs,
    bytes calldata proof
    ) external view returns (bytes4 magicValue);

  /**

  • @notice 回傳此驗證器支援的證明類型
  • @dev 格式: keccak256("system-implementation")
  • @return proofType 證明系統識別碼
    */
    function getProofType() external pure returns (bytes32 proofType);

  /**

  • @notice 回傳人類可讀的元數據
  • @dev 描述正在證明的陳述/關係
  • @return metadata 應用程式名稱、用途及版本
    */
    function metadata() external pure returns (string memory metadata);
    }

三大核心函數

1. verifyProof() - 核心驗證
   用途： 根據公開輸入驗證 ZK 證明。
   設計原則：

• 不回退： 失敗時回傳 0x00000000（類似 ERC-1271）。
• 通用 Bytes： 支援任何證明格式。
• View 函數： 無狀態更改，Gas 高效。
• 魔術值： 成功時回傳 0x534f5876。

2. getProofType() - 技術識別
   用途： 識別證明系統的實作方式。
   格式： keccak256(“system-implementation”)
   範例：

• keccak256("groth16-circom") // 透過 Circom/SnarkJS 的 Groth16
• keccak256("honk-barretenberg") // 透過 Noir/Aztec 的 UltraHonk
• keccak256("sp1") // SP1 zkVM (Rust)

使用案例：

• 驗證證明格式是否符合預期。
• 根據證明系統路由驗證邏輯。
• 自動化工具與內省 (Introspection)。

3. metadata() - 人類可讀描述
   用途： 描述正在證明的內容。
   格式： “應用名稱 v版本 - 用途”
   範例：

• “ZK MultiSig v1.0.0 - Private threshold signatures”
• “Spending Limit v2.0.0 - Private daily spending caps”

使用案例：

• UI 顯示與除錯。
• 審計追蹤與日誌記錄。

職責分離
這三個函數提供了完整的上下文：
getProofType() → 技術上下文（「如何驗證」 - 證明系統）
↓
verifyProof() → 驗證（「是否通過？」）
↓
metadata() → 語義上下文（「證明什麼」 - 應用用途）

ERC-8039 如何實現隱私且高效的帳戶邏輯

架構概覽

實作 1：zkSafe
連結：GitHub - MicrochainLabs/microchain-zk-signers
使用 ZK 代理作為所有者的 Safe 帳戶。

// ZK 簽署者代理 (使用 ERC-8039)
contract ZKSignerProxy {
IERC8039 public immutable verifier; // ERC-8039 驗證器
bytes32 public signersRoot;

constructor(address _verifier) {
    verifier = IERC8039(_verifier);
}

// ERC-1271: Safe 呼叫此函數驗證簽章
function isValidSignature(
    bytes32 hash,
    bytes memory signature
) external view returns (bytes4) {
    bytes memory publicInputs = abi.encode(hash, stateRoot);
    
    // 使用 ERC-8039 驗證證明
    bytes4 result = verifier.verifyProof(publicInputs, signature);

    if (result == 0x534f5876) {
        return 0x1626ba7e; // ERC-1271 成功
    }
    return 0xffffffff; // ERC-1271 失敗
}

}

實作 2：zkNexus (ERC-7579)
連結：GitHub - MicrochainLabs/microchain-zk-signers
帶有 ZK 驗證器模組的 Biconomy Nexus。

// ZK 驗證器模組 (使用 ERC-8039)
contract ZKValidatorModule {
IERC8039 public immutable verifier;

function validateUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash
) external returns (uint256) {
    bytes memory publicInputs = abi.encode(userOpHash, signersRoot);
    
    // 透過 ERC-8039 驗證
    bytes4 result = verifier.verifyProof(publicInputs, userOp.signature);

    if (result == 0x534f5876) {
        return VALIDATION_SUCCESS;
    }
    return VALIDATION_FAILED;
}

}

證明系統無關設計

透過 ERC-8039，我們可以使用適配器模式（Adapter Pattern）來封裝特定證明系統的驗證器：

範例：

1. HONK 適配器 (Noir/Barretenberg)
   將 publicInputs 解碼為 bytes32[] 並呼叫原生的 HONK 驗證器。

2. Groth16 適配器 (Circom)
   將 proof 解碼為 a, b, c 元件並呼叫原生的 Groth16 驗證器。

3. SP1 zkVM 適配器
   使用 try/catch 封裝 SP1 驗證器（因為 SP1 在失敗時會 revert），並回傳 ERC-8039 魔術值。

安全考量 (Security Considerations)

證明重放攻擊 (Proof Replay Attacks)
應用程式必須在電路設計中包含重放防止機制。

• 帳戶特定綁定：在公開輸入中包含帳戶地址。
• 基於 Nonce 的防止：在公開輸入中包含遞增的 Nonce。

不可變驗證器
建議將驗證器地址設為 immutable 以防止被惡意替換。

公開輸入操縱
需確保攻擊者無法修改公開輸入使無效證明看起來有效。

生態系統影響 (Ecosystem Impact)

1. 標準化的 ZK 整合

• ERC-8039 之前：每個帳戶都需要針對不同證明系統編寫自定義整合邏輯。
• ERC-8039 之後：通用整合，一個 StandardAccount 即可與任何符合標準的驗證器協作。

2. 生態系統工具

• 錢包與介面：可實作通用的證明驗證檢查。

• SDK 與函式庫：開發與證明系統無關的 SDK，輕鬆支援多種 ZK 框架。

        1 則貼文 - 1 位參與者
        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8039-zk-proof-verification-for-smart-accounts-programming-smart-account-logic-with-zk-circuits/27919)