上一篇收在一個死線上:二元樹的 witness 是 0.154859 bytes/gas,乘上 p2p 的 10 MiB 實務天花板,得到 67,711,767 gas。今天的主網 gas limit 是 60M,Glamsterdam 的目標是 200M,所以那條線比現在只高 13%,而目標比它高三倍。當時的結論是:要嘛把 WITNESS_CHUNK_COST 從 200 提到 605 把局部性折扣砍掉三分之二,要嘛改變傳播模型。
第二條路已經有規格了,編號是 EIP-8025: Optional Execution Proofs(Draft,2025-09-17,作者群包含 Justin Drake 與 Ignacio Hagopian)。它做的事情非常簡單粗暴:witness 不上 gossip。產生證明的節點在本機組出 witness、丟進 zkVM、只把證明廣播出去。而規格給證明的上限是 MAX_PROOF_SIZE = 409600 bytes,每個 payload 最多 MAX_EXECUTION_PROOFS_PER_PAYLOAD = 4 種證明系統,最壞情況每 slot 4 × 400 KiB = 1.5625 MiB。
這個數字有一個上一篇所有數字都沒有的性質:它不隨 gas limit 成長。8.86 MiB 是 60M 的函數,29.54 MiB 是 200M 的函數,而 1.5625 MiB 是常數。所以「witness 撞上 10 MiB」這件事,在執行證明的世界裡根本不會發生——頻寬瓶頸被整個移走了。移到哪裡去?移到時間:那台產生證明的機器,要在 slot 結束之前把證明算完。今天要處理的就是這筆帳。
📖 學
一、換單位:從 bytes/gas 到 gas/second
上一篇之所以能把所有東西放在一起比較,是因為找到了 bytes/gas 這個量綱。證明這一側需要的是另一個量綱:gas/second——一台機器每秒能證明多少 gas 的工作。
把需求端先列出來。要在時間 T 內證明一個 gas limit G 的區塊,需要的吞吐就是 G / T:
| 情境 | gas limit | 期限 | 需要的吞吐 |
|---|---|---|---|
| 塞滿整個 slot | 60M | 12 s | 5.00 M gas/s |
| EF 的 realtime 定義 | 60M | 10 s | 6.00 M gas/s |
| ethproofs 2026 目標 | 60M | 8 s | 7.50 M gas/s |
| Glamsterdam 目標 | 200M | 10 s | 20.00 M gas/s |
| Glamsterdam + 2026 目標 | 200M | 8 s | 25.00 M gas/s |
EF 那個 10 秒不是隨便取的。Shipping an L1 zkEVM #1: Realtime Proving 把整組門檻寫死了:
| 項目 | 門檻 | 理由 |
|---|---|---|
| 延遲 | <= 10s for P99 of mainnet blocks | 12 秒 slot 扣掉約 1.5 秒的網路傳播 |
| 證明尺寸 | <= 300KiB with no trusted setups | 要能在網路上傳得動 |
| 安全性 | >= 128 bits(上線初期暫時 100 bits) | 「Ethereum L1 正確的長期目標」 |
| 硬體資本支出 | <= 100k USD | 對標「跑一個驗證者約需 $80k」 |
| 功耗 | <= 10kW | 「多數住宅的街邊電源至少有 10kW」 |
| 開源 | 完全開源 | 透明與社群監督 |
最後兩項是整篇文章的關鍵,等一下會算。先注意一件事:P99 而不是平均,而且是主網真實區塊,不是合成 workload。這代表這組門檻是拿最難的那 1% 區塊在打。
供給端有一個很乾淨的一手數字。Ignacio Hagopian(jsign,也就是上一篇 witness 最壞情況推導的作者)在改寫 OpenVM guest 的 stateless MPT 實作時,跑了 500 個連續主網區塊(23533500-23533999)的前後對照:
| 指標 | 改寫前 | 改寫後 | 變化 |
|---|---|---|---|
| 總證明時間 | 4h 59m 23.67s | 4h 13m 56.83s | −15.2% |
| 平均吞吐 | 624.25K gas/s | 735.96K gas/s | +17.9% |
| 單區塊中位數 | — | — | −15.5%(最好 −22.0%,最差 +3.4%) |
先驗算這兩列自洽不自洽:
改寫前:624,250 gas/s × 17,963.67 s = 11,213,000,000 gas
改寫後:735,960 gas/s × 15,236.83 s = 11,213,000,000 gas
÷ 500 區塊 = 22,426,000 gas/區塊
兩邊對得上,而且反推出來的每區塊平均 22.43M gas,跟那個高度的主網平均用量是同一個量級。這組數字可以用。
(原文沒有列硬體規格,已標存疑;但 gas/s 這個單位本身是可移植的,下面所有推導只用比值。)
拿它去除需求:
6.00 M gas/s ÷ 0.73596 M gas/s = 8.15 台
20.00 M gas/s ÷ 0.73596 M gas/s = 27.17 台
25.00 M gas/s ÷ 0.73596 M gas/s = 33.97 台
8 台。 而 ethproofs 現在的 live cohort 裡,ZisK 跑的是 8 × RTX 5090,Axiom 的 OpenVM 2.1 Preview 跑的是 16 張。一個從單機吞吐硬除出來的數字,跟業界實際堆的卡數對得上——這代表 gas/second 這個單位抓到的是真的東西,不是紙上作業。
二、2026 年 9 月的實測:9.62 秒、4 張卡
把過去二十個月的進展壓成一條線:
| 時間 | 誰 | 配置 | 延遲 |
|---|---|---|---|
| 2025-05 | SP1 Hypercube | 160 GPU | < 12 s |
| 2025 全年 | 單卡 | 1 GPU | 16 分鐘 → < 60 秒 |
| 2026-02 | (綜合) | ~12 GPU | ~7 s |
| 2026-08-18 | ZisK v1.1.0-alpha | 4 × RTX 5090 | P99 9.62 s |
| (同期) | OpenVM 2.0 | 8 × 5090 | P99 9.8 s |
ethproofs 對 2025 年的總結是:延遲年增 5 倍、單卡從 16 分鐘掉到 60 秒以內、每份證明成本從 $1.69 掉到一分錢以內、上線 7 個 zkVM 與 15 個 prover、累計驗證約 20 萬個區塊,而且「100% Reproducibility Across All Provers」、驗證器全部 MIT + Apache 2.0 雙授權。
現在掛在 ethproofs 首頁的兩組:
| cluster | zkVM | GPU | 成功率 | 每證明成本 |
|---|---|---|---|---|
| ZisK 8x5090 | ZisK | 8 × 5090 | 100.00% | $0.0055 |
| Axiom 16x5090 | OpenVM 2.1 Preview | 16 × 5090 | 99.99% | $0.0066 |
把 ZisK 那個 4 卡結果換成吞吐(假設 P99 的區塊接近滿載的 60M,已標存疑——P99 抓的是最難的區塊,通常也是最滿的,但原文沒有揭露 block range 與樣本數):
60,000,000 ÷ 9.62 s = 6,237,006 gas/s
÷ 4 張卡 = 1,559,252 gas/s/卡
每張 RTX 5090 約 1.56 M gas/s。 對照前面那台未揭露規格的機器 0.736 M gas/s,比值 2.12——5090 對上一張資料中心級的老卡,這個倍率合理。
要為 ZisK 這個數字加三個保留:一是它是廠商自報、沒有揭露 block range 與樣本數;二是沒有揭露證明尺寸,無從對照 300 KiB 的門檻;三是「2.3 kW」只是四張卡的 GPU 銘牌功耗(4 × 575 W),不是整機實測。這三點都是 2026 年把主指標從美元改成能耗的直接原因——下一節就會看到為什麼。
三、證明是常數,witness 是線性
回到 EIP-8025 的規格本身。它定義的容器很值得逐欄看:
ExecutionProof:
proof_data: ByteList[MAX_PROOF_SIZE] # 序列化的證明
proof_type: ProofType # 選哪一套證明系統
public_input: PublicInput # 綁定到特定 payload
PublicInput:
new_payload_request_root: Root # SSZ hash,把證明釘在這個 payload 上
successful_validation: bool # 要是 True 才算正面的有效性訊號
chain_config: ChainConfig # 防跨鏈重放
而餵給 zkVM guest 的私有輸入:
StatelessInput:
new_payload_request: NewPayloadRequest # Engine API 的 payload
witness: ExecutionWitness # 帳戶 / storage / code
chain_id: U64
public_keys: Tuple[Bytes, ...] # 交易簽章者的未壓縮 secp256k1 公鑰
ExecutionWitness:
state: Tuple[Bytes, ...] # RLP 編碼的 trie node 原像
codes: Tuple[Bytes, ...] # 需要用到的 bytecode
headers: Tuple[Bytes, ...] # RLP 編碼的祖先 header,連續鏈
注意 state 那一行:RLP 編碼的 trie node 原像。也就是說,今天的執行證明吃的 witness,就是 MPT 的 witness——上一篇算出最壞情況 330MB 的那個東西。沒有換樹,沒有 chunk 化,什麼都沒改。
為什麼它沒有炸掉?因為它從來不上網路。產生證明的節點自己執行或自己組裝區塊,一邊記錄帳戶 / storage / code / 祖先 header 的存取,然後呼叫 build_stateless_input 把這些打包成 StatelessInput 餵給 guest。上網路的只有 SignedExecutionProof,走一個新的 global topic,節點用 ENR 裡的 eproof 欄位(uint8)宣告自己支援哪些證明。同一個 (new_payload_request_root, proof_type) 只有第一份有效的會傳播,後面的直接丟掉。
規格對 MAX_PROOF_SIZE 的理由寫得很清楚:
在「每個
(payload, proof_type)一份證明」的 gossip 目標、以及每個 payload 最多MAX_EXECUTION_PROOFS_PER_PAYLOAD = 4種證明類型的上限之下,最壞情況的每 slot 在途證明頻寬是4 × 400 KiB = 1.6 MiB——與現有的每 slot blob sidecar 流量同一個量級。
把這個跟上一篇的 witness 表併在一起,才看得出結構:
| block gas limit | witness(EIP-4762) | 證明(EIP-8025 最壞) | 倍數 |
|---|---|---|---|
| 30M | 4.43 MiB | 1.5625 MiB | 2.84 |
| 60M(今天) | 8.86 MiB | 1.5625 MiB | 5.67 |
| 200M(Glamsterdam) | 29.54 MiB | 1.5625 MiB | 18.90 |
| 1G | 147.68 MiB | 1.5625 MiB | 94.5 |
換成 bytes/gas:
witness : 0.154859 bytes/gas(常數,與 gas limit 無關)
證明 @ 60M : 1,638,400 ÷ 60,000,000 = 0.027307 bytes/gas
證明 @ 200M: 1,638,400 ÷ 200,000,000 = 0.008192 bytes/gas
證明 @ 1G : 1,638,400 ÷ 1,000,000,000 = 0.0016384 bytes/gas
這是整張表上唯一一條斜率向下的線。 上一篇列的所有定價——calldata 的 64 gas/byte、access list 的 64 gas/byte、BAL 的 ITEM_COST = 2000、witness leaf 的 6.25 gas/byte——全部是固定的每 byte 價格,所以 gas limit 一漲,絕對尺寸就等比例漲。證明不是。證明的 byte 數是常數,所以它的 bytes/gas 隨 gas limit 反比下降。gas limit 每漲一倍,證明就便宜一半。
這也是為什麼 zkEVM 被當成 gas limit 的解鎖鍵,而不只是一個驗證加速器。
更正 1:「witness 撞上 10 MiB 就完蛋」的前提,在執行證明底下不成立
上一篇把 EIP-7782 的那句「不做大幅的網路層改動,把區塊尺寸推到 10MiB 以上是不切實際的」直接套在 witness 上,算出 67.7M 的死線,並且用「比今天只高 13%」當成結論的重量。
那個推論漏了一個前提檢查:10 MiB 講的是「必須 fan-out 到全網每個節點」的資料。witness 在 EIP-8025 的模型裡不是這種資料。它是一台機器的本機輸入,從 builder 或 prover 的執行過程直接落下來,不經過 p2p。真正 fan-out 的是 1.5625 MiB 的證明,而那個數字在 200M 甚至 1G gas limit 下都不會變。
所以上一篇那個「二元樹上線之後 gas limit 只能到 67.7M」的結論,適用範圍要收窄:它只適用於「每個驗證節點自己拿 witness 自己驗」的完整無狀態模型。而 Ethereum 正在蓋的不是那個。
但這個更正要立刻打一個折。EIP-8025 的 Rationale 白紙黑字寫著:「本 EIP 不為產生證明的節點引入任何誘因;基於這個理由,它們被視為利他的。」 而 Security Considerations 進一步說 process_execution_proof 跑在 beacon block 的 state transition function 之外,證明的產生與驗證都不在 attestation 的路徑上,「如果證明缺席,驗證者可以用執行引擎的結果來投票」。
翻成人話:今天 EIP-8025 一個字都沒有解除 witness 的約束。 每個節點仍然重新執行,證明只是一個可有可無的旁路。上一篇那條 67.7M 的線在「證明變成共識的必要條件」之前都還活著;它不是被拆掉了,是被排進了一個沒有日期的待辦清單。EIP-8025 自己也把這件事列為風險:驗證變成無狀態且常數時間,但產生證明仍然算力密集,「可能讓持有完整狀態的營運者更集中,即使驗證者的參與門檻同時變低」。
四、真正的瓶頸不是錢,是 10 kW 的家用電源
現在把 EF 那兩個硬體門檻算清楚。RTX 5090 的銘牌功耗是 575 W,launch MSRP 是 **7,996)。兩個預算各自能買幾張卡:
功耗上限:10,000 W ÷ 575 W = 17.39 張
金額上限:$100,000 ÷ $1,999 = 50.03 張
17 張 vs 50 張。 功耗那條線緊 2.87 倍。換句話說,<= 100k USD 這個門檻根本沒有在起作用——17 張卡只要 17 × 1,999 = $33,983,連預算的三分之一都用不到。真正在限制 Ethereum gas limit 的,是一般住宅的電源容量。
把第二節的每張卡吞吐代進去:
每 kW 吞吐 = 6,237,006 gas/s ÷ 2.3 kW = 2,711,742 gas/s/kW
10 kW 上限 = 2,711,742 × 10 = 27,117,420 gas/s
27.1 M gas/s。 這是一台完全符合 EF 門檻的家用 prover,在 2026 年 8 月的效率下,理論上的吞吐天花板。乘上時間預算:
| 期限 | 撐得起的 gas limit |
|---|---|
| 12 s(整個 slot) | 325.4 M |
| 10 s(EF 的 realtime 定義) | 271.2 M |
| 8 s(ethproofs 2026 目標) | 216.9 M |
Glamsterdam 的 200M 目標通過了,而且三個期限都通過。但這個「通過」必須加三層扣減,而且三層都是往壞的方向:
第一層,系統功耗不等於 GPU 功耗。 2.3 kW 只算四張卡的銘牌值。CPU、記憶體、主機板、網路、電源轉換損耗、散熱,真實整機大概要在 GPU 功耗上再加三到五成。取 30% 的話,GPU 實際能分到的只有 10,000 ÷ 1.3 = 7,692 W,吞吐掉到 20.9 M gas/s,10 秒的預算變成 208.6M gas——剛好卡在 200M 上,餘裕是 4%。
第二層,平行擴展不是免費的。 把 1 張卡的結果乘 17 倍,假設的是完美線性。實務上不是:證明要切成多段、各自證完再遞迴合併,合併那一層本身是序列的。push0(arXiv 2602.16338)這類編排系統把排程開銷壓到中位數 5 毫秒、在 32 個 dispatcher 上維持 99–100% 的排程效率,但那是編排的效率,不是遞迴合併的效率——後者是證明系統本身的數學性質,沒辦法用調度解決。
第三層,那個 9.62 秒本身就已經在用掉大部分預算。 10 秒的門檻只剩 0.38 秒餘裕;ethproofs 2026 年把目標訂在 P99 < 8 秒加上 ≥90% 上線率才算進「RTP Cohort」,而目前掛牌的兩組都做不到 8 秒。
三層疊起來,結論比較誠實的版本是:200M gas limit 與 10 kW 家用 prover 這兩件事,在 2026 年 9 月的效率下勉強共存,餘裕是個位數百分比,而且建立在「完美平行擴展」這個一定不成立的假設上。 任何一邊再往前推一格,就得靠效率繼續改善來填。
順帶算一下能耗。ethproofs 2026 年把主指標從美元換成 kWh,公式是 num_gpus × TDP × proving_time_ms / 3,600,000:
ZisK 4 卡:4 × 575 × 9,620 ÷ 3,600,000 = 6.146 Wh / 證明
× 7,200 區塊/天 = 44,252 Wh = 44.25 kWh/天
× 365 = 16.15 MWh/年
一台家用 prover 一天約 44 度電。一般家庭一天大概 10 度上下,所以是 4 倍多一個家庭——確實還在「家裡跑得動」的範圍,這是 10 kW 門檻想守住的東西。
再用它反推成本結構。電價取 $0.08/kWh(美國工業均價量級,已標存疑),8 卡配置的純電費是:
8 × 575 × 9,620 ÷ 3,600,000 = 12.29 Wh = 0.01229 kWh
× $0.08 = $0.00098
約 0.1 美分。而 ethproofs 給 ZisK 8x5090 掛的是 $0.0055,差 5.6 倍——約 82% 的掛牌成本不是電,是硬體攤提與託管的會計假設。 這個比例本身就是把主指標從美元換成 kWh 的理由:美元數字裡有八成是假設,kWh 數字裡一個假設都沒有(只要肯揭露整機實測功耗,而目前沒人揭露)。
五、證明時間裡有多少花在 hash 狀態樹:1.65 倍
到這裡都還在算總量。下一個問題是:那 9.62 秒,花在哪裡?
jsign 另外做過一個專門回答這個問題的實驗:把單一的 state transition function 證明拆成兩份——
- execution-only proof:對著一個 flat database 的 pre-state 執行區塊,產出 state diff
- pre/post state check proof:驗證 pre-state 的 Merkle 樹、確認 flat database 的正確性、算出新的 state root
第二份就是純粹的 keccak + MPT 工作。設定:30 個主網區塊(23743854-23743883)、SP1 Turbo v5.2.1 與 ZisK v0.13.0、AMD EPYC-Milan + 128GB RAM + 單張 Nvidia L40S。
結果:
| zkVM | pre/post 相對於 execution-only | pre/post 佔總時間 | 每百萬 cycle 的證明時間 |
|---|---|---|---|
| SP1 | 0.79×(比執行快) | 0.79 ÷ 1.79 = 44.1% | 貴 1.13× |
| ZisK | 1.65–1.69×(比執行慢) | 1.65 ÷ 2.65 = 62.3% | 貴 1.34× |
加上跨證明的驗證檢查,額外開銷 15–19%;帶檢查的完整時間是 SP1 平均 289 秒/區塊、ZisK 164 秒/區塊(單張 L40S,跟前面的多卡叢集數字不可直接比較)。
兩個 zkVM 給出方向相反的答案,原文自己也說「不同 zkVM 的最佳化方向不同」,不宜下決定性結論。但兩邊有一個共同的、比誰快誰慢更重要的發現:pre/post state check 的 cycle 數比執行少,但每個 cycle 貴 1.13–1.34 倍。 這句話的意思是——
keccak 在 zkVM 裡是用 precompile 實作的,precompile 的 cycle 跟一般 cycle 不是同一種 cycle。所以「數 cycle 數」這個最直覺的 profiling 方法,在這裡會系統性低估 hash 的成本。而 pre/post state check 這一份證明,幾乎整份都是 hash。
把兩邊的區間取交集,一個誠實的說法是:主網區塊的證明時間裡,大約四成到六成花在對狀態樹做 keccak,而不是在執行 EVM。
更正 2:二元樹的主要收益不在 witness 尺寸,在證明時間
上一篇整整八節都在算 EIP-7864 對 witness 尺寸的影響:11.24 ÷ 0.154859 = 72.58 倍、分支從 2,880 降到 768 bytes、code 進樹、chunk 化。整個框架是「witness 太大 → 換樹 → witness 變小」。
那個框架本身沒有錯,但它選錯了要證明的命題。在執行證明的模型裡,witness 的尺寸只影響 prover 一台機器的 I/O 與記憶體,那是最容易解決的一種成本。而同一次換樹同時改掉了 40–60% 證明時間所在的那個東西:狀態樹的 merkle 化。
樹形本身就會改變 hash 的工作量。粗估一下(下面每個假設都標出來,整段已標存疑):
MPT:分支節點 RLP ≈ 17 項 × 33 bytes ≈ 532 bytes(假設分支飽滿)
帳戶樹深度 ≈ 8(假設約 3 億個帳戶,hexary)
每次存取餵進 keccak 的 bytes ≈ 8 × 532 = 4,256
二元樹:每層輸入 = 左右各 32 bytes = 64 bytes
深度 24(取 EIP-7864 自己的 N = 2²⁴,768 bytes 分支 ÷ 32)
每次存取餵進 hash 的 bytes = 24 × 64 = 1,536
4,256 ÷ 1,536 = 2.77 倍
樹形大約省掉 2.8 倍的 hash 輸入量。而 hash function 本身還可以再換——那是下一節。兩者相乘才是二元樹對證明時間的真正效果,而這個乘積跟 witness 縮小的 72.6 倍是兩件不同的事,只是剛好由同一次換樹一起帶來。
要補一個反方向的算式,才算誠實。把上一篇的最壞情況構造(讀滿整個 stem)換成 hash 次數:
一個滿載 stem:256 個 leaf → 完全二元樹需要 255 次內部 hash
stem 之上到 root:24 層 → 24 次(上界,實際路徑會共用)
每個 stem ≈ 255 + 24 = 279 次 hash
200M gas → 3,766.5 組 stem(上一篇的表)
3,766.5 × 279 = 1,050,854 次 hash / 區塊
÷ 10 秒 = 105,085 次 hash / 秒 —— 而且是「證明」,不是「計算」
換成 bytes:3,766.5 × 279 × 64 = 67,254,624 bytes = 64.14 MiB,十秒內要證明完 6.41 MiB/s 的 hash。原生 BLAKE3 一秒跑幾個 GB;在電路裡差幾個數量級。上一篇那個 0.154859 bytes/gas 的係數沒有消失,它只是從「頻寬係數」變成了「必須被證明的 hash 工作量係數」。同一個常數,換了一個單位在收費。
六、hash function 的選擇,就是 gas limit 的天花板
上一篇的座標表把 EIP-7864 的狀態寫成「Draft,hash function 未定」,語氣是「還有一個小細節沒敲定」。查清楚之後,那不是小細節。
Ethereum stateless book 的原文:
目前的 EIP 提出 Blake3 作為一個保守的選擇,但這件事還沒有完全定案。
而同一頁對三個候選的效能判斷是:
對於 Keccak 或 Blake3 這類一般的 hash function,在目標硬體規格上,目前的證明效能仍然比 L1 區塊所需要的慢一個數量級。
如果我們有一個像 Poseidon2 這樣的算術 hash function,在目標硬體上目前的證明效能對 L1 區塊的需求來說綽綽有餘。
把這兩句跟第四節的結論放在一起,結構就出來了:
| hash | 狀態 | 對證明的意義 |
|---|---|---|
| Keccak | MPT 現行 | 佔今天證明時間的 40–60% |
| BLAKE3 | EIP-7864 目前寫的保守選項 | 「仍比需求慢一個數量級」 |
| Poseidon2 | 候選,EF 密碼學計畫在評估中 | 「綽綽有餘」 |
也就是說,選 BLAKE3 還是 Poseidon2,不是一個實作偏好問題,而是直接決定 200M gas limit 撐不撐得住 10 秒。 第四節那個 4% 餘裕,是在今天的 keccak-MPT 上量出來的;換成 Poseidon2,餘裕可能是好幾倍;換成 BLAKE3,按這段原文的說法,可能還是不夠。
(要標一個保留:那句「慢一個數量級」原文沒有給數字,也沒有說是相對於哪一個工作量的哪一個部分。已標存疑。)
更正 3:EIP-7864 的 hash 選擇跟 EF 自己的安全門檻正面對撞
EF 在 2025-12-18 宣告 zkEVM 的效能目標已經達成,然後把重心整個轉到安全性,訂了一組新的時程:
| 時點 | 要求 |
|---|---|
| 2026-02 底 | 所有 zkEVM 團隊把證明提交給 soundcalc(EF 的標準安全性計算器),尚無安全性下限 |
| 2026-05 底(Glamsterdam 期中) | 100-bit 可證明安全、證明尺寸 ≤ 600 KB、需公開說明遞迴架構 |
| 2026 年底(H-Star 最終) | 128-bit 可證明安全(以 soundcalc 為準)、證明尺寸 ≤ 300 KB、遞迴拓樸需有形式化安全論證 |
關鍵字是「可證明」。EF 的說法是,L1 唯一可接受的終局是 provable security,而不是「假設猜想 X 成立之下的安全」。
Poseidon2 正好是那個最需要「假設猜想 X」的候選。算術 hash function 的安全性依賴的是代數結構上的難度假設,密碼分析的歷史比 Keccak 短得多;EF 為此專門開了一個評估計畫,而這個計畫至今沒有結案。
於是 2026 年的 Ethereum 同時握著兩個互相拉扯的目標:
- 要速度 → 需要算術 hash(Poseidon2),因為標準 hash「慢一個數量級」
- 要可證明安全 → 傾向保守 hash(Keccak / BLAKE3),因為算術 hash 的難度假設還沒被時間檢驗過
上一篇寫「hash function 未定」的時候,我以為那是 EIP-7864 內部的一個懸而未決項。實際上它是兩條 EF 頂層路線圖的交會點,而且兩條路線圖給出相反的指示。這也解釋了為什麼 EIP-7864 到現在還掛 Draft:它在等的不是實作,是一個密碼學結論。
七、ePBS 才是那個把 2 秒變成 9 秒的東西
還有一件上一篇完全沒展開的事。EIP-7732(ePBS)是 Glamsterdam 兩個執行層 headliner 之一,上一篇只把它列在座標表裡。但在證明這條線上,它是先決條件。
原因很物理:今天的 12 秒 slot 裡,區塊傳播佔前三分之一約 4 秒,attestation deadline 在那之後,所以一個想在 attestation 之前把證明交出來的 prover,實際可用的窗口只有 1–2 秒。這個數字對任何證明系統來說都是不可能的。
ePBS 把共識區塊的驗證與執行 payload 的驗證在邏輯上與時間上都拆開。驗證者可以先處理共識層的承諾,payload 在自己的截止期限底下另行傳播與檢查,由 Payload Timeliness Committee(PTC)專門對「builder 有沒有準時揭露 payload」投票。副作用就是 prover 的窗口從 1–2 秒撐到 6–9 秒(二手來源之間有 6–9 與「將近整個 12 秒」兩種說法,已標存疑)。
這條因果鏈值得記住,因為它把三個看起來不相干的東西串成一條:
ePBS(EIP-7732)→ 把證明窗口從 1–2 秒撐到 6–9 秒
→ 讓 P99 < 10 秒從「不可能」變成「勉強」
→ 執行證明(EIP-8025)才有意義
→ witness 不必 fan-out
→ 上一篇那條 67.7M 的死線才可能鬆綁
反過來讀也成立:在 ePBS 上主網之前,EIP-8025 是一份跑不動的規格。 而這也是上一篇提到的、EIP-7782(6 秒 slot)被 Declined 的真正原因——不是「6 秒太急」這種感覺問題,是 6 秒的 slot 會把 ePBS 剛剛撐開的那個窗口再砍一半,讓整條鏈從頭斷掉。
八、witness 定價的問題換了單位,但沒有消失
把七節收攏。上一篇的核心張力是:
局部性折扣的大小,和最壞情況 witness 的大小,是同一個數字。
在執行證明的世界裡,這句話要改寫成:
局部性折扣的大小,和 prover 必須在一個 slot 內證明完的 hash 工作量,是同一個數字。
因為 WITNESS_CHUNK_COST = 200 決定的不只是「多少 bytes 進 witness」,同時也決定了「多少個 leaf 要被 merkle 化」。第五節算出來的 105,085 次 hash/秒 就是直接從那個常數推出來的。把 WITNESS_CHUNK_COST 提到 605,hash 工作量跟著掉到三分之一。
差別在於約束的性質變了,而這個改變對規格制定者是好消息:
| 頻寬版本(上一篇) | 延遲版本(本篇) | |
|---|---|---|
| 約束對象 | 全網每個節點 | 產生證明的少數機器 |
| 天花板來源 | p2p fan-out,10 MiB | 單機吞吐 × 時間預算 |
| 改善方式 | 只能改協議常數 | 也可以靠硬體 / 演算法 |
| 改善速度 | 一個硬分叉一次 | 2025 年延遲改善 5 倍 |
| 誰付代價 | 所有使用者(折扣被砍) | prover 營運者 |
最後一列是重點。頻寬版本裡,唯一的旋鈕是 gas 常數,而動那個旋鈕就等於對所有使用者漲價。延遲版本裡多了一條路:讓證明變快。而證明變快這件事,2025 年一年就做到 5 倍,2026 年又把 12 GPU 壓到 4 GPU。
所以上一篇那個「EIP-4762 的常數必須重算」的結論要修一個方向,而不是修數值:那五個常數的確從來沒有為二元樹校準過,但校準它們的目標函數變了。2022 年為 Verkle 訂常數時,目標函數是「證明尺寸」;上一篇推導 605 時,目標函數是「p2p 頻寬」;而 2026 年真正該用的目標函數是「單一 prover 在 10 kW 與 10 秒之內能證明多少 hash」——一個會隨硬體與演算法逐年變動的量。
這其實比「一個固定的 10 MiB 上限」更難處理。固定上限至少是固定的;一個隨摩爾定律移動的目標,意味著這組常數永遠不會收斂。我沒有在任何公開文件裡看到有人明確地用「prover 吞吐」當作 EIP-4762 常數校準的目標函數,已標存疑,但第五節那個「40–60% 證明時間是狀態樹 hash」的實測,已經把兩邊接上線了。
九、2026 年 9 月 22 日的座標
| 主題 | EIP / 來源 | 狀態 |
|---|---|---|
| 可選執行證明 | EIP-8025 | Draft(2025-09-17),CL 層,選擇性、無誘因、跑在 STF 之外 |
| 統一二元狀態樹 | EIP-7864 | Draft,hash 仍是 BLAKE3「保守選項」,等密碼學結論 |
| Statelessness gas 定價 | EIP-4762 | Draft,常數仍為 Verkle 校準 |
| ePBS | EIP-7732 | Glamsterdam headliner,把證明窗口從 1–2 秒撐到 6–9 秒 |
| Block-Level Access Lists | EIP-7928 | Glamsterdam headliner,SFI |
| 6 秒 slot | EIP-7782 | Declined——會把 ePBS 撐開的窗口砍半 |
| realtime 門檻 | EF blog(2025-07-10) | P99 ≤ 10s、≤ 300 KiB、≥ 128-bit、≤ $100k、≤ 10 kW、全開源 |
| 安全性時程 | EF(2025-12-18) | 2026-05 要 100-bit / ≤ 600 KB;2026 年底要 128-bit / ≤ 300 KB |
| ethproofs 2026 目標 | ethproofs | 主指標改 kWh;RTP Cohort 門檻 P99 < 8s + ≥ 90% 上線 |
| 現役最佳(自報) | ZisK v1.1.0-alpha | 4 × 5090,P99 9.62 s,99.7% 區塊 < 10 s(2026-08-18) |
| 現役掛牌 | ethproofs live | ZisK 8×5090 成功率 100.00% / 0.0066 |
| 主網 gas limit | — | 60M;Glamsterdam 目標 200M,主網啟用預期 2026 Q4 |
🧠 記
- 證明這一側的量綱是
gas/second,對應上一篇 witness 的bytes/gas。需求端:60M ÷ 10s = 6.00 M gas/s、200M ÷ 10s = 20.0 M gas/s、200M ÷ 8s = 25.0 M gas/s。 - EF 的 realtime 六項門檻:P99 ≤ 10 秒(主網真實區塊)、證明 ≤ 300 KiB 且無 trusted setup、≥ 128-bit(上線初期 100-bit)、CAPEX ≤ $100k、功耗 ≤ 10 kW、完全開源。
- 兩個硬體門檻只有一個在起作用。
10,000 W ÷ 575 W = 17.4 張卡,$100,000 ÷ $1,999 = 50 張卡。功耗緊 2.87 倍,17 張卡只花 $33,983。限制 Ethereum gas limit 的是住宅電源容量,不是錢。 - 10 kW 的吞吐天花板 ≈ 27.1 M gas/s(由 ZisK 4 卡 9.62 秒反推:
60M ÷ 9.62 ÷ 2.3 kW = 2.71 M gas/s/kW)。× 10 秒 = 271M gas。200M 通過,但扣掉 30% 整機功耗只剩 208.6M,餘裕 4%,而且假設完美平行擴展。 - 證明是唯一一條斜率向下的線。 EIP-8025 的
MAX_PROOF_SIZE = 409600×MAX_EXECUTION_PROOFS_PER_PAYLOAD = 4= 1.5625 MiB,與 gas limit 無關。bytes/gas:60M 是 0.0273、200M 是 0.0082、1G 是 0.0016。witness 永遠是 0.1549。60M 差 5.67 倍,200M 差 18.9 倍。 - 執行證明的 witness 就是 MPT witness:
ExecutionWitness.state是「RLP 編碼的 trie node 原像」。它沒有變小,它只是不上網路了——由 prover 本機組出來當 zkVM 的私有輸入。 - 但 EIP-8025 今天什麼都沒解除。 規格明寫「不引入任何誘因,因此產生證明的節點被視為利他的」,
process_execution_proof跑在 beacon block STF 之外,證明缺席時驗證者照樣用執行引擎的結果投票。上一篇那條 67.7M 的線還活著,只是被排進一個沒有日期的待辦清單。 - 證明時間的四到六成花在 hash 狀態樹。jsign 把 STF 證明拆成 execution-only 與 pre/post state check:ZisK 的 pre/post 是執行的 1.65–1.69 倍(佔 62.3%),SP1 是 0.79 倍(佔 44.1%)。兩邊共同的發現更重要:pre/post 的 cycle 比較少但每個貴 1.13–1.34 倍——數 cycle 會系統性低估 hash 成本。
- 二元樹真正的獎品是證明時間,不是 witness 尺寸。 樹形本身粗估省
4,256 ÷ 1,536 = 2.77 倍的 hash 輸入量(存疑);hash function 再換一次。而 witness 縮小的 72.6 倍是另一件事,只是同一次換樹順便帶來的。 - hash function 的選擇 = gas limit 的天花板。 Stateless book 原文:Keccak / BLAKE3 在目標硬體上「仍比 L1 區塊所需慢一個數量級」,Poseidon2「綽綽有餘」。EIP-7864 現在寫的是 BLAKE3,而且明說是「保守選項,尚未定案」。
- 而 EF 自己的安全時程跟它對撞:2026-05 要 100-bit 可證明安全 + ≤ 600 KB,2026 年底要 128-bit 可證明安全 + ≤ 300 KB,而且強調是「可證明」而非「假設猜想 X 成立」。Poseidon2 正是最需要那個猜想的候選。要速度就要算術 hash,要可證明安全就要保守 hash——EIP-7864 卡在中間,等的是密碼學結論不是實作。
- ePBS 是整條鏈的先決條件。 12 秒 slot 下 prover 的實際窗口只有 1–2 秒;EIP-7732 把共識驗證與 payload 驗證拆開(PTC 專門對 payload 準時性投票),窗口撐到 6–9 秒。沒有 ePBS,EIP-8025 是一份跑不動的規格。EIP-7782(6 秒 slot)被 Declined 的真正原因就是它會把這個窗口再砍一半。
- 上一篇的張力換了單位但沒消失:
WITNESS_CHUNK_COST = 200同時決定「多少 bytes 進 witness」與「多少 leaf 要 merkle 化」。200M gas 最壞情況3,766.5 × 279 = 1,050,854 次 hash,十秒內 = 105,085 次 hash/秒(要證明,不是要算)。 - 差別是約束的性質變了。 頻寬版本的唯一旋鈕是 gas 常數,動它就是對所有使用者漲價;延遲版本多了「讓證明變快」這條路,而那條路 2025 年一年就走了 5 倍。代價:目標函數變成一個隨硬體移動的量,這組常數可能永遠不會收斂。
- 成本結構:ethproofs 掛 ZisK 8×5090 0.08/kWh 算純電費只有 $0.00098。約 82% 是硬體攤提與託管——這就是把主指標從美元換成 kWh 的理由。一台家用 prover 一天約 44 度電。
✍️ 實踐
把自己關心的那條鏈換算成 gas/second,然後對照 10 kW。 這件事今天做得完,而且只需要三個數字。
步驟:
-
找出目標 gas limit 與時間預算。 如果你在看 Ethereum L1,就是
200,000,000與10秒。如果你在做 L2 或 appchain,用你自己的區塊 gas limit 與出塊間隔。相除得到需求吞吐R(gas/s)。 -
找出單卡吞吐。 沒有自己的測量的話,用本文的兩個參照點:未揭露規格的單機 0.736 M gas/s(jsign 的 500 區塊實測),或 RTX 5090 的 1.56 M gas/s(從 ZisK 4 卡 9.62 秒反推,存疑)。
R ÷ 單卡吞吐 = 需要幾張卡。 -
乘上 575 W,跟 10,000 W 比。 如果 GPU 銘牌功耗就已經超過 7,700 W(留 30% 給整機其他部分),你的設計在 EF 的家用 prover 門檻之外——這代表證明會集中到資料中心,而那是一個治理問題,不是工程問題。
-
把第三節那張
bytes/gas表重算一次,用你自己的證明尺寸上限。 公式是證明尺寸 × 證明系統數量 ÷ gas limit。跟你的 witness / state diff 的bytes/gas相除,得到「證明比 witness 省幾倍」。如果這個倍數小於 3,你的證明還太大,先解決尺寸再談延遲。 -
最後做一次敏感度分析:把 hash 成本乘 0.3 與乘 3,看結論會不會翻。 如果會翻(通常會),那麼你這條鏈的 gas limit 上限實際上是由 hash function 的選擇決定的,而不是由任何一個 gas 常數決定的。把這個結論寫進設計文件,因為它會決定你要不要押算術 hash——以及要不要接受隨之而來的、還沒有被時間檢驗過的難度假設。
做完這五步會得到一張一頁的表。它不會給你答案,但它會讓你在下次有人說「gas limit 可以再往上拉」的時候,能立刻問出正確的那個問題:在幾 kW、幾秒、哪一個 hash function 之下?
🔗 延伸學習
- EIP-8025: Optional Execution Proofs — 本篇的規格基礎。
StatelessInput與ExecutionWitness的欄位定義值得逐欄讀,尤其是state那一行的「RLP 編碼的 trie node 原像」——它說明今天的執行證明吃的還是 MPT witness。Rationale 對4 × 400 KiB = 1.6 MiB的頻寬論證,以及 Security Considerations 裡「產生證明的節點被視為利他的」與「可能讓完整狀態的營運者更集中」,是理解這條路線真正風險的地方。 - Shipping an L1 zkEVM #1: Realtime Proving(Ethereum Foundation) — 六項門檻的一手出處。特別注意 10 kW 那一項的理由寫的是「多數住宅的街邊電源至少有 10kW」,以及 80k」——這兩個數字把一個密碼學問題直接綁在家庭電力基礎設施上。
- zkVM - Proof separation: Execution vs. Pre/Post state(Ignacio Hagopian) — 唯一一份把證明時間拆成「執行」與「狀態樹 hash」兩半的公開實測。SP1 與 ZisK 給出方向相反的結果,但「pre/post 的 cycle 比較少卻每個貴 1.13–1.34 倍」這個共同發現,是理解為什麼不能用 cycle 數做 profiling 的關鍵。
- zkVM Ethereum - OpenVM guest input & optimized MPT implementation(Ignacio Hagopian) — 500 個連續主網區塊的前後對照,提供了本篇所有推導的基準吞吐
735.96K gas/s。單純換一個 MPT 的記憶體佈局(深度優先前序、4-byte 對齊、NodeId索引取代指標)就拿到 15.2% 的證明時間,說明這一層還有多少沒被榨乾的空間。 - Ethproofs 2025 Review & 2026 Roadmap for Real-Time Proving — 2026 年把主指標從美元換成
num_gpus × TDP × proving_time_ms / 3,600,000的那份文件,同時把 RTP Cohort 的門檻訂在 P99 < 8 秒加 90% 上線率。搭配 ethproofs.org 的即時榜單看,可以自己驗算本篇的每一個能耗數字。
💬 問 AI
我在研究 Ethereum 執行證明(execution proofs)的延遲預算,想把它跟 stateless witness 的尺寸預算接起來。請以一手來源(EIP 原文、Ethereum Foundation 部落格、ethresear.ch、ethproofs、zkVM 團隊自己的 benchmark)為依據回答。每個數字請標明出處與章節,並且嚴格區分「來源明確說的」與「你自己推論的」——推論的部分請標示為推論並寫出推導步驟。查不到就直接說查不到,不要用記憶補。
【一、把兩個量綱接起來】
1. 請把 stateless witness 的 bytes/gas 與執行證明的 bytes/gas 放在同一張表上。witness 用 EIP-4762 的常數推(讀滿一個 stem 的 gas 成本、換算成 state_diff 的 bytes),證明用 EIP-8025 的 MAX_PROOF_SIZE × MAX_EXECUTION_PROOFS_PER_PAYLOAD。列出 30M / 60M / 200M / 500M / 1G 五個 gas limit 下兩者的絕對尺寸與 bytes/gas,並指出哪一條線的斜率是負的、為什麼。
2. EIP-8025 的 StatelessInput.witness 用的是哪一種 witness?它跟二元樹的 execution witness 是同一個東西嗎?如果不是,兩者的尺寸差多少?請引用規格原文的欄位定義。
【二、延遲帳】
3. 請把「證明一個區塊」換算成 gas/second 這個單位。列出 60M/10s、60M/8s、200M/10s、200M/8s 需要的吞吐。然後找出你能查到的、有公開 benchmark 的單機或單卡吞吐數字(標明 zkVM 版本、硬體、block range、樣本數),算出各需要幾張卡。
4. Ethereum Foundation 的 realtime proving 六項門檻分別是什麼?請特別分析 ≤10kW 與 ≤$100k USD 這兩項:以 RTX 5090(575W、$1,999 MSRP)計算,各自能買幾張卡?哪一項才是真正的約束?差幾倍?這對「gas limit 的上限由什麼決定」意味著什麼?
5. 用 ethproofs 2026 的能耗公式(num_gpus × TDP × proving_time_ms / 3,600,000)算出一份證明的 Wh、一天的 kWh、一年的 MWh。再用合理的電價反推純電費,跟 ethproofs 掛牌的每證明成本對照,說明差額是什麼。如果 ethproofs 有揭露電價假設,請用他們的。
【三、證明時間的組成】
6. 目前的 zkEVM 證明時間裡,有多少比例花在 EVM 執行、多少花在狀態樹的 keccak?請找出有公開拆解的實測(而不是估計),列出 zkVM、版本、硬體、區塊範圍與結果。不同 zkVM 的結果一致嗎?如果不一致,原因是什麼?
7. 為什麼「數 cycle 數」在 zkVM profiling 上會低估 hash 的成本?precompile 的 cycle 跟一般 cycle 在證明時間上差多少?請給實測倍率。
【四、hash function 這個旋鈕】
8. EIP-7864 目前提議哪一個 hash function?為什麼說它是「保守選項」?Keccak、BLAKE3、Poseidon2 三者在「目標硬體上證明 L1 區塊」這件事上的差距,有沒有任何一份有數字的比較?如果只有定性描述(例如「慢一個數量級」),請明說只有定性描述。
9. 請把 EF 的 zkEVM 安全性時程(soundcalc、100-bit / 128-bit 可證明安全、600KB / 300KB 證明尺寸、遞迴拓樸的形式化論證)完整列出來,並分析它跟「選 Poseidon2 以求速度」之間的張力。算術 hash function 的可證明安全性目前卡在哪裡?EF 的評估計畫有結案嗎?
【五、時間線的依賴關係】
10. 請畫出 EIP-7732(ePBS)→ 證明窗口 → EIP-8025 → witness 不必 fan-out 這條因果鏈,並核實每一段的數字:今天 prover 的實際窗口是幾秒?ePBS 之後是幾秒?來源是什麼?順便說明 EIP-7782(6 秒 slot)被 Declined 跟這條鏈的關係。
【六、對我的意義】
11. 綜合以上,如果我要在 2026-2028 年之間做一個跟 Ethereum L1 gas limit 有關的長期賭注(例如押注 gas limit 會不會在 2028 年前超過 500M),上面哪幾個數字是決定性的?哪幾個是雜訊?
12. 最後,請對「執行證明讓 witness 尺寸不再是 gas limit 的約束」這個結論,給出你能構造的**最強反方論證**——包括但不限於:利他 prover 的激勵不相容、證明產生的中心化、遞迴合併的非線性擴展、算術 hash 的密碼分析風險、以及 mempool 與抗審查在部分無狀態下的退化。然後說明要讓你改變立場,需要看到什麼樣的證據。
13. 請指出我上面的問題裡有沒有錯誤的前提、或因為問法而被我漏掉的重要面向。