我的知識庫

區塊鏈 · 2026-09-30

閱讀時間約 15 分鐘

昨天收在一個尚未解開的矛盾上:EIP-8037 自己舉的例子——部署 24KB 上限合約需要約 37.8M state gas——已經是同期在跑的 EIP-7825 單筆交易 gas 上限(16,777,216)的兩倍以上,而且標註「EIP 目前狀態仍是 under peer review,尚未解決」。今天去 GitHub 上追這個矛盾的後續,結果是:它其實已經解了,而且解決的時間點,比昨天那篇寫下來的時間點還早了整整兩週。

📖 學

在 ethereum/EIPs 倉庫裡,有一個 PR #12311,標題是「cap the transaction gas limit at 2^32-1」,作者 chfast,已在 2026-09-14 合併(commit d708780,由 misilva73 觸發重跑檢查後通過)。它做的事很直接:新增一個常數 TX_MAX_TOTAL_GAS_LIMIT = 4,294,967,295(即 2^32-1),把它套在 tx.gas 這個整體上——包含 gas_left(執行 gas)跟 state_gas_reservoir(state gas)兩者的總和。PR 說明裡寫得很白:「單獨把 EIP-7825 的上限套在 execution-gas 上,會讓 tx.gas 本身只受區塊 gas limit 約束,這不是原本設計的意圖」,所以才補一個獨立的、套在整體上的絕對上限。關鍵的一句話在旁邊的留言裡:「這個上限離真正卡住還很遠——它留給 code-deposit 的預算大約 2.8 MB,相當於 EIP-7954 合約大小上限的 43 倍。」驗算一下:4,294,967,295 ÷ 1530(COST_PER_STATE_BYTE)≈ 2,807,168 bytes ≈ 2.8 MB,而 EIP-7954(把最大合約大小從 24KiB 拉到 64KiB,同樣排進 Glamsterdam)的新上限是 65,536 bytes,2,807,168 ÷ 65,536 ≈ 42.8,四捨五入正好是「43 倍」。這代表昨天算的 37.8M state gas,不管是對舊的 24KB 上限還是新的 64KiB 上限,都遠遠塞得進這個新增的整體上限裡——EIP-7825 的 16,777,216 那個數字,從一開始就沒有被要求套用到 state gas 上,PR 只是把這句話從「隱含的設計意圖」變成「白紙黑字的常數」。

這件事本身值得多停一秒。修這個矛盾的 PR 早在 9 月 14 日就合併了,而昨天那篇文章寫於 9 月 29 日,離修復已經過了十五天,卻仍然把它寫成「尚未解決」的懸案。這不是昨天那篇查得不夠仔細——ethereum-magicians 上的公開討論串跟媒體報導確實都還在談這個矛盾,一個影響 execution/consensus 兩層客戶端實作的 PR,合併進 EIP 正文之後,不會自動出現在論壇或新聞的搜尋結果裡。這也是這個系列一直在強調的同一件事的又一次示範:一份技術推導的正確與否,跟它「查證當下」是不是最新,是兩個不同的問題,而後者的半衰期可以短到兩週。

但把這件矛盾解開,不代表「200M gas limit 安不安全」這個更大的問題也解開了。ACDT #98(2026-09-28,兩天前)的議程上,misilva73 領銜的討論項目寫著:「針對上次 ACDE 的 devnet-8 慢區塊討論、以及 200M gas limit 安全性,做一個簡短澄清」——這句話本身說明,截至本週,這個問題仍然開著。往回查「上次 ACDE」——即 2026-09-24 的 ACDE #246——它的議程標題直接寫「Glamsterdam gas limit——200M 真的可以了嗎?」。而這個問題跟昨天寫的 EIP-8037/EIP-7825 矛盾完全無關,是另一條獨立的斷層線:EIP-6110(Pectra 引入的「驗證者存款上鏈」)在共識層寫死了一個 SSZ list 上限 MAX_DEPOSIT_REQUESTS_PER_PAYLOAD = 8192。在 193–200M gas 的區塊裡,靠一個批次存款合約,大約每 10M gas 能塞進 410 筆存款請求——200M gas 換算下來大約 8,200 筆,已經超過 8,192 這個寫死的上限。後果是:執行層產出一個自己認為合法的 payload,共識層卻沒辦法解碼它,驗證者收到解碼錯誤、錯過自己的出塊,而且同一個執行層 head 之上的後續提案會持續失敗,直到存款佇列被排空為止。這不是紙上推演——9 月 3 日的開發者議程記錄了 Devnet-8(Gloas 啟用)真實撞上這個問題,多個共識層客戶端同時受影響、無法 finalize。

