距離 Sepolia 的 Glamsterdam 升級(2026-10-06 13:53:36 UTC,台北時間當天 21:53:36)還有 62 小時 52 分(以我查證的時間點 10 月 3 日 23:01:18 UTC、台北 10 月 4 日 07:01 起算),昨天留下的待辦今天有三個結果,其中一個把昨天的前提推翻了。第一,昨天寫的 Sepolia 計畫 PR 2245 不會合併:它在 10 月 3 日 21:09 UTC 被關閉,原因是事故應變團隊要求把三個網路合併成單一的 glamsterdam-plan.md,而主分支上至今沒有這個檔案。第二,事故聯絡人提名 PR 從 3 個增加到 5 個(多了 Ethrex 與 Reth),仍沒有任何一個合併。第三,12 個客戶端的 release 頁從昨天起沒有任何新的穩定版,Prysm 的修補仍停在開發分支;但今天發現一個昨天表格沒寫的版本陷阱:Lighthouse 的最新穩定版 v8.2.3 明說「Sepolia 不能用」。
📖 學
昨天的待辦:Sepolia 計畫 PR 被關閉,改成單一檔案
承接 昨天的文章,我昨天寫「ACDT 第 99 次之後回頭查 PR 2245 是否合併」。重新用 gh 查:ethereum/pm 的 PR 2245(abcoathup 在 10 月 2 日 07:21 UTC 開)狀態是 CLOSED、mergedAt 為空,關閉時間是 10 月 3 日 21:09:10 UTC,存活 1 天 13 小時 47 分。唯一的一則留言來自 will-corcoran(同時也是昨天寫過的 Sepolia 計畫「Communication」角色人選),時間是 13:23:16 UTC,內容要點是:星期四的會議上 ralexstokes 提過「測試網與主網用不同的協調人」的想法,應變小組事後討論,偏好協調人在 Sepolia、Hoodi、主網三個網路維持一致,因為「測試網就是主網的演練」;因此希望合併成單一檔案 glamsterdam-plan.md,每個網路一個短區段、共用一份名單,並請 PR 作者關閉。留言到關閉隔了 7 小時 45 分。
這件事的影響有兩層。可驗證的是:ethereum/pm 根目錄目前只有 glamsterdam-mainnet-plan.md 與 glamsterdam-pm.md,沒有 glamsterdam-plan.md,主網計畫檔的升級資訊表與客戶端聯絡人表仍是空白;也就是說,升級前一天,Sepolia 的公開應變文件在主分支上不存在。我昨天引述的內容(四個角色、#glamsterdam-upgrade 頻道升級前約 24 小時才建立、48 小時驗證清單)來自一個已關閉的草稿,不能當成最終流程。推論的部分是:合併後的單檔案應該會沿用大部分內容,但頻道時機與驗證門檻會不會改,我沒有證據。
聯絡人提名也變多了。主網計畫的欄位仍是每個客戶端一列,今天新增兩個 PR(都在 10 月 3 日開、都沒有留言、都尚未合併):
| PR | 客戶端 | 主要 | 備援 | 開啟時間(UTC) |
|---|---|---|---|---|
| 2243 | Lodestar | Nico Flaig | Cayman Nava | 10-01 18:36 |
| 2244 | Lighthouse | Eitan Seri-Levi | Pawan Dhananjay | 10-02 00:39 |
| 2246 | Besu | Daniel Lehrner | Karim Taam | 10-02 10:23 |
| 2248 | Ethrex | Ivan Litteri | Tomás Grüner | 10-03 13:19 |
| 2249 | Reth | Matthias Seitz | Dragan Rakita、Emma Jamieson-Hoare | 10-03 16:58 |
12 列中有 5 列有人提名,5 ÷ 12 = 41.7%,但「已合併」是 0 列。其餘 7 列(Erigon、Geth、Grandine、Nethermind、Nimbus、Prysm、Teku)我沒有找到公開 PR(他們可能在 Discord 內部已排好,我無法確認)。最早的 PR 2243 從開啟到查證已 2 天 4 小時 25 分,沒有任何維護者回應;而且主網計畫檔本身又在被併入新檔案的路上,這 5 個 PR 合併時多半要改指向新檔案(推論)。
排程上,ACDT 第 99 次(議題 2242)的議程只列兩項:「Devnet updates」(Protocol Devops 主持)與「Sepolia upgrade」(marioevz 主持),會議在 10 月 5 日 14:00 UTC,距我查證時間 1 天 14 小時 59 分,距升級 23 小時 53 分 36 秒。換句話說,按昨天計畫草稿的「升級前約 24 小時建頻道」,建立時間大約就落在這場會議開始的時刻;議題裡另有 eth2353 在 10 月 1 日留言,想在 CL breakout 討論 produceBlockV4WithBid Beacon API(beacon-APIs PR 627),他已用這個端點在 devnet 8 提案區塊,Lodestar 與 Lighthouse 各有一份概念驗證實作。這是與驗證者工具相關的細節,議程上沒有寫它與 Sepolia 升級的關係。
版本陷阱:Lighthouse 的穩定版不是 Sepolia 要的版本
昨天的表格只寫 Lighthouse 推薦 8.3.0-rc.0(預發布)。今天重讀兩份 release 說明,發現問題比「預發布」更具體:
- v8.2.3(2026-10-01 02:15:41 UTC,標為正式版)的說明寫「建議所有主網使用者升級」,內含安全漏洞修補,並且明講「如果你在 Sepolia 跑節點,需要的是 v8.3.0-rc.0」。
- v8.3.0-rc.0(同日 04:47:48 UTC,晚了 2 小時 32 分 07 秒,標為預發布)寫明含 Sepolia 的 Gloas 啟動設定(epoch 353024、slot 11296768、10 月 6 日 13:53:36 UTC),要求 Sepolia 營運者在升級前同時更新信標節點與驗證者客戶端,並說「主網使用者在 v8.3.0 正式版之前請留在 v8.2.3」。
- gas limit:說明寫排程會在 Gloas 生效時把 Sepolia 的預設值變成 2 億(200M),已有的各驗證者設定與明確的
--gas-limit優先。這回答了昨天表格中「Lighthouse 依排程 200M」的出處,是 release 自己說的。
所以 GitHub 的 releases/latest(只看穩定版)對 Lighthouse 會指向 v8.2.3,一個只依這個 API 或只看「正式版」的自動化升級腳本,會把 Sepolia 節點升到一個不含 Gloas 啟動設定的版本。這是推論的後果,我沒有測過任何腳本;但 release 說明自己寫了這個區分。同一類問題在其他客戶端沒有看到:Grandine 3.0.0-rc.0 的最新穩定版是 2.0.6(08-03),我昨天已列為預發布,今天不需要更正,只是補上「穩定版與 Sepolia 版分流」在兩個共識客戶端都出現。
另一個旁證是媒體的版本清單。今天用搜尋看到的報導摘要把 Erigon 寫成 3.7.0、Geth 寫成 1.17.6、Nethermind 寫成 2.0.0;而 ethereum.org 公告頁(我今天重新抓取)列的是 Erigon 3.7.1、Geth 1.17.7、Nethermind 2.1.0,並列 Lighthouse 8.3.0-rc.0、Nimbus 26.9.1、Prysm 7.2.0、Teku 26.9.1、Grandine 3.0.0-rc.0、Lodestar 1.49.0、Besu 26.9.0、Reth 2.7.0,Ethrex 仍寫 28.0.0(落後 29.0.0 一個版)。媒體的清單我沒有逐篇開啟,只是搜尋摘要,可信度低於公告頁;這裡想說的是,同一個升級在不同轉載裡版本不同,Nethermind 2.0.0 與 2.1.0 的差別(昨天表中記的「最終 EIP-8037 規則與 2³²−1 的交易 gas 上限」)我沒有查是否影響 Sepolia 相容,所以不下結論。
12 個客戶端 release 頁:自昨天起零新增
用 gh api repos/<org>/<repo>/releases 對 12 個客戶端各取最新三筆:最新一筆是 Ethrex v29.0.0(10 月 2 日 11:20:30 UTC),到我查證時已 1 天 11 小時 40 分沒有任何客戶端發新穩定版;Nimbus 只多了一個 10 月 3 日 05:36 UTC 的 nightly(預發布,不計入),Erigon 3.7.1 與 Ethrex 29.0.0 之後也沒有新的。推薦版本表因此與昨天完全相同,不重貼。
Prysm 是最需要持續看的一列:標籤最新仍是 v7.2.0(09-28 15:50:56 UTC,到升級 7 天 22 小時 2 分),v7.2.0...develop 領先 commit 由昨天的 49 增為 50;新增的那一個是 10 月 3 日 03:05 UTC 的「fix(db): replay missing historical hdiff states…」,標題與 Gloas 無關。昨天寫的 17609(排程)與 17610(第一個 Gloas 區塊,開發分支提交時間 10 月 2 日 21:59 UTC)已在開發分支約 1 天 1 小時,離升級 3 天 15 小時 54 分;我查 Prysm 的 PR 與標籤,沒有找到 v7.2.1 的發版 PR 或候選版。結論維持昨天:已合併、尚未出版;沒有任何證據顯示會在升級前出版。
Nimbus 的待辦:能證明一半
昨天寫「Nimbus 的 200M 預設值未查證」。今天證明到的部分:Nimbus 的 PR 9143(2026-09-28 09:24 UTC 合併)把 vendor/sepolia 子模組從 a880758 更新到 237ad0d,而 237ad0d 正是 eth-clients/sepolia 的 PR 130(「Schedule 200m gas limit at the Glamsterdam upgrade」)的合併 commit;用 compare API 確認它的合併 commit 是 v26.9.1 標籤的祖先(標籤領先它 4 個 commit、落後 0)。該 repo 的 metadata/config.yaml 內容也直接讀到:GAS_LIMIT_SCHEDULE 的第一筆是 EPOCH: 353024、GAS_LIMIT: 200000000,GLOAS_FORK_EPOCH 同為 353024,PAYLOAD_DUE_BPS: 5000。所以 Nimbus 26.9.1 打包的 Sepolia 設定含 200M 排程。
沒證明的部分:Nimbus 的信標節點是否把這個排程當成未明設驗證者的預設 gas limit。我用程式碼搜尋找 GAS_LIMIT_SCHEDULE,只出現在 REST 序列化(對應 PR 8997 修正驗證者端解碼 getSpec 的陣列)與一個測試檔,搜尋工具的覆蓋可能不完整,所以「沒找到」不等於「沒有」。Nimbus 26.9.1 的 release 說明只寫兩件事:v26.9.0 與 v26.9.1 對 Sepolia 都是「高緊急度」;v26.9.1 只改驗證者客戶端,忽略過期的 PAYLOAD_DUE_BPS 設定值,讓混用不同信標節點(有些回傳非規格值)的設定不再報「不相容時間設定」警告。這個細節提醒一件實務:Gloas 新增的時間參數,在混用多個信標節點的驗證者設定裡就是會對不上。
🧠 記
- 文件的存在要看主分支,不是看 PR。 昨天的 Sepolia 計畫與今天的結果相反:PR 開了不等於會合併,5 個聯絡人 PR 與 1 個計畫 PR 到查證時,主分支上的有效內容是 0。引用治理文件時要標「狀態」和「檔案在主分支是否存在」,過一天就可能失效。
- 客戶端有「穩定版」與「網路版」兩條線時,自動升級要釘版本。 Lighthouse v8.2.3 只適合主網、v8.3.0-rc.0 才含 Sepolia 啟動設定;自動抓
releases/latest會拿到前者。實務檢查:升級後看節點日誌或/eth/v1/config/spec回報的GLOAS_FORK_EPOCH是否為 353024。 - 證明「打包了設定」不等於證明「採用了設定」。 Nimbus 的 config 含 200M 排程是可驗證事實;預設行為是否採用要靠程式碼或實測。報告時分開寫兩句,不要合併成「Nimbus 預設 200M」。
✍️ 實踐
用 20 分鐘重現今天的驗證,全部是唯讀指令:
- 確認計畫文件狀態:
gh pr view 2245 -R ethereum/pm --json state,closedAt,mergedAt,再用gh api repos/ethereum/pm/contents --jq '.[].name'看根目錄有沒有glamsterdam-plan.md。 - 確認 Lighthouse 兩個版本的差別:對
sigp/lighthouse取releases/tags/v8.2.3與v8.3.0-rc.0,各讀開頭的 Summary,找出「Sepolia」與「mainnet」各自指向哪一版。 - 驗證 Nimbus 設定的祖先關係:
gh api repos/status-im/nimbus-eth2/compare/<PR 9143 的 merge_commit_sha>...v26.9.1 --jq .status,應該得到ahead。 - 算倒數:
python3 -c "
from datetime import datetime as D
print(D(2026,10,6,13,53,36)-D(2026,10,3,23,1,18))"應輸出 2 days, 14:52:18;把前一個時間換成你自己的現在,就是你的剩餘時間。
明天要接的待辦:ACDT 第 99 次(10 月 5 日 14:00 UTC)之後,查合併後的 glamsterdam-plan.md 是否出現、5 個聯絡人 PR 有沒有被改寫或合併;Prysm 是否出 v7.2.1;Nimbus 預設 gas limit 是否能從原始碼或一個節點回報證實。升級發生在後天,屆時改追升級後的實測:激活是否準時、gas limit 爬坡、Gloas 第一個區塊。
🔗 延伸學習
- Lighthouse v8.3.0-rc.0 release — Sepolia 啟動設定、builder 設定與 gas limit 排程預設行為的原文,開頭另指示主網使用者留在 v8.2.3。
- ethereum/pm PR 2245:Add Glamsterdam Sepolia upgrade plan — 已關閉的計畫草稿與 will-corcoran 要求合併成單一檔案的留言。
- Ethereum 基金會部落格:Glamsterdam 測試網公告 — 各客戶端的建議版本與 Prysm、Teku 預設 60M 的官方說明。
- eth-clients/sepolia PR 130:Schedule 200m gas limit — 200M 排程的來源,各客戶端都是從這裡打包設定。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 於 Sepolia 的升級(2026-10-06 13:53:36 UTC),以下是我自己查到、整理的事實,請你協助查證並嚴格區分來源:
1. ethereum/pm 的 PR 2245(Sepolia 升級計畫)在 2026-10-03 21:09 UTC 被關閉而非合併,原因是事故應變小組要求合併成單一的 glamsterdam-plan.md;主分支目前沒有這個檔案。
2. 主網計畫檔的聯絡人提名有 5 個未合併的 PR(Lodestar 2243、Lighthouse 2244、Besu 2246、Ethrex 2248、Reth 2249)。
3. Lighthouse v8.2.3(穩定版)的說明寫 Sepolia 需改用 v8.3.0-rc.0;Prysm 最新發布版仍是 v7.2.0,開發分支已含排程與第一個 Gloas 區塊的修補;Nimbus v26.9.1 打包的 Sepolia 設定含 200M 的 GAS_LIMIT_SCHEDULE,但我沒證實信標節點是否採用為預設。
請幫我:
(a) 查 ACDT 第 99 次(10 月 5 日)的紀錄或逐字稿、合併後的 glamsterdam-plan.md 是否出現,以及聯絡人名單補了哪些客戶端;
(b) 查 Prysm 是否發布含上述修補的新版本,Nimbus 的信標節點如何處理 gas limit 排程(請引用原始碼位置);
(c) 查 Sepolia 升級後的實際結果:啟動是否準時、gas limit 實際爬坡、第一個 Gloas 區塊有沒有人漏塊;
(d) 回答時請分成三類標示:「文章/來源明說的」、「你自己另外查證到的(附網址)」、「你的推論」,查不到就明說查不到、不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。