我的知識庫

區塊鏈 · 2026-10-01

閱讀時間約 14 分鐘

昨天留下三條線:ACDT #98 上 misilva73 說要對「devnet-8 慢區塊與 200M gas limit 安全性」做個簡短澄清、EIP-8254(修 EIP-6110 存款洪水問題的草案)還在不在 Glamsterdam 追蹤清單上、以及 Sepolia 10 月 6 日升級後這道防線到底補上了沒有。今天直接去查這三件事的一手來源,結果是:澄清沒有下文,清單沒有變化,但意外在另一個地方,撞見了同一種 state gas 漲價機制,已經真實弄壞了一個正在跑的基礎設施。

📖 學

ACDT #98 的「快速澄清」,查到的只有標題本身

直接呼叫 GitHub API 拉 ethereum/pm issue #2230(ACDT #98,2026-09-28)底下的留言,整串只有四則:一則是會議資源連結的機器人留言、一則是 Ma-Julian 關於 safe 區塊標籤的議題、misilva73 在 09-28 08:13:39 UTC 發的那一句——逐字是「I would like to give a quick clarification on the devnet-8 slow blocks discussion from last ADCE and the safety of the 200M gas limit」——以及 barnabasbusa 回報的一個 shadowfork genesis.json 小 bug。misilva73 那則就是議程提案本身,不是澄清的內容;會議實際講了什麼通常要等逐字稿或 TLDR 另外貼上來,而截至今天(會議後第三天),這個 issue 底下沒有出現任何會議記錄、逐字稿或錄影連結。這不是「查不到」的藉口性存疑,是直接盯著一手來源確認:內容還沒公開,昨天標的存疑今天仍然是存疑。

Devnet-11 通過了,但通過的是「快樂路徑」

往前查才發現,在 ACDT #98 之前,Glamsterdam 已經另外跑過一輪 Devnet-11,九月中旬完成(KuCoin 快訊發布於 2026-09-18,同篇引述「this week」完成測試,推算落在 09-15 前後),多個執行客戶端參與,Nethermind 一家就在 3 分 15 秒內處理了 5,707 億 gas、跑完 2,302 項測試,區塊在 200M gas 目標下維持了 finality。但 coinpaprika 對同一輪測試的報導寫得很直白:「開發者把 Devnet-11 設計成給客戶端團隊與主要 L2 builder 的『快樂路徑』彩排,不包含蓄意攻擊」。換句話說,這一輪證明的是 200M gas 在正常負載下「跑得動」,不是「扛得住」——存款洪水(EIP-6110 那條線)或 builder 惡意佔位這類對抗式場景,devnet-11 明確沒有測。這跟昨天標的懸案是同一個問題:效能驗證跟安全驗證是兩件事,而目前只有前者做完了。

EIP-8254 現狀:直接讀 EIP-7773 原始碼確認

不靠轉述,直接抓 eips.ethereum.org/EIPS/eip-7773 的當前清單核對。已排定納入 Glamsterdam 的有 EIP-2780、7688、7708、7732、7778、7843、7928、7954、7976、7981、7997、8024、8037、8038、8045、8061、8246、8282;另外還有網路層與資訊性的幾個編號。EIP-8254 不在任何一個子清單裡——跟昨天查到的狀態完全一樣,十四天前的懸案到今天連追蹤清單本身都沒有更新過。EIP-8037(今天下面會用到的那個 state gas 重新定價)倒是確實在清單上,狀態頁寫的是「目前正在同儕審查中」,建立日期 2025-10-01——查的當下正好是它建立滿一年的日子。

意外撞見:state gas 漲價已經真實弄壞一個基礎設施

在追蹤 devnet 與 EIP-7773 的過程裡,連帶查到 crtahlin/wasp 倉庫的 issue #541,標題是「swap: fixed gas limits fail under Glamsterdam’s state-gas costs; chequebook deploy breaks on Sepolia on 2026-10-06」。這是 Swarm 儲存網路的 Bee 節點程式碼,裡面有三筆交易(支票簿部署、代幣轉帳、支票簿提現)為了省一次 eth_estimateGas 呼叫,直接寫死了固定 gas 上限,而不是動態估算。issue 內文把 EIP-8037 的漲價數字整理成表:新帳戶建立 25,000 → 183,600、CREATE 32,000 → 183,600、code deposit 每 byte 200 → 1,530、新 storage slot 20,000 → 97,920——這四個數字跟這個系列 09-30 那篇驗算過的 COST_PER_STATE_BYTE = 1530 完全對得上。拿支票簿部署(deploySimpleSwap:一次 CREATE2 部署 45 byte 的 proxy 合約,外加約 3 個新 storage slot)來看,寫死的固定上限是 175,000,今天在 Gnosis Chain 上三次實測部署用掉 141,893 到 141,905 gas,貼著上限但還過得去;issue 作者按 EIP-8037 的新成本逐項重算——intrinsic gas 因 EIP-2780 從 21,000 降到 15,000(−6,000)、CREATE2 本身 +163,600、45 byte 程式碼 +59,862、3 個新 slot 約 +257,000——加總後估計 Glamsterdam 生效後這筆交易大約要吃掉 616,000 gas,是寫死上限的 3.5 倍。後果寫得很具體:節點送出部署交易,因為 gas 不夠而 revert,而程式碼裡 init.go 會在交易確認「之前」就先把這筆交易的 hash 存起來,且從不清除——於是每次重開機都在等同一筆已經失敗的交易,節點自己沒辦法恢復,得手動介入。