檯面上的修法是 EIP-8254:Cap Deposit Requests Per Block(作者 pk910 與 Barnabas Busa,建立於 2026-05-06,狀態仍是 Draft)。做法跟 EIP-8037/7825 那組矛盾的解法邏輯很像:在執行層加一道硬上限 MAX_DEPOSIT_REQUESTS_PER_BLOCK = 8192,精確對齊共識層既有的 SSZ 上限,超過上限的區塊直接判定無效,超額的存款交易被排除在外但留到下一個區塊仍然合法。EIP 原文說得很清楚:「把 EL 的上限設得跟 CL 的上限一樣,直接堵住這個失效路徑」,而且因為兩邊數字相同,共識層不需要跟著改。但查證 Glamsterdam 的追蹤 meta-EIP——EIP-7773——目前列出的清單裡,並沒有 EIP-8254。也就是說,這個修法目前還只是一份 Draft,尚未確認會被排進 Glamsterdam 這一次分叉;EIP-8037 跟 EIP-7954 都在 EIP-7773 的清單上,EIP-8254 不在。

即便如此,開發者在 ACDE #246 上還是決定往前走:議程紀錄「同意合併」eth-clients/sepolia 的 PR #130,標題是「在 Glamsterdam 升級時直接把 gas limit 排程到 200M」,說明寫著「這會需要幾個小時,gas target 才會真的爬到 200M」——不是漸進調升,是升級瞬間就把上限打開。這代表 Sepolia 會在還沒有 EIP-8254 這道防線的情況下,直接暴露在 193M 存款洪水攻擊之下,測試等於也在測這個風險本身。至於 misilva73 在 ACDT #98 上那個「簡短澄清」具體說了什麼——是否引用了 EIP-8254、或者判定這個風險在測試網階段可以接受——目前查不到逐字稿或會議紀錄公開的內容,已標存疑。

昨天標的另一處存疑,今天可以收斂。昨天寫官方 ACDT #97 agenda 的 Sepolia fork 是 epoch 353024,但同一週的媒體報導寫的是 epoch 351232,兩邊對不上。今天查 2026-09-17 blog.ethereum.org 的官方 Glamsterdam 測試網公告,寫的是「epoch 353,024,slot 11,296,768(2026 年 10 月 6 日 13:53:36 UTC)」;而 9/29–9/30 這兩天陸續出現的後續報導(crypto.news、Cointelegraph、CoinDesk)清一色只引用 10 月 6 日 13:53:36 UTC 這個時間,沒有再出現 351232 這個數字。這不能證明 351232 是哪裡來的錯誤,但可以確認 353024 這個數字在往後的報導裡站住了——昨天那個存疑,目前傾向於是媒體一次性的誤植,而非官方數字本身還有爭議。

最後帶一句題外話,跟今天主線不同但共用同一個十月六日:2026-09-17 的 ACDC 會議上,開發者 Potuz 提出另一個跟 ePBS(EIP-7732)有關的 Sepolia 測試網風險——用便宜的測試幣量產一次性 builder 身分,靠灌高出價贏得出塊權之後不交付 payload,癱瘓網路可用性。crypto.news 報導這件事把原本兩週一次的客戶端版本審查期,壓縮成只剩七天,而審查期限剛好就是昨天文章提到的 9 月 29 日——也就是今天。兩個完全不同機制的風險(存款洪水、builder 佔位不交付),在同一個十月六日之前擠進同一段緊縮的準備時間裡。

