newsence
探索AI 對話
EIP-8215：雜湊承諾帳戶 (HCA)

EIP-8215：雜湊承諾帳戶 (HCA)

Ethereum Magicians·8 天前
原文

本提案引入了一種新的以太坊帳戶類型，其地址是由身份驗證策略的默克爾樹根（Merkle root）衍生而成，而非傳統的公鑰，旨在填補後量子安全路徑中的關鍵漏洞。

更新（2026 年 4 月）： 正式的 EIP 草案已作為 EIP-XXXX 提交。根據 EIP 前言的「討論至」（discussions-to）欄位，此討論串將作為官方討論論壇。

我一直在研究以太坊的後量子（Post-Quantum）版圖，並發現了一個在現有提案中尚未被解決的結構性缺口。我在此發文是為了收集技術反饋，並附上正式的 EIP 草案。

缺口

以太坊社群在後量子安全方面正取得顯著進展：

  • EIP-8141 — 透過框架交易（frame transactions）實現靈活的簽名方案
  • EIP-7932 — 後量子演算法註冊表與預編譯（precompiles）
  • EIP-7864 — 使用量子安全雜湊函數的統一二進位狀態樹

這些提案中的每一項都改變了你如何進行簽名、驗證或儲存。

但它們都沒有改變地址是如何推導的。

在上述三個提案完全部署後，以太坊地址的推導公式仍為：

address = keccak256(public_key)[12:]

公鑰仍然是每個 EOA（外部帳戶）身份的種子。第一筆交易會透過 ecrecover 將該密鑰永久暴露在鏈上。運行 Shor 演算法的「具備密碼學能力的量子計算機」（CRQC）只需要這個暴露的公鑰即可還原私鑰。

這不是簽名問題，而是承諾（commitment）問題。

地址推導層是以太坊後量子路線圖中，唯一沒有量子安全升級路徑的層級。

概念 — 雜湊承諾帳戶 (HCA)

一種新的以太坊帳戶類型，其地址承諾的是一個身份驗證策略樹（authentication policy tree），而非公鑰：

auth_root = merkle_root([leaf_0, leaf_1, ..., leaf_n])
address = keccak256(tagged_hash("HCAAddr", auth_root))[12:]
leaf_n = version_byte || EVM bytecode spending condition

在任何階段，公鑰都不會進入地址推導或承諾鏈。觀察該地址的量子計算機將一無所獲——因為沒有可供攻擊的代數結構。

支出流程

從 HCA 帳戶發送交易時，見證數據（witness）包含：