這個 issue 建立於 2026-09-27,隔天(09-28 14:39:18 UTC)crtahlin/wasp 的 PR #546 就合併了修法:把三筆交易全部改回動態估算,抓到估算值之後加 33% 緩衝、夾在原本寫死的數值當底線與 1,000,000 當上限之間,估算失敗就退回底線值。issue 本身也誠實寫了兩件事:一是 EIP-8037 的數字「尚未最終定案」(not yet final),Gnosis Chain 是否跟進以及何時跟進也都還沒公告;二是這整套推算「還沒有在真正跑 Glamsterdam 規則的鏈上驗證過,只有 10 月 6 日之後或在 devnet 上才驗證得了」——issue 末尾附註這份分析是「在 AI 協助下產生」。也就是說,這是一個下游專案在協定規則都還沒定案的情況下,靠著讀 EIP 文本自己推算、搶在真正升級生效前把修法合併進去,而這筆推算本身要等 10 月 6 日之後才能知道準不準——跟這個系列一直在講的「查證當下」與「正確與否」是兩回事,是同一個道理的另一個實例,只是這次不是我們在查資料,是下游開發者在賭協定文本。

🧠 記

  • 一個還在同儕審查中、標「尚未最終定案」的 EIP,可以在兩天內從論文變成真實程式碼的修法。 crtahlin/wasp issue #541(09-27)到 PR #546 合併(09-28)只隔了一天,下游專案等不起協定定案,只能先照現有文本推算、先修、再等升級後驗證。
  • 效能驗證跟安全驗證是兩個不同的問題,devnet-11 只做了前者。 「快樂路徑彩排,不包含蓄意攻擊」是 coinpaprika 原文用詞,200M gas 在正常負載下 finality 沒斷,不代表存款洪水或 builder 惡意佔位這類對抗場景也安全——這兩類風險目前都還沒有已知的 devnet 實測結果。
  • 同一種 state gas 漲價機制,同時在兩個完全不同的高度上造成影響。 協定層的問題是 tx.gas 整體上限夠不夠大(昨天解掉的 EIP-8037/7825 矛盾),應用層的問題是寫死的 gas 估算值夠不夠用(今天的 Swarm chequebook)——同一組新常數(183,600 / 97,920 / 1,530 per byte),同時砸中了設計協定的人跟寫應用程式的人,只是砸中的方式完全不同。
  • 查不到會議記錄,跟會議記錄不存在,是同一件事的兩種可能,但今天可以排除其中一種。 直接拉 GitHub API 確認 ACDT #98 底下只有四則留言、misilva73 那則就是議程提案全文——不是搜尋引擎沒收錄,是逐字稿真的還沒貼上來。
  • EIP-7773 追蹤清單十四天沒有變化,本身就是一個訊號。 EIP-8254 連續兩次查證都不在清單上,意味著這不是查證疏漏,而是這份清單目前就是這樣定的——距離 10 月 6 日只剩五天,留給它被排進去的視窗正在關閉。

✍️ 實踐

  • 讀 crtahlin/wasp issue #541 全文與 PR #546 的 diff,自己驗一次「141,900 − 6,000 + 163,600 + 59,900 + 257,000 ≈ 616,000」這個算式,判斷加 33% 緩衝、夾在 175,000–1,000,000 之間這個修法設計合不合理:github.com/crtahlin/wasp/issues/541
  • 10 月 6 日 13:53:36 UTC 之後,回頭查這個 issue 有沒有貼出 Sepolia 上的實測結果(部署/首次存款/提現/首次兌現/postage 批次建立五項),看 616,000 這個估算值準不準。
  • 定期重新拉一次 github.com/ethereum/pm/issues/2230 的留言(用 gh api repos/ethereum/pm/issues/2230/comments 或直接訪問網頁),看 misilva73 的澄清內容或會議 TLDR 有沒有補上。
  • 對照 eips.ethereum.org/EIPS/eip-7773 的清單,在 10 月 6 日前每隔幾天重新讀一次,看 EIP-8254 有沒有被加進去,或是被正式確認排除在 Glamsterdam 之外。

🔗 延伸學習

💬 問 AI

我在追蹤 Ethereum Glamsterdam 升級(2026-10-06 於 Sepolia 生效)的兩條獨立風險線:
1. EIP-6110 共識層 SSZ 上限(MAX_DEPOSIT_REQUESTS_PER_PAYLOAD = 8192)在 200M gas
   下可能被存款洪水攻擊打穿,修法 EIP-8254 目前仍是 Draft,且連續多天查證都
   不在 Glamsterdam 的追蹤清單 EIP-7773 上。
2. EIP-8037(state gas 重新定價)雖然已解決了協定層 tx.gas 上限的矛盾,但已經
   在下游應用(例如 crtahlin/wasp 的 Swarm chequebook 合約部署,issue `#541`)
   造成寫死 gas 上限失效的真實案例,修法已於 2026-09-28 合併但尚未在真正跑
   Glamsterdam 規則的鏈上驗證過。
 
請幫我查:
1. EIP-8254 有沒有在 10 月 6 日 Sepolia 升級前後出現新進展,或被正式排除在
   Glamsterdam 之外並延後到下一次升級(Hegotá)?
2. ACDT `#98`(2026-09-28)misilva73 那則「devnet-8 慢區塊與 200M gas limit
   安全性」的澄清,逐字稿或會議紀錄有沒有公開,內容具體說了什麼?
3. crtahlin/wasp issue `#541` 提到的 Sepolia 實測(部署/存款/提現/兌現/postage
   批次建立五項 gas 用量),10 月 6 日之後有沒有測出結果,616,000 gas 的估算
   準不準?
請附上原始來源連結(GitHub issue/PR、EIP 官方頁面、ethereum-magicians 為優先),
查不到就明說查不到,不要用你自己記憶裡的舊資訊回答。