距離 Sepolia 的 Glamsterdam 升級(2026-10-06 13:53:36 UTC,台北時間當天 21:53:36)還有 1 天 14 小時 47 分(以我查證的時間點 10 月 4 日 23:06 UTC、台北 10 月 5 日 07:06 起算),ACDT 第 99 次會議(10 月 5 日 14:00 UTC)還有 14 小時 54 分,所以今天的資料全部是會議之前的狀態。承 昨天的區塊鏈 的待辦,今天有三個結果:第一,事故聯絡人名單從 5 個提名增加到 8 個,仍然沒有任何一個合併,單一計畫檔 glamsterdam-plan.md 在主分支上依舊不存在;第二,我昨天的紀錄有兩處錯誤,一處是 Prysm 其實已有候選版標籤,另一處是 Ethrex 並沒有 v29.0.0 正式版,下面逐一更正;第三,新增一個昨天沒看到的落差:Prysm 與 Teku 的 200M gas limit 排程都已合併進開發分支,但兩者的穩定版都還不含它。
📖 學
一、先更正昨天的兩處
昨天我寫「查 Prysm 的 PR 與標籤,沒有找到 v7.2.1 的發版 PR 或候選版」,這句是錯的。今天用 git/matching-refs/tags/v7.2 列出標籤,OffchainLabs/prysm 有一個 v7.2.1-rc.0,是輕量標籤(沒有附註、沒有發布日期),指向 commit fea24b41,也就是 10 月 3 日 03:05 UTC 那個「fix(db): replay missing historical hdiff states…」,與開發分支目前的頂端是同一個 commit。v7.2.0...v7.2.1-rc.0 領先 50 個 commit、落後 0,所以昨天提到的排程(17609)與第一個 Gloas 區塊修補(17610)都在這個標籤裡。標籤的建立時間 GitHub 沒有直接給;我找到的最早旁證是以該名稱為分支的一次 CI 執行,建立於 10 月 3 日 16:44:41 UTC,比我昨天查證的 23:01:18 UTC 早 6 小時 17 分,所以昨天不是「還沒有」而是我沒查到。我昨天用的是列 release 頁的方式,而這個標籤沒有對應的 release 物件(今天 Prysm 的 release 頁最新一筆仍是 v7.2.0,09-28 15:50:56 UTC);用 release API 找不到標籤,這是我的方法錯誤,不是 Prysm 瞞著不說。目前能確定的是「候選版標籤存在、尚無 release、我沒有確認是否有對應的容器映像」;不能確定的是它會不會在升級前變成正式版。
第二處是 Ethrex。昨天我把「Ethrex v29.0.0,10 月 2 日 11:20:30 UTC」當成最新穩定版,並據此寫「已 1 天 11 小時沒有新穩定版」。今天重取 release 清單,Ethrex 的最新穩定版是 v28.0.0(09-29 04:03:04 UTC),v29.0.0 只有三個候選標籤:rc.1(10-02 06:19:27 UTC,有 release 頁)、rc.2(只有標籤)、rc.3(10-04 22:31:58 UTC,有 release 頁,標為預發布),不存在 v29.0.0 標籤,用標籤名稱查 release 也回 404。我無法重現昨天的那一筆,可能是我把候選版讀成正式版,也可能是當時有 release 後來被撤下,兩者我都沒有證據。這與 ethereum.org 公告頁一直寫 Ethrex 28.0.0 是一致的,所以昨天表格裡「Ethrex 落後一版」的說法也要撤回:28.0.0 就是公告頁的建議版本。這件事不影響結論,因為我另外驗證了 v28.0.0 的 cmd/ethrex/networks/sepolia/genesis.json 已含升級時間戳(見第四節)。
二、事故聯絡人:5 個提名變 8 個,合併仍是 0
ethereum/pm 在昨天之後多了三個提名 PR,全部都只改主網計畫檔的一格:
| PR | 客戶端 | 主要 | 備援 | 開啟時間(UTC) |
|---|---|---|---|---|
| 2250 | Nimbus | tersec | 0xshum | 10-03 23:04 |
| 2251 | Teku | Enrico | Stefan | 10-04 20:55 |
| 2252 | Prysm | 「Tag the Prysm team on Eth R&D Discord」 | (空) | 10-04 21:44 |
加上先前的 Lodestar、Lighthouse、Besu、Ethrex、Reth,現在 12 個客戶端有 8 個提名,8 ÷ 12 = 66.7%,已合併仍是 0 列;還沒出現公開 PR 的是 Erigon、Geth、Grandine、Nethermind 四個(可能在 Discord 內部已排好,我無法確認)。Prysm 那一格值得注意:它不是人名而是一句「請在 Eth R&D Discord 標記 Prysm 團隊」,備援欄留空,與其他客戶端「兩個具名的人」的格式不同;這是一個團隊頻道代替個人聯絡窗口的選擇,好處是不會因為某個人睡著而漏接,代價是升級當下沒有一個固定的人負責。這是我對格式的解讀,PR 本身沒有留言說明。
另外兩件可驗證的事。第一,glamsterdam-plan.md 到今天仍不存在,根目錄只有 glamsterdam-mainnet-plan.md 與 glamsterdam-pm.md,而 glamsterdam-pm.md 的 Sepolia 列有完整的 epoch 353024、slot 11296768、Unix 1791294816,Hoodi 列仍寫 TBD。第二,主網計畫檔的免責聲明段落寫的是「Fusaka network upgrade」而不是 Glamsterdam,表示這份範本是從 Fusaka 時期複製來的,尚未改字;這是一個小疏漏,也說明這份文件目前還是半成品。8 個提名 PR 裡最早的 PR 2243 從開啟到今天已 3 天 4 小時 29 分,沒有任何一則留言或審查。若 ACDT 第 99 次要在升級前約 24 小時建立 #glamsterdam-upgrade 頻道(這個「約 24 小時」來自主網計畫檔現行文字),時間點就落在這場會議前後,屆時名單是否合併可以直接觀察。
三、更大的落差:穩定版的 gas limit 預設值不一致
升級那一刻,Sepolia 的 gas limit 排程要從 60M 變成 200M。昨天我整理過這個排程由 eth-clients/sepolia 的 PR 130 引入,今天更清楚的是「誰的穩定版真的帶著它」:
| 客戶端 | 穩定版 | 200M 排程在哪裡 | 結論 |
|---|---|---|---|
| Lighthouse | v8.2.3 / v8.3.0-rc.0 | rc.0 的說明寫 Gloas 生效時預設變 200M | 要用預發布版 |
| Nimbus | v26.10.0 | 打包的 Sepolia 設定含排程;信標節點是否採用為預設仍未證實 | 設定有,行為待證 |
| Teku | 26.9.1 | PR 11358(09-29 11:48:39 UTC)已合併進 master,26.9.1 發布於 09-28 01:16:09,早它 1 天 10 小時;之後沒有新標籤 | 穩定版預設仍 60M |
| Prysm | v7.2.0 | PR 17609 已在 v7.2.1-rc.0 標籤內;v7.2.0 沒有 | 穩定版預設仍 60M |
Teku 與 Prysm 的穩定版預設仍是 60M,是 ethereum.org 公告頁自己寫的:「Prysm 7.2.0 supports the Sepolia fork but defaults to a 60M gas limit after activation」,Teku 26.9.1 同理,要 200M 必須顯式設定(Teku 的旗標是 --validators-builder-registration-default-gas-limit=200000000,Prysm 用第 2 版 proposer settings 或 keymanager API)。今天補上的是時間線:這兩個客戶端「修好了」都發生在穩定版之後,而且今天為止沒有一個進到穩定版。
這會造成什麼後果,我用一個簡化的平均場模型估算。假設區塊 gas limit 仍由提案者偏好決定,每個區塊最多朝偏好方向改變 1/1024;若有比例 p 的提案者偏好 200M、其餘 1−p 偏好留在 60M,在 60M 到 200M 之間,期望每區塊的相對變動是 (2p−1)/1024。從 60M 爬到 200M 需要 ln(200/60) ÷ ln(1+(2p−1)/1024) 個區塊:
| 偏好 200M 的提案者比例 p | 所需區塊數 | 約合時間(12 秒一塊) |
|---|---|---|
| 100% | 約 1,234 | 4.1 小時 |
| 90% | 1,542 | 5.1 小時 |
| 80% | 2,055 | 6.9 小時 |
| 70% | 3,083 | 10.3 小時 |
| 60% | 6,165 | 20.5 小時 |
| 55% | 12,329 | 41.1 小時 |
| 50% 以下 | 不會爬升 | 不會爬升 |
100% 那一列與昨天的模擬(1,234 個區塊)吻合。這個模型忽略了隨機性、提案者輪替不均與步幅的取整,而且我沒有逐條讀過 Gloas 的提案者偏好機制是否改變這個行為,所以只當作量級參考,不是預測。它真正說明的是門檻:只要預設 60M 的客戶端占提案權重達一半以上,gas limit 不僅爬不到 200M,還會被推回去;而升級後 48 小時的驗證窗口(昨天算到 10 月 8 日 13:53:36 UTC 結束)只夠容納 p 在 55% 以上的情境。各客戶端在 Sepolia 驗證者中的實際比例我查不到,所以不下結論。
四、版本「含不含升級時間」要在標籤上查
執行層用 Unix 時間戳決定分叉,共識層用 epoch,兩者換算是 1655733600 + 11296768 × 12 = 1791294816(1655733600 是 Sepolia 信標鏈創世時間,PR 2205 的說明就是這樣寫的,我也重算過),也就是 353024 個 epoch、11,296,768 個 slot。Geth 在 core/forkid/forkid_test.go 的 Sepolia 測試表裡寫:升級前一刻(時間戳 1791294815)的分叉識別碼是 0x268956b6、Next 指向 1791294816;升級後第一個區塊變成 0x6c1d9423。這個識別碼會在 eth 協定握手時交換,沒升級的執行層節點在分界後會與已升級的節點識別碼不符而被斷線,所以落後者的症狀是「peer 掉光」,而不是產生一條分叉鏈(這是對 EIP-2124 機制的推論,我沒有在 Sepolia 上實測)。共識層側,GLOAS_FORK_VERSION 是 0x90000076,依規格它會進 gossip 主題名稱的分叉摘要(規格背景,今天沒有逐條驗證)。
我用標籤逐一檢查四個執行層客戶端的 Sepolia 設定是否已含 1791294816:
| 客戶端 | 不含 | 含 | 備註 |
|---|---|---|---|
| Geth | v1.17.5 | v1.17.6、v1.17.7 | v1.17.7 的 release 說明明寫兩版都準備好 Sepolia 的 Amsterdam 分叉,v1.17.7 是因為 v1.17.6 發布到 Ubuntu PPA 失敗而趕出的版本 |
| Erigon | v3.6.1 | v3.7.0、v3.7.1 | |
| Besu | 26.8.1 | 26.9.0 | |
| Ethrex | (未查更早版本) | v28.0.0、v29.0.0-rc.1、rc.3 | 公告頁建議的 28.0.0 已含 |
Nethermind 與 Reth 我沒有驗證:它們的鏈設定放在壓縮資源或外部套件裡,我直接抓檔案找不到那個字串,所以空白是「沒查到」不是「沒有」。這個檢查的方法陷阱是我第一次用 GitHub 程式碼搜尋,它只搜預設分支,Geth 的 master 含有時間戳,若據此推論,v1.17.5 也會被誤判為「已準備好」;必須用標籤逐一取檔案才準。
五、Nimbus:穩定版出現,但昨天的問題沒有新證據
Nimbus v26.10.0 在 10 月 4 日 11:28:04 UTC 發布,是昨天不存在的穩定版,距升級還有 2 天 2 小時 25 分。說明寫 v26.9.0、v26.9.1、v26.10.0 對 Sepolia 都是高緊急度,且「v26.9.0 或更新的版本都與 Sepolia 的 Glamsterdam 分叉相容」;改進項目包括 Glamsterdam 分叉轉換提示(PR 9175)、改善 Sepolia peer 連線(PR 9182)、列舉驗證者時涵蓋已被懲罰與退出中的驗證者(PR 9186)。這份說明明確表示 26.9.1 就夠用,所以 26.10.0 不是升級的必要條件。昨天留下的「信標節點是否把 GAS_LIMIT_SCHEDULE 當成預設」今天我沒有重新查原始碼,維持未證實。
🧠 記
- 「已合併」和「用戶拿得到」是兩個狀態。 Prysm 的 200M 排程與 Teku 的 PR 11358 都在開發分支;Teku 沒有後續標籤,Prysm 有候選標籤但沒有 release。查一個修補是否「在升級前到得了節點」,要看標籤、release、容器映像三層,不是看 PR 狀態。
- 查東西要用對層級。 release API 只列有 release 物件的版本,輕量標籤要用
git/matching-refs/tags;程式碼搜尋只看預設分支,要確認某版本含不含一個設定,必須在該標籤上取檔案。我昨天與今天的兩個錯誤都來自用錯層級。 - 更正自己的紀錄要寫出方法錯在哪。 「沒找到候選版」這種否定句最危險,因為它的可信度取決於搜尋方法;今後否定結論都附上我用的查詢方式。
✍️ 實踐
用 20 分鐘重現今天的驗證,全部是唯讀指令(注意 zsh 要把含 ? 的網址加引號):
- 看標籤而不是 release:
gh api repos/OffchainLabs/prysm/git/matching-refs/tags/v7.2 --jq '.[].ref',應看到refs/tags/v7.2.1-rc.0;再用gh api repos/OffchainLabs/prysm/compare/v7.2.0...v7.2.1-rc.0 --jq '[.ahead_by,.behind_by]'得到[50,0]。 - 在標籤上檢查執行層設定:
gh api "repos/ethereum/go-ethereum/contents/params/config.go?ref=v1.17.5" -H "Accept: application/vnd.github.raw" | grep -c 1791294816,v1.17.5 得 0、v1.17.6 得 1。 - 驗證時間戳換算與倒數:
python3 -c "
from datetime import datetime as D, timezone as Z
print(1655733600 + 11296768*12)
print(D(2026,10,6,13,53,36,tzinfo=Z.utc) - D(2026,10,4,23,6,0,tzinfo=Z.utc))"應輸出 1791294816 與 1 day, 14:47:36;把後一個時間換成你的現在就是你的剩餘時間。
4. 自己跑爬升模型:改 p 值,算 math.log(200/60) / math.log(1 + (2*p-1)/1024),看門檻在哪裡。
明天(升級日)要接的待辦:ACDT 第 99 次之後,glamsterdam-plan.md 是否出現、8 個提名 PR 與另外 4 個客戶端的狀態;Prysm 的 v7.2.1-rc.0 是否有 release、Teku 是否出含 PR 11358 的版本;升級當天 13:53:36 UTC 之後改追實測:啟動是否準時、gas limit 實際走勢、Gloas 第一個區塊。
🔗 延伸學習
- Geth v1.17.7 release — 明寫 v1.17.6 與 v1.17.7 都已為 Sepolia 的 Amsterdam 分叉準備好,以及為何急著發 v1.17.7。
- Nimbus v26.10.0 release — 「v26.9.0 以後都與 Sepolia 分叉相容」的原文與緊急度分級。
- Teku PR 11358:Schedule 200m gas limit for Sepolia — Teku 的 200M 排程,已合併到 master、尚未進入穩定版。
- Prysm 比較:v7.2.0 到 v7.2.1-rc.0 — 候選版標籤相對 v7.2.0 的 50 個 commit,含排程與第一個 Gloas 區塊修補。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 於 Sepolia 的升級(2026-10-06 13:53:36 UTC,epoch 353024),以下是我自己查到、整理的事實,請你協助查證並嚴格區分來源:
1. ethereum/pm 主網計畫檔的事故聯絡人提名目前有 8 個未合併的 PR(Lodestar 2243、Lighthouse 2244、Besu 2246、Ethrex 2248、Reth 2249、Nimbus 2250、Teku 2251、Prysm 2252),單一檔案 glamsterdam-plan.md 在主分支上不存在。
2. Prysm 有輕量標籤 v7.2.1-rc.0(領先 v7.2.0 共 50 個 commit,含 200M 排程 PR 17609),但沒有 release;Teku 的 200M 排程 PR 11358 已合併進 master,但最新標籤仍是 26.9.1;ethereum.org 公告頁寫兩者穩定版預設 gas limit 為 60M。
3. 我用簡化模型估算:gas limit 從 60M 爬到 200M,所需區塊數 = ln(200/60) / ln(1 + (2p-1)/1024),p 為偏好 200M 的提案者比例;p=100% 約 1,234 區塊,p=55% 約 12,329 區塊,p<=50% 不會爬升。
請幫我:
(a) 查 ACDT 第 99 次(10 月 5 日 14:00 UTC)的紀錄,看 glamsterdam-plan.md 是否合併、事故頻道何時建立、四個尚未提名的客戶端(Erigon、Geth、Grandine、Nethermind)是否補上;
(b) 查 Prysm 是否正式發布含 200M 排程的版本、Teku 是否發布含 PR 11358 的版本;
(c) 檢查我的模型在 Gloas 的提案者偏好機制(ePBS 之後 gas limit 由誰決定)下是否仍成立,並指出需要修正的地方;
(d) 回答時請分成三類標示:「文章/來源明說的」、「你自己另外查證到的(附網址)」、「你的推論」,查不到就明說查不到、不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。