[Discussion] Hash-Committed Account (HCA) — Quantum-safe address derivation for Ethereum

更新（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:]

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

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

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

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

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

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
• 根據 merkle_proof 從 leaf_hash 向上計算 → 重新計算出的根（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 根，沒有密鑰路徑支出（key-path spend）。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) — 2030 年後棄用 ECDSA，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 應該針對更晚的分叉？
• 先前技術： 我是否遺漏了任何專門針對在地址推導層級移除公鑰的提案？

資源

• EIP 草案： 已提交至 ethereum/EIPs（鏈接待編輯分配編號後更新）
• 概念定義： eth-hca/research
• 組織： github.com/eth-hca

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

1 則貼文 - 1 位參與者

閱讀完整主題