newsence
如果後量子時代的以太坊根本不需要簽名會怎樣?

如果後量子時代的以太坊根本不需要簽名會怎樣?

ethresear.ch·19 天前

這項研究提出了 ZK-ACE 框架,主張以身份中心化的零知識證明取代傳統的後量子簽名,從而大幅減少交易數據體積與計算成本。

摘要(TL;DR):目前的後量子密碼學(PQC)遷移計劃假設我們必須驗證後量子簽名——無論是在鏈上驗證(每筆交易數 KB)還是在 ZK 電路中驗證(數百萬個約束)。我們提出了一種替代方案:直接在 ZK 中證明授權語義(authorization semantics),而不使用任何簽名對象。結果:4,024 個 R1CS 約束、128 位元組證明、52 毫秒證明時間。此構造與證明系統無關(Groth16、PLONK、STARK 均適用),且現已可作為 AA(帳戶抽象)驗證器模組部署——無需更改協議。


動機:PQC 數據牆

社群一直在積極探索 PQC 遷移路徑(13),其核心矛盾眾所周知:

方案簽名大小公鑰大小每筆交易總計
ML-DSA-44 (Level 2)2,420 B1,312 B3,732 B
ML-DSA-65 (Level 3)3,309 B1,952 B5,261 B
ML-DSA-87 (Level 5)4,627 B2,592 B7,219 B
SLH-DSA-128f17,088 B32 B17,120 B
FN-DSA-512~666 B897 B1,563 B
Ed25519 (傳統)64 B32 B96 B

這意味著每筆交易的授權數據增加了 30-60 倍。在 calldata/blob 空間明確計價的 Rollup 架構中,這是一個首要的可擴展性問題。

「顯而易見」的解決方案及其昂貴的原因

自然的反應是:在 ZK 電路中驗證 PQ 簽名,僅將簡潔證明上鏈。

問題在於:基於格(lattice-based)的簽名驗證需要在 $\mathbb{Z}_q$ ($q = 2^{23} - 2^{13} + 1$) 的 256 階多項式環上進行 NTT,並在約 254 位元的證明系統欄位上進行模擬。結構性下限如下:

電路內驗證R1CS 約束數主要成本
ML-DSA-44 驗證≥ 2M4×4 NTTs + 非原生模運算
ML-DSA-65 驗證≥ 4M6×5 NTTs + 非原生模運算
FN-DSA-512 驗證≥ 1MFFT + Gram-Schmidt + 模運算
SLH-DSA 驗證≥ 5MWOTS+ 鏈 + Merkle 樹
ECDSA 驗證 (傳統)~1.5M純量乘法 + 模反元素

即使使用優化的組件,僅為了證明「此簽名有效」,我們也面臨著數百萬個約束

關鍵觀察:授權 ≠ 簽名

問題在於:在共識層,區塊鏈實際上並不需要驗證特定的簽名對象。共識需要的是確保交易是由正確的實體授權的

簽名只是表達授權的一種實現產物——而非授權本身。我們一直將兩者混為一談。

ZK-ACE:以身份為中心的授權

我們提出了 ZK-ACE(密碼學實體零知識授權),將這一觀察推向邏輯終點:

不要在 ZK 中驗證簽名。不要壓縮簽名。從授權路徑中完全消除簽名對象。

取而代之的是,鏈上存儲一個緊湊的身份承諾(identity commitment)(32 位元組):

$$ID_{com} = H(REV | salt | domain)$$

其中 REV 是從確定性身份衍生原語(DIDP)衍生的 256 位元身份根。每筆交易攜帶一個 ZK 證明,證明:

  • (C1) 承諾一致性:證明者知道 $ID_{com}$ 的原像
  • (C2) 衍生正確性:目標綁定哈希與身份根下的確定性密鑰衍生一致
  • (C3) 授權綁定:身份根已授權此特定的 TxHash
  • (C4) 防重放:Nonce 承諾或 Nullifier 已正確衍生
  • (C5) 域隔離:所有綁定均使用聲明的鏈/域標籤

整個電路僅包含 5 次 Poseidon 哈希調用 + 等價約束。沒有格運算。沒有簽名驗證邏輯。沒有非原生欄位模擬。

基準測試(參考實現)

實現方式:arkworks + BN254 上的 Groth16,Poseidon (t=3, $\alpha=17$, 8 全輪 + 57 部分輪)。

電路大小:

約束輸入哈希調用R1CS
(C1) 承諾一致性31805
(C2) 衍生正確性4+121,200
(C3) 授權綁定711,615
(C4) 重放防止21400
(C5) 域隔離 + 強制相等4
總計54,024

兩種重放模式(Nonce 註冊表和 Nullifier 集合)產生的約束數量相同。

性能(單線程,Apple M3 Pro,Criterion.rs,100 個樣本):

