明天,也就是 2026-09-29,是 Glamsterdam 客戶端版本必須釋出的死線;Sepolia 的分叉時間訂在 2026-10-06 的 13:53 UTC。中間只有七天,而核心開發流程對測試網分叉的標準建議是十四天。這個折半的複查窗口,是上一篇那個「算得出上限、算不出時程」的結論在現實裡的樣子——時程沒有變得更可預測,它變得更擠。
上一篇的結尾停在一個懸而未決的地方:Glamsterdam 的 devnet-0 到 devnet-9 沒有一個達成穩定 finality,devnet-10 被整個跳過,devnet-11 在 2026-09-14 以 84,000 個驗證者重啟並在 09-16 完成 transition,而造成連續失敗的原因被記成「EIP-8037 的執行層與共識層分裂實作」。那時候還不知道 devnet-11 後來怎麼了。
答案是:devnet-11 完成 transition 之後大約一小時,把 gas limit 從 6,000 萬直接調到 2 億,而且沒有失去 finality。 上一篇整整八節在推導「200M gas 撐不撐得住」,推導出來的答案是撐不住;而在那篇文章寫下之前十一天,一個 84,000 個驗證者的網路已經跑起來了。
這兩件事不矛盾。但要說清楚它們為什麼不矛盾,得先承認上一篇有五個地方錯了,而且錯的方式跟上一篇自己診斷出來的那個病因——「把一個目標當成一個常數」——是同一種。
📖 學
一、devnet-11 跑的 200M,不是我算的那個 200M
先把時間線補完,因為上一篇那張表在 devnet-11 那一列停在「完成 transition」。
| 時點 | 事件 |
|---|---|
| 2026-03 至 2026-09 | devnet-0 到 devnet-9,沒有一個達成穩定 finality |
| devnet-8 | Stefan Starflinger(EF 工程師)找到的 CL bug:一個區塊可以被造出跟它的 parent 完全相同的 hash,他的評語是這「可能在主網造成全網中斷」 |
| 2026-09-01 起 | devnet-9,1,000 個驗證者,仍無法正常 finalize |
| devnet-10 | 整個跳過 |
| 2026-09-14 | devnet-11 上線,84,000 個驗證者 |
| 2026-09-16 | 完成 Glamsterdam transition |
| 約一小時後 | gas limit 6,000 萬 → 2 億,finality 未中斷 |
| 2026-09-17 | ACDC 會議,Potuz 提出 builder Sybil 疑慮(第九節) |
| 2026-09-29 | 客戶端釋出死線 |
| 2026-10-06 13:53 UTC | Sepolia 分叉(ACDC #186 在 09-03 決定) |
| 2026-10-27 | Hoodi 分叉,暫定,待 Sepolia 成功 |
| 2026-12(最早) | 主網 |
主持會議的 Paritosh Jayanti 講過一句很清楚的話:如果下一個 devnet 再失敗,接下來那週的開發者會議就要討論乾脆跳過 10-06 的分叉。devnet-11 沒有失敗,所以 10-06 還在。
更正 1:上一篇說「reference testing 用的是 150M,不是 200M」,這句話從頭到尾是錯的
上一篇第八節有一段很自信的推論:
還有一個容易錯過的細節:reference testing 用的是 150M gas,不是 200M。
然後從這裡推出「上一篇的焦慮提前了至少一個 gas limit 級距」。
150M 這個數字確實存在,但它不是任何一個 devnet 的測試參數。它是 EIP-8037 用來推導 CPSB 這個常數的參考 gas limit,原文寫的是 “reference block gas limit: 150M gas units”。那是一個定價推導裡的輸入,不是一個測試計畫裡的設定。
我把一個經濟學推導的假設值,讀成了工程測試的執行值。而真正在 devnet 上跑的數字,就是 200M。
這個錯誤的代價比看起來大,因為上一篇用它安慰了自己一次:「208.6M ÷ 150M = 1.39,餘裕 39%」。那個 39% 的餘裕不存在,回到 200M 就是原來的 4%。上一篇找到的那個安慰,是從一個讀錯的欄位裡撿來的。
二、但 200M 的 gas limit,不是 200M 的 gas
devnet-11 的成功要怎麼跟上一篇的推導對齊?關鍵在一個非常樸素的區分:gas limit 是一個上限,區塊實際用掉多少 gas 是另一回事。
上一篇第二節整段的 Amdahl 計算,分母是「一個用滿 200M gas 的區塊」。ZisK 的 9.62 秒基準是在 60M gas limit 的主網真實區塊上量的,而主網區塊的平均使用率遠低於 limit。把 9.62 秒乘上 200 ÷ 60 得到 32.07 秒,這一步隱含的假設是「gas limit 變 3.33 倍,實際 gas 用量也變 3.33 倍」。
在 devnet 上,這個假設幾乎確定不成立。一個剛上線兩天、沒有真實使用者、沒有 DeFi、沒有 NFT 鑄造的 devnet,把 gas limit 調到 2 億之後,區塊裡裝的東西不會因此變多。它驗證的是「協議接受 200M 這個參數」,不是「網路能處理 200M gas 的工作量」。
我查不到 devnet-11 在調高 gas limit 之後的實際 gas 使用率,所以這一段是推論,已標存疑。但有一個獨立的數字可以交叉檢查這件事在物理上非做不可:
EIP-8038 的 Motivation 寫得很白,它要把執行吞吐量從現在的 20 Mgas/s 提高五倍到 100 Mgas/s 的目標。用這兩個數字算一個 200M gas 區塊要執行多久:
今天的客戶端: 200,000,000 ÷ 20,000,000 = 10.00 秒
EIP-8038 目標: 200,000,000 ÷ 100,000,000 = 2.00 秒
而 Glamsterdam 的 payload 傳播與驗證窗口是 9 秒(第五節會推這個數字的來源)。
今天的執行客戶端,把一個用滿 200M gas 的區塊單純重新執行一遍,就要 10 秒,超過 9 秒的窗口。 不是證明,是純執行。所以 devnet-11 上那些 200M limit 的區塊,只可能是沒有裝滿的。
這也順便解釋了為什麼 Glamsterdam 的執行層 headliner 是 EIP-7928(Block-Level Access Lists)而不是別的東西:BAL 的整個賣點就是把執行時間從「循序」壓成「平行 IO + 平行 EVM」,而它宣稱主網上有 60% 到 80% 的交易在儲存存取上是互不相交的。五倍的吞吐目標,不是靠單執行緒變快五倍來的。
三、EIP-8037 的 bug 不是 EL/CL 分裂實作,是 EL 自己的兩種同步模式對不上
上一篇把 devnet 失敗的原因寫成:
EIP-8037(state creation gas cost increase):執行層與共識層分開實作,造成 finality 失敗
這句話在二手報導裡到處都是,但它是一個壓縮過頭的描述。EIP 倉庫裡有可追的一手紀錄:ethereum/EIPs#10542,作者 CPerezz,審查者 misilva73 與 gballet,由 jochem-brouwer 在 2026-09-23 關閉。
那個 PR 修了兩件事,第一件就是真正的 bug。
更正 2:分裂發生在 full-sync 與 snap-sync 之間,不在 EL 與 CL 之間
EIP-8037 對 code deposit 有一個去重設計:同樣的 bytecode 被部署第二次的時候不該再收一次新增狀態的錢。要做這件事,節點得回答「這份 code hash 我是不是已經有了」。
原本的規格讓節點查自己的資料庫。問題在於,不同同步模式的節點,資料庫裡的東西不一樣。PR 給出的數字是:一個 full-sync 的節點裡存在約 27,869 份孤兒 bytecode——已經沒有任何活著的帳戶指向它們,但 full-sync 的過程留了下來;snap-sync 的節點從快照重建,這些孤兒不會出現。
於是同一筆交易,在 full-sync 節點上算出來「這份 code 已經存在,不收錢」,在 snap-sync 節點上算出來「這是新的,收錢」。兩邊的 gas_used 不同,state root 不同,共識分裂。
修法是把查表換成明示:只認交易的 access list 裡明寫的 code hash。這樣去重的判斷完全由交易內容決定,不依賴節點的本地資料庫狀態。
這是一個教科書等級的錯誤類型——把「本地可觀測的事實」當成「共識可觀測的事實」——而它跟共識層一點關係都沒有。它是執行層內部兩種歷史路徑造成的狀態差異。
PR 修的第二件事順帶提一句:ACCOUNT_CREATION_COST、HASH_GAS、CODE_DEPOSIT_GAS 這三項後執行成本,現在只在部署成功時收取,理由是「gas 應該反映實際消耗的資源」。
那 EL 跟 CL 真正碰在一起的地方在哪裡?
既然更正了,就得指出真正的跨層介面在哪裡,否則這個更正只是把錯的拿掉,沒有補上對的。
EIP-8037 引進的是一個二維 gas 模型:execution-gas 與 state-gas 兩條互相獨立的計量。而區塊 header 只有一個 gas_used 欄位。規格的處理方式是:
gas_used = max(block_output.block_execution_gas_used,
block_output.block_state_gas_used)
assert gas_used <= block.gas_limit
注意那是 max,不是 sum。 共識層驗證的就是這個 header 欄位。所以 EL 與 CL 之間確實有一條窄縫:兩邊對「這個區塊用了多少 gas」的理解,必須透過一個把二維壓成一維的 max 函數保持一致。任何一邊對哪一個維度該被報出來有不同意見,就是分叉。
這條縫是真的存在,上一篇的描述不算憑空捏造,只是把窄縫當成了裂谷。
EIP-7251(MaxEB)那一項的交互,是我能給的最好推論
上一篇的另一個原因是「與 Pectra 的 EIP-7251(MaxEB)跨 EIP 交互問題」。公開描述只說「初始規格沒有完整考慮 EIP-8037 與 EIP-7251 的驗證者合併之間的交互」,沒有給機制。
我在 EIP-8037 的常數表裡看到一個名字對得起來的東西:
| 常數 | 值 |
|---|---|
SYSTEM_MAX_SSTORES_PER_CALL | 16 |
EIP-7251 的驗證者合併請求,是由共識層驅動、寫進執行層系統合約的佇列——也就是說,共識層會讓執行層做 SSTORE,而這些 SSTORE 沒有一筆交易在付錢。在一個「寫新狀態要收 state-gas」的世界裡,系統呼叫的 SSTORE 該不該收費?收了誰付?不收的話,共識層就有一條免費的狀態寫入通道。
SYSTEM_MAX_SSTORES_PER_CALL = 16 這個常數的存在,強烈暗示答案是「不收費,但硬限制次數」。這個讀法是我自己的推論,EIP 原文沒有把它跟 EIP-7251 連起來,已標存疑。 但如果它對,那麼這才是那條真正的 EL/CL 縫:不是兩邊實作同一條規則對不上,而是共識層有一個繞過執行層 gas 計量的狀態寫入路徑,而二維 gas 模型必須替它開一個帶上限的後門。
四、CPSB = 1530 是被選出來的,不是被推出來的
上一篇第八節做過一個交叉驗算,結論是:
gas limit 漲 3.33 倍,狀態成長只漲 3.3%。 這就是 EIP-8037 的 reservoir 定價在做的事——它把 3.33 倍的容量成長吸收掉了 97%。
當時標了「已標存疑」,理由是「兩個數字來自不同來源、口徑可能不同」,但最後還是寫了一句「比值離 1.0 這麼近,很難是巧合」。
它確實不是巧合。但它也不是「吸收率」。它是一個設計選擇,而且我把它套用在錯的 gas limit 上。
先把 EIP-8037 的推導完整重跑一次,確認 1530 這個數字是怎麼出來的:
目標狀態成長 = 120 GiB/年 = 128,849,018,880 bytes
參考 gas limit = 150,000,000
state-gas 使用率 = 50%
每年區塊數 = 365 × 86,400 ÷ 12 = 2,628,000
每年可用的 state gas = (150,000,000 ÷ 2) × 2,628,000 = 1.971 × 10^14
CPSB = 1.971 × 10^14 ÷ 128,849,018,880 = 1,529.7 → 1,530 gas/byte
對上了。三個輸入:120 GiB/年(目標)、150M(參考 gas limit)、50%(使用率假設)。三個都是人挑的。
更正 3:120 GiB/年 是 150M 下的目標,不是 200M 下的上限
上一篇寫「Glamsterdam 的文件給出的是:200M gas limit 下,狀態成長上限 120 GiB/年」。錯了一個 gas limit 級距。
用同一個 CPSB 與同一個 50% 使用率假設,把 gas limit 換成 200M:
(200,000,000 ÷ 2) × 2,628,000 = 2.628 × 10^14 state gas/年
2.628 × 10^14 ÷ 1,530 = 171,764,705,882 bytes = 159.97 GiB/年
200M 下是 160 GiB/年,不是 120 GiB/年。 差 33.3%,而且這個 33.3% 就是 200 ÷ 150 − 1,一點都不神秘。
把三個更正串起來,重算那個「吸收 97%」:
| gas limit | 不改定價的年成長 | EIP-8037 之後 | 吸收比例 |
|---|---|---|---|
| 60M(今天) | ~116 GiB | — | — |
| 150M | ~290 GiB | 120 GiB | 58.6% |
| 200M | ~387 GiB | 160 GiB | 58.7% |
（60M 的 ~116 GiB 與 200M 的 ~387 GiB 都是 EIP-8037 原文給的數字。387 ÷ 116 = 3.336,而 200 ÷ 60 = 3.333,線性外推在來源自己的數字裡就成立,所以 150M 那一列的 290 GiB 是我用同樣線性關係補的,已標存疑。）
吸收的不是 97%,是 58.7%。 上一篇把數字誇大了 38 個百分點,原因是拿 150M 的目標值去除 60M 的現況值。
而那個 120 ÷ 116.2 = 1.033 的「驚人巧合」,真相很平淡:EF 挑 120 GiB/年 當目標,就是因為它大約等於今天的成長率。 他們選了一個「不要比現在更糟」的目標,然後反解出 CPSB。比值接近 1.0 是這個選擇的定義,不是這個機制的性質。
這是上一篇那個方法論最難防的一種錯:我看到兩個數字比值接近 1,就假設它們之間有因果;實際上它們之間有的是同一個人的意圖。
五、這一次,終於有一個可證的上界
上一篇第七節抱怨過一件事,而且把它寫成整篇的方法論教訓之一:
「最壞情況 witness」不是一個協議常數,是一個構造的函數。（……）所有建立在「最壞情況」之上的推導,都繼承了「目前已知的最壞構造」這個時間戳,而不是繼承一個數學上的上界。
狀態成長這條線可以補上那個缺口,而工具就是第三節那個 max 規則。
gas_used = max(execution_gas_used, state_gas_used) 且 gas_used <= gas_limit,推論是 state_gas_used <= gas_limit。一個區塊在最壞情況下,可以把整個 gas limit 全部花在 state gas 上——因為那兩個維度不相加。
最壞情況年成長 = gas_limit × 2,628,000 ÷ CPSB
60M : 6.0e7 × 2,628,000 ÷ 1,530 = 1.0306e11 bytes = 95.98 GiB/年
150M: 1.5e8 × 2,628,000 ÷ 1,530 = 2.5765e11 bytes = 239.93 GiB/年
200M: 2.0e8 × 2,628,000 ÷ 1,530 = 3.4353e11 bytes = 319.94 GiB/年
200M gas limit 下,狀態成長的硬上界是 319.9 GiB/年。 這個數字有一個上一篇所有「最壞情況」都沒有的性質:它不依賴任何攻擊構造。 它只用了三個協議常數(gas limit、CPSB、每年區塊數)與一條 header 驗證規則。沒有人需要想出一個更壞的讀取模式來把它推高,因為 gas limit 就是上限,而 state-gas 的定價是線性的。
換句話說:目標值 160 GiB/年,硬上界 319.9 GiB/年,剛好兩倍。 那個兩倍就是 50% 使用率假設的倒數。EIP-8037 的目標不是一個保證,是一個對平均行為的預期;協議真正保證的是它的兩倍。
把這條線接到 650 GiB 的效能懸崖上:
| 情境 | 年成長 | 從 461 GiB 到 650 GiB |
|---|---|---|
| 200M,無 EIP-8037 | ~387 GiB | 0.49 年 ≈ 5.9 個月 |
| 200M,EIP-8037,最壞情況 | 319.9 GiB | 0.59 年 ≈ 7.1 個月 |
| 200M,EIP-8037,50% 假設 | 160.0 GiB | 1.18 年 ≈ 14.2 個月 |
| 60M,今天 | ~116 GiB | 1.63 年 |
（461 GiB 這個起點來自一份 2026-09-27 的報導,說 Glamsterdam 之後節點在 pruning 後約 461 GiB。它跟 EIP-8037 引用的「2026-01 約 390 GiB」口徑可能不同——一個是 pruning 後,一個是 Geth 專用節點的資料庫大小——已標存疑。順帶一提,(461 − 390) ÷ 0.67 年 = 106 GiB/年,跟 EIP-8037 說的 ~116 GiB/年 差 8.6%,兩個來源大致對得上,所以口徑差異應該不大。)
最壞情況下,EIP-8037 也只把撞上效能懸崖的時間從 5.9 個月推遲到 7.1 個月。 多出來的 1.2 個月,是 Ethereum 為了一個把所有執行客戶端搞到要重寫 state-creation 邏輯、把 devnet 卡了半年的 EIP,在最壞情況下買到的全部東西。
當然,最壞情況不是常態。50% 假設下是 14.2 個月,那個才是實際預期。但這正是重點:上一篇花了一整節論證「已知的最壞」跟「可證的最壞」不是同一件事;現在拿到一個可證的最壞之後,才看得出來它跟預期值差兩倍,而且兩倍的來源是一個沒人保證的使用率假設。
還有一個要標的存疑:CPSB 計的是「state bytes」這個會計單位(每個 storage slot 算 64 bytes、每個新帳戶算 120 bytes),不是磁碟上真實增加的位元組。真實資料庫因為 trie 節點、索引、寫放大,增加量會高於這個會計值。所以 319.9 GiB/年 是會計上的硬上界,磁碟上的實際成長只會更高,不會更低。
順便記一筆:我在二手描述裡看到另一組參數(300M gas limit、30% state-gas 使用率、60 GiB/年目標),跟 EIP 正文的 150M / 50% / 120 GiB 不一致。用那組參數反解會得到 (3e8 × 0.3) × 2,628,000 ÷ 64,424,509,440 = 3,671 gas/byte,是現行 1,530 的 2.4 倍。我以 EIP 正文為準,那組二手參數標存疑;但如果它是某個修訂方向,CPSB 還有一次 2.4 倍的漲幅在路上。
六、10 秒不是協議常數,9 秒才是
上一篇與前一篇整個延遲分析,分母都是「10 秒」。那個 10 秒從來沒有被追問過它是什麼。
現在追問一次。EIP-7732 的規格裡有兩個用公式寫出來的時間點:
下一個 proposer 驗證 payload 的期限 = SECONDS_PER_SLOT × 2 ÷ INTERVALS_PER_SLOT = 6 秒
其他驗證者驗證 payload 的期限 = SECONDS_PER_SLOT × 3 ÷ INTERVALS_PER_SLOT = 9 秒
SECONDS_PER_SLOT = 12。要讓 12 × 2 ÷ x = 6 且 12 × 3 ÷ x = 9,只有 x = 4。所以 Glamsterdam 下 INTERVALS_PER_SLOT 是 4,每個 interval 3 秒,而今天是 3(每個 interval 4 秒——EIP 原文提到「在 Ethereum 主網是 4 秒」指的正是現行值)。（INTERVALS_PER_SLOT = 4 是我從兩條公式反解的,EIP 摘要裡沒有直接列出這個常數,已標存疑。)
於是 12 秒的 slot 被切成:
| 時點 | 事件 |
|---|---|
| t = 0 秒 | proposer 發出 beacon block,裡面只有 builder 的 bid,沒有 payload |
| t = 3 秒 | attestation 截止——驗證者對共識區塊投票,不需要執行 payload |
| t = 6 秒 | 下一個 slot 的 proposer 必須驗完 payload |
| t = 9 秒 | 其他驗證者必須驗完 payload |
這就是那個被到處引用的「傳播窗口從約 2 秒延長到約 9 秒」。今天的結構裡,payload 必須在 4 秒的 attestation 截止之前傳播並且被執行完,扣掉執行時間,實際留給傳播的大約 2 秒。ePBS 把 attestation 從 payload 上解耦之後,payload 只要在 9 秒之前到就行。
9 ÷ 2 = 4.5 倍
更正 4:上一篇的 10 秒是 EF 的目標,不是協議的期限
EF 的 L1 zkEVM 目標是「99% 的區塊在 10 秒內證完」。那是一個團隊設定的目標,半衰期以月計、可以被改。協議真正寫死的期限是 9 秒,而且它是 SECONDS_PER_SLOT × 3 ÷ INTERVALS_PER_SLOT 這個公式的輸出。
上一篇的三個時鐘被混成了一個:
| 時鐘 | 數值 | 性質 | 半衰期 |
|---|---|---|---|
| EF 的 zkEVM 目標 | 10 秒 | 路線圖判斷 | 月 |
| ePBS 的 payload 期限 | 9 秒 | 協議常數(公式導出) | 年 |
| 今天的實務傳播窗口 | ~2 秒 | 實測 | 月 |
這正是上一篇自己在「實踐」那一節寫的第二步:「把每一行分成三類:協議常數、實測數字、路線圖判斷」。上一篇把這一條當成給讀者的建議,自己沒有對「10 秒」執行。
把 10 換成 9,重算上一篇第二節的 Amdahl:
ZisK 9.62 秒 @ 60M,線性外推到 200M = 32.07 秒
hash 部分 : 32.07 × 0.623 = 19.98 秒 → 套 Flock 的 7.75 倍 → 2.58 秒
execution : 32.07 × 0.377 = 12.09 秒
合計 14.67 秒
對 10 秒: execution 必須壓到 10 − 2.58 = 7.42 秒 → 12.09 ÷ 7.42 = 1.63 倍
對 9 秒: execution 必須壓到 9 − 2.58 = 6.42 秒 → 12.09 ÷ 6.42 = 1.88 倍
1.63 倍變成 1.88 倍。 數值上只差 15%,老實說不多。但機制上的差別是:10 秒可以被 EF 改成 12 秒,9 秒要改得動一次硬分叉。
同樣的 11% 也傳到前一篇那個「需要幾台機器」的數字上:
需求 200M ÷ 10 秒 = 20.00 Mgas/s → 20.00e6 ÷ 735,960 = 27.18 → 27 台
需求 200M ÷ 9 秒 = 22.22 Mgas/s → 22.22e6 ÷ 735,960 = 30.20 → 31 台
而上一篇引的 EF 門檻(不超過 10 kW、不超過十萬美元)只養得起 17 張 RTX 5090。27 台變 31 台,缺口從 1.59 倍變成 1.78 倍。
七、67.7M 那條死線有三個獨立的理由不成立
上一篇對 09-06 那篇留下的 67.7M 頻寬死線做了一個明確的背書:
所以上一篇那條 67.7M 的死線——「每個驗證節點自己拿 witness 自己驗」模型下的頻寬上限——到今天仍然有效,而且要到 Hegotá 之後的某個未定分叉才會被真正解除。Hegotá 本身解除不了,它只是把工具放上去。
這句話裡的每一個子句都要修。
更正 5(a):那個模型沒有被採用
09-06 的推導是:200M gas 下最壞情況 witness 是 29.54 MiB,而 p2p 的實務天花板是 10 MiB,所以 gas limit 只能到 67.7M。這假設完整的無狀態 witness 要上 gossip。
Glamsterdam 上的不是 witness,是 BAL。EIP-7928 給的平均尺寸是 72.4 KiB(壓縮後),拆解如下:
| 組成 | 大小 | 佔比 |
|---|---|---|
| storage writes | ~29.2 KiB | 40.3% |
| storage reads | ~18.7 KiB | 25.8% |
| account addresses | ~7.7 KiB | 10.7% |
| balance diffs | ~6.7 KiB | 9.2% |
| RLP overhead | ~4.4 KiB | 6.1% |
| code diffs | ~1.2 KiB | 1.6% |
| nonce diffs | ~1.1 KiB | 1.5% |
29.54 MiB ÷ 72.4 KiB = 30,248.96 ÷ 72.4 = 417.8 倍
但這個 417.8 倍是不公平的比較:一個是最壞情況,一個是平均。要公平,得自己算一個 BAL 的最壞情況上界。EIP-7928 沒有給固定的 MAX_* 常數,它用 gas 綁住尺寸:
ITEM_COST = 2,000 gas/item
bal_items 上限 = block_gas_limit ÷ 2,000
在 200M 下就是 100,000 個 item。假設最貴的 item 是一次 storage write(32 bytes key + 32 bytes value + 索引約 2 bytes ≈ 66 bytes):
100,000 × 66 bytes = 6,600,000 bytes = 6.29 MiB
在 10 MiB 的天花板之下。 反過來問 BAL 什麼時候會撞到 10 MiB:
10 × 1024 × 1024 ÷ 66 = 158,875 個 item
158,875 × 2,000 = 317,750,000 gas ≈ 318M
BAL 路線的頻寬天花板大約在 318M gas,witness 路線是 67.7M,差 4.69 倍。(每個 item 66 bytes 是我自己估的,RLP 的每帳戶 address 開銷沒有算進去,真實值會更大一些、天花板會更低一些,整段已標存疑。但數量級的結論是穩的:BAL 不是 witness,它便宜一到兩個數量級。)
要講清楚代價:BAL 便宜是因為它攜帶的資訊比 witness 少。BAL 告訴你哪些帳戶與 slot 被碰到、變成什麼值;witness 還要附上 Merkle 證明,讓你不用有狀態就能驗。BAL 讓有狀態的節點可以平行執行,它不讓無狀態的節點可以驗證。所以 67.7M 那條線不是被繞過,是那條路暫時沒走——無狀態驗證被推給了 EIP-8025 的 zkAttester(證明取代 witness),而不是 witness 本身。
更正 5(b):10 MiB 這個數字的出處被 Glamsterdam 拒絕了
09-06 那篇說「EIP-7782 給的 p2p 實務天花板 10 MiB」。EIP-7782 的原文是:「在沒有實質網路層改動的情況下,把區塊尺寸增加到 10 MiB 以上是不切實際的。」這句話今天仍然成立。
但 EIP-7782 本身——把 slot 從 12 秒縮到 6 秒——被 Glamsterdam 拒絕納入,留給 Hegotá 或更後面的升級,理由是要先看 ePBS 與 BAL 在更高 gas limit 下跑起來的樣子。
這件事有一個很漂亮的反諷:上一篇擔心的是「時程滑動」,而 EIP-7782 的落選正好是時程管理在運作——先做會放寬約束的那個(ePBS),再做會加緊約束的那個(6 秒 slot)。如果兩個同時做,傳播窗口會先被砍半再被拉長,誰也不知道最後淨值是多少。
而 EIP-7782 本來就註明它會把 gas limit 與 blob target 各砍一半,「重新解讀為每 12 秒的 gas」。也就是說,它從來不是一個提升吞吐的提案,它是一個把同樣的吞吐攤得更平的提案。 09-06 那篇把它的 10 MiB 當成「Ethereum 的頻寬上限」,但它在那份 EIP 裡的角色是「我們不打算突破的那條線,所以我們改用頻率」。
更正 5(c):Glamsterdam 正在把 10 MiB 這條線重新定價,而數字是 6.4 倍
EIP-7976(Increase Calldata Floor Cost)把 calldata 的地板價從 10/40 gas per zero/non-zero byte 改成 64/64 gas per byte。它的 Motivation 裡有一句可以直接驗算的話:
在 64/64 定價下,一個 10 MiB 的未壓縮執行 payload 需要約 671M gas,而不是現行定價下的約 105M gas。
驗算:
10 MiB = 10 × 1024 × 1024 = 10,485,760 bytes
現行(全零 byte,最便宜的構造): 10,485,760 × 10 = 104,857,600 gas ✓ ≈ 105M
EIP-7976(64/64) : 10,485,760 × 64 = 671,088,640 gas ✓ ≈ 671M
671,088,640 ÷ 104,857,600 = 6.4 倍(= 64 ÷ 10)
一位小數都不差。這代表:把「10 MiB 的實務天花板」換算成 gas limit,在今天的定價下答案是 105M,在 Glamsterdam 的定價下是 671M。
還有一個補刀:EIP-7981 把 access list 也按 64 × bytes 收費(每個地址 1,280 gas、每個 storage key 2,048 gas),原文說這「把最壞情況區塊尺寸再降低約 21%」,理由是 access list 原本可以繞過 EIP-7623 的地板定價、用 EVM gas 換資料足跡。
671M × 1.21 ≈ 812M ← 把 7981 堵住的漏洞也算進去的等效 gas limit
（這個 1.21 的乘法方向是我自己接的:7981 讓同樣的 gas 買到更少的 bytes,所以同樣的 bytes 要更多 gas。EIP 原文只給了「最壞區塊尺寸降 21%」,沒有給這個乘法,已標存疑。）
把三條放在一起:
| 約束的版本 | 等效 gas limit 天花板 |
|---|---|
| 09-06 的 witness 模型 + 10 MiB | 67.7M |
| BAL 模型 + 10 MiB(我自己估) | ~318M |
| calldata 模型,現行定價 | ~105M |
| calldata 模型,EIP-7976 定價 | ~671M |
上一篇說 67.7M「到今天仍然有效」,而且要等 Hegotá 之後。實際上 Glamsterdam 這一個分叉同時做了三件事把它推開:換掉資料結構(BAL)、拉長傳播窗口(ePBS 的 9 秒)、重新定價資料(EIP-7976 / 7981)。 沒有一件要等到 Hegotá。
八、EIP-8038:把 09-06 篇所有的 gas 常數換掉,除了關鍵的那一個
09-27 那篇第三節有一條推導,分母是 2,100 gas 這個 cold storage 讀取的價格:
200,000,000 ÷ 2,100 = 95,238 次存取
EIP-8038 把幾乎每一個狀態相關的價格都改了,所以我原本以為這條推導會整個作廢。結果查完的答案是:沒有。
| 參數 | 現行 | EIP-8038 | 變化 |
|---|---|---|---|
COLD_STORAGE_ACCESS | 2,100 | 2,100 | 不變 |
WARM_ACCESS | 100 | 100 | 不變 |
COLD_ACCOUNT_ACCESS | 2,600 | 3,000 | +15.4% |
ACCOUNT_WRITE | 6,700 | 9,000 | +34.3% |
STORAGE_WRITE | 2,800 | 10,000 | +257% |
CREATE_ACCESS | 7,000 | 12,000 | +71.4% |
STORAGE_CLEAR_REFUND | 4,800 | 11,616 | +142% |
ACCESS_LIST_ADDRESS_COST | 2,400 | 2,900 | +21% |
ACCESS_LIST_STORAGE_KEY_COST | 1,900 | 2,000 | +5% |
讀沒有漲,寫漲了 3.57 倍。 這是一個很明確的立場:EIP-8038 的原文自己說了,方向是「計算變便宜,永久狀態變貴」。而 COLD_STORAGE_ACCESS 保持 2,100 的理由,大概是因為 BAL 讓讀取可以平行預取,讀的邊際成本本來就該下降——維持不變已經是相對降價。
所以 09-27 第三節那個 95,238 次存取的算式,在 Glamsterdam 之後仍然成立。這是本篇唯一一個「我預期會被推翻但沒有被推翻」的推導,值得單獨記一筆,因為一份誠實的更正清單裡應該同時包含「查了之後發現原本是對的」。
但 1.8 GB 那個 code 存取構造會變。EIP-8297 的最壞情況構造是存取不同帳戶的 code,而那條路徑吃的是 COLD_ACCOUNT_ACCESS:
同樣的 gas 預算,能做的 cold account access 變成 2,600 ÷ 3,000 = 86.67%
1.8 GB × 0.8667 = 1.56 GB
最壞情況 witness 從 1.8 GB 降到約 1.56 GB,降幅 13.3%。(這是把 witness 尺寸對 cold account access 次數當成純線性,已標存疑。)一個 15% 的漲價,買到 13% 的最壞情況縮減——這個兌換率說明 EIP-8038 根本不是為了壓 witness 設計的,壓 witness 只是副作用。
把 8037 與 8038 疊起來:開一個新 storage slot 要多少錢
兩個 EIP 刻意分工:8038 管 execution-gas 的 access 與 write,8037 管 state-gas 的創造。疊起來才是使用者看到的價格。
今天,冷的 SSTORE 從 0 寫成非 0:
cold storage access 2,100
SSTORE set 20,000
合計 22,100 gas
Glamsterdam 之後:
cold storage access 2,100 (execution gas)
STORAGE_WRITE 10,000 (execution gas)
state 創造 64 × 1,530 = 97,920 (state gas)
合計 110,020 gas
110,020 ÷ 22,100 = 4.978 倍
新帳戶:
今天: 2,600 + 25,000 = 27,600 gas
之後: 3,000 (cold account access)
+ 9,000 (ACCOUNT_WRITE)
+ 120 × 1,530 = 183,600 (state gas)
= 195,600 gas
195,600 ÷ 27,600 = 7.087 倍
EIP-8037 自己列的例子是「新帳戶約 7 倍、新 storage slot 約 5 倍」,跟這兩個數字對得上,差別只在它只數 state gas 那一項。用 0.08 Gwei 的 base fee 換算,開一個新 slot 大約 0.0000088 顆 ETH,開一個新帳戶大約 0.0000156 顆 ETH——絕對金額仍然小到沒有人會注意,這也是為什麼 EF 敢一次漲五到七倍。
九、合約上限提到 64 KiB,同一個分叉把它定價成半個區塊
EIP-7954 把 MAX_CODE_SIZE 從 24,576 bytes(24 KiB)提到 65,536 bytes(64 KiB),MAX_INITCODE_SIZE 從 48 KiB 提到 128 KiB。作者是 Giulio Rebuffo 與 Ben Adams,Review 狀態,2025-06-09 建立。理由很單純:24 KiB 對複雜合約太緊。
但 EIP-8037 同時把 code deposit 的價格從 200 gas/byte 換成 CPSB = 1,530 gas/byte。把兩個放在一起:
今天部署一個 24 KiB 合約:
24,576 × 200 = 4,915,200
+ GAS_CREATE 32,000
= 4,947,200 gas → 佔 60M 區塊的 8.25%
Glamsterdam 部署一個 24 KiB 合約(EIP-8037 原文的例子):
(24,576 + 120) × 1,530 = 37,784,880 gas → 佔 200M 區塊的 18.9%
Glamsterdam 部署一個 64 KiB 合約(新上限):
(65,536 + 120) × 1,530 = 100,453,680 gas → 佔 200M 區塊的 50.2%
一個用滿新上限的合約,單獨佔掉半個區塊。 加上執行 gas(6 × ceil(65536 ÷ 32) = 12,288,相對之下可以忽略),以 0.08 Gwei 計約 0.008 顆 ETH。
這不是矛盾,是一個很清楚的設計語言:上限從「協議禁止」變成「市場定價」。 今天的 24 KiB 是一堵牆,撞上去就是部署失敗;Glamsterdam 之後的 64 KiB 是一個價目表,你想要就付錢,而價錢被設計成大到會讓你先想想能不能拆成兩個合約。
用一張表把「牆」換成「價」這件事量化:
| 今天 | Glamsterdam | |
|---|---|---|
| 最大合約 | 24 KiB | 64 KiB |
| 每 byte code 價格 | 200 gas | 1,530 gas |
| 部署滿版合約 | 4,947,200 gas | 100,453,680 gas |
| 佔一個區塊 | 8.25%(60M) | 50.2%(200M) |
| 一個區塊最多能塞幾個滿版部署 | 12.1 個 | 1.99 個 |
12.1 → 1.99,降了 6.1 倍。gas limit 漲了 3.33 倍、合約上限漲了 2.67 倍,而一個區塊能容納的滿版部署數量反而掉到六分之一。這就是 EIP-8037 真正在做的事,而它做得比「吸收 58.7% 的狀態成長」這句話聽起來兇猛得多。
十、真正在擋 10-06 的,是一個不用花錢的身分
上一篇第五節花了很長的篇幅論證 EIP-8025 的誘因結構壞掉:「成本落在生產者這一側,風險落在消費者這一側,而報酬兩邊都沒有。」
2026-09-17 的 ACDC 會議上,共識層開發者 Potuz 提出了同一個結構的鏡像。
在 ePBS 下,builder 提交一份 SignedExecutionPayloadBid,proposer 把它放進 beacon block,bid 的金額立刻從 builder 的質押餘額扣除。之後 builder 才揭露完整的 payload。這個設計的整個安全性建立在「bid 的金額是真錢」上。
而在測試網上,ether 沒有價值。Potuz 的說法是:
I can just spin up a thousand builders.
以及:
Any teenager can do this.
攻擊流程:開一堆用完即丟的 builder 身分,出天價 bid 贏下拍賣,贏了之後不交 payload,身分燒掉換下一個。主網上這會很貴,測試網上這是免費的。EIP-7732 的相關常數:
| 常數 | 值 |
|---|---|
PTC_SIZE | 512 |
BUILDER_REGISTRY_LIMIT | 2^40 = 1,099,511,627,776 |
MIN_BUILDER_WITHDRAWABILITY_DELAY | 64 epochs |
BUILDER_PAYMENT_THRESHOLD_NUMERATOR / DENOMINATOR | 6 / 10 |
MAX_PAYLOAD_ATTESTATIONS | 4 |
DOMAIN_BEACON_BUILDER | 0x0B000000 |
DOMAIN_PTC_ATTESTER | 0x0C000000 |
BUILDER_REGISTRY_LIMIT = 2^40 是一兆多個 builder 槽位。在一個 ether 免費的網路上,這個常數的實際意義是「無限」。
這件事跟上一篇的 EIP-8025 分析是同一個問題的兩面:
| EIP-8025 的 prover | ePBS 測試網的 builder | |
|---|---|---|
| 參與成本 | 極高(多張 GPU、10 kW) | 零(免費身分) |
| 不參與的懲罰 | 零 | — |
| 失敗的後果 | 沒人生產證明 | 人人都能癱瘓拍賣 |
當一個角色的參與成本趨近於零,你同時失去供給誘因跟 Sybil 抵抗;當它趨近於無限,你只失去供給誘因。 上一篇只看了後半段,因為它只看了 prover。而 Glamsterdam 的 headliner 恰好是一個把參與成本設計成「由質押金額決定」的機制——在有價值的網路上它是安全的,在測試網上它是敞開的。
還有一層反諷值得停一下:第六節說 ePBS 把 payload 窗口從 2 秒拉到 9 秒、這是 zkEVM 路線圖的關鍵里程碑;第十節說 ePBS 開了一個免費的 Sybil 面。是同一個 EIP。 上一篇的座標表把 EIP-7732 當成背景,今天它同時是最大的解法跟最大的風險。
Potuz 自己也說明了邊界:他擔心的是可用性中斷,不是主網盜竊——主網的經濟成本自然會壓制這種行為。所以這是一個測試網專屬的問題。但測試網專屬的問題會延後主網,而延後主網正是上一篇整節在講的那件事。
十一、證明能力正在被 gas limit 甩開
上一篇留了一組數字:ethproofs 在 2026-09-02 的統計,所有被評估的 slot 裡只有 39.7% 達成 sub-10-second 的成功證明,而單一 cluster 自報 99.7%。那個 39.7% 是在 60M 的 gas limit 上量的。
現在 devnet-11 把 limit 推到 200M,而證明那一側什麼都沒變。把兩條線畫在一起:
| 60M | 200M | |
|---|---|---|
| ZisK 4×5090 的 P99(外推) | 9.62 秒 | 32.07 秒 |
| 對 9 秒窗口的超出倍數 | 1.07× | 3.56× |
| ethproofs 的 sub-10s 覆蓋率 | 39.7% | ? |
| 原生重新執行(20 Mgas/s) | 3.0 秒 | 10.0 秒 |
| 原生重新執行(100 Mgas/s 目標) | 0.6 秒 | 2.0 秒 |
32.07 ÷ 9 = 3.563。今天全網最快的那一組叢集,在 200M 上比 9 秒的窗口慢 3.56 倍。 而覆蓋率那一格填不出來,因為在 200M 上沒有任何一組達標,分子會是 0。
這件事的形狀值得講清楚。上一篇的結論是「hash 不是綁住的那個約束,Amdahl 才是」,而今天多了一層:Ethereum 正在用一條不需要證明的路徑(BAL + 平行執行 + ePBS 的 9 秒窗口)把 gas limit 推上去,而證明那條路徑還停在 60M 的世界。 兩條線在 2026 年 9 月正式分岔。
分岔本身不是壞事,甚至可能是刻意的。EIP-8025 的目標分叉是 Hegotá(2027),它是 opt-in 的,沒有任何東西強迫證明覆蓋率跟上 gas limit。上一篇算過的那件事在這裡變得更明確:
zkAttester 相對於全節點的優勢 = gas limit 的倍數
60M → 200M: 優勢從 1× 變成 3.33×
gas limit 漲得越快,zkAttester 的價值越高,同時它能達成的比例越低。 這兩個效應方向相反但都被同一個變數驅動,而上一篇只看到了前者(「EIP-8025 是一張為 600M 世界買的門票」)。後者是:門票的價格也在漲。
要標一個誠實的保留:把 9.62 秒線性外推到 200M 的那一步,在第二節已經被質疑過——devnet 的 200M 區塊不是滿的,主網未來的 200M 區塊也未必會滿。如果主網的 gas 使用量不隨 limit 等比成長,那麼「證明時間」的實際成長會遠小於 3.33 倍。這一整節的悲觀程度,完全取決於那個我查不到的數字:limit 調高之後,區塊真的會裝更多嗎?已標存疑。
歷史上的答案是會:09-05 那篇引的數字是 gas limit 從 30M 調到 60M 之後,每日新增狀態從 105 MiB 跳到 326 MiB,3.1 倍,而不是 2 倍。使用量不只跟上了 limit,還超過了——因為便宜的執行 gas 被換成了昂貴的狀態寫入。如果 60M → 200M 也是這個形狀,那麼 3.33 倍還是低估。
而這恰好就是 EIP-8037 存在的理由:上一次 gas limit 翻倍時,使用量的成長超過了 limit 的成長,而超出的部分全部落在最貴的資源上。 EIP-8037 把那個資源漲價五到七倍,就是為了讓這一次不要重演。它成不成功,要等主網跑起來才知道——而這是本篇唯一一個真正需要等時間、不能靠查資料解決的問題。
十二、三個測試面,三個分母
上一篇把「devnet 沒有一個達成穩定 finality」當成整個故事。查完之後,Glamsterdam 同時跑著三條測試線,各自量不同的東西:
| 測試面 | 量什麼 | 誰參加 | 對抗性 |
|---|---|---|---|
| devnet-0 ~ 11 | 誠實負載下的 finality 與客戶端互通 | 受邀的客戶端團隊 | 明確排除蓄意攻擊 |
| Platåberget | 工具鏈、應用相容性、破壞性改動 | 公開可加入,驗證者集較小 | 對抗性實驗留在這裡 |
| non-finality devnet | 病態共識情境 | 客戶端團隊 | 就是要它不 finalize |
Platåberget 的 Glamsterdam 分叉時間是 2026-08-20,公告在 2026-08-17,涵蓋 EIP-7732、EIP-7928、EIP-8007、EIP-7954、EIP-7688、EIP-2780、EIP-8037、EIP-8038,目標是「約 200M gas 的地板」。公告裡還寫了「一個月內會跟上一個 non-finality devnet,測試病態共識情境」。
所以「devnet 連續九次 finalize 不了」這句話的分母是第一條線。它不包含 Platåberget 的公開測試,也不包含那個刻意不 finalize 的 devnet(在那裡不 finalize 是成功不是失敗)。上一篇把三條線的其中一條當成全部,得到的悲觀程度被高估了。
這正是上一篇「實踐」那一節的第三步——「對每一個實測數字,問一次『這是誰的分母』」——的直接應用。而今天一共可以應用三次:
第一次:Nethermind 的 2,926 Mgas/s。 devnet-11 期間,Nethermind 通過全部 2,302 項效能測試,在 3 分 15 秒內處理 5,707 億 gas。
570,700,000,000 ÷ 195 秒 = 2,926,666,667 gas/s = 2,926.7 Mgas/s
每項測試: 570.7e9 ÷ 2,302 = 247,914,857 gas,耗時 195 ÷ 2,302 = 84.7 ms
而 EIP-8038 說今天的執行吞吐是 20 Mgas/s,目標是 100 Mgas/s。
2,926.7 ÷ 20 = 146.3 倍
2,926.7 ÷ 100 = 29.3 倍
同一個網路,同一個月份,一個說 2,927 Mgas/s,一個說 20 Mgas/s。 這不是誰說謊,是兩個分母:效能測試跑的是合成區塊,狀態在快取裡、磁碟 IO 被排除、平行度拉滿;EIP-8038 的 20 Mgas/s 是主網真實區塊在真實狀態上的端到端速率,包含冷狀態的磁碟隨機讀。這跟上一篇那個「99.7% 對 39.7%」是完全同一個形狀的落差,只是倍數從 2.5 倍變成 146 倍。
第二次:「ETH 轉帳便宜 71%」。 EIP-2780 把 21,000 的固定 intrinsic gas 拆成有依據的組件(基礎交易成本、收款帳戶存取、價值寫入、EIP-7708 的轉帳 log)。一般報導寫「ETH 轉帳成本降低最多 71%」。查原文:
一般 ETH 轉帳(收款帳戶已存在): 21,000 gas(不變)
零值交易 : 15,000 gas
自己轉給自己 : 12,000 gas
15,000 ÷ 21,000 = 71.4%
12,000 ÷ 21,000 = 57.1%
那個「71%」是「降到 71%」,不是「降了 71%」。 實際降幅是 28.6%(零值)與 42.9%(自轉)。一個介系詞的誤譯把數字誇大了 2.5 倍,然後它被複製到好幾家媒體。（「降到而非降了」是我的判讀,基於 15,000 ÷ 21,000 = 71.4% 這個過於精確的巧合,已標存疑。）
第三次:devnet-11 的 200M。 第二節已經講過:gas limit 是 200M,區塊裡裝了多少 gas 是另一件事。
三次分母問題,三種形態:合成 vs 真實、降到 vs 降了、上限 vs 用量。上一篇把「問誰的分母」寫成一條建議,今天它抓到的錯比重算抓到的多——就像上一篇自己預言的那樣。
十三、2026 年 9 月 28 日的座標
| 主題 | EIP / 來源 | 狀態 |
|---|---|---|
| devnet-11 | Glamsterdam | 2026-09-14 上線、84,000 驗證者、09-16 完成 transition、約一小時後 60M → 200M,finality 未中斷 |
| devnet 失敗主因 | ethereum/EIPs#10542 | full-sync 與 snap-sync 的分歧(約 27,869 份孤兒 bytecode)+ 與 EIP-7251 的交互;2026-09-23 關閉 |
| 二維 gas | EIP-8037 | CPSB = 1,530;header gas_used = max(execution, state);state gas ≤ gas limit ⇒ 200M 下狀態成長硬上界 319.9 GiB/年 |
| 狀態成長目標 | EIP-8037 | 120 GiB/年 @ 150M;200M 下是 160 GiB/年;不改定價則 ~387 GiB/年;懸崖 650 GiB |
| 狀態存取漲價 | EIP-8038 | STORAGE_WRITE 2,800 → 10,000(+257%);COLD_STORAGE_ACCESS 維持 2,100;目標 20 → 100 Mgas/s |
| ePBS | EIP-7732 | headliner;INTERVALS_PER_SLOT = 4 ⇒ attest 3 秒 / 次 proposer 6 秒 / 其他 9 秒;payload 窗口 ~2 秒 → ~9 秒 |
| 區塊級存取清單 | EIP-7928 | headliner;平均 72.4 KiB(壓縮);ITEM_COST = 2,000;60–80% 儲存存取互不相交 |
| calldata 重新定價 | EIP-7976 | 10/40 → 64/64;10 MiB payload 從 105M gas 變 671M gas(6.4 倍) |
| access list 重新定價 | EIP-7981 | 64 × bytes;最壞區塊尺寸 −21% |
| 合約上限 | EIP-7954 | 24 KiB → 64 KiB;但滿版部署要 100,453,680 gas = 半個 200M 區塊 |
| 6 秒 slot | EIP-7782 | 被 Glamsterdam 拒絕,留待 Hegotá 之後;「10 MiB 以上不切實際」那句話仍有效 |
| 測試面 | devnet / Platåberget / non-finality devnet | 三條線三個分母;devnet 明確排除蓄意攻擊 |
| 最新風險 | Potuz,2026-09-17 ACDC | 測試網 ether 無價 ⇒ 免費 builder 身分 ⇒ ePBS 拍賣可被癱瘓 |
| 時程 | — | 客戶端死線 2026-09-29;Sepolia 2026-10-06 13:53 UTC(複查窗口 7 天 vs 標準 14 天);Hoodi 2026-10-27;主網最早 2026-12 |
| 可選執行證明 | EIP-8025 | 仍為 Hegotá(2027);今天的 9 秒窗口是為它鋪的路 |
🧠 記
- devnet-11 在 2026-09-16 完成 Glamsterdam transition 之後約一小時,把 gas limit 從 6,000 萬調到 2 億,沒有失去 finality。 84,000 個驗證者。這回答了上一篇留下的未解問題,但它回答的不是上一篇以為的那個問題——200M 的 gas limit 不是 200M 的 gas 區塊,而且 devnet 的範圍明確排除蓄意攻擊。
- 更正 1:「reference testing 用的是 150M 不是 200M」整句是錯的。 150M 是 EIP-8037 推導
CPSB用的參考 gas limit(一個定價假設),不是任何 devnet 的測試參數。devnet-11 測的就是 200M。上一篇靠這個誤讀得到的「餘裕 39%」不存在,回到 200M 的 4%。 - 更正 2:EIP-8037 的 bug 不是 EL/CL 分裂實作,是 EL 內部 full-sync 與 snap-sync 的分歧。 一手來源是 ethereum/EIPs#10542(CPerezz 作,misilva73 / gballet 審,jochem-brouwer 於 2026-09-23 關閉):full-sync 節點裡有約 27,869 份孤兒 bytecode,讓「這份 code 是否已存在」的資料庫查詢不具決定性,兩種同步模式算出不同的 gas_used 與 state root。修法是改成只認交易 access list 裡明寫的 code hash。另外
ACCOUNT_CREATION_COST/HASH_GAS/CODE_DEPOSIT_GAS改成只在成功時收費。 - 真正的 EL/CL 窄縫在 header:
gas_used = max(execution_gas_used, state_gas_used),且gas_used <= gas_limit。是max不是sum。 共識層驗的就是這個把二維壓成一維的欄位。與 EIP-7251(MaxEB)的交互,我的推論是共識層驅動的系統呼叫會做沒人付錢的 SSTORE,故 EIP-8037 有SYSTEM_MAX_SSTORES_PER_CALL = 16這個硬上限(推論,已標存疑)。 - 更正 3:120 GiB/年 是 150M 下的目標,不是 200M 下的上限。
CPSB = 1,530的推導是(150,000,000 ÷ 2) × 2,628,000 ÷ 128,849,018,880,三個輸入(120 GiB 目標、150M 參考、50% 使用率)全是人挑的。同樣公式代 200M 得 159.97 GiB/年。上一篇的「吸收 97%」實際是 58.7%(1 − 160 ÷ 387),誇大了 38 個百分點。而120 ÷ 116.2 = 1.033不是巧合也不是吸收率——EF 就是照「大約等於今天」挑的 120,比值接近 1 是意圖,不是性質。 - 這一次有可證的上界了。 因為
state_gas_used <= gas_limit,gas_limit × 2,628,000 ÷ 1,530就是硬上界:60M 下 95.98 GiB/年、150M 下 239.93 GiB/年、200M 下 319.94 GiB/年。不依賴任何攻擊構造,只用三個協議常數。目標值 160 GiB 與硬上界 320 GiB 剛好差兩倍,那個兩倍就是 50% 使用率假設的倒數。最壞情況下 EIP-8037 只把撞上 650 GiB 懸崖的時間從 5.9 個月推到 7.1 個月(50% 假設下是 14.2 個月)。注意 CPSB 計的是會計 state bytes,磁碟實際成長只會更高。 - 更正 4:10 秒是 EF 的目標,9 秒才是協議期限。 EIP-7732 用公式給出
SECONDS_PER_SLOT × 2 ÷ INTERVALS_PER_SLOT = 6與× 3 ÷ = 9,反解出INTERVALS_PER_SLOT = 4(今天是 3),於是 12 秒 slot 切成 attest 3 秒 / 次 proposer 6 秒 / 其他驗證者 9 秒,payload 傳播窗口從 ~2 秒變 ~9 秒(4.5 倍)。上一篇把三個時鐘(EF 目標 10 秒、協議 9 秒、實務 2 秒)混成一個。重算:execution 要再快 1.63 倍 → 1.88 倍;機器需求 27 台 → 31 台(22.22 Mgas/s ÷ 735,960),對 17 張卡的缺口從 1.59 倍變 1.78 倍。 - 更正 5:67.7M 那條死線有三個獨立的理由不成立,而且都在 Glamsterdam 裡、不用等 Hegotá。(a)那個模型沒被採用——上的是 BAL(平均 72.4 KiB 壓縮)不是 witness(200M 最壞 29.54 MiB),差 417.8 倍;用
ITEM_COST = 2,000自算 BAL 的頻寬天花板約 318M gas(已標存疑)。但要講清代價:BAL 讓有狀態節點平行執行,不讓無狀態節點驗證。(b)10 MiB 出自 EIP-7782,而 EIP-7782 被 Glamsterdam 拒絕,且它本來就要把 gas limit 砍半、是「攤平」不是「提升」。(c)EIP-7976 把 calldata 地板從10/40改成64/64,10 MiB payload 從 104,857,600 gas 變成 671,088,640 gas,整整 6.4 倍(= 64 ÷ 10,驗算一位小數不差);EIP-7981 再把 access list 按64 × bytes收,最壞區塊尺寸再 −21%。 - EIP-8038:讀沒漲,寫漲 3.57 倍。
COLD_STORAGE_ACCESS維持 2,100(所以 09-27 第三節的 95,238 次存取推導仍然成立——這是本篇唯一一個「我以為會被推翻但沒有」的項目);STORAGE_WRITE2,800 → 10,000(+257%);COLD_ACCOUNT_ACCESS2,600 → 3,000;CREATE_ACCESS7,000 → 12,000;STORAGE_CLEAR_REFUND4,800 → 11,616。目標是把執行吞吐從 20 Mgas/s 提到 100 Mgas/s。EIP-8297 那個 1.8 GB 的 code 構造因為 cold account access 漲價,降到約 1.56 GB(−13.3%,已標存疑)。 - 疊起來的使用者價格:新 storage slot
2,100 + 10,000 + 64 × 1,530 = 110,020gas(今天 22,100,4.98 倍);新帳戶3,000 + 9,000 + 120 × 1,530 = 195,600gas(今天 27,600,7.09 倍)。 以 0.08 Gwei 計,絕對金額仍在萬分之一顆 ETH 以下,這是敢漲五到七倍的原因。 - EIP-7954 把合約上限從 24 KiB 提到 64 KiB,同一個分叉把滿版部署定價成半個區塊:
(65,536 + 120) × 1,530 = 100,453,680 gas,佔 200M 區塊的 50.2%。一個區塊能塞的滿版部署從今天的 12.1 個降到 1.99 個,少 6.1 倍。上限從「協議禁止」變成「市場定價」。 - 擋在 10-06 前面的不是密碼學,是一個免費的身分。 2026-09-17 ACDC,Potuz:測試網 ether 無價 ⇒ 開無限個 builder、出天價 bid 贏拍賣、不交 payload、換身分。「I can just spin up a thousand builders」「Any teenager can do this」。
BUILDER_REGISTRY_LIMIT = 2^40在免費網路上等於無限。這跟上一篇 EIP-8025 的誘因分析是同一問題的兩面:參與成本趨近零時同時失去供給誘因與 Sybil 抵抗,趨近無限時只失去供給誘因。 而拉開證明窗口的跟開啟 Sybil 面的是同一個 EIP(7732)。 - 證明能力正在被 gas limit 甩開。 ethproofs 的 39.7% 是在 60M 上量的;ZisK 外推到 200M 是 32.07 秒,對 9 秒窗口超出 3.56 倍,覆蓋率那一格填不出來因為分子會是 0。Ethereum 正在用一條不需要證明的路徑(BAL + 平行執行 + ePBS 的 9 秒窗口)把 gas limit 推上去,證明那條路徑還停在 60M 的世界。 上一篇說「EIP-8025 是一張為 600M 世界買的門票」——補一句:門票的價格也在漲,因為同一個變數(gas limit)同時抬高 zkAttester 的價值與它的達成門檻。另注意 09-05 那篇的歷史證據:gas limit 30M → 60M 時每日新增狀態從 105 MiB 跳到 326 MiB,3.1 倍而非 2 倍——使用量超過了 limit 的成長,而超出的部分全落在最貴的資源上。這正是 EIP-8037 存在的理由,也是本篇唯一一個只能等主網、不能靠查資料解決的問題。
- 三條測試線三個分母:devnet(誠實負載,明確排除蓄意攻擊)、Platåberget(2026-08-20 分叉,公開可加入,對抗性實驗)、non-finality devnet(病態共識,不 finalize 才是成功)。上一篇把其中一條當成全部。
- 分母問題今天抓到三次:①Nethermind 2,302 項測試、5,707 億 gas、3 分 15 秒 = 2,926.7 Mgas/s,對 EIP-8038 說的主網 20 Mgas/s 差 146.3 倍(合成 vs 真實冷狀態);②媒體的「ETH 轉帳便宜 71%」實為「降到 71%」(15,000 ÷ 21,000),真實降幅 28.6%;③devnet-11 的 200M 是 limit 不是用量。
- 方法論的第二重打擊:上一篇說「算得出上限,算不出時程」;今天要補一句——上限也常常算錯,因為很多看起來像物理常數的數字其實是政策常數。
CPSB = 1,530沒有任何物理成分,它是從一個目標反解出來的;120 GiB 是挑的;10 秒是挑的;150M 是假設。真正由物理決定的只有 10 MiB(而它出自一個被拒絕的 EIP)與 650 GiB(而它是一個效能懸崖的經驗值)。 在一個大部分約束都是人訂的系統裡,「找出物理約束」這個動作的產出,多半是別人去年的選擇。
✍️ 實踐
拿你正在追蹤的任何一個技術系統,把它的「約束」全部列出來,然後逐條判斷它是物理的、經濟的,還是政策的。 本篇五個更正裡有三個(更正 1、3、4)的根源完全相同:我把政策常數當成物理常數,於是不去問「誰訂的、為什麼、可不可以改」。
步驟:
-
列出你推導裡用到的每一個上限、門檻與期限,一行一個。 本篇的清單是:10 MiB、650 GiB、10 秒、9 秒、150M、200M、120 GiB/年、1,530 gas/byte、2,000 gas/item、24 KiB、64 KiB、2,100 gas、10,000 gas。十三條,而上一篇把它們當成同一種東西在用。
-
對每一條問:如果我想把它改成兩倍,我要說服誰?
- 物理:誰也說服不了,得等技術進步。10 MiB 屬於這一類——它是「在沒有實質網路層改動的情況下」的實務極限,而且注意這句話自己就帶條件。650 GiB 也接近這一類,但它是一個效能曲線的拐點,不是一堵牆。
- 經濟:要說服一個市場。
ITEM_COST = 2,000與CPSB = 1,530屬於這一類——改了會有人的成本上升,他們會反對。 - 政策:要說服一個房間裡的人。10 秒(EF 的目標)、150M(一個推導假設)、120 GiB/年(一個選定的目標)、64 KiB(一個「夠用就好」的判斷)全屬於這一類,而且改它們不需要任何技術進步。
做完這一步,通常會發現最緊的那個約束是政策的。本篇的 120 GiB 就是:整個 EIP-8037 的定價,是從「我們希望狀態成長不要比今天糟」這個句子反解出來的。
-
對每一個政策常數,回溯它被訂下來時的輸入值,然後檢查那些輸入今天還對不對。
CPSB = 1,530的三個輸入是 120 GiB、150M、50%。第三個是最脆的——50% 的 state-gas 使用率沒有任何東西保證它,而協議允許 100%。所以真正的上界是 2 倍。每一個「平均情況」的參數,背後都有一個「協議其實允許多少」的問題,而兩者的比值就是你的安全邊際被高估的倍數。 -
把「這個限制存在」跟「這個限制無法被越過」分開寫。 EIP-7954 是最乾淨的例子:24 KiB 的限制被提到 64 KiB(限制放寬了),同時滿版部署被定價成半個區塊(實際上更難達到)。如果你的筆記裡只寫「上限從 24 KiB 變 64 KiB」,你會得出完全相反的結論。限制放寬 + 價格上漲,淨效果可能是收緊。
-
最後,對每一個你覺得「巧合到不可能」的比值,先假設它是有人選的。 本篇的
120 ÷ 116.2 = 1.033是一個設計目標,不是一個湧現性質。上一篇當時寫「比值離 1.0 這麼近,很難是巧合」——這句話對了一半:它確實不是巧合,但它也不是因果,它是意圖。在一個有人設計的系統裡,「意圖」這個解釋的先驗機率,比「巧合」跟「因果」加起來都高。
做完這五步,你的約束清單會分成兩疊:一疊要等世界改變,一疊只要等一次會議。而大部分時候,決定時程的是第二疊——這也是上一篇那句「算得出上限,算不出時程」真正的原因:時程是由政策常數決定的,而政策常數不出現在物理推導裡。
🔗 延伸學習
- EIP-8037: State Creation Gas Cost Increase — 本篇第三、四、五節的一手出處。重點讀三個地方:Motivation 裡把
CPSB = 1,530從「120 GiB/年目標 + 150M 參考 gas limit + 50% 使用率」反解出來的那段完整推導(讀完就會明白為什麼這不是物理);Specification 裡gas_used = max(execution, state)那條 header 規則(它同時是 EL/CL 的介面,也是那個 319.9 GiB/年硬上界的來源);以及SYSTEM_MAX_SSTORES_PER_CALL = 16這個常數——它是共識層驅動的系統呼叫做免費 SSTORE 時的硬限制,大概也是與 EIP-7251 那個跨 EIP 問題的收口處。 - Update EIP-8037: Add access-list based deduplication and success/failure cases(ethereum/EIPs#10542) — 本篇更正 2 的一手來源,也是整個 Glamsterdam 延期故事裡最值得讀的一份短文件。它把「約 27,869 份孤兒 bytecode 讓 full-sync 與 snap-sync 節點算出不同結果」這件事講得很清楚,而這是一個可以直接搬走的通用教訓:任何依賴「查我本地有沒有」的共識規則,都在假設所有節點的本地狀態相同,而同步模式會打破這個假設。 讀完再回頭看二手報導把它寫成「EL/CL 分裂實作」,會對壓縮過的技術描述保持應有的警覺。
- EIP-7976: Increase Calldata Floor Cost — 本篇第七節那個 6.4 倍的來源。Motivation 只有兩句話,但那兩句話把「頻寬天花板換算成 gas limit」這件事從 105M 改寫成 671M,而且可以用
10,485,760 × 64一步驗算完。附帶的 1.5% 交易受影響的統計(2024-09 至 2025-09 的區塊)也值得記:一個把最壞情況區塊尺寸砍 37% 的改動,代價是 1.5% 的交易漲價。搭配 EIP-7981 一起讀,會看到同一位作者(Toni Wahrstätter)在兩份 EIP 裡做同一件事——堵住所有「用 EVM gas 換資料足跡」的路徑。 - Announcing the Platåberget Testnet(Ethereum Foundation) — 本篇第十一節的來源,也是唯一一份把 Glamsterdam 的測試面完整列出來的一手文件。重點不是它宣布了什麼,而是它揭示了「devnet finalize 不了」這句話的分母有多窄:devnet 量的是誠實負載下的客戶端互通,對抗性實驗在 Platåberget,病態共識情境在另一個刻意不 finalize 的 devnet。它列出的 EIP 清單(7732、7928、8007、7954、7688、2780、8037、8038)也是今天 Glamsterdam 範圍最可靠的一份快照。
💬 問 AI
我在追蹤 Ethereum Glamsterdam(2026-12 最早上主網)的三類約束——物理的、經濟的、政策的——並且想分清楚哪些數字是協議常數、哪些是推導假設、哪些是團隊目標。請以一手來源(EIP 原文與其 Status/Created/Last Call 日期、ethereum/EIPs 與 consensus-specs 的 PR/issue、ethereum/pm 的 ACD 會議紀錄與錄影、EF 部落格、devnet 的 spec 與 config 檔、客戶端 release notes)為依據回答。**每一個數字請同時標明出處與該出處的日期**,並嚴格區分「來源明確寫的」「我自己推論的」「查不到的」。查不到就說查不到,不要用二手報導補洞。
【一、devnet-11 到底證明了什麼】
1. 請重建 Glamsterdam devnet-11 的完整紀錄:啟動時間、驗證者數量、參與的客戶端與版本、transition 時間、gas limit 從 60M 調到 200M 的確切時間與方法(是 config 改還是驗證者投票?)。調高之後,**區塊的實際 gas used 中位數與 P99 是多少**?有沒有任何一個區塊真的接近 200M?如果沒有,那「200M 未失 finality」這句話的有效範圍是什麼?
2. devnet-0 到 devnet-11 每一個的失敗原因,請逐一給出可追溯的 issue / PR / 會議紀錄連結。devnet-8 那個「區塊 hash 與 parent 相同」的 CL bug,根因是什麼?它跟 EIP-7732 的 payload/bid 分離有沒有關係?
3. devnet 的 scope 文件裡怎麼寫「排除蓄意攻擊」?Platåberget 與那個 non-finality devnet 各自的 scope、時間與目前結果是什麼?
【二、EIP-8037 的定價是政策還是物理】
4. 請完整重建 `CPSB = 1530` 的推導,並列出它的每一個輸入的來源與日期:120 GiB/年這個目標是誰、在哪裡、基於什麼訂的?150M 這個參考 gas limit 為什麼是 150M 而不是 200M(既然 Glamsterdam 的目標是 200M)?50% 的 state-gas 使用率假設有沒有主網資料支持?
5. 我看到一份二手描述說 EIP-8037 的參數是「300M gas limit、30% 使用率、60 GiB/年」,跟 EIP 正文的「150M / 50% / 120 GiB」不一致。哪一個是現行的?有沒有修訂紀錄?如果是後者取代前者(或反過來),CPSB 應該是多少?
6. 因為 header 的 `gas_used = max(execution, state)` 且 `gas_used <= gas_limit`,我推得 `state_gas_used <= gas_limit`,於是 200M 下的狀態成長硬上界是 `200e6 × 2,628,000 ÷ 1530 = 319.9 GiB/年`。這個推論對嗎?有沒有其他機制(per-tx 上限、`TX_MAX_TOTAL_GAS_LIMIT = 2^32-1`、blob、EIP-7825)會讓實際上界更低?另外,CPSB 計的「state bytes」與磁碟實際增量之間的比值,有沒有任何實測?
7. `SYSTEM_MAX_SSTORES_PER_CALL = 16` 是為了什麼?它跟 EIP-7251(MaxEB)的合併請求佇列有沒有關係?那個「EIP-8037 與 EIP-7251 跨 EIP 交互」的問題,具體的機制與修法是什麼?
【三、時鐘】
8. 請把 Glamsterdam 之後的 slot 時間結構完整寫出來:`INTERVALS_PER_SLOT` 在 EIP-7732 之後是多少?每個 interval 幾秒?attestation 截止、payload 揭露截止、PTC 投票、次 proposer 驗證、其他驗證者驗證,各在第幾秒?「傳播窗口從約 2 秒變約 9 秒」這句話的 2 秒與 9 秒,分別是哪兩個時間點的差?
9. EF 的「10 秒內證完 99% 的區塊」這個目標,最早出現在哪份文件、哪一天?它跟協議的 9 秒有沒有被正式對齊過?如果 zkEVM 的證明實際上要跨 slot 交付(EIP-8025 的模型),那「10 秒」在協議裡對應到什麼?
10. EIP-7782(6 秒 slot)被 Glamsterdam 拒絕的完整理由與會議紀錄在哪裡?它目前的目標分叉是哪一個?如果它最終上線,payload 窗口會從 9 秒變成多少?
【四、頻寬這條線到底有多緊】
11. 請給出 Glamsterdam 之後「一個區塊在 p2p 上的最大位元組數」的完整拆解:execution payload、BAL、blob sidecar、beacon block 各自的上界,以及它們是同時還是分時傳播。EIP-7976 的 64/64 與 EIP-7981 的 access list 定價疊起來之後,最壞情況 payload 是多少 MiB?
12. EIP-7928 的 BAL 有沒有可證的尺寸上界?我用 `ITEM_COST = 2000` 與 `bal_items <= gas_limit / 2000` 推得 200M 下最多 100,000 個 item、每個 item 約 66 bytes、共約 6.29 MiB。這個估算的 item 大小對嗎?RLP 的每帳戶開銷怎麼算?壓縮前後差多少?
13. 09-06 那篇算的「200M 下最壞 witness 29.54 MiB」在 Glamsterdam 的世界裡還有意義嗎?也就是說:在 BAL 之下,無狀態驗證還需要傳 witness 嗎?如果不需要,那 EIP-8025 的 zkAttester 是唯一的無狀態路徑嗎?EIP-7864 / EIP-8297 的二元樹在這個圖裡還站在哪裡?
【五、Sybil 與誘因】
14. Potuz 在 2026-09-17 ACDC 上提出的 builder Sybil 問題,完整論述是什麼?有哪些候選緩解(builder 白名單、最低質押、bid bond、聲譽、PTC 罰則)被討論過?各自的取捨是什麼?它會不會影響 10-06 的 Sepolia 分叉決定?
15. 承上:主網上「經濟成本自然壓制」這個假設成立到什麼程度?一個願意虧錢的攻擊者,要癱瘓 ePBS 拍賣多久、要花多少 ETH?請用 `BUILDER_PAYMENT_THRESHOLD = 6/10`、`MIN_BUILDER_WITHDRAWABILITY_DELAY = 64 epochs`、`PTC_SIZE = 512` 這些常數算一個具體的成本下界。
16. 把 EIP-8025 的 prover(成本極高、報酬零)與 ePBS 測試網的 builder(成本零、破壞力高)放在同一個框架裡,這兩者是不是同一個「參與成本 vs Sybil 抵抗」權衡的兩端?有沒有既有的機制設計文獻在處理這個連續體?
【六、分母】
17. Nethermind 那個「2,302 項效能測試、5,707 億 gas、3 分 15 秒」的測試方法是什麼?狀態在快取裡嗎?磁碟 IO 算進去了嗎?平行度多少?它跟 EIP-8038 說的「現在 20 Mgas/s」差 146 倍,兩個數字的定義各是什麼?哪一個才是「200M gas 區塊能不能在 9 秒內執行完」的正確分母?
18. EIP-8038 的 20 → 100 Mgas/s 目標,是在什麼硬體、什麼狀態大小、哪個客戶端上定義的?它的 benchmark 方法(2026-03 的 mainnet 快照、非負最小平方回歸、取最差客戶端)有沒有公開的資料與程式碼?
19. EIP-2780 的「ETH 轉帳便宜」到底是多少?21,000 / 15,000 / 12,000 這三個數字分別對應什麼情境?媒體寫的「降低最多 71%」是不是「降到 71%」的誤譯?
【七、反方與盲點】
20. 我的框架是「把約束分成物理 / 經濟 / 政策三類,然後主張真正決定時程的是政策那一類」。請給出你能構造的最強反方論證:在哪些情況下這個分類會系統性地誤導?(例如:政策常數其實是物理常數的代理變數;或者物理約束的改善速度本來就快過決策速度。)
21. 如果要押注「Ethereum 主網在 2027 年底之前 gas limit 超過 150M」,上面哪幾個數字是決定性的?請特別評估三件事的相對權重:客戶端執行吞吐(20 → 100 Mgas/s)、狀態成長對 650 GiB 懸崖的距離、以及社群對 gas limit 投票的實際行為(驗證者投票 vs 核心開發者建議)。
22. 最後,請指出我上面這些問題裡有沒有錯誤的前提、過期的事實,或被我完全漏掉的重要面向——特別是 Glamsterdam 範圍內我沒提到的 EIP(7688、7708、7997、8159、7778、7904),以及 Hegotá 那 25 個 PFI 的 EIP 裡有沒有會改變上面任何一個結論的。