🧠 記

  • 昨天的矛盾已經解了,但比昨天那篇文章早解了兩週。 PR #12311(2026-09-14 合併)新增 TX_MAX_TOTAL_GAS_LIMIT = 4,294,967,295(2^32-1),套用在 tx.gas 整體(執行 gas + state gas)而非只套用在執行 gas 上——EIP-7825 的 16,777,216 上限本來就只管執行 gas。留給 code-deposit 的預算約 2.8 MB,是 EIP-7954 新合約大小上限(64KiB)的約 43 倍,昨天的 37.8M state gas 完全塞得進去。
  • 一份查證的推導,正確與否跟它是否過期,是兩件事。 這次過期的間隔只有十五天——一個合併進 EIP 正文、沒有登上論壇或媒體的 PR,足以讓一個「尚未解決」的結論在寫下來的當下就已經不成立。
  • 「200M gas limit 安不安全」是一條完全獨立的斷層線,今天仍然開著。 EIP-6110 寫死的共識層 SSZ 上限 MAX_DEPOSIT_REQUESTS_PER_PAYLOAD = 8192,在 193–200M gas 下可被一個批次存款合約打穿(約每 10M gas 存 410 筆,200M gas ≈ 8,200 筆 > 8,192),已在 Devnet-8 Gloas 啟用時造成多個共識層客戶端無法 finalize(9/3 議程記錄)。
  • 修法 EIP-8254(MAX_DEPOSIT_REQUESTS_PER_BLOCK = 8192,對齊既有 CL 上限)還是 Draft,不在 Glamsterdam 的追蹤清單 EIP-7773 上。 但開發者在 ACDE #246(9/24)仍決定「200M good to go」,合併了 Sepolia PR #130,升級瞬間直接把 gas limit 排程到 200M,沒有漸進緩衝——等於讓測試網在沒有這道防線的狀態下直接暴露在這個風險之下。
  • 昨天標的 epoch 存疑收斂了。 官方公告(blog.ethereum.org,9/17)寫 epoch 353,024 / slot 11,296,768 / 2026-10-06 13:53:36 UTC,9/29–9/30 的後續報導只重複這個時間、不再出現昨天媒體提到的 351232,傾向判定後者是一次性誤植。
  • 同一個十月六日還疊了第三個風險,跟今天主線無關但共享同一段時間壓力:ePBS 的 builder 佔位不交付攻擊(Potuz,9/17 ACDC),把原本兩週的客戶端審查期壓到七天,期限正好是 9 月 29 日。

✍️ 實踐

  • 讀 PR #12311 全文與留言,自己驗一次 4,294,967,295 ÷ 1530 ≈ 2.8MB、2.8MB ÷ 65536 ≈ 43x 這兩個算式:github.com/ethereum/EIPs/pull/12311
  • 讀 EIP-8254 全文,判斷 MAX_DEPOSIT_REQUESTS_PER_BLOCK = 8192 這個設計會不會製造新的 DoS 向量(例如故意把交易堆到上限邊界卡住別人的存款):eips.ethereum.org/EIPS/eip-8254
  • 對照 EIP-7773(Glamsterdam 追蹤清單)跟 EIP-8254 的 Draft 狀態,自己判斷這個修法有沒有機會趕上 10/6 之後的下一個 devnet 或 Hoodi 測試網:eips.ethereum.org/EIPS/eip-7773
  • 10 月 6 日之後,回頭查 ACDT #99/#100 或 ACDE #247 的議程,看 misilva73 那個「簡短澄清」有沒有被寫進逐字稿:github.com/ethereum/pm/issues/2230

🔗 延伸學習

💬 問 AI

我在追蹤 Ethereum Glamsterdam 的 200M gas limit 安全性問題,已知的是:
1. EIP-8037(state gas 重新定價)與 EIP-7825(單筆交易 gas 上限)之間原本的矛盾,
   已靠 PR #12311(2026-09-14 合併,新增 TX_MAX_TOTAL_GAS_LIMIT = 2^32-1)解決。
2. 另一條獨立的問題是 EIP-6110 的共識層 SSZ 上限(MAX_DEPOSIT_REQUESTS_PER_PAYLOAD
   = 8192)在 193-200M gas 下可能被存款洪水攻擊打穿,修法 EIP-8254 目前還是 Draft,
   不在 Glamsterdam 的追蹤清單 EIP-7773 上。
 
請幫我查:
1. EIP-8254 有沒有新進展?有沒有被排進 Glamsterdam、Hoodi 測試網、或延後到 Hegotá?
2. ACDT #98(2026-09-28)misilva73 那個「devnet-8 慢區塊與 200M gas limit 安全性」
   的簡短澄清,實際內容是什麼?逐字稿或錄影有沒有公開?
3. Sepolia 在 2026-10-06 升級後,gas limit 立即跳到 200M,有沒有實際觀察到存款洪水
   攻擊的嘗試或 finality 異常?
請附上你查到的原始來源連結(GitHub issue/PR、ethereum-magicians、EF 部落格為優先),
不要用你自己記憶裡的舊資訊回答,查不到就明說查不到。

反向連結