距離 Sepolia 的 Glamsterdam 升級(2026-10-06 13:53:36 UTC,台北時間當天 21:53:36)還有三天,今天先更正昨天一處讀錯的來源:我昨天寫的 ethereum/pm「issue 2243」其實是一個尚未合併的 PR,而且它改的是主網計畫文件,不是 Sepolia 的;Sepolia 專屬的計畫文件是另一個 PR(2245 號),十二個客戶端聯絡人欄位全是空的。接著把 12 個客戶端團隊的推薦版本逐一核對成表,發現今天最具體的落差在 Prysm:Sepolia 的 200M gas limit 排程與一個「Gloas 第一個區塊可能出不了塊」的修補,都在 10 月 2 日才併進開發分支,距離 v7.2.0 發版已過 4 天、仍沒有新版本。最後用整數模擬算出 200M 不會在升級那一刻出現:全部提案者都推高也要約 4.1 小時,若預設 60M 的提案者占多數,它根本爬不上去。
📖 學
更正:昨天的「incident response 聯絡人」寫進的是主網計畫
重新用 gh api 與 PR diff 逐一讀:ethereum/pm 的 2243、2244、2246 號都是 PR(不是 issue),各自只改 glamsterdam-mainnet-plan.md 的一列。Lodestar 是 Nico Flaig 主、Cayman Nava 備;Lighthouse 是 Eitan Seri-Levi 主、Pawan Dhananjay 備;Besu 是 Daniel Lehrner 主、Karim Taam 備(10 月 2 日 10:23 UTC 新開)。三個 PR 都是開啟狀態、沒有留言、尚未合併,所以昨天「各客戶端都提名了聯絡人」的說法要縮小:十二個客戶端列(Besu、Erigon、Ethrex、Geth、Grandine、Lighthouse、Lodestar、Nimbus、Nethermind、Prysm、Reth、Teku)中,主網計畫有 3 列有人提名,而且還沒合併。
Sepolia 的計畫是 abcoathup 在 10 月 2 日 07:21 UTC 開的 PR 2245(新增 glamsterdam-sepolia-plan.md,53 行,同樣尚未合併)。內容有幾項可直接驗證:升級列寫 epoch 353024、起始 slot 11296768、unix 1791294816;四個角色已填人名(DevOps 是 Pari 主、Barnabas 備;Testing 是 Mario Vega 主、Justin Traglia 備;Communication 是 Will Corcoran;Security 是 Nikos);溝通頻道是 Eth R&D Discord 的 #glamsterdam-upgrade,規定在升級前約 24 小時才建立、成功後封存;12 列客戶端聯絡人全是空白,PR 內文也寫明「still to be filled in」。PR 內文還順帶承認一個疏漏:主網計畫的免責聲明仍寫著 Fusaka。這表示聯絡人名單可能已經在 Discord 私下排好,但公開文件上的 Sepolia 客戶端欄位,到查證時是 0 比 12,我沒有辦法確認私下的安排。
計畫文件的「升級後驗證」清單給了可以自己換算的門檻:區塊生產與參與率要監看至少 32 個 epoch,即 32 × 384 = 12,288 秒 ≈ 3.41 小時;網路穩定度要驗 48 小時,即 14,400 個槽位、450 個 epoch,結束點是 10 月 8 日 13:53:36 UTC(台北 21:53:36)。對照排程:ACDT 第 99 次在 10 月 5 日 14:00 UTC,議程列「Sepolia upgrade」由 marioevz 主持;Frame Transaction Breakout 第 6 次刻意延後到 10 月 6 日 14:30 UTC,理由寫明是「不要與 Glamsterdam Sepolia 啟動與 watch party 重疊」;ACDE 第 247 次在 10 月 8 日 14:00 UTC,剛好在 48 小時觀察期結束後 6 分 24 秒,議程第一項就是 Glamsterdam。
12 個客戶端的推薦版本逐一核對
資料來源是各客戶端 GitHub release 的發布時間與說明,以及 ethereum.org 部落格 9 月 17 日的 Glamsterdam 測試網公告(頁面沒有標更新日期,但已列到 10 月 2 日才發的 Erigon 3.7.1,可見有更新過)。「距升級」是發版時刻到 10 月 6 日 13:53:36 UTC 的小時數:
| 客戶端 | 推薦版本 | 發版(UTC) | 距升級 | 備註 |
|---|---|---|---|---|
| Besu | 26.9.0 | 09-25 22:22 | 255.5 小時 | 排程已寫入,並為 200M 調整交易池 |
| Geth | 1.17.7 | 09-30 11:48 | 146.1 小時 | release 說明 1.17.6 與 1.17.7 皆可用於 Sepolia |
| Reth | 2.7.0 | 09-28 12:45 | 193.1 小時 | 排程與 fork ID 轉換已測 |
| Nethermind | 2.1.0 | 10-01 22:43 | 111.2 小時 | 含最終 EIP-8037 規則與 2³²−1 的交易總 gas 上限 |
| Erigon(含 Caplin) | 3.7.1 | 10-02 08:12 | 101.7 小時 | Caplin 預設排程 200M |
| Ethrex | 29.0.0 | 10-02 11:20 | 98.6 小時 | 已用 28.0.0 的也要再升 |
| Lighthouse | 8.3.0-rc.0 | 10-01 04:47 | 129.1 小時 | 預發布版,依排程 200M |
| Lodestar | 1.49.0 | 09-28 13:54 | 192.0 小時 | 排程 200M |
| Grandine | 3.0.0-rc.0 | 09-30 07:45 | 150.1 小時 | 預發布版,release 說明列有 gas limit schedule |
| Nimbus | 26.9.1 | 09-30 04:00 | 153.9 小時 | 200M 預設值未查證 |
| Prysm | 7.2.0 | 09-28 15:50 | 190.0 小時 | 預設 60M,見下節 |
| Teku | 26.9.1 | 09-28 01:16 | 204.6 小時 | 預設 60M(公告明寫) |
十二個版本的發版時間距升級的中位數是 (150.1 + 153.9) ÷ 2 = 152.0 小時,約 6.3 天;有 3 個(Nethermind、Erigon、Ethrex)距升級不到 5 天,有 2 個(Lighthouse、Grandine)推薦的仍是預發布版。Ethrex 的例子最值得細讀:v28.0.0 在 09-29 04:03 發版,說明寫「不升級跟不上分叉」,但 10 月 2 日的 v29.0.0 又說「連已升到 v28.0.0 的也請再升」,原因是它把「對 peer 提供區塊存取清單(BAL)」的工作量與記憶體加上限、計入每個 peer 的速率限制、丟棄連線從未發出請求卻收到的回應,並在 BAL 超過 EIP-7928 的項目上限時不先處理就拒絕。release 說明明講「每個 Sepolia 節點在分叉時就開始提供 BAL」。這和昨天的假 builder 同類:分叉當下才開啟的新面向,攻擊面也是在分叉那刻才出現。公告頁(寫的是 Ethrex 28.0.0)已落後這個版本一個版,所以「官方清單」不等於最新。
Prysm:三個都只存在於開發分支的 PR
昨天寫「Prysm v7.2.0 的 200M 排程不在內、官方說後續版本才帶入」,今天查到後續有了動作,但還不是版本。OffchainLabs/prysm 的開發分支在 10 月 2 日併進三個相關 PR:
| PR | 合併時間(UTC) | 內容 |
|---|---|---|
17601 | 15:20 | 修正 keymanager 的後備邏輯用的是預設 gas limit 而非排程(PR 內文感謝 nflaig 發現) |
17609 | 16:35 | 加入 Sepolia 官方排程:epoch 353024 起 200,000,000;未明設 gas limit 的驗證者採排程值,明設者保留自己的值;排程取自 eth-clients/sepolia 的 PR 130 |
17610 | 22:05(potuz 合併) | 若在 Gloas 第一個區塊時 payload ID 快取未命中,Prysm 找不到正確的 parent hash 來建構 payload,就會漏掉那個區塊 |
用 compare API 看 v7.2.0...develop 領先 49 個 commit,標籤清單最新仍是 v7.2.0(09-28 15:50 UTC)。從 17609 合併到升級還有 3 天 21 小時 17 分(93.3 小時),從 17610 合併到升級 87.8 小時;v7.2.0 發版到升級是 7 天 22 小時。這三項我能確認的是「已合併、尚未出版」,至於有沒有排好 v7.2.1 或候選版,我沒查到,不下結論。
對 Prysm 驗證者而言,今天能分辨的是三種處境:用 v7.2.0,gas limit 偏好預設 60M(要 200M 得自己設),並承受第一個 Gloas 區塊的建構風險;自己設 gas_limit 避開前者,後者仍在;自行從開發分支建置,兩者都避開,但要自己承擔未發版的風險。「第一個 Gloas 區塊」只有一個槽位(12 秒),那個槽位要分到 Prysm 提案者、而且快取剛好未命中才會漏,所以影響上限是一個槽位,不是整條鏈;Prysm 在 Sepolia 驗證者中的占比我沒有查到,所以機率無法估。
200M 不會在升級那一刻出現:爬坡算式
EIP-8261 條文明說 EIP-1559 的 ±1/1024 規則仍是「唯一的 gas limit 有效性規則」,排程只是改變預設目標,不是直接跳值。eth-clients/sepolia 的 PR 130 內文也寫:「it will take a few hours for the gas target to actually reach 200m」。把規則寫成算式:每個區塊 gas limit 只能比父區塊的差距小於 parent // 1024,所以單區塊最大上調約 ×(1 + 1/1024)。
從 60M(假設起點,我沒有查 Sepolia 當下的實際 gas limit)到 200M:ln(200/60) = 1.2040,ln(1 + 1/1024) = 0.000976,所需區塊 ≈ 1,233.5。實際用整數規則(每步 parent // 1024 − 1)逐區塊模擬是 1,234 個區塊、停在 200,099,894,共 1,234 × 12 = 14,808 秒 = 4 小時 6 分 48 秒,即 10 月 6 日約 18:00:24 UTC(台北 10 月 7 日 02:00:24)。這是「所有提案者都把目標設成 200M、每個區塊都出塊」的最快情況。
預設 60M 的提案者會在 gas limit 高於 60M 時往下推,所以若只有比例 p 的提案者目標是 200M、其餘 1 − p 目標是 60M,淨漂移每區塊是 (2p − 1)/1024 左右,所需時間為 4.11 小時 ÷ (2p − 1):
| 目標 200M 的提案者比例 p | 到 200M 的時間 |
|---|---|
| 100% | 約 4.1 小時 |
| 90% | 約 5.1 小時 |
| 75% | 約 8.2 小時 |
| 60% | 約 20.6 小時 |
| 50% 以下 | 不會到(在 60M 附近被拉回) |
這個模型假設每個提案者都每個區塊朝自己的目標走滿一步、沒有人設其他值(例如 30M 或 36M)、不計漏塊,所以是推論,不是量測。它的用意在於:Prysm 與 Teku 預設 60M 這件事,不是「一部分驗證者慢一點到 200M」,而是只要預設 60M 的提案者達到一半,整個網路都到不了 200M。Gloas 下 gas limit 如何落到區塊上,我依 Grandine、Prysm 的 release 與 PR 標題(提案者偏好、builder bid 的 gas limit 要對照 payload)推論是「builder 的出價須符合提案者偏好」,沒有逐行讀規格,所以爬坡是否完全等同於上述模型,要待 10 月 6 日之後看鏈上實測。
昨天三條舊線的第四次結算
EIP-7773 最後一次提交是 09-17 21:48 UTC(設定 Sepolia 啟動時間),檔案內仍沒有 EIP-8254;Hoodi 那一列是空白的,所以昨天文中「Hoodi 暫定 10 月 27 日」的出處是 CoinDesk 轉述,規範文件與 ethereum.org 公告都寫「尚未決定」。ACDT 第 98 次的澄清仍無逐字稿。crtahlin/wasp 的 issue 541 仍是開啟狀態、兩則留言、09-28 16:59 UTC 最後更新,升級後的實測還沒出現(因為還沒升級)。
🧠 記
- 「聯絡人名單」要看是哪份文件、什麼狀態。 同一組姓名可以出現在尚未合併的 PR、主網計畫與 Sepolia 計畫三個地方;昨天把一個改主網計畫的 PR 當成 Sepolia 的 issue,是因為只看標題沒看 diff。以後引用 ethereum/pm 的編號,要先分辨 issue 與 PR,再看改的是哪個檔。
- 版本推薦清單要看四欄:發版時間、是否預發布、預設的 gas limit、有沒有更新的修補。 十二個推薦版本中有 2 個是預發布版、3 個距升級不到 5 天、2 個預設 60M(Prysm、Teku),另有一個(Nimbus)的 200M 預設值我沒查到。官方公告會落後最新版一版,開發分支可能已修好但沒出版。
- gas limit 目標是投票,不是設定值。 50% 是分水嶺:達 200M 的提案者過半才會爬上去,速度為 4.11 小時 ÷ (2p − 1),全員 200M 也要 4.1 小時。邊界是這個模型只含兩種目標、忽略漏塊,真實爬坡要等 Sepolia 實測。
✍️ 實踐
用 30 分鐘把今天的數字自己重算一次:
- 在終端機跑下面這段,確認 1,234 區塊與 4 小時 6 分 48 秒:
python3 -c "
g=60_000_000;n=0
while g<200_000_000:
g+=g//1024-1;n+=1
print(n,n*12,g)"- 把 p 換成 0.9、0.75、0.6,用
4.11 ÷ (2p − 1)對照上面表格;想一想若 Sepolia 上 Prysm 與 Teku 提案者合計接近 50%,爬坡會發生什麼事。 - 用
gh api repos/OffchainLabs/prysm/compare/v7.2.0...develop --jq .ahead_by看 Prysm 領先 commit 數,並確認releases/latest是否已經不是 v7.2.0。 - 若你跑 Sepolia 驗證者:依你用的客戶端,到上表對應的 release 頁確認 gas limit 預設值,沒有寫的就當作 60M。
明天要接的待辦:ACDT 第 99 次在 10 月 5 日 14:00 UTC 召開,屆時回頭查 PR 2245 是否合併、12 列客戶端聯絡人補了幾列,以及 Prysm 是否出了含 17609 與 17610 的新版本;Nimbus 的 gas limit 預設值也補查。
🔗 延伸學習
- ethereum/pm PR 2245:Sepolia 升級與事件應變計畫 — 計畫文件全文、四個角色、48 小時驗證清單與客戶端聯絡人欄位全空的出處。
- Ethereum 基金會部落格:Glamsterdam 測試網公告 — Sepolia 時程、各客戶端建議版本,以及 Prysm 與 Teku 預設 60M 的官方說明。
- Prysm PR 17609:加入 Sepolia gas limit 排程 — 排程值、epoch 與「明設者保留」的行為,可對照同一頁連到的其他兩個 PR。
- EIP-8261:Gas Limit Schedule — 說明排程只改預設目標,±1/1024 規則仍是唯一的有效性規則。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 於 Sepolia 的升級(2026-10-06 13:53:36 UTC),以下是我自己查到、整理的事實,請你協助查證並嚴格區分來源:
1. ethereum/pm 的 2243、2244、2246 是修改主網計畫的 PR,2245 是新增 Sepolia 計畫的 PR,四個都尚未合併,Sepolia 計畫的 12 列客戶端聯絡人全空。
2. Prysm 開發分支在 10 月 2 日合併 17601、17609、17610,最新發布版仍是 v7.2.0(預設 gas limit 60M);Teku 26.9.1 同樣預設 60M。
3. EIP-8261 保留 ±1/1024 規則;我用整數模擬(每步 parent // 1024 − 1)從 60M 到 200M 要 1,234 個區塊約 4.1 小時,並推論目標 200M 的提案者低於一半時 gas limit 不會爬上去。
請幫我:
(a) 查 ACDT 第 99 次(10 月 5 日)是否有紀錄或逐字稿,Sepolia 計畫 PR 2245 是否合併、客戶端聯絡人補了誰,Prysm 是否發布含 17609 與 17610 的新版本;
(b) 查 Sepolia 升級後的實際結果:gas limit 實際爬坡曲線與到達 200M 的時間、有沒有被扣住 payload 的槽位、Gloas 第一個區塊是否有人漏塊;
(c) 檢查我的爬坡模型假設(單一路徑、兩種目標、忽略漏塊、起點 60M)哪裡會失準,Gloas 下 gas limit 到底由提案者偏好還是 builder 決定;
(d) 回答時請分成三類標示:「文章/來源明說的」、「你自己另外查證到的(附網址)」、「你的推論」,查不到就明說查不到、不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。