哈希承諾帳戶 (HCA)：一種用於抗量子地址派生的新帳戶類型

我已經研究以太坊的後量子（Post-Quantum）版圖數個月，並發現了一個在現有提案中尚未被直接解決的缺口。在撰寫正式的 EIP 之前，我在此發文以收集技術回饋。

---

背景

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

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

這些提案中的每一項都有充分的理由且技術健全。然而，在仔細研究所有提案後，我注意到一個一致的模式：

現有的每一個後量子提案都改變了「簽名方式」，但沒有一個改變「地址推導方式」。

在所有這些提案完全部署後，以太坊地址推導公式仍然是：

address = keccak256(public_key)[12:]

公鑰（Public Key）仍然是每個以太坊帳戶身份的種子。第一筆交易會透過 ecrecover 將該金鑰永久暴露在鏈上。運行 Shor 演算法的「具備密碼學意義的量子電腦」（CRQC）只需要該暴露的公鑰，即可恢復私鑰並清空帳戶。

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

Vitalik 在 ethresear.ch 的後量子任務清單（2024 年 12 月）中提到：

「使用者透過帳戶抽象（Account Abstraction）選擇他們想要的簽名演算法。」

這精確地回答了簽名問題。但承諾問題——即一個量子安全帳戶應如何在不暴露公鑰的情況下，對其授權條件進行承諾——仍然懸而未決。

---

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

我提議一種新的以太坊帳戶類型，其地址是從支出條件（spending conditions）的 Merkle 根推導而來，而非從公鑰推導：

address = keccak256(tagged_hash("HCAAddr", auth_root))[12:]
auth_root = merkle_root([leaf_0, leaf_1, ..., leaf_n])
leaf_n = EVM 位元組碼支出條件

在地址推導或承諾鏈的任何環節中，都不會引入公鑰。觀察該地址的量子電腦無法得知任何關於支出條件的資訊——因為沒有可供攻擊的代數結構。

支出流程：

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

witness = { leaf_script, // 正在使用的支出條件 merkle_proof, // leaf_script ∈ auth_root 的證明 signature // 該葉節點所要求的任何簽名 }

驗證過程：

• 對 leaf_script 進行雜湊 → leaf_hash
• 走訪 merkle_proof → 重新計算根（root）
• 斷言（Assert）重新計算的根 == 狀態中的 authRoot
• 執行 leaf_script，並將簽名置於堆疊（stack）上

無需 ecrecover。無需公鑰恢復。發送者地址明確標註在交易體中——這與 EIP-7701 一致。

設計上與方案無關（Scheme-agnostic）：

HCA 不強制要求特定的簽名方案。ECDSA 葉節點在今天即可運作。當 Falcon 或 SPHINCS+ 透過 EIP-7932 標準化為操作碼（opcodes）時，相關葉節點也能運作。HCA 定義的是承諾容器——簽名方案是葉節點層級的事務。

---

HCA 與現有 AA 提案的區別

我想直接說明這一點。

EIP-4337、EIP-7702、EIP-7701 和 EIP-8141 全都運作於簽名驗證層——它們改變了帳戶識別後交易的驗證方式。

HCA 運作於身份層——它改變了地址本身所承諾的內容。即使所有現有的 AA 提案都完全部署，EOA 地址仍然是 keccak256(pubkey)[12:]。公鑰依然深植於帳戶身份中。

這是針對不同問題的不同層級。HCA 不是 AA 的替代品，而是其補充。

---

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

解決了： 長期暴露的量子攻擊——在設計上被消除了。地址中從未承諾過公鑰。CRQC 沒有暴露的金鑰可以用來運行 Shor 演算法。

未解決： 短期暴露攻擊——在交易處於內存池（mempool）期間（約 12 秒的窗口）破解金鑰。全面防禦短期暴露攻擊需要在葉節點腳本中使用後量子簽名方案，而 HCA 的架構在設計上明確支持將此作為未來的步驟。

不需要： 強制遷移現有的 EOA。HCA 是一種新的選擇性加入（opt-in）帳戶類型。所有現有帳戶完全不受影響。遷移可透過 EIP-7702 進行。

---

初步設計決策

以下決策是當前概念的一部分。我對這些回饋特別感興趣：

狀態樹（State trie）： HCA 在帳戶結構中引入了一個新的 32 位元組欄位 authRoot——位於 EIP-7864 統一二進制樹的 stem[4] 位置，與 codeHash 並列。

地址長度： 目前提案使用 20 位元組（keccak256(auth_root)[12:]）以實現完全的 EVM 相容性。前瞻性聲明支持在以太坊地址格式擴展時升級至 32 位元組。

authRoot 可變性： 提議在帳戶創建後嚴格不可變——與 codeHash 相同。金鑰輪換（Key rotation）在葉節點層級透過專用的恢復葉節點處理，而非在協議層級處理。

交易類型： 新的 EIP-2718 Type 5 交易，具有明確的 from 欄位、leaf_script、merkle_proof 和 signature。

葉節點版本控制： 每個葉節點有 1 位元組的版本前綴，以便與未來的後量子簽名操作碼保持前瞻相容性。

---

給社群的開放問題

• 社群是否認可這個缺口？或者是否有理由認為承諾結構應保留在應用層而非協議層？
• authRoot 嚴格不可變是否為正確的權衡，或者 HCA 應該定義協議層級的輪換機制？
• 鑑於雜湊函數在 BLAKE3 和 Poseidon2 之間尚未定案，HCA 應如何與 EIP-7864 的狀態樹互動？
• 考慮到目前的硬分叉路線圖（Glamsterdam 定於 2026 上半年，Hegota 定於 2026 下半年），現在的時機是否合適？
• 是否有我遺漏的先前技術（prior art）——特別是任何在地址推導層級解決公鑰移除問題的提案？

---

後續步驟

我目前尚未提交正式的 EIP。我發布此文的目標是確定社群是否看到了同樣的缺口，及早發現任何根本性的反對意見，並尋找有興趣將其開發為完整規範的合作者。

完整的研筆記、概念規範和參考實現進度可在 eth-hca · GitHub 取得。

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

1 則貼文 - 1 位參與者

閱讀完整主題