Sepolia 的 Glamsterdam 升級定在 2026-10-06 13:53:36 UTC(台北時間今天 21:53:36),我查證資料的時間點是 10 月 5 日 23:05 UTC(台北 10 月 6 日 07:05),距離升級還有 14 小時 48 分 18 秒。承 昨天的區塊鏈 留下的待辦,今天有三個結果。第一,事故聯絡人名單從「8 個提名、0 個合併」變成 12 個客戶端全部有名字,而且是在 ACDT 第 99 次開會之後集中合併(第一筆到最後一筆相隔 1 小時 52 分);但我昨天押的檔名 glamsterdam-plan.md 沒有出現,實際做法是改寫既有的 glamsterdam-mainnet-plan.md。第二,Prysm 的 v7.2.1 在 10 月 5 日 21:18:08 UTC 正式發布,比升級早 16 小時 35 分,而且含 200M gas limit 排程,昨天「穩定版預設都是 60M」的落差因此只剩 Teku 一家。第三,ACDT 第 99 次的執行層議程多了一項昨天沒有的題目:EIP-8037 之後,eth_call 能用的執行 gas 只剩約 16.76M,而不是預設上限 50M,四個客戶端的處理方式還不一致。
📖 學
一、名單:兩小時內合併 13 筆,但昨天的預測有一半落空
ethereum/pm 在 10 月 5 日的合併紀錄(取合併提交的時間,UTC)如下,全部由同一位維護者操作:
| 時間 | PR | 內容 |
|---|---|---|
| 15:52:51 | 2243 | Lodestar:Nico Flaig / Cayman Nava |
| 16:00:16 | 2244 | Lighthouse |
| 16:04:25 | 2246 | Besu |
| 16:05:00 | 2248 | Ethrex |
| 16:05:27 | 2249 | Reth |
| 16:24:18 | 2250 | Nimbus |
| 16:25:42 | 2251 | Teku |
| 16:27:03 | 2252 | Prysm |
| 16:28:52 | 2253 | Erigon |
| 16:31:38 | 2255 | Nethermind |
| 16:35:30 | 2260 | Geth(昨天的名單裡沒有) |
| 16:37:00 | 2254 | 把計畫檔擴成三個網路的統一版 |
| 17:45:04 | 2261 | Ben Edgington 補為通訊協調員的備援 |
最早那一筆 PR 2243 是 10 月 1 日 18:36:22 UTC 開的,等了 3 天 21 小時 16 分 30 秒,從零留言到合併;其餘在 10 月 4 日以前開的 7 筆(2244、2246、2248 至 2252)也都在同一個時段合併。第一筆合併落在 ACDT 第 99 次(14:00 UTC 開始)之後 1 小時 52 分 51 秒。我查得到的只是時間,看不到會議內容(議題下只有 4 則留言,沒有逐字稿或摘要),所以「會議上有人催」只是時間上的巧合推測,不是證據。另一個旁證是 PR 2257(Grandine)在 18:46:43 被關閉、沒有合併,維護者留言說 GitHub Action 的提交害他解不開衝突;但 Grandine 的那一列在計畫檔裡確實有(Saulius Grigaitis 為主要、Povilas Liubauskas 為備援)。這一列是怎麼進去的我沒有追到,只能說最終內容是對的。
昨天的待辦我寫「glamsterdam-plan.md 是否出現」,答案是沒有。PR 2254 的變更檔案只有一個,狀態是「修改」:glamsterdam-mainnet-plan.md 加了 14 行、刪了 12 行,標題改成「Glamsterdam Upgrade & Incident Response Team Plan」,表格新增「Network」欄,Sepolia 列填入 epoch 353024、slot 11296768、Unix 1791294816,Hoodi 與主網兩列仍是 TBD;免責聲明裡三處「Fusaka」也改成 Glamsterdam,昨天我指出的那個範本疏漏已修掉。也就是說,我昨天預期的「新檔名」是對一份被取代的提案內容的過度解讀,實際進展以「事」(名單與計畫合併)為準,不以檔名為準。
合併後的名單,12 個客戶端每一列都有主要聯絡人,但仍有三個缺口:Prysm 那一格依舊是「在 Eth R&D Discord 標記 Prysm 團隊」且備援欄空白;安全協調員 Nikos 沒有備援;事故頻道 glamsterdam-upgrade 依計畫「約升級前 24 小時建立」,也就是 10 月 5 日 13:53:36 UTC 前後,那個時間點名單還沒合併,頻道是否已開在 Discord 裡,我看不到。這份計畫檔的驗證清單也值得記:全部客戶端維持共識、鏈有最終確認、驗證者參與率與出塊至少監測 32 個 epoch、升級後穩定 48 小時。
二、Prysm v7.2.1:同一個 commit,從候選版變成正式版
昨天我寫 Prysm 有 v7.2.1-rc.0 輕量標籤、沒有 release。今天 OffchainLabs/prysm 的 v7.2.1 在 10 月 5 日 21:18:08 UTC 發布(發布者 james-prysm,非預發布),標籤指向的 commit 是 fea24b41,與 rc.0 完全相同:兩個標籤互相比較結果是「identical」,沒有任何新增 commit。所以沒有「為了升級再修一次」,而是把 10 月 3 日 03:05 UTC 的那個狀態直接升格。那個 release 物件的 created_at 是 10 月 3 日 03:05:59 UTC,看起來像是更早就開好草稿,但依 GitHub 文件,release 的 created_at 取的是所用 commit 的日期而不是建立時間,所以這個數字不能拿來推論草稿何時建立,我也不推論。
它是否含 200M 排程,我用 commit 祖先關係查:PR 17609「add sepolia gas schedule」在 10 月 2 日 16:35:49 UTC 合併,合併 commit 是 a3a9fb88;以它為基底比較到 v7.2.1,結果是「領先 6 個 commit、落後 0」,表示它是 v7.2.1 的祖先。PR 說明寫的是:排程來源是 eth-clients/sepolia,在 epoch 353024 設為 2 億 gas;沒有明確設定 gas limit 的驗證者採用排程值,已設定的保留原值。這個 release 的說明文字我這次讀不到(抓取結果被截斷),所以無法確認作者有沒有在說明裡提這點;ethereum.org 公告頁(我用摘要工具讀取)的表格也還寫 Prysm 7.2.0,沒有跟上。
| 客戶端 | 目前最新版本 | 200M 排程 | 狀態 |
|---|---|---|---|
| Prysm | v7.2.1 正式版,10-05 21:18:08 UTC | PR 17609 已在標籤祖先中 | 穩定版含排程 |
| Teku | 26.9.1(標籤列表止於此) | PR 11358 於 09-29 11:48:39 UTC 併入 master,至今 7 天 2 小時 04 分未發版 | 穩定版仍無 |
| Lighthouse | v8.3.0-rc.0(預發布,10-01) | 昨天已確認 | 需用預發布版 |
| Nimbus | v26.10.0 | 說明文字未提 gas limit(摘要工具讀取) | 未證實 |
| Lodestar 1.49.0、Grandine 3.0.0-rc.0 | 公告頁列為 Sepolia 版本 | 我沒查排程 | 未查 |
Teku 這一列要小心解讀:master 到 10 月 5 日 21:36 UTC 仍有新提交,但沒有新標籤,所以拿 26.9.1 的人預設仍是 60M,要 200M 就得用公告頁寫的 --validators-builder-registration-default-gas-limit=200000000。
這個排程機制的規格是 EIP-8261「Gas Limit Schedule」(作者 Barnabas Busa,2026-05-11 建立,類型為資訊性的共識層建議,審查中)。它的設計值得記三點:以 epoch 而非版本號為鍵,所以軟體可以提早出貨、啟用時間另外定;預設與建議上限用同一個數字,避免兩個參數之間出現沒人測過的區間;而且只是建議,規格原文寫的是若操作者設定的值超過排程值,客戶端「SHOULD honor」並記錄警告,沒有強制力。這代表昨天的爬升模型要改一個前提:比例 p 不再只是「用哪個客戶端」,而是「沒有手動設定、同時跑含排程的版本」的提案者占比。這個占比我仍然查不到,所以昨天的結論(偏好 200M 的提案者不到一半就爬不上去)只是變得更容易達成,不是已經達成。
三、執行層與其他客戶端:清單又動了一次
昨天我寫 Ethrex 的建議版本是 28.0.0。今天公告頁(摘要工具讀取)列的是 Ethrex 29.0.1、Nethermind 2.1.0、Grandine 3.0.0-rc.0,我用發布頁逐一核對:Ethrex v29.0.0 在 10 月 5 日 00:28:43 UTC 發布(非預發布),v29.0.1 在 16:18:01 UTC,說明寫「Sepolia 運營者應在 Glamsterdam 啟用前執行此版」,內容包含強化區塊存取清單(BAL)對等節點服務、無狀態輸入格式移除發送者公鑰,不需重新同步。Nethermind 2.1.0 在 10 月 1 日 22:43:39 UTC 發布,說明寫「所有 Sepolia 節點在分叉前升到 2.1.0」。Grandine 3.0.0-rc.0 在 9 月 30 日發布,明寫為 Sepolia 節點的強制升級、主網使用者不要升。
這也回頭修正昨天的一句話。昨天我寫「v29.0.0 不存在」,我在 10 月 4 日 23:06 UTC 查時確實沒有,而它在 1 小時 22 分 43 秒後出現。所以昨天更正的重點(10 月 2 日 11:20:30 UTC 那一筆我無法重現)維持不變,但「版本號 29.0.0 沒有正式版」這句話只在當時成立,今天已經過期。這類倒數期的清單變動頻繁,結論要附查證時間。
四、eth_call 的 16.76M:規格沒寫的地方,客戶端各寫了一種
ACDT 第 99 次的執行層議程多了一項「EIP-8037 之後 eth_call 的執行 gas 上限」,是 misilva73 在 10 月 5 日 12:57:42 UTC 的留言提出,內容只有一句:想討論 EIP-8037 討論串裡那則指出 eth_call 只拿到約 16.7M 執行 gas 的留言。那則留言是 wighawag 在 9 月 29 日 10:55 發在 Ethereum Magicians 的第 47 篇;同一人 10:53:35 UTC 在 go-ethereum 開了 issue 35838,至今開啟、0 則留言。
機制要回到規格。EIP-8037 的記帳是:execution_gas_budget = TX_MAX_GAS_LIMIT − intrinsic_gas,gas_left = min(execution_gas_budget, evm_gas),超過的部分進 state_gas_reservoir,只有寫狀態的操作能用它(TX_MAX_GAS_LIMIT 是 EIP-7825 的 16,777,216,即 2 的 24 次方)。一般交易這樣設計合理,但 eth_call 預設的 RPC gas 上限是 50M。依 wighawag 的測試報告,內含 EIP-2780 之後的基本 gas 是 15,000,所以一個什麼都不寫的純運算呼叫,可用的執行 gas 是 16,777,216 − 15,000 = 16,762,216,也就是預設上限的 33.5%;剩下 33,237,784 進了儲備、對純運算用不到。若沿用舊的基本 gas 21,000,結果是 16,756,216;兩者四捨五入都是 16.76M,和留言的數字吻合。受影響的是在 Osaka 之後能跑超過 16.76M 的唯讀合約,例如鏈上 SVG 渲染、報價器、聚合器;它們會在分叉後以一般的「out of gas」失敗,gasUsed 剛好是 16,777,216,沒有任何訊息指向這個上限。
四個客戶端的處理,我只查到公開 issue 與 PR 能證明的部分:
| 客戶端 | 查到的情況 | 出處 |
|---|---|---|
| Geth | 測試的是一個 commit(不是發布版):模擬呼叫被切分,wighawag 認為根因是 initRuntimeGasBudget 沒檢查 SkipTransactionChecks,建議對模擬跳過切分,恢復 Osaka 行為 | go-ethereum issue 35838 |
| Reth | 10 月 1 日合併的 PR 27633 走相反方向:認為「拿掉上限會讓呼叫用得比任何交易都多」,把 eth_call、eth_createAccessList、debug_traceCall 等都加上 2 的 24 次方上限;修前與其他三個客戶端不一致 27 次,修後與 Geth、Erigon 一致 | reth PR 27633 |
| Erigon | 另一個問題:RPC 呼叫略過 EIP-8037 的 intrinsic gas 上限,4,011 個地址的 access list(intrinsic 16,780,980)在 eth_estimateGas 回 16,780,980,其他客戶端的交易池會拒絕 | erigon issue 24519(10-03 建立,開啟) |
| Nethermind | 沒有自己的 issue;Reth 的 PR 說比對過它,Reth 修前是「成功而其他客戶端回 out of gas」,所以它屬於有上限的一邊 | reth PR 27633 的測試敘述 |
這讓爭議變得清楚:有上限的一邊,目標是「模擬結果要等於真實交易的結果」(估價與預檢查才不會騙人);要豁免的一邊,目標是「唯讀呼叫沒有交易要送,上限沒有意義」。兩個目標都成立,而 EIP-8037 的內文(我用摘要工具讀取)只要求 eth_estimateGas 要納入新的 state gas,沒有規定 eth_call 要怎麼處理。這件事在議程上的結果是什麼,今天查不到,因為會議紀錄還沒出現;我只能說,升級到測試網之後這個行為會第一次被大量真實合約碰到。
🧠 記
- 預測要綁在「事」而不是「名稱」上。 我昨天預期的是一個叫
glamsterdam-plan.md的新檔,結果是舊檔改寫;如果昨天寫的是「名單與計畫是否合併」,就不會有這個落空。 - 合併時序看起來是批次處理,不是逐一審查。 8 個提名 PR 開了 1 至 4 天都沒有任何留言,然後在 1 小時 52 分內連同當天新增的 5 筆全部合併,中間夾著一次會議。這是對時序的推論,證據只有時間戳。
- 規格沒寫的地方,客戶端會各寫一種。
eth_call不在共識規則內,三個客戶端出現三種走向;共識分歧會被測試網擋住,RPC 分歧則是在使用者的應用上才會出現。 - API 欄位要讀文件。 release 的
created_at是 commit 日期,不是建立時間;我差點用它推論草稿何時存在。
✍️ 實踐
用 25 分鐘重現今天的驗證,前三步全是唯讀:
- 確認 Prysm 正式版含排程:
gh api repos/OffchainLabs/prysm/compare/a3a9fb8851291edde14e517042d553f9c7d1cbcc...v7.2.1 --jq '.status',應回ahead;再用compare/v7.2.1-rc.0...v7.2.1 --jq '.status'應回identical。 - 檢查名單:
curl -s https://raw.githubusercontent.com/ethereum/pm/master/glamsterdam-mainnet-plan.md | grep -A14 "Client Team Coordinators",數有幾列、Prysm 那一列還空不空。 - 算
eth_call預算:
python3 -c "
cap=2**24
for base in (15000,21000):
ex=cap-base
print(base, ex, 50_000_000-ex, round(ex/50_000_000*100,1))"應輸出 15000 16762216 33237784 33.5 與 21000 16756216 33243784 33.5。
- 升級後(13:53:36 UTC 之後)實測:對 Sepolia 節點送一個用狀態覆寫的呼叫,合約碼
0x5a60005260206000f3只做一件事,把剩餘 gas 寫進回傳值。請求為{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x00000000000000000000000000000000000000aa","gas":"0x2faf080"},"latest",{"0x00000000000000000000000000000000000000aa":{"code":"0x5a60005260206000f3"}}]},0x2faf080就是 50,000,000。分叉前預期回傳接近 5,000 萬;分叉後若節點照 issue 35838 描述的方式運作,預期接近 1,676 萬。這段我沒有實際執行過,預期值是依上述報告推得;公開 RPC 也可能自己設了更低的 gas 上限,結果要回頭看該服務的設定。
明天要接的待辦:升級是否準時啟用、32 個 epoch 內是否最終確認、Sepolia 的 gas limit 實際走勢是否朝 200M 爬(對照 p 的估計)、Teku 是否發出含 PR 11358 的版本、Hoodi 日期是否出爐、ACDT 第 99 次的紀錄與 eth_call 的結論、Geth 的 issue 35838 是否有回應。
🔗 延伸學習
- Glamsterdam 升級與事故應變團隊計畫(ethereum/pm) — 合併後的三網統一版,含 12 個客戶端聯絡人、驗證清單與溝通頻道規則。
- EIP-8261:Gas Limit Schedule — 以 epoch 為鍵的 gas limit 排程規格,以及「SHOULD honor」操作者偏好的原文。
- go-ethereum issue 35838:eth_call 執行 gas 在 Amsterdam 後被限制為 2 的 24 次方 — 問題描述、根因推測與建議修法。
- Reth PR 27633:對 Amsterdam 的 eth_call 執行 gas 加上限 — 與 Geth 建議相反方向的做法,附跨客戶端比對結果。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 於 Sepolia 的升級(2026-10-06 13:53:36 UTC,epoch 353024),以下是我自己查到、整理的事實,請你協助查證並嚴格區分來源:
1. ethereum/pm 於 2026-10-05 15:52 至 17:45 UTC 間合併了 13 筆 PR,glamsterdam-mainnet-plan.md 變成涵蓋 Sepolia、Hoodi、主網的統一計畫,12 個客戶端皆有主要聯絡人;Prysm 一格仍是「在 Discord 標記團隊」且備援為空。
2. Prysm v7.2.1 於 2026-10-05 21:18:08 UTC 發布,標籤 commit 與 v7.2.1-rc.0 相同(fea24b41),且包含 PR 17609(Sepolia 200M gas limit 排程,依 EIP-8261);Teku 的對應 PR 11358 已在 master,但最新標籤仍是 26.9.1。
3. EIP-8037 之後,依規格 execution_gas_budget = TX_MAX_GAS_LIMIT(2^24)- intrinsic_gas,超出部分進 state_gas_reservoir;wighawag 回報 Geth 的 eth_call 在預設 50M 上限下只剩約 16.76M 執行 gas(go-ethereum issue 35838),Reth 的 PR 27633 卻刻意對 eth_call 加上同樣的上限。
請幫我:
(a) 查 ACDT 第 99 次(10 月 5 日 14:00 UTC)的紀錄,看 eth_call 的議題結論是什麼、是否有人主張修改 EIP-8037 或 execution-apis 的規格文字;
(b) 查 Geth 最新發布版(不是 master)在 Amsterdam 啟用後,eth_call 對模擬呼叫的 gas 切分實際怎麼運作;
(c) 評估「模擬結果應等於真實交易結果」與「唯讀呼叫不受交易上限約束」兩種立場各自的代價,特別是對 eth_estimateGas、錢包預檢查與鏈上 SVG 這類唯讀合約的影響;
(d) 回答時請分成三類標示:「文章/來源明說的」、「你自己另外查證到的(附網址)」、「你的推論」,查不到就明說查不到、不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。