上一篇花了整整一節論證「hash function 的選擇,就是 gas limit 的天花板」,結論是 Ethereum 卡在「要速度就選 Poseidon2、要可證明安全就選 BLAKE3」這個兩難中間,而 EIP-7864 掛著 Draft 是在等一個密碼學結論。這個結論在寫下來的時候,已經過期四十四天。
2026-08-13,Justin Drake 在 X 上宣布 Ethereum Foundation 放棄 Poseidon,L1 轉向 SHA 或 BLAKE。 原文的用詞是「一場八年、八位數美元的後量子密碼學兔子洞,抵達了它夢想中的結局」。而理由跟上一篇寫的方向完全相反——不是算術 hash 的安全假設沒有通過檢驗,是通用 hash 追上來了。Drake 自己那句話是整件事的樞紐:關鍵不是 SNARK-friendly hash,而是 hash-friendly SNARK,秘密在於「對最小的質數,也就是二,做算術」——特徵為 2 的二元擴張域。
把這件事變成數字的是 2026 年 6 月的一篇論文。Benedikt Bünz、Ron Rothblum 與 William Wang 的 Flock(arXiv 2607.27491 / eprint 2026/1329),一個專門證明批次布林運算的 SNARK。它在一顆 Apple M4 Max 的單核上,每秒證明 82,100 次 BLAKE3 compression、42,100 次 SHA-256 compression、30,700 次 Keccak-f[1600] permutation;十核上 BLAKE3 超過 660,000 次/秒。對原生執行的額外開銷不到 250 倍(SHA-256 約 170 倍、Keccak 約 245 倍)。
上一篇第五節推過一個數字:200M gas 的最壞情況構造,每個區塊要對二元狀態樹做 1,050,854 次 hash,分攤到十秒是 105,085 次/秒。那時候的語氣是「而且是『證明』,不是『計算』」,意思是這個數字遠遠超出當時的能力。現在把兩個數字並排:105,085 對 660,000。餘裕 6.28 倍,而且一張 GPU 都沒用到。
📖 學
一、為什麼這兩個數字可以直接相除
先確認這不是單位混用。BLAKE3 的 compression function 吃的是 64-byte 的輸入區塊,而 BLAKE3 本身就是一棵 Merkle 樹,它的 parent node 壓縮正好是「把左右兩個 32-byte 的 chaining value 合併成一個」。
而一棵二元狀態樹的內部節點 hash,輸入正好是 left(32 bytes) || right(32 bytes) = 64 bytes。
一個樹節點 = 一次 compression。 沒有 padding、沒有多區塊、沒有換算係數。上一篇那個 1,050,854 次 hash/區塊,在 Flock 的計價單位裡就是 1,050,854 次 compression,一比一。
所以可以直接算時間:
單核: 1,050,854 ÷ 82,100 = 12.80 秒
十核: 1,050,854 ÷ 660,000 = 1.593 秒
最壞情況 200M gas 區塊的整棵二元樹 merkle 化,在一台筆電的十個 CPU 核心上,1.59 秒證明完。 十秒預算裡佔 15.9%。
順便,這組數字回答了上一篇第四節那個懸而未決的擔憂。上一篇寫「把 1 張卡的結果乘 17 倍,假設的是完美線性。實務上不是」,但只能定性地說,拿不到數字。Flock 給了:
完美線性下的十核 = 82,100 × 10 = 821,000 次/秒
實測十核 = 660,000 次/秒
平行效率 = 660,000 ÷ 821,000 = 80.4%
80.4%。 十核掉 19.6%。要標保留:十核跟十七張 GPU 的擴展曲線不是同一回事(CPU 核心共享 L3 與記憶體頻寬,GPU 之間走 PCIe),而且這 80.4% 裡混了記憶體頻寬飽和與排程開銷兩種效應,沒有拆開,已標存疑。但至少有了一個實測起點,而不是「一定不是完美線性」這種空話。
更正 1:上一篇說 hash function 是 gas limit 的天花板,方向錯了兩次
上一篇引 Ethereum stateless book 的原文,說 Keccak / BLAKE3 這類通用 hash「在目標硬體規格上,目前的證明效能仍然比 L1 區塊所需要的慢一個數量級」,而 Poseidon2「綽綽有餘」,然後把這件事寫成「選 BLAKE3 還是 Poseidon2,直接決定 200M gas limit 撐不撐得住 10 秒」。
兩個錯誤疊在一起。
第一個錯誤是時效。 那段 stateless book 的文字是真的,EIP-7864 的原文到今天也還寫著 BLAKE3 是「減少 EL 客戶端實驗摩擦的選擇,最終決定 TBD」,候選裡也還列著 Poseidon2,並註明「EF 有一個密碼學計畫正在評估其安全性質」。但那份文件跟 2026-08-13 的宣布之間有落差——EIP 的正文沒有跟上 roadmap 的決定。我把一份沒有更新的規格文字當成了現況。
第二個錯誤更嚴重,是因果方向。 上一篇把張力寫成「要速度 → 選算術 hash(Poseidon2);要可證明安全 → 選保守 hash(Keccak / BLAKE3)」,這個框架假設速度與安全是一條軸的兩端,只能二選一。實際發生的是第三種結果:證明系統進步到讓保守 hash 拿到算術 hash 的速度。Drake 的說法是 Poseidon 沒有被攻破,Ethereum 也沒有發出任何遷移命令或部署分叉;改變的是證明系統這一側的權衡。Binius 在 EUROCRYPT 2025 把二元域證明做出來,Binius64 落地,Flock 在 2026-06 把它推到「SHA-256 比 Binius64 快 8.4 倍、BLAKE3 快 14 倍、對質數域系統快 10–40 倍(Plonky3)到數百倍(Spartan)」。
當一條軸的兩端同時往前移動的時候,「取捨」這個框架本身就失效了。 上一篇的錯不在算錯,在於選了一個把答案限制成二選一的問題形式。
要補一句公平的話:那個框架在 2025 年 7 月是對的。stateless book 那段文字寫下來的時候,二元域 SNARK 還沒有實用實作。它不是錯的分析,是過期的分析,而我沒有查證期限。
二、換了 hash 也撐不起 200M:Amdahl 的帳
現在做一件比慶祝更有用的事:假設 hash 完全免費,200M gas 撐得住 10 秒嗎?
上一篇第五節有一個實測可以拿來當分母。jsign 把單一 state transition function 的證明拆成 execution-only 與 pre/post state check 兩份,在單張 Nvidia L40S 上跑 30 個主網區塊,結果是 ZisK 的 pre/post 佔總時間 62.3%、SP1 佔 44.1%。也就是說,今天的證明時間裡有四成到六成是在對狀態樹做 hash。
把 ZisK 那個 60M / 9.62 秒的 P99 線性外推到 200M:
9.62 秒 × (200 ÷ 60) = 32.07 秒
其中 hash : 32.07 × 0.623 = 19.98 秒
其中 execution: 32.07 × 0.377 = 12.09 秒
execution 那一段,單獨就已經 12.09 秒。 超過 10 秒門檻 20.9%。
這代表:即使把狀態樹的 hash 成本除以無限大,200M gas 在 2026 年 8 月的 zkVM 效率下仍然做不到 10 秒。 換 hash、換樹形、換證明系統,全部只作用在那 62.3% 上;剩下的 37.7% 是純粹的 EVM 執行,而它自己就撐爆了預算。
用 SP1 的比例算更糟,因為 SP1 的 execution 佔比更高:
| zkVM | 基準 | 外推到 200M | execution 佔比 | hash 歸零後的下限 |
|---|---|---|---|---|
| ZisK 4×5090 | 9.62 s @ 60M(P99) | 32.07 s | 37.7% | 12.09 s |
| SP1 Hypercube 16×5090 | 10.3 s @ 60M(平均) | 34.33 s | 55.9% | 19.19 s |
兩個 zkVM 在上一篇給出方向相反的拆解結果,但在這個問題上給出同一個答案:hash 不是那個綁住的約束。
算出實際需要的加速倍數。把 Flock 帶來的改善估成 7.75 倍(下一段會推這個數字),代進去:
hash 部分: 19.98 ÷ 7.75 = 2.58 秒
execution: 12.09 秒
合計: 14.67 秒 ← 仍超過 10 秒 46.7%
要進 10 秒,execution 必須壓到 10 − 2.58 = 7.42 秒
12.09 ÷ 7.42 = 1.63 倍
EVM 執行的證明還要再快 1.63 倍。 這是一個明確的、可以被查核的缺口,而它跟 hash function 一點關係都沒有。
(要標三個保留。一,gas 與證明時間的線性外推是假設,實際上更大的區塊在遞迴合併那一層有超線性成本,所以 32.07 秒是樂觀值。二,62.3% / 44.1% 是在單張 L40S 上量的,多卡叢集上執行與 hash 的平行化程度不同,比例會變。三,Flock 是研究原型、不是生產 zkEVM,7.75 倍能不能落到端到端的 STF 證明上完全未知。整段已標存疑,但三個保留都指向同一個方向:真實情況比這裡算的更糟,不會更好。)
三、7.75 倍是怎麼來的,以及一個意外的交叉驗證
上一篇第五節粗估「樹形本身省掉 2.77 倍的 hash 輸入量」,推導是:
MPT : 8 層 × 532 bytes/分支節點 = 4,256 bytes/存取
二元樹: 24 層 × 64 bytes/節點 = 1,536 bytes/存取
4,256 ÷ 1,536 = 2.77 倍
當時標了「整段已標存疑」,因為每一步都是假設。今天用一條完全不同的路徑再算一次,看看會不會對上。
這次從 gas 預算出發,而不是從樹的形狀出發。MPT 上沒有局部性折扣,每次 cold storage 讀都是 2,100 gas:
200,000,000 ÷ 2,100 = 95,238 次存取
每次存取餵進 keccak 約 4,256 bytes
Keccak-256 的 rate 是 136 bytes/permutation
4,256 ÷ 136 = 31.3 → 取 32 次 permutation(含 padding)
95,238 × 32 = 3,047,619 次 permutation
對照二元樹那一側,上一篇算出的最壞情況是 3,766.5 stem × 279 hash = 1,050,854 次。
3,047,619 ÷ 1,050,854 = 2.900 倍
2.900 對上一篇的 2.771,差 4.7%。 兩條完全獨立的推導路徑——一條數樹的層數與節點大小,一條數 gas 預算與 permutation 數——落在同一個數量級的同一個位置。這讓我對「樹形本身大約省 2.8 倍 hash 工作量」這個結論的信心提高不少。
第二個因子是 hash function 本身,直接用 Flock 的單核數字:82,100 ÷ 30,700 = 2.674 倍。兩者相乘 2.900 × 2.674 = 7.755,就是上一節用的 7.75。換成時間更直觀,假設同樣的 80.4% 十核平行效率:
| 配置 | hash 次數/區塊 | 十核吞吐 | 時間 |
|---|---|---|---|
| MPT + Keccak | 3,047,619 permutation | 246,828/s | 12.35 秒 |
| 二元樹 + BLAKE3 | 1,050,854 compression | 660,000/s | 1.59 秒 |
十秒預算裡,一個佔 123.5%,一個佔 15.9%。
這張表還有一個值得停一下的地方:MPT 那一行的 12.35 秒,跟上一節「hash 歸零後 execution 還要 12.09 秒」幾乎一樣。 這不是巧合也不是因果,是兩個獨立的數字碰巧撞在一起,但它把今天的處境講得很清楚——在 200M gas 上,狀態樹的 hash 與 EVM 的執行,各自單獨都會把十秒的預算用完。 換樹解決其中一個,另一個原封不動。
四、39.7%:冠軍機的數字不是網路的數字
上一篇整個第四節的推導,分母是一個數字:ZisK 4×5090 的 P99 9.62 秒。從它反推出 每 kW 2.71 M gas/s,再乘 10 kW 得到 27.1 M gas/s 的家用 prover 天花板,再乘十秒得到 271M gas,最後扣 30% 整機功耗得到 208.6M,宣布「200M 通過,餘裕 4%」。
今天要標這個推導的適用邊界。ethproofs 在 2026-09-02 的 cohort 數字是:掛牌的兩組 eligible 配置確實都落在半美分上下,但所有被評估的區塊 slot 裡,只有 39.7% 達成 sub-10-second 的成功證明,因為離線與不符資格的 run 也計入分母。
把公開的數字排在一起看:
| 來源 | 配置 | 宣稱 | 性質 |
|---|---|---|---|
| ZisK v1.1.0-alpha(2026-08-18) | 4 × RTX 5090 | P99 9.62 s,99.7% < 10 s | 廠商自報,單一 cluster |
| SP1 Hypercube(2026) | 16 × RTX 5090 | 平均 10.3 s,95.4% < 10 s,99.7% < 12 s | 廠商自報,單一 cluster |
| ethproofs cohort(2026-09-02) | 全部 | 39.7% 的 slot sub-10-second | 第三方聚合,含離線 |
同一件事,一個說 99.7%,一個說 39.7%。 差別不在誰誠實,在分母:cluster 自報的分母是「我有跑的區塊」,ethproofs 的分母是「所有區塊」。一台機器下線三小時,它自己的統計裡那段時間不存在,ethproofs 的統計裡那 900 個 slot 全部算失敗。
還有一個很粗的逼近值得記(純屬推論,已標存疑):若 cohort 裡有五組在跑、只有兩組達得到 sub-10s,2 ÷ 5 = 40.0%,跟 39.7% 差 0.75%。這暗示它不是機率問題,是普查問題——不是「每次證明有四成機率成功」,而是「五台機器裡有兩台做得到」。若這個讀法對,提升覆蓋率的方法不是讓現有機器更快,是讓更多機器跨過門檻。
更正 2:27.1 M gas/s 那個天花板,分母是全網最好的那一台
上一篇用 9.62 秒當基準,等於預設「一台符合 EF 門檻的家用 prover」= 「2026 年 8 月表現最好的那一組叢集」。這兩件事不是同一件事。
更正後的說法應該是:208.6M gas 是能力上限的估計,不是網路現況的估計。 它回答的問題是「今天最好的技術在 10 kW 底下能做到什麼」,而不是「今天的網路能承受什麼」。後者的答案是 39.7%。
這個區分在 EIP-8025 的脈絡下特別重要,下一節會看到為什麼:當證明是選擇性的、而且沒有誘因時,決定網路安全性的是覆蓋率,不是峰值能力。
順便把成本曲線也更新一下,並且算出它什麼時候會失去意義:
| 時點 | 每份區塊證明 |
|---|---|
| 2025-01 | $1.69 |
| 2025-12 | < $0.04 |
| 2026-09-02 | ≈ $0.005 |
驗算那個「二十個月降 99.7%」:
1 − 0.005 ÷ 1.69 = 1 − 0.002959 = 0.99704 ✓
1.69 ÷ 0.005 = 338 倍
月均衰減 = 338^(−1/20) = 0.7419 → 每月降 25.8%
上一篇算過 8 卡配置的純電費下限是 **0.08/kWh 計)。照這個衰減率外推:
0.005 × 0.7419^n = 0.00098
0.7419^n = 0.196
n = ln(0.196) ÷ ln(0.7419) = 5.46 個月
大約 2027 年 3 月,美元成本會撞上電費地板。 之後這條曲線就不再下降了,因為剩下的都是物理。這正是 ethproofs 在 2026 年把主指標從美元換成 kWh 的理由——一個再過五個半月就會觸底的指標,沒辦法拿來衡量接下來三年的進展。
五、EIP-8025 有目的地了,而且上一篇漏掉了一個角色
上一篇對 EIP-8025 的結論是「它不是被拆掉了,是被排進了一個沒有日期的待辦清單」。這句話今天要改。
日期有了:Hegotá。 也就是 Glamsterdam 的下一個硬分叉,時間在 2027 年,走 non-headliner 的窗口。EF 的 zkEVM 部落格對這件事的理由寫得很直白:因為它是完全 opt-in 的改動,納入 Hegotá 的風險很低——沒有啟用任何一種模式的驗證者,在行為、頻寬與 attestation 義務上都看不到變化。
規格這一側的進度也比上一篇描述的成熟得多。CL 與 EL 兩邊的規格都「大致底定」,而且兩邊都已經有能跑的客戶端實作(Prysm 的實作過程有公開的 HackMD 紀錄)。consensus-specs 上的追蹤 issue 是 #5653,到 2026-09-21 還在動,掛著四個 PR:
| PR | 內容 |
|---|---|
| #5593 | 精煉 ProofData 型別與 gossip 驗證邏輯 |
| #5639 | 把 ProofEngine 改成 validation-only |
| #5534 | 定義遞迴的 EIP-8025 execution proof guest |
| #5622 | 移除 EIP-8025 的測試 |
第二個跟第三個值得注意。ProofEngine 改成 validation-only,意思是規格把「產生證明」完全推出協議邊界——協議只定義怎麼驗,不定義怎麼證。而「定義遞迴的 execution proof guest」在處理上一篇第四節第二層扣減講的那件事:多段證明各自證完再遞迴合併,合併那一層需要一個標準化的 guest 程式。上一篇說「遞迴合併沒辦法用調度解決」,現在看到的是他們正在把它標準化,而不是解決它。
更重要的是上一篇漏掉的東西。EIP-8025 定義的不是一個角色,是兩個互相獨立的 opt-in 角色:
| 角色 | 做什麼 | 資源需求 |
|---|---|---|
| prover | 本機組 witness、餵 zkVM、把證明廣播到 execution_proof topic | 極高(多張 GPU) |
| zkAttester(無狀態 attester) | 不跑執行客戶端,收 beacon block + 證明,驗證後投票 | 極低 |
上一篇整篇只寫了 prover 這一側,把 EIP-8025 當成「一個讓 witness 不上 gossip 的機制」。那只是副作用。主作用在 zkAttester:它是那個真正不需要重新執行的節點。 一個 zkAttester 不需要狀態、不需要執行客戶端、不需要 witness,只需要下載一份最多 400 KiB 的證明然後驗證它。
EIP 裡的常數沒有變,再確認一次:
| 常數 | 值 |
|---|---|
MAX_PROOF_SIZE | 409,600 bytes(400 KiB) |
MAX_EXECUTION_PROOFS_PER_PAYLOAD | 4 |
DOMAIN_EXECUTION_PROOF | 0x0D000000 |
STATELESS_INPUT_SCHEMA_ID | 0x1501(Amsterdam revision 1) |
| gossip topic | execution_proof |
| ENR 欄位 | eproof(uint8) |
更正 3:誘因的方向是反的,而且更難修
上一篇引了規格那句「本 EIP 不為產生證明的節點引入任何誘因;基於這個理由,它們被視為利他的」,然後結論是「證明的產生沒有報酬,所以會缺人做」。
規格原文今天一字未改,所以那句引用沒有問題。有問題的是我對它的解讀。EF 部落格補了一句更精確的描述:
proving is altruistic during the optional phase, and missed or late proofs translate into missed timeliness rewards.
注意這句話的主詞轉移。「錯過或遲到的證明會轉化成錯過的及時性獎勵」——被扣獎勵的不是沒有生產證明的 prover,而是選擇了 zkAttester 模式、結果等不到證明的那個驗證者。prover 不生產證明,什麼都不會發生;zkAttester 等不到證明,attestation 遲到,獎勵少拿。
所以誘因結構是這樣的:
| 做這件事的成本 | 做這件事的收益 | 不做的懲罰 | |
|---|---|---|---|
| prover | 極高(多張 GPU、10 kW) | 零 | 零 |
| zkAttester | 極低 | 省下執行與狀態的資源 | 有(等不到證明就遲到) |
成本落在生產者這一側,風險落在消費者這一側,而報酬兩邊都沒有。 這是比「沒人做」更糟的公共財問題版本——它不只缺乏供給誘因,還對需求方收費。一個理性的驗證者在覆蓋率只有 39.7% 的網路裡不會選 zkAttester 模式,因為六成的 slot 他會空等;而如果沒有人選 zkAttester,生產證明的唯一動機——「讓別人省下執行」——也消失了。
這讓上一篇那句「被排進一個沒有日期的待辦清單」要改成一個更精確的說法:日期有了,雞生蛋的問題還在。 EF 自己也把這件事留在門外:
Whether and when proofs eventually become protocol-native and mandatory is a separate decision for a later EIP and a later fork.
要不要、什麼時候讓證明變成協議原生且強制的,是另一個 EIP、另一個分叉的決定。所以上一篇那條 67.7M 的死線——「每個驗證節點自己拿 witness 自己驗」模型下的頻寬上限——到今天仍然有效,而且要到 Hegotá 之後的某個未定分叉才會被真正解除。Hegotá 本身解除不了,它只是把工具放上去。
六、驗證側是第二條斜率向下的線,而且比證明尺寸那條更陡
上一篇找到一條「唯一斜率向下的線」:證明尺寸是常數,所以 bytes/gas 隨 gas limit 反比下降(60M 時 0.0273、200M 時 0.0082、1G 時 0.0016)。EF 的部落格指出第二條:「a 60M-gas block and a 600M-gas block verify in approximately the same time」——驗證時間也是常數。
兩條線的性質不同。證明尺寸的常數性影響頻寬:zkAttester 每個 slot 下載的 bytes 不隨 gas limit 成長。驗證時間的常數性影響 CPU:每個 slot 燒的 cycle 不隨 gas limit 成長。
而對照組——今天的全節點——兩項都是線性的:下載的 payload 線性成長,重新執行的時間線性成長。
所以 zkAttester 相對於全節點的優勢隨 gas limit 線性放大:
| gas limit | 全節點重新執行(相對) | zkAttester 驗證(相對) | 優勢倍數 |
|---|---|---|---|
| 60M | 1.0 | 1.0 | 1× |
| 200M | 3.33 | 1.0 | 3.33× |
| 600M | 10.0 | 1.0 | 10× |
| 1G | 16.67 | 1.0 | 16.7× |
這解釋了一件上一篇沒有想清楚的事:為什麼 EF 願意把一個沒有誘因、沒有人會用的機制排進硬分叉。 因為它的價值不在今天兌現。在 60M 的世界裡 zkAttester 沒有優勢——重新執行一個 60M 的區塊,一台普通機器兩百毫秒就做完了,沒有人需要省這個。在 600M 的世界裡優勢是十倍,而那個世界沒有 zkAttester 就根本不能存在,因為家用機器跑不動 600M 的重新執行。
先把工具放進協議,等 gas limit 長到讓工具變得必要。 順序是反的,但邏輯是對的,而且這也是為什麼「現在沒有誘因」在 EF 看來不是一個要立刻修的 bug——在 gas limit 還沒長起來之前,誘因給了也沒有用。
更準確的讀法因此是:EIP-8025 是一張為 600M 世界準備的門票,提前三到五年買好。 用它評估今天的 gas limit 上限,本來就問錯了時間。
七、EIP-8297:把局部性折扣寫進樹的形狀,而不是寫進 gas 表
上一篇的座標表把「統一二元狀態樹」等同於 EIP-7864。2026-06-11 有一份新的提案,而它的作者名單本身就是訊息:EIP-8297: Partitioned Binary Tree,Vitalik Buterin、Guillaume Ballet、Dankrad Feist、Ignacio Hagopian、Kevaundray Wedderburn、Tanishq Jasoria、Gajinder Singh、Danno Ferrin、Piper Merriam、Gottfried Herold、Wei Han Ng、Carlos Perez——十二個人,基本上是整個 stateless 工作組加上幾個客戶端維護者。Draft。
核心設計是 zone partitioning:每個 key 的第一個 byte 就是 zone 編號。
| zone | 內容 |
|---|---|
0x00 | 帳戶 header |
0x01 | code chunk(content-addressed,內容定址) |
0xFF | storage |
帳戶樹與 storage 樹合併成同一棵,靠 key 的第一個 byte 分區。主要參數:
| 參數 | 值 |
|---|---|
MAX_KEY_LENGTH | 8,192 bytes |
STEM_SUBTREE_WIDTH | 256 |
HEADER_STORAGE_SLOTS | 64 |
ACCOUNT_KEY_LENGTH | 34 bytes |
STORAGE_KEY_LENGTH | 66 bytes |
HEADER_STORAGE_SLOTS = 64 是對上一篇整個論證最直接的一擊。
上一篇的核心張力是這一句:
局部性折扣的大小,和最壞情況 witness 的大小,是同一個數字。
推導過程是:WITNESS_CHUNK_COST = 200 給了局部讀十倍的折扣(第一個付 2,100,後面 255 個各付 200),而攻擊者可以把這個折扣完全兌現——讀滿一個 stem 的 256 個值——所以折扣越大,最壞情況 witness 越大。旋鈕只有一個,往哪邊轉都會痛。
EIP-8297 的 HEADER_STORAGE_SLOTS = 64 做的是另一件事:把前 64 個 storage slot 直接放進帳戶 header 的 stem 裡。
差別在哪裡?這是一個局部性折扣,但它被寫進樹的形狀,不是寫進 gas 表。而樹的形狀有一個 gas 表沒有的性質:
gas 表的折扣: 攻擊者可以構造讀滿 stem 的模式,把折扣兌現到上限
上限 = 256 個 leaf × (有多少個 stem 買得起)
「有多少個 stem 買得起」隨 gas limit 線性成長 → 無界
樹形的折扣: 每個帳戶最多 64 個 slot 享受這個位置
上限 = 64,寫死在常數裡
不隨 gas limit 成長 → 有界
這是上一篇那條等式的一個結構性反例。 折扣的大小與最壞情況的大小,只有在折扣由 gas 定價給出的時候才是同一個數字;當折扣由資料佈局給出時,兩者解耦——因為攻擊者不能「買更多的 64」,64 是每個帳戶的物理上限。
實務上這個選擇也合理:絕大多數合約的熱資料(ERC-20 的 totalSupply、decimals、owner、暫停旗標)都落在前幾十個 slot,因為 Solidity 的儲存佈局從 slot 0 往上排。64 這個數字是拿「真實合約的儲存佈局統計」換來的,不是拿 gas 經濟學推出來的。(「絕大多數」是我自己的推斷,EIP 原文沒給統計,已標存疑。)
0x01 那個 zone 也值得一提:code chunk 是內容定址的,同一份 bytecode 不管被部署幾次,在樹裡只有一份。上一篇算 witness 時把「code 進樹」當成純粹的成本(chunk 化、每個 chunk 一個 leaf),沒有考慮去重。主網上代理合約、工廠產物、相同 implementation 的重複部署極多,去重的實際效果可能很大,但沒有公開統計,已標存疑。
最後一個數字,是本篇裡最需要小心的一個。EIP-8297 的 Motivation 說 MPT「對有效性證明不友善」——RLP 編碼、Keccak hash、code 片段難證——並給出一個最壞情況:存取不同帳戶的 code 時,witness 可以到大約 1.8 GB。
上一篇用的最壞情況是 330 MB。
1.8 GB ÷ 330 MB = 5.45 倍
兩個數字都對,因為它們量的不是同一個攻擊構造:330 MB 來自 jsign 的 stem 讀取構造,1.8 GB 來自 code 存取構造。這件事本身比數字重要:
「最壞情況 witness」不是一個協議常數,是一個構造的函數。 上一篇把 330 MB 當成一個固定的基準,再從它推出 11.24 bytes/gas,再推出所有後續結論。但只要有人想出更壞的構造,這個基準就往上跳——這次跳了 5.45 倍。所有建立在「最壞情況」之上的推導,都繼承了「目前已知的最壞構造」這個時間戳,而不是繼承一個數學上的上界。
這跟第一節那個「過期的分析」是同一種錯誤的兩個面向:一個是把過期的規格當現況,一個是把已知的最壞當理論的最壞。
八、真正的天花板不在我算過的任何一張表上
上一篇與本篇一共算過三個天花板:頻寬(10 MiB p2p)、延遲(10 秒 × 10 kW)、hash(現在已知不是約束)。2026 年 9 月的實際情況是,決定 Ethereum gas limit 的不是這三個裡的任何一個。
Glamsterdam 的 devnet 紀錄:
| devnet | 時間 | 狀況 |
|---|---|---|
| devnet-0 到 devnet-9 | 2026-03 至 2026-09 | 沒有一個達成穩定 finality |
| devnet-8 | — | CL bug:區塊 hash 與 parent 相同 |
| devnet-9 | 2026-09-01 起,1,000 個驗證者 | 仍無法正常 finalize |
| devnet-10 | — | 整個跳過 |
| devnet-11 | 2026-09-14 起,84,000 個驗證者 | 2026-09-16 完成 Glamsterdam transition |
時程滑動:
| 項目 | 原訂 | 現在 |
|---|---|---|
| 主網 | 2026-06 | 最早 2026-12 |
| Sepolia 分叉 | 2026-08-03 | 2026-10-06 |
| Hoodi 分叉 | — | 暫定 2026-10-27 |
四個月內滑了三次。 而造成 finality 失敗的原因是什麼?
- EIP-8037(state creation gas cost increase):執行層與共識層分開實作,造成 finality 失敗
- EIP-7251(MaxEB 驗證者合併,來自 Pectra)與 Glamsterdam 各 EIP 的跨 EIP 交互問題
Christine D. Kim 的評語只有一句:「Glamsterdam still needs a stable devnet.」
沒有一項跟證明、hash、witness 尺寸或頻寬有關。它們全部是工程整合問題——兩個層各自實作同一個 gas 規則時對不上、兩個不同分叉引進的機制在邊界條件互相踩到。
還有一個容易錯過的細節:reference testing 用的是 150M gas,不是 200M。
150 ÷ 60 = 2.5 倍(而非 3.33 倍)
上一篇算的 10 kW 上限 208.6M ÷ 150M = 1.39 → 餘裕 39%
上一篇說「200M 通過,餘裕 4%」,那個緊繃感來自把 200M 當成即將發生的事。實際在測的是 150M,而 150M 在同一套假設下有 39% 的餘裕。上一篇的焦慮提前了至少一個 gas limit 級距。
最後一個交叉驗算,把 09-05 那篇的狀態成長數字接進來。那篇算出 60M gas limit 下每日新增狀態約 326 MiB:
326 MiB × 365 = 118,990 MiB = 116.2 GiB/年
而 Glamsterdam 的文件給出的是:200M gas limit 下,狀態成長上限 120 GiB/年。
120 ÷ 116.2 = 1.033
gas limit 漲 3.33 倍,狀態成長只漲 3.3%。 這就是 EIP-8037 的 reservoir 定價在做的事——它把 3.33 倍的容量成長吸收掉了 97%。(這是一個推論,因為兩個數字來自不同來源、口徑可能不同,已標存疑;但比值離 1.0 這麼近,很難是巧合。)
這讓 devnet 的失敗多了一層諷刺:造成連續失敗的那個 EIP,正是唯一讓 200M gas limit 在狀態成長上說得通的那個 EIP。 它同時是解法與障礙。
收攏成一句話:上一篇的方法論是「找出物理約束,算出數字,得到 gas limit 上限」。它在 2026 年 9 月的適用邊界是——算得出上限,算不出時程。 而過去四個月,決定 Ethereum 什麼時候能跑 200M gas 的,是後者。
九、2026 年 9 月 27 日的座標
| 主題 | EIP / 來源 | 狀態 |
|---|---|---|
| hash function 路線 | Justin Drake(2026-08-13) | L1 放棄 Poseidon,轉向 SHA / BLAKE;理由是二元域 SNARK,不是安全疑慮 |
| 二元域 SNARK | Flock(arXiv 2607.27491,2026-06) | M4 Max 單核 82,100 BLAKE3/s;十核 660,000/s;overhead < 250× |
| 統一二元狀態樹 | EIP-7864 | Draft,正文仍寫 BLAKE3「TBD」、仍列 Poseidon2 為候選——未跟上 08-13 的決定 |
| 分區二元樹 | EIP-8297 | Draft(2026-06-11),12 位作者,zone 分區,HEADER_STORAGE_SLOTS = 64,code 內容定址 |
| 可選執行證明 | EIP-8025 | Draft,目標 Hegotá(2027);CL/EL 規格大致底定,已有客戶端實作;仍無誘因 |
| 狀態建立漲價 | EIP-8037 | Glamsterdam;EL/CL 分裂實作造成 devnet finality 失敗 |
| Glamsterdam 主網 | — | 原訂 2026-06 → 最早 2026-12;Sepolia 2026-10-06 |
| devnet 狀態 | — | 0–9 全部無法穩定 finalize;10 跳過;11(84,000 驗證者)2026-09-16 完成 transition |
| gas limit | — | 現行 60M;測試用 150M;目標 200M;200M 下狀態成長上限 120 GiB/年 |
| 實測覆蓋率 | ethproofs(2026-09-02) | 39.7% 的 slot sub-10-second;單一 cluster 自報 99.7% |
🧠 記
- 2026-08-13,Ethereum Foundation 放棄 Poseidon,L1 轉向 SHA / BLAKE。 理由不是算術 hash 不安全(Drake 明說 Poseidon 沒被攻破、也沒有遷移命令),而是「關鍵不是 SNARK-friendly hash,是 hash-friendly SNARK」——二元擴張域(特徵 2)讓通用 hash 在 SNARK 裡追上算術 hash。上一篇「要速度選 Poseidon2 / 要安全選 BLAKE3」的二選一框架整個失效。
- Flock(Bünz / Rothblum / Wang,2026-06,arXiv 2607.27491)的實測:M4 Max 單核每秒 82,100 次 BLAKE3 compression、42,100 次 SHA-256、30,700 次 Keccak-f[1600] permutation;十核 660,000 次 BLAKE3/s。overhead < 250×(SHA-256 約 170×、Keccak 約 245×);對 Binius64 的 SHA-256 快 8.4×、BLAKE3 快 14×。
- BLAKE3 的 compression 吃 64-byte 區塊,二元樹節點 hash 的輸入正好是 32+32=64 bytes,所以「一個樹節點 = 一次 compression」,兩個數字可直接相除。 上一篇的
1,050,854 次 hash/區塊(200M 最壞情況)÷ 660,000 = 1.59 秒(單核 12.80 秒),十秒預算裡佔 15.9%。 - Amdahl 才是真正的牆:hash 歸零也撐不住 200M。 ZisK 9.62s @ 60M 線性外推到 200M = 32.07 秒,其中 execution 佔 37.7% = 12.09 秒,已超過 10 秒門檻 20.9%;SP1 的比例更糟(execution 55.9% → 19.19 秒)。換樹、換 hash、換證明系統,全部只作用在那 62.3% 上。 算上 Flock 的 7.75 倍改善(= 樹形 2.900 × hash function 2.674,而那個 2.900 從 gas 預算算出來,跟上一篇從樹形算的 2.771 只差 4.7%),總時間 14.67 秒,要進 10 秒 execution 還得再快 1.63 倍;平行效率也終於有實測:
660,000 ÷ (82,100 × 10) = 80.4%。 - 同一件事,cluster 說 99.7%,ethproofs 說 39.7%。 差別在分母:cluster 的分母是「我有跑的區塊」,ethproofs 的分母是「所有區塊」,離線與不符資格的 run 全算失敗。上一篇的
27.1 M gas/s天花板,分母是全網最好的那一台,它算的是能力上限,不是網路現況。另注意39.7% ≈ 2/5,可能不是機率而是普查(五組在跑、兩組達得到,推論、已標存疑)。 - 成本曲線約 2027 年 3 月撞電費地板。 0.04 → 0.00098 只需 5.46 個月。這是 ethproofs 把主指標換成 kWh 的真正理由——一個五個半月後就觸底的指標撐不起接下來三年。
- EIP-8025 有目的地了:Hegotá(2027),走 non-headliner 窗口,理由是完全 opt-in、沒啟用的驗證者「行為、頻寬與 attestation 義務都無變化」。CL/EL 規格大致底定、已有客戶端實作;consensus-specs #5653 到 09-21 仍在動(ProofEngine 改 validation-only、定義遞迴 guest)。
- 上一篇漏掉了 zkAttester。 EIP-8025 是兩個獨立的 opt-in 角色:prover(組 witness、餵 zkVM、廣播)與 zkAttester(不跑執行客戶端,只下載 ≤400 KiB 證明驗證後投票)。真正省下重新執行的是後者,witness 不上 gossip 只是副作用。
- 誘因的方向是反的。 prover 不做:零成本、零懲罰。zkAttester 等不到證明:attestation 遲到、少拿及時性獎勵。成本在生產者、風險在消費者、報酬兩邊都沒有——比「沒人做」更糟的公共財問題;在 39.7% 覆蓋率下理性驗證者不會選 zkAttester,於是 prover 也失去唯一動機。而 EF 明寫「要不要、什麼時候讓證明變成協議原生且強制的,是另一個 EIP、另一個分叉的決定」,所以上一篇那條 67.7M 的死線今天仍然有效,Hegotá 解除不了,只是把工具放上去。
- 驗證時間也是常數:「60M gas 的區塊與 600M gas 的區塊,驗證時間大致相同」。所以 zkAttester 對全節點的優勢隨 gas limit 線性放大:200M 時 3.33×、600M 時 10×、1G 時 16.7×。EIP-8025 是一張為 600M 世界買的門票,提前三到五年——用它評估今天的 gas limit 上限,本來就問錯了時間。
- EIP-8297: Partitioned Binary Tree(Draft,2026-06-11,12 位作者含 Vitalik / Dankrad / Ballet / jsign)。key 第一個 byte 是 zone:
0x00帳戶 header、0x01code chunk(內容定址、可去重)、0xFFstorage。STEM_SUBTREE_WIDTH = 256、HEADER_STORAGE_SLOTS = 64、ACCOUNT_KEY_LENGTH = 34、STORAGE_KEY_LENGTH = 66、MAX_KEY_LENGTH = 8192。 HEADER_STORAGE_SLOTS = 64是上一篇「折扣大小 = 最壞 witness 大小」那條等式的結構性反例。 gas 表給的折扣,攻擊者能買更多 stem 來兌現,上限隨 gas limit 線性成長、無界;樹形給的折扣寫死每帳戶 64 個 slot,有界。折扣搬進資料佈局,兩者就解耦。- 「最壞情況 witness」不是協議常數,是構造的函數。 EIP-8297 給的 code 存取構造是 約 1.8 GB,上一篇用的 stem 讀取構造是 330 MB,差 5.45 倍。兩個都對,量的不是同一件事。所有建立在「最壞情況」之上的推導,繼承的是「目前已知的最壞構造」這個時間戳,不是數學上界。
- Glamsterdam devnet-0 到 devnet-9 沒有一個達成穩定 finality(2026-03 至 2026-09);devnet-8 撞到「區塊 hash 與 parent 相同」的 CL bug;devnet-10 整個跳過;devnet-11 在 2026-09-14 用 84,000 個驗證者(devnet-9 的 84 倍)重啟,09-16 完成 transition。主網從 2026-06 滑到最早 2026-12,四個月滑三次。造成失敗的是 EIP-8037 的 EL/CL 分裂實作與與 Pectra 的 EIP-7251(MaxEB)跨 EIP 交互——沒有一項跟證明、hash、witness 或頻寬有關,全部是工程整合問題。
- 測試用的是 150M,不是 200M。
150 ÷ 60 = 2.5,而上一篇算的 10 kW 上限 208.6M 對 150M 有 39% 餘裕(對 200M 只有 4%)。上一篇的焦慮提前了至少一個 gas limit 級距。 - EIP-8037 的 reservoir 定價吸收掉 97% 的成長:09-05 那篇算 60M 下每日 326 MiB →
× 365 = 116.2 GiB/年,而 Glamsterdam 文件給 200M 下的狀態成長上限是 120 GiB/年,比值 1.033。gas limit 漲 3.33 倍,狀態成長只漲 3.3%(推論,已標存疑)。諷刺的是:讓 200M 在狀態成長上說得通的那個 EIP,正是讓 devnet finalize 不了的那個 EIP。 - 方法論的適用邊界:「找出物理約束 → 算出數字 → 得到 gas limit 上限」這個做法算得出上限,算不出時程。而過去四個月,決定 Ethereum 什麼時候能跑 200M 的是後者。
✍️ 實踐
給你手上任何一份技術推導加一個「來源時間戳」欄位,然後重算一次哪些結論已經過期。 這件事今天做得完,而且本篇的三個更正全部來自同一個疏漏:我引用了正確的文字,但沒有問那段文字是什麼時候寫的。
步驟:
-
把推導裡的每一個外部事實列成一行,標上三欄:數字、來源、來源的發布日期。 不是「我什麼時候讀到的」,是「它什麼時候被寫下來的」。本篇的例子:stateless book 那句「慢一個數量級」的發布日大約在 2025 年年中,而 Flock 是 2026-06——中間差十二個月,而那十二個月裡二元域 SNARK 從論文變成實作。
-
把每一行分成三類:協議常數、實測數字、路線圖判斷。 協議常數(
MAX_PROOF_SIZE = 409600、HEADER_STORAGE_SLOTS = 64)半衰期以年計。實測數字(9.62 秒、82,100 次/秒)半衰期以月計,而且單向——只會變好。路線圖判斷(「Poseidon2 是速度候選」「主網 Q4」)半衰期最短,而且雙向。三類混在同一張表裡,是本篇三個更正的共同根源。 -
對每一個實測數字,問一次「這是誰的分母」。 99.7% 對 39.7% 這個十四倍的落差,不是任何一方說謊,是兩個分母。任何自報的成功率,先找出它把什麼排除在分母外。這一步能抓到的錯,比重算一遍能抓到的多。
-
對每一個「最壞情況」,問一次「這是已知的最壞,還是可證的最壞」。 330 MB 與 1.8 GB 都是「已知的最壞」,差 5.45 倍,下一個構造可能再翻一倍。如果一個數字是「已知的最壞」,它在推導裡應該出現為下界,不是上界。 上一篇把它當上界用,所以所有結論都偏樂觀。
-
最後,對整份推導做一次 Amdahl 檢查:如果我正在優化的那一項變成免費,總體改善多少? 本篇第二節那個
12.09 秒 > 10 秒就是這個檢查的結果——它在三十秒內證明了上一篇花整整一節論證的那個瓶頸,不是真正的瓶頸。這一步應該放在分析的開頭,不是結尾。 如果一項成本歸零之後結論不變,那它就不值得寫一節。
做完這五步,會得到一張帶時間戳的事實表,與一份「哪些結論已過期」的清單。它不會讓推導更正確,但會讓你知道它什麼時候會變得不正確——在一個每六個月翻一次的領域裡,後者比前者有用。
🔗 延伸學習
- EIP-8025: bringing optional execution proofs to Hegotá(Ethereum Foundation zkEVM Blog) — 本篇第五、六節的一手出處。最值得讀的是兩個 opt-in 角色(prover 與 zkAttester)的拆分,以及那句「60M gas 的區塊與 600M gas 的區塊,驗證時間大致相同」——它解釋了為什麼一個今天沒有誘因、沒有人會用的機制值得排進硬分叉。另外注意「proving is altruistic during the optional phase, and missed or late proofs translate into missed timeliness rewards」這句的主詞:被扣獎勵的是等不到證明的 zkAttester,不是不生產證明的 prover。
- How Close Can Proving Get to Computing? Introducing Flock(Succinct) — Flock 的完整 benchmark 與設計動機,論文在 arXiv 2607.27491。除了本篇引用的三組 hash 數字,兩件事值得看:一是「單核對十核」的完整擴展數據(本篇 80.4% 的平行效率就是從這裡算的),二是它對後量子簽章的估算(十核 BLAKE3 約支撐 4,000 TPS,SHA-256 版本三秒內證完一個區塊的五千個簽章)——同一套技術同時作用在狀態樹與簽章兩條線上。
- EIP-8297: Partitioned Binary Tree — 本篇第七節的來源。十二位作者的名單本身就值得看一次。重點讀 zone 分區(
0x00/0x01/0xFF)與HEADER_STORAGE_SLOTS = 64:後者是「把局部性折扣寫進樹的形狀而不是 gas 表」的具體做法,也是上一篇「折扣大小 = 最壞 witness 大小」那條等式的反例。Motivation 裡那個「存取不同帳戶 code 時 witness 可達約 1.8 GB」的數字,跟上一篇用的 330 MB 對照著看,會對「最壞情況」這個詞產生應有的警覺。 - Shipping an L1 zkEVM #2: The Security Foundations(Ethereum Foundation) — 128-bit 可證明安全、300 KB 證明尺寸、
soundcalc與遞迴形式化論證那組時程的一手出處。文中「安全性才是房間裡的大象,許多 STARK-based zkEVM 依賴未經證明的數學猜想,而近期研究已開始推翻其中一些」那句,跟本篇第一節的 Poseidon 決定放在一起讀,會看出 EF 在 2026 年的一致立場:寧可換掉一個跑了八年的方案,也不接受一個需要猜想撐著的安全論證。
💬 問 AI
我在追蹤 Ethereum L1 zkEVM 的三個約束(頻寬、延遲、hash 成本),想確認哪些結論已經過期。請以一手來源(EIP 原文與其 Last Updated、EF 部落格、ethresear.ch、consensus-specs 的 issue/PR、論文的 arXiv/eprint 版本、ethproofs)為依據回答。**每一個數字請同時標明出處與該出處的發布日期**,並嚴格區分「來源明確說的」「你自己推論的」「你查不到的」。查不到就說查不到。
【一、hash function 這條線的現況】
1. 2026-08-13 Justin Drake 關於 Ethereum L1 放棄 Poseidon 的宣布,原文完整說了什麼?二元擴張域(characteristic 2)為什麼改變了權衡?請把 Binius(EUROCRYPT 2025)→ Binius64 → Flock(2026-06)這條技術線的關鍵進展與各自的實測數字列出來。
2. Flock 的 benchmark(M4 Max 單核 82,100 BLAKE3 compressions/s、十核 660,000/s)能不能直接對應到「證明一棵二元 Merkle 樹的節點 hash」?BLAKE3 的 compression 輸入是 64 bytes,二元樹節點是 32+32 bytes——這個對應成立嗎?我漏掉了什麼 overhead(padding、domain separation、chaining value 的語意差異)?另外,EIP-7864 與 EIP-8297 的正文到今天有沒有反映 08-13 的決定?
【二、Amdahl 檢查】
3. 用公開的證明時間拆解(execution vs pre/post state check),算出「如果狀態樹 hash 的成本歸零,200M gas 的區塊證明時間是多少」。請找出所有你能查到的拆解實測(zkVM、版本、硬體、區塊範圍、樣本數),不要只用一份。gas 與證明時間之間是線性的嗎?有沒有公開資料顯示它是超線性的?
4. 承上:要讓 200M gas 進 10 秒,EVM 執行那一段還需要幾倍加速?有哪些工作(RISC-V EVM、precompile 加速、更好的 zkVM ISA、GPU kernel)針對的是這一段而非 hash 那一段?各自宣稱幾倍?
【三、分母問題】
5. ethproofs 在 2026 年的「sub-10-second 成功率」的完整定義是什麼?分母包含哪些 slot?離線、ineligible、失敗各自怎麼計?為什麼單一 cluster 自報 99.7% 而 cohort 統計是 39.7%?
6. 目前有幾組 prover 在 ethproofs 上活躍?RTP Cohort(P99 < 8s + ≥90% 上線)有幾組達標?如果 39.7% 大致等於「達標組數 ÷ 總組數」,這個讀法對嗎?
【四、EIP-8025 的誘因結構】
7. 請完整整理 EIP-8025 兩個 opt-in 角色(prover / zkAttester)的規格定義、資源需求、以及 slot 內的時間安排(證明要在第幾秒之前到?晚到會怎樣?)。zkAttester 等不到證明時具體損失多少獎勵?請引用規格或 spec PR 原文。
8. 這個「成本在 prover、風險在 zkAttester、報酬兩邊都沒有」的結構,是公共財問題的哪一種變體?社群有沒有提出過誘因方案(協議內獎勵、builder 付費、restaking、proof marketplace)?各自卡在哪裡?
9. consensus-specs #5653 底下的四個 PR 各自改了什麼?「把 ProofEngine 改成 validation-only」代表什麼取捨?「定義遞迴 execution proof guest」是在解決遞迴合併的成本,還是只是在標準化它?
【五、最壞情況這個詞】
10. 請列出不同構造下的 Ethereum 最壞情況 witness 尺寸估計(至少含 stem 讀取構造與 code 存取構造),標明各自的 gas limit 前提、樹形前提與出處。有沒有任何一份文件給的是**可證的上界**而不是「目前已知的最壞」?如果沒有,這對所有以最壞情況為基礎的 gas 定價推導意味著什麼?
11. EIP-8297 的 `HEADER_STORAGE_SLOTS = 64` 與 `0x01` zone 的 code 內容定址分別能省下多少?有沒有基於主網真實資料的統計(前 64 個 slot 涵蓋多少比例的熱存取?重複 bytecode 佔多少比例?)?
【六、時程與方法論】
12. 請重建 Glamsterdam 從 devnet-0 到 devnet-11 的時間線與每一次的失敗原因。EIP-8037 的 EL/CL 分裂實作具體是什麼問題?與 EIP-7251(MaxEB)的跨 EIP 交互具體是什麼?這些問題屬於「規格沒寫清楚」還是「實作對不上」?
13. 如果要押注「Ethereum 主網 gas limit 在 2028 年前是否超過 500M」,上面哪幾個數字是決定性的、哪幾個是雜訊?請特別評估「工程整合速度」相對於「證明效率」的權重。
14. 我的做法是「找出物理約束 → 算出數字 → 推出 gas limit 上限」。請給出你能構造的最強反方論證,指出它在哪些情況下會系統性地給出錯誤答案。並指出我上面的問題裡有沒有錯誤的前提、過期的事實、或被我漏掉的重要面向。