操作中位數95% 置信區間
可信設置 (一次性)45.6 ms[45.4, 45.8] ms
證明 (每筆交易)52.3 ms[51.5, 53.4] ms
驗證 (每筆交易)604 μs[600, 608] μs

證明大小:

編碼證明公開輸入總授權數據
壓縮 Groth16128 B160 B (5 × 32 B)288 B

壓縮率 vs. PQ 簽名:

方案PQ 簽名+公鑰ZK-ACE減少量
ML-DSA-44 (Level 2)3,732 B288 B13x (92.3%)
ML-DSA-65 (Level 3)5,261 B288 B18x (94.5%)
ML-DSA-87 (Level 5)7,219 B288 B25x (96.0%)
SLH-DSA-128f17,120 B288 B59x (98.3%)

約束對比(核心結果):

方法R1CS 約束數
ZK-ACE (本研究)4,024
電路內 ML-DSA-44 驗證≥ 2,000,000
電路內 ECDSA 驗證~1,500,000

這實現了 ~500 倍 的約束減少——這並非源於優化簽名驗證,而是源於根本不進行簽名驗證

部署:AA 驗證器模組

ZK-ACE 被設計為一個 ERC-4337 驗證器模組。在 AA 錢包中:

  • 帳戶驗證邏輯調用 ZK-ACE 驗證,而非檢查傳統或 PQ 簽名
  • 證明生成發生在客戶端(~52 毫秒)
  • Bundler 傳輸證明 + 公開輸入(不可信,不獲取任何信息)
  • 鏈上驗證成本約為每個證明 604 μs

這意味著不需要協議層級的更改。ZK-ACE 可以部署在現有基礎設施上。

設計上與證明系統無關

一個重要的設計屬性:ZK-ACE 是一個協議層級的授權模型,而非特定於證明系統的構造。 五個約束 (C1)–(C5) 是基於抽象哈希評估和等價檢查陳述的。它們可以用以下系統實例化:

證明系統設置證明大小權衡
Groth16 (參考實現)可信 (每個電路)128 B證明最小,驗證最快
PLONK / KZG通用 (一次性)~400–600 B無需每個電路的設置
STARKs / FRI透明 (無)~40–100 KB無可信設置,具備後量子安全性
Bulletproofs / IPA透明~700 B無設置,驗證成本較高

上述基準測試使用 Groth16 是因為它提供了最精簡的數據,但協議並不依賴於它。特別是,STARK 實例化將使整個授權流水線在證明層也具備後量子安全性——無可信設置,無配對假設,僅基於哈希的健全性。身份承諾與證明系統無關(它們只是哈希輸出),因此從一個證明系統遷移到另一個證明系統不需要更換身份或重新註冊

論文中的安全歸約是以知識健全性優勢 $\text{Adv}^{ks}$ 泛化陳述的,並與任何滿足完備性、知識健全性、零知識性和公開輸入綁定的後端兼容。

假設的原語:DIDP

ZK-ACE 將確定性身份衍生原語(DIDP)視為黑盒——任何提供以下功能的框架:

  • 從高熵根進行確定性密鑰衍生
  • 跨衍生路徑的上下文隔離
  • 身份根恢復難度

這不與任何特定構造綁定。一個簡單的 HKDF(root, context) 即可滿足接口。我們提供 ACE-GF 作為一種實例化;任何具有域隔離的 KDF 均可工作。

安全性

定義了四種基於遊戲的安全定義,並在標準假設下進行了基於歸約的證明:

  • 授權健全性 → 歸約至知識健全性 + 碰撞抵抗 + DIDP 恢復難度
  • 重放抵抗 → 歸約至授權健全性 + 驗證器強制執行
  • 替換抵抗 → 歸約至證明系統的公開輸入綁定
  • 跨域隔離 → 歸約至碰撞抵抗 + 公開輸入綁定

完整證明見論文。

這「不是」什麼

明確說明:

  • 不是 PQ 簽名的 ZK 驗證(我們不在電路內驗證任何簽名)
  • 不是 簽名壓縮(我們消除了簽名,而不是縮小它們)
  • 不是 一種新的簽名方案
  • 依賴於任何特定的身份框架

這是一種證明內容的轉變:從「此簽名有效」轉變為「此身份授權了此交易」。

與現有討論的關係

這項工作與正在進行的 PQC 遷移討論相關聯:

這些方法都保留了以簽名為中心的模型。ZK-ACE 則問:如果我們不這樣做呢?


論文: ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems

參考實現: github.com/ya-xyz/zk-ace

        1 貼文 - 1 位參與者

        [閱讀完整主題](https://ethresear.ch/t/what-if-post-quantum-ethereum-doesn-t-need-signatures-at-all/24427)
https://ethresear.ch/t/what-if-post-quantum-ethereum-doesn-t-need-signatures-at-all/24427