witness = { leaf_script, // 正在使用的支出條件 merkle_proof, // 證明 leaf_script ∈ auth_root witness_data // 簽名或該葉節點要求的其他數據 }

驗證過程：

  • 對 leaf_script 進行雜湊 → leaf_hash
  • 從 leaf_hash 遍歷 merkle_proof → 重新計算根（root）
  • 斷言：重新計算的根 == 儲存在帳戶狀態中的 authRoot
  • 在受限的 EVM 上下文中執行 leaf_script（唯讀、有 Gas 上限）
  • 若有效，則執行交易。msg.sender = HCA 地址。

無需 ecrecover。無需公鑰還原。發送者地址是交易體中的一個明確欄位——這與 EIP-8141 的框架交易一致。

簽名方案無關性

HCA 並不強制要求特定的簽名方案。葉節點版本 0x01 使用 ECDSA 且目前即可運作。葉節點版本 0x02 則調用 EIP-7932 的演算法註冊表——當 Falcon、Dilithium、SPHINCS+ 標準化後即可使用。HCA 定義的是承諾結構，簽名方案則是葉節點層級的事務。

HCA 與帳戶抽象（AA）的區別

我想直接說明這一點，因為這是最常見的問題。

帳戶抽象（EIP-8141, ERC-4337, EIP-7702）改變了交易如何被驗證——它將簽名驗證與 ECDSA 解耦。HCA 則改變了地址本身承諾的內容——它將地址推導與公鑰解耦。

這些是正交的層級：

  • EIP-7864 → 量子安全狀態儲存（數據如何儲存）
  • EIP-7932 → 量子安全演算法註冊表（存在哪些演算法）
  • EIP-8141 → 量子安全驗證（你如何簽名）
  • HCA → 量子安全地址推導（你的地址承諾什麼）

即使完全部署了 EIP-8141，新 EOA 的地址仍然是 keccak256(pubkey)[12:]。公鑰在誕生時就已植入身份中。HCA 則消除了這種殘留的依賴性。

類比：比特幣中，BIP-360 的 P2MR 與 Taproot 並存。Taproot 啟用了腳本路徑支出（script-path spends）。P2MR 則提供了一種專門構建的量子安全輸出類型，它僅承諾 Merkle 根，沒有密鑰路徑支出。HCA 之於 EIP-8141，正如 P2MR 之於 Taproot。

HCA 解決了什麼，沒解決什麼

解決了： 長期暴露的量子攻擊——從設計上消除。公鑰永遠不會承諾到地址中，也不會透過地址推導暴露在鏈上。CRQC 沒有可用於運行 Shor 演算法的密鑰。

未解決： 短期暴露攻擊（在約 12 秒的內存池窗口期內破解密鑰）。全面防禦短期暴露攻擊需要在葉腳本中使用後量子簽名方案，而 HCA 在設計上已明確支持這一點。

不需要： 強制現有 EOA 遷移。HCA 是選擇性加入（opt-in）的。所有現有帳戶完全不受影響。

緊迫性

這並非臆測。政府指令已經存在：

  • CNSA 2.0 (NSA, 2022) — 2030 年前軟體完成 PQ 遷移，2033 年前全面升級。
  • NIST IR 8547 (2024) — ECDSA 在 2030 年後棄用，2035 年後禁用。
  • Google Quantum AI (2026 年 3 月 30 日) — ECDLP-256 可在數分鐘內被少於 500,000 個物理量子位元破解。比之前的估計減少了 20 倍。內部遷移截止日期為 2029 年。
  • 以太坊基金會 (pq.ethereum.org, 2026) — 「工作必須在威脅到來之前很久就開始。」

HCA 在錢包、DeFi 協議、交易所和 L2 之間的遷移本身就需要數年時間。現在開始並不嫌早。

設計摘要

元素設計
帳戶狀態在 nonce、balance、codeHash 之外新增一個 32 字節的 authRoot 欄位
地址長度20 字節 (keccak256(tagged_hash("HCAAddr", auth_root))[12:]) 以保持 EVM 兼容性
域分離BIP-340 標記雜湊慣例：`keccak256(SHA256(tag)
葉節點版本化每個葉節點有 1 字節前綴，以實現與 PQ 操作碼的前向兼容性
authRoot 輪換透過專用的輪換葉節點類型——其唯一目的是授權新的 authRoot
交易類型新的 EIP-2718 信封，包含明確的 from、leaf_script、merkle_proof、witness_data
葉節點執行受限的 EVM 上下文：唯讀、MAX_LEAF_GAS = 100,000、無狀態變更
Gas 成本Merkle 證明：約 80 gas/層 + 200 基礎。深度為 3 的樹：約 440 gas（對比 ecrecover 為 3,000）

給社群的開放問題

  • 社群是否認可這個缺口？ 是否有理由讓承諾結構保留在應用層（透過 CREATE2 + 智能合約錢包），而不是協議層（透過原生帳戶類型）？
  • authRoot 輪換： 專用的輪換葉節點是正確的機制嗎？還是 HCA 應該定義一個協議層級的 SET_AUTH_ROOT 操作碼？
  • 與 EIP-7864 的交互： 鑑於狀態樹雜湊函數仍在 BLAKE3 和 Poseidon2 之間待定，authRoot 應如何儲存？HCA 的內部樹使用 keccak256——這兩棵樹是獨立的，但它們應該保持一致嗎？
  • 時機： 這適合 Hegota 升級（2026 年下半年）嗎？還是 HCA 應該針對更晚的分叉？
  • 先前技術： 我是否遺漏了任何專門針對在地址推導層級移除公鑰的提案？

資源

我歡迎所有技術反對意見、替代方案以及先前技術的參考。期待與大家的討論。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/eip-8215-hash-committed-account-hca/28094)
https://ethereum-magicians.org/t/eip-8215-hash-committed-account-hca/28094