Glamsterdam devnet-11 是 ethPandaOps 為以太坊下一次硬分叉排的一張短命測試網,規格頁寫明它是 devnet-8 的複本、沒有新 EIP、不做對抗測試,目的只有一個:讓 Lido、Optimism、Arbitrum 這些 L2 與協議方,能在一條正常走完分叉轉換的網路上驗證自己的系統。今天拆這份規格頁,看一次硬分叉的測試網是怎麼被設計出來的,以及它順手揭露的各客戶端就緒程度。
讀到的程度:我透過網頁擷取工具讀了規格頁(notes.ethereum.org 上的 glamsterdam-devnet-11),但那個工具會先用小模型摘要再回傳,所以不是逐字讀原文,表格內容可能有轉述誤差。這份頁面的客戶端狀態標註「驗證於 2026-09-08」,距今已兩個多月,我沒有查到 devnet-11 實際跑得如何,也沒有讀到 ACDE 第 245 次的結論。標明「自算」的數字是我自己推的。
📖 學
一、這張網路要回答什麼問題
規格頁把 devnet-11 定位成「快樂路徑的分叉轉換測試網」:創世時間是 2026-09-14 12:00 UTC,Gloas(共識層)在 epoch 450 啟用,也就是 2026-09-16 12:00 UTC,創世後 48 小時。自算:450 個 epoch 乘上每 epoch 32 個 slot、每 slot 12 秒,是 172,800 秒,剛好 48 小時,和頁面相符。Lido 要求分叉前至少要有兩天,這個 48 小時應該就是針對它。
它刻意不做兩件事:不加新 EIP,也不做對抗測試。EIP 清單與 devnet-8 相同,僅有三處差異:EIP-7732(ePBS)與 EIP-8037 做了更新,EIP-7610 被移除。這等於把變因壓到最小,因為 devnet-8 本身會一直活到主網分叉,devnet-11 只負責驗證「從舊規則切到新規則的那一刻」。
二、與 devnet-8 的差異
| 參數 | devnet-8 | devnet-11 |
|---|---|---|
| 創世 | 2026-08-13 12:00 UTC | 2026-09-14 12:00 UTC |
| Gloas epoch | 1536 | 450 |
| gas 上限升到 2 億的 epoch | 1566 | 480 |
| Watchtower | 開 | 關,逐台滾動、分叉前後各 4 個 epoch 內不動 |
| Buildoor 主機記憶體 | 16 GB | 32 GB(devnet-9 曾 OOM) |
自算:兩張網路從分叉到 gas 上限調高都隔 30 個 epoch(1566 減 1536、480 減 450),約 3 小時 12 分鐘,頁面標示的 15:12 UTC 與此一致。gas 上限由 6,000 萬升到 2 億,是這一輪 Glamsterdam 測試的共同主題。節點規模維持 84 個節點加 2 個 bootnode 與 8 個 buildoor,驗證者 84,000 個;自算:84 等於 6 個共識客戶端乘 7 個執行客戶端乘 2,平均每節點約 1,000 個驗證者。
三、客戶端就緒度:13 個裡有 3 個亮紅燈
頁面為每個客戶端列了主幹映像的狀態。依我的計數,標綠的有 5 個(Geth、Nethermind、Erigon、Lodestar、Teku),標警告的 5 個(Besu、Nimbus-EL、Ethrex、Lighthouse、Nimbus),標紅的 3 個(Reth、Prysm、Grandine)。紅燈的原因各不同:Reth 還在 pre-12265 版本,需要未發布的 revm 修正;Prysm 的 develop 分支仍像 devnet-9 那樣分叉,備案是退回特定 commit;Grandine 還停在 alpha.14,沒有第 5594 號 PR,會接受別的客戶端會拒絕的 bid。警告類多半是「仍在執行已被移除的 EIP-7610」:Besu、Nimbus-EL、Ethrex 三個執行客戶端都還在強制它。
這張表的教訓是,多客戶端的共識安全來自「大家行為一致」,而不是各自正確。只要一個客戶端對邊界案例的判斷不同(例如 Grandine 接受 block_hash 等於 parent_block_hash 的 bid),就會在分叉點分出另一條鏈。所以才需要一張專門的轉換測試網,把「誰跟得上」在上主網前暴露出來。
四、頁面列出的未決事項
頁面把待解問題寫成清單,值得看的有三類。第一,EIP-7610 要在週一前修,還是排出 devnet-11 範圍(Sepolia 仍在範圍內),執行客戶端是 4 比 3 分裂。第二,EIP-8253 不在 devnet-11 裡,要由 ACDE 第 245 次決定歸 Glamsterdam 或下一版 Hegotá,而且不論歸哪邊都需要另外的測試 fixture。第三,EIP PR 12249 已被拒絕三次、準備關閉,PR 12303 指出若客戶端在最上層呼叫 revert 時回填 7702 的費用會分歧。這些都是「規格尚未定稿,但測試網已經要開」的實況。
五、還沒回答的問題
這份頁面是 9 月上旬寫的。我不知道 devnet-11 有沒有如期在 9 月 14 日創世、各客戶端後來有沒有補齊;而我讀過的近期資料顯示,Hoodi 上的 Glamsterdam 排程後來在 ACDE 第 248 次因 EIP-8037 的合約互動疑慮被延後(見前幾天的筆記)。因此 devnet-11 的「快樂路徑」與後來的延期之間的關係,我沒有證據可下結論。
🧠 記
- 一句話: devnet-11 是 devnet-8 的短命複本,只驗證 Glamsterdam 的分叉轉換,不加 EIP、不做對抗測試。
- 時間: 創世 2026-09-14,Gloas 在 epoch 450(創世後 48 小時,自算驗證),gas 上限在 epoch 480 由 6,000 萬升到 2 億。
- 就緒度: 13 個客戶端中 5 綠、5 警告、3 紅(自計,依頁面 9/8 狀態)。
- 設計原則: 變因壓到最小,測試網只回答單一問題。
- 邊界: 我讀的是摘要工具轉述的規格頁,狀態停在 9/8,沒查後續結果。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 打開規格頁,自己把 epoch 450 換算成時間,再把 epoch 480 換算一次,和頁面標示的時間比對(約 5 分鐘)。
- 做一張表:13 個客戶端各自的狀態與阻擋原因,標出哪些是「還沒實作規格」、哪些是「仍在執行已移除的規則」(約 10 分鐘)。
- 找 ethereum/pm 的 ACDE 第 245 次議程或紀錄,看 EIP-8253 的結論與日期,把來源與日期記下來(約 10 分鐘)。
可證偽預測(台北時間):
- 預測一: 2026 年 12 月 15 日前,Glamsterdam 在 Hoodi 重新排出具體分叉日期 30%。
- 預測二: 2026 年 12 月 31 日前,EF 或核心開發者公布 Glamsterdam 主網分叉日期 10%。
🔗 延伸學習
- glamsterdam devnet 11(ethPandaOps 規格頁):有透過擷取工具讀,本文所有表格與清單的來源,為摘要轉述。
- Ethereum’s Glamsterdam Upgrade Enters Final Testing Phase(KuCoin 快訊):只看到搜尋結果標題,沒打開。
- Christine D. Kim 的 ACDE 週報系列:只看到搜尋結果標題,沒打開,是追蹤每次 ACDE 結論的入口之一。
💬 問 AI
我在學以太坊 Glamsterdam 的 devnet-11(ethPandaOps 規格頁)。我只透過摘要工具讀到頁面轉述,頁面狀態停在 2026-09-08,沒讀後續結果。
我目前的理解(請逐條檢查):
- devnet-11 是 devnet-8 的複本,沒有新 EIP,只驗證分叉轉換,創世後 48 小時啟用 Gloas。
- gas 上限在分叉後 30 個 epoch 由 6,000 萬升到 2 億。
- 13 個客戶端裡約有 3 個(Reth、Prysm、Grandine)當時未就緒。
- 多客戶端網路的風險在於邊界案例行為不一致會造成分叉。
請幫我:
(a) 解釋為什麼硬分叉前需要專門的「轉換測試網」,與一般 devnet 差在哪;
(b) 說明 EIP-7610 被移除後,仍強制它的客戶端會在什麼情境與其他客戶端分歧;
(c) 列出我該去哪裡查 devnet-11 後來的實際結果(標示你確定與不確定的來源);
(d) 每個結論標示「來源說的」、「你另外查到的(附網址)」、「你的推論」,不要編造連結、日期、數字。
這是學習用,不要給投資建議。