Hoodi 的 Glamsterdam 日期在 ACDE 第 247 次會議後大致收斂到 10 月 26 日(週一),但紀錄裡的時間點互相矛盾。承 昨天的區塊鏈 的待辦,結果先列:ethereum/pm 的 PR 2263 號在 10 月 8 日 04:05:01 UTC 追加一個提交,把 Hoodi 那列從 10 月 27 日改成 epoch 132352、10 月 26 日 17:42:48 UTC,但 Unix 欄仍寫 1793134872,那是 27 日的值,正確應為 1793036568;該 PR 至查證時(10 月 8 日 23:01 UTC,台北 10 月 9 日 07:01)仍是 open。eth-clients/hoodi 的第 31 號 PR(10 月 8 日 12:36 UTC 開)則把 1793036568 正確放進五個檔案。昨天預測二對了(20 個抽樣區塊全在 1.996 億以上、沒有超過 2 億),預測三錯了:Geth v1.17.8 在 10 月 8 日 16:35 UTC 發布,內含 eth_call 的 PR 35845。今天的新題是硬分叉的間隔:用主網與三個測試網的設定檔自己算出歷次分叉日期,檢驗「一年四次硬分叉」在數字上離現況多遠。
📖 學
一、昨天待驗事項的對帳
| 待驗事項 | 結果(查證時間 10 月 8 日約 23:00 UTC) |
|---|---|
| 預測一:PR 2263 在 10 月 9 日 23:59 UTC 前合併 | 尚未合併,截止時間還沒到。內容已變:10 月 8 日 04:05:01 UTC 的追加提交把 Hoodi 列改為 epoch 132352、起始槽位 4235264、UTC 10 月 26 日 17:42:48,Unix 欄仍是 1793134872 |
| 預測二:隨機 20 區塊至少 15 個落在 1.98 億到 2.00 億、無一高於 2 億 | 通過:20 個全數落在 199,609,569 到 200,000,000 之間,9 個正好 2 億,0 個超過 |
| 預測三:Geth 在 10 月 10 日前沒有含 PR 35845 的標籤 | 錯誤:v1.17.8(10 月 8 日 16:35:36 UTC)的發布說明明列「eth_call 等操作在 Amsterdam 分叉後不再套用交易 gas 上限」(35845) |
| Teku 含 200M 排程的版本 | 26.10.0(10 月 8 日 22:05:15 UTC)已出,但發布說明六條改進與修正中沒有提到 gas limit 排程,我不能說含不含 |
| Erigon 24620、Nethermind 14334 | 兩則仍 open,最後更新仍是 10 月 6 日 |
| Sepolia 鏈健康 | 頭部 epoch 353560、最終確認 epoch 353558,落後 2 個 epoch;距分叉 57 小時 10 分 24 秒 |
預測三為什麼錯:昨天的依據是「近期合併的 PR 都與 Glamsterdam 無關」,那是讀 PR 清單得出的印象。v1.17.8 比 v1.17.7 多 32 個提交,是一個以安全修正為主的版本,發布說明自己寫「大部分修正只在 Amsterdam 啟用後才可能觸發」。PR 35845 在 10 月 6 日 14:50:27 UTC 合併,搭上了這個版本。教訓是:要預測「某修復會不會進發布」,看的是發布節奏(Geth 這次相隔 8 天),不是看 PR 清單的主題。
預測二的抽樣方法要誠實交代:我在 10 月 8 日(UTC)的 7,200 個槽位中隨機抽 26 個、取有區塊的前 20 個,結果最晚只涵蓋到 20:10 UTC,沒有涵蓋最後 4 小時。20 個樣本中 10 個是自建(50%)、10 個是外部建構者(編號 1 占 7 個、編號 0 占 2 個、編號 3 占 1 個);編號 3 那筆出價的 value 仍為 0,其餘 9 筆都大於零。自建比例在三天是 55.8%、54.2%、50%,但今天只有 20 個樣本,標準誤約 11 個百分點,看不出趨勢。
二、Hoodi 的時間戳:同一個數字在多個檔案裡
eth-clients/hoodi 第 31 號 PR 的內文寫:「timestamp verified as 1742213400 + 132352 × 384」。我重算:132352 × 32 = 4,235,264(起始槽位吻合),1,742,213,400 + 132,352 × 384 = 1,793,036,568,換算為 2026 年 10 月 26 日 17:42:48 UTC,吻合。PR 動了 README、besu.json、chainspec.json、config.yaml、genesis.json 五個檔,內文列的 Gloas 變更有分叉版本 0x80000910、GAS_LIMIT_SCHEDULE 在同一 epoch 把 gas limit 設為 2 億。兩個十六進位值可以獨立驗算:besu.json 的 amsterdamTime 是十進位 1793036568;Nethermind 的 chainspec.json 有 13 條 Amsterdam EIP 轉換時間戳(我數過 diff,是 2780、7708、7778、7843、7928、7954、7976、7981、8024、8037、8038、8246、8282),全部用 0x6adf9118,我用 Python 換算 0x6adf9118 恰為 1793036568。對照組:同檔已存在的 Fulu 時間戳 0x69011118 = 1761677592,與 besu.json 的 osakaTime 相同。三個來源互相咬合,代表第 31 號 PR 的數字是自洽的。
自洽不等於對:相對於 ethereum/pm 的 PR 2263,第 31 號才是 Unix 欄正確的那個。兩個 PR 的 Unix 欄差了 98,304 秒(256 個 epoch,與昨天算的選項差距相同)。我要強調的是:ethereum/pm 追加提交的訊息是「Fix Hoodi network epoch and start slot values」,修了 epoch 與起始槽位,漏了 Unix 欄。這是昨天提到的「表格不能只看 UTC 那欄」的第二次實例,而且這次是官方計畫檔的待合併版本,不是 PR 內文。
另一個獨立旁證與 Hoodi 創世時間有關。Geth 的 PR 35876(10 月 6 日 04:11:48 UTC 合併,在 v1.17.8 內)修的是:HoodiLightConfig 把執行層創世時間戳 1742212800 當成信標鏈創世時間,但信標鏈要再等 GENESIS_DELAY 的 600 秒才開始,正確是 1742213400,所以 blsync 把每個頭部都算成「10 分鐘前」,Geth 每個槽位都印 Old signed head received age=10m13s。作者量到兩個節點一小時內 311 次警告對 0 次。一小時有 300 個槽位,311 與它同量級(我不清楚多出的 11 次從何而來)。這個修正獨立確認了我昨天用 Lodestar 的 genesis_time 得到的 1742213400,也提醒了一件事:Hoodi 的執行層創世(1742212800)與信標層創世差 600 秒,這個混淆在客戶端程式碼裡真的出過錯。
三、ACDE 第 247 次到底決定了什麼
會議在 10 月 8 日 14:00 UTC 舉行。我讀到的是 ethereum-magicians 討論串第 3 則貼文(系統機器人 18:08 UTC 張貼的 AI 會議摘要),沒有逐字稿(逐字稿要密碼)。這份摘要本身有內部矛盾,所以只把能互相佐證的部分當事實:
- 摘要同時出現「Hoodi 分叉訂在 10 月 26 日 1742 UTC」與「Monday the 26th at 11 UTC」。17:42 對得上第 31 號 PR 的 17:42:48。11:00 UTC 不是 epoch 的起點:Hoodi 的 epoch 起點在 10:59:36(epoch 132289,Unix 1793012376)與 11:06:00 之間。所以口頭的「11 UTC」若被採用,時間戳就會與兩個 PR 都不同。我無法判斷哪個正確,只能說兩個 PR 在會議前就都是 17:42:48,到我查證時(會議後約 9 小時),PR 2263 的最後更新仍是 04:05 UTC,第 31 號 PR 沒有任何留言。
- 摘要寫「DEF CON」,議程留言裡 nixorokish 提到的是孟買(Mumbai)當腦力激盪場地,我猜是 Devcon 的誤聽,這是推測。
- 它把 CFI 展開成「Community Finalized Initiative」、DFI 展開成「Developer Finalized Initiative」,與我所知的慣用意思(Considered / Declined for Inclusion)不同,所以 Hegotá 那段(CFI 5920、8151、8298、8360、7709、8116,DFI 7666)我只轉述,不查證。
- 較可信的是行動項目,因為它們是具體可被事後檢驗的:所有客戶端在 10 月 16 日前發布含 Hoodi 設定的版本;nixo 確認 gas limit 在 Hoodi 與主網都於分叉 epoch 生效;potuz 在 Prysm 加旗標,可關掉 P2P 建構者堆疊、退回信任建構者或本地建構。
- Barnabas 回報 Sepolia 上只有 4 到 5 個建構者活躍,主要是 Titan 與 Sigma Prime。我今天的 10 個外部出價只看到編號 0、1、3 三個,方向一致,但編號不等於組織,我無法對應。
截止日有一個可以算的地方:10 月 16 日 00:00 UTC 到 10 月 26 日 17:42:48 UTC 是 10 天 17 小時 42 分 48 秒。昨天的 Sepolia 對照是 Geth v1.17.6 在分叉前 13 天發布,所以 Hoodi 的客戶端準備期比 Sepolia 短約 2 天 6 小時,這也對應摘要所說「大型質押池通知時間短」的疑慮。這裡的 13 天是昨天的數字,我今天沒有重驗發布日期。
四、新題:一年四次硬分叉,數字上離現況多遠
ACDE 第 247 次的議程留言裡,Nethermind 的 Lukasz Rozmej 提出目標「每年至少四次現有規模的硬分叉」(ethereum/pm 第 2227 號 issue 的留言),測試側的 spencer-tb 回覆「四次不切實際,每五個月一次是硬上限」,理想是同時處理三個分叉(Glamsterdam 20%、Hegotá 50%、再下一個 20% 的注意力)。這些是意見,我們可以用設定檔把「現況」量出來。主網與測試網的分叉 epoch 都寫在 eth-clients 的 config.yaml,換算公式是 創世時間 + epoch × 384 秒。主網創世時間我用 1606824023:這不是 MIN_GENESIS_TIME 1606824000 加 GENESIS_DELAY 604800(那會得到 1607428800,差一週),而是用設定檔註解的 Altair 時間 2021 年 10 月 27 日 10:56:23 減去 74240 × 384 反推而來,再拿其餘註解逐一驗證,算出的時間與檔內註解全部吻合。
| 主網分叉 | epoch | UTC | 距上一次 |
|---|---|---|---|
| Altair | 74240 | 2021-10-27 10:56:23 | |
| Bellatrix | 144896 | 2022-09-06 11:34:47 | 314.0 天 |
| Capella | 194048 | 2023-04-12 22:27:35 | 218.5 天 |
| Deneb | 269568 | 2024-03-13 13:55:35 | 335.6 天 |
| Electra | 364032 | 2025-05-07 10:05:11 | 419.8 天 |
| Fulu | 411392 | 2025-12-03 21:49:11 | 210.5 天 |
這 5 個間隔總計 1,498.45 天,平均 299.7 天(一年約 1.22 次),最短是 210.5 天。四次一年要求間隔 91.3 天,是歷史最短值的 43%;spencer-tb 說的五個月硬上限(約 152 天)是歷史最短值的 72%。目前距 Fulu 已過 309.0 天,已經超過那個最短間隔。這張表只含共識層 epoch 分叉,沒有納入合併前的執行層分叉,也沒有把以執行層終端總難度觸發的 Merge 另算一次。
另一類分叉的間隔完全不同:BPO(只改 blob 上限參數的分叉)。主網 BPO1 在 2025-12-09 14:21:11,距 Fulu 5.69 天;BPO2 在 2026-01-07 01:01:11,距 BPO1 28.44 天(上限從 9 到 15 到 21)。Fulu 到 BPO2 共 34.1 天發生三個分叉事件,之後到現在(274.9 天)一個也沒有。設定檔裡 BPO 只是 BLOB_SCHEDULE 的兩行,所以「分叉快」在有現成範本時已被做到,只是它改的是一個參數,不是十幾個 EIP。這個區分我認為是討論提速時最該先講清楚的:「現有規模」的定義決定了四次是否合理。
接著是測試網管線。把每個測試網的分叉時間算出來,與主網日期相減:
| 分叉 | Holesky → 主網 | Sepolia → 主網 | Hoodi → 主網 | Sepolia → Hoodi |
|---|---|---|---|---|
| Electra(Pectra) | 71.5 天 | 63.1 天 | 41.8 天 | 21.3 天 |
| Fulu(Fusaka) | 63.5 天 | 50.6 天 | 36.1 天 | 14.5 天 |
| Gloas(Glamsterdam) | (主網未排) | (主網未排) | 20.2 天(Sepolia 10 月 6 日、Hoodi 10 月 26 日) |
如果每年四次、91.3 天一輪,光是從 Sepolia 分叉走到主網的時間(Fulu 的 50.6 天、Electra 的 63.1 天)就占 55% 到 69%;只算 Hoodi 到主網(36.1、41.8 天)也占 40% 到 46%。五個月一輪(152.2 天)時分別降到 33%–41% 與 24%–27%。也就是說,在不縮短測試網階段的前提下,四次一年要求「規格、實作、devnet」三階段全部擠進剩下的 22 到 41 天,或者像 spencer-tb 所說,讓它們在時間上重疊(平行)。
這可以用一個最簡單的排隊公式表示(利特爾法則):同時在進行的分叉數 = 吞吐率 × 單一分叉的總生命週期。假設一個分叉從鎖定範疇到主網的生命週期是 12 個月(這是舉例用的假設,不是量到的數字):每 91.3 天一次時同時有 4.0 個在進行;每 152 天一次時 2.4 個;每 365 天一次時 1 個。spencer-tb 的「三個平行」在五個月一輪時對應生命週期約 15 個月。公式沒有說誰對,只說明要提速,要嘛縮短生命週期、要嘛承受同時多個分叉的協調成本,這與他說的「協調永遠是主要瓶頸」方向一致。
把 Gloas 放進去看。Sepolia 從 Fulu(2025-10-14)到 Gloas(2026-10-06)是 357.3 天,Hoodi 是 363.0 天(2025-10-28 到 2026-10-26)。如果主網沿用前兩次的 Hoodi 到主網或 Sepolia 到主網的領先時間(Fulu 的 36.1/50.6 天、Electra 的 41.8/63.1 天),機械式外推得到的主網日期落在 11 月 26 日到 12 月 8 日之間,Fulu 到 Gloas 的間隔是 358 到 370 天,會是這 6 個間隔裡第二長(僅次於 Deneb 到 Electra 的 419.8 天)。主網日期沒有任何官方排程,glamsterdam-pm.md 的主網列到我查證時仍是 TBD,這個範圍只是把過去兩次的領先時間套到今年的測試網日期上,不是預測。
最後是 ACDE 摘要裡提到的複雜度研究:Dan(danceratopz)用 LLM 為 EIP 打「複雜度分數」,回溯過去幾次分叉,顯示累計分數與「從 devnet 到主網的時間」有相關。我只讀到摘要,沒看到數據、相關係數或樣本數,所以不評價。但上表給了一個可以自己對照的另一半:從 Sepolia 到主網的實測時間,Fulu 與 Electra 相差 12.5 天。兩次只是兩個點,連回歸都談不上。
🧠 記
- 預測三錯在看錯指標。 預測發布看發布節奏,不是看 PR 主題;Geth 相隔 8 天一版,35845 合併後 2 天就搭上車。
- 同一個時間戳要在多個檔案交叉驗。 Hoodi 的 1793036568 在
besu.json(十進位)、chainspec.json(0x6adf9118)、PR 內文三處互相對得上;而 ethereum/pm 的 Unix 欄是另一個值。 - Hoodi 創世有 600 秒的雙重身分。 執行層創世 1742212800,信標鏈創世 1742213400,差
GENESIS_DELAY;Geth 在 PR 35876 才修掉這個混淆。 - 主網歷史間隔平均約 300 天,最短 210.5 天。 四次一年是 91.3 天,是最短值的 43%;BPO 才是真正做到「快」的分叉,但它只改參數。
- 測試網管線就占一年四次的 40% 到 69%。 不縮短測試網階段,提速只能靠平行,而平行把協調成本變成主要成本。
邊界: 兩份 PR 的差異、發布說明與設定檔數字是我用 GitHub API 直接讀到的。ACDE 第 247 次的內容只來自 AI 自動摘要,它的 11 UTC 與 17:42 UTC 互相矛盾,所以 Hoodi 的最終時間戳目前是「兩個 PR 寫的值」而不是「會議確認的值」。Lukasz Rozmej 的原文我只讀到留言正文,沒讀到後續討論;spencer-tb 的看法是單一留言,不代表整個測試團隊。主網日期外推只用了兩次歷史樣本。分叉間隔表不含合併前的執行層分叉,所以「歷史最短 210.5 天」只適用於這張表的定義。Teku 26.10.0 是否含 200M 排程,發布說明沒寫,我沒有查程式碼。
✍️ 實踐
用 20 分鐘重現,全是唯讀。
- 讀主網與測試網的分叉 epoch 並換算日期,再比對檔內註解。你應該得到 Fulu 為 2025-12-03 21:49:11 UTC,Hoodi 的 Gloas 為 2026-10-26 17:42:48 UTC:
import datetime as d
U = d.timezone.utc
genesis = {"main": 1606824023, "sepolia": 1655733600, "hoodi": 1742213400}
def when(net, epoch):
return d.datetime.fromtimestamp(genesis[net] + epoch * 384, U)
print(when("main", 411392)) # Fulu
print(when("sepolia", 353024)) # Gloas on Sepolia
print(when("hoodi", 132352)) # Gloas on Hoodi (PR 31 of eth-clients/hoodi)
print((when("main", 411392) - when("main", 364032)).days) # 210- 用
gh pr diff 2263 -R ethereum/pm看 Hoodi 那列,自己檢查 Unix 欄是不是創世時間 + epoch × 384。同樣用gh pr view 31 -R eth-clients/hoodi對照。 - 對 Sepolia 隨機抽 20 個槽位,讀
signed_execution_payload_bid.message.gas_limit,計算落在 1.98 億到 2.00 億的個數與最大值。
可證偽預測,附驗證條件:
- 預測一: 到 10 月 10 日 23:59 UTC,ethereum/pm 的
glamsterdam-pm.md或 eth-clients/hoodi 的metadata/config.yaml其中之一已合併,且 Hoodi 的 Gloas 時間戳為 1793036568;若兩者都沒合併,或合併的值不同(例如改成 11 UTC 附近的 1793012376),此預測失敗。依據:兩個 PR 在會議前就一致,且時間戳已被三個設定檔交叉驗過;風險:AI 摘要的 11 UTC 屬實。驗證:gh api repos/eth-clients/hoodi/contents/metadata/config.yaml與 PR 2263 狀態。 - 預測二: 到 10 月 16 日 23:59 UTC,
glamsterdam-pm.md的主網列仍是 TBD。依據:Hoodi 要到 10 月 26 日才分叉,而前兩次主網日期都是在 Hoodi 之後才出現(Pectra 與 Fusaka 的 Hoodi 到主網各隔 41.8、36.1 天,我沒有查主網日期是何時決定的,所以這只是推測)。 - 預測三: 10 月 9 日(UTC)隨機抽 20 個 Sepolia 區塊,至少 15 個落在 1.98 億到 2.00 億、無一高於 2 億。
- 預測四: 到 10 月 16 日 23:59 UTC,Lighthouse、Nethermind、Erigon、Besu 四者中至少三個發布含 Hoodi Gloas 時間戳的版本(以發布說明或程式碼中的 1793036568 為準)。這個預測有明顯失敗風險:摘要所說 16 日截止是行動項目,不是已完成。
明天接的待辦:兩個 Hoodi PR 的合併狀態與最終時間戳、Prysm 的 P2P 建構者旗標、Geth v1.17.8 之後是否有 Hoodi 設定的版本、Teku 排程是否確認、Erigon 24620 與 Nethermind 14334。
🔗 延伸學習
- eth-clients/hoodi 第 31 號 PR:schedule Hoodi Glamsterdam activation — 含時間戳 1742213400 + 132352 × 384 的驗算與五個檔案的 diff,可逐檔對照。
- ethereum/pm PR 2263:schedule glamsterdam on hoodi — 計畫檔版本,可看到追加提交只修了 epoch 與起始槽位。
- ACDE 第 247 次討論串(Ethereum Magicians) — 議程、AI 摘要與錄影連結;摘要有矛盾,請當線索而非定論。
- go-ethereum v1.17.8 發布說明 — 含 PR 35845(eth_call 的 gas 上限)與 PR 35876(Hoodi 信標創世時間)。
💬 問 AI
我在研究 Ethereum Glamsterdam 的排程與硬分叉節奏(查證時間 2026-10-08 約 23:00 UTC),以下是我自己讀到的事實,請協助查證並嚴格區分來源:
1. eth-clients/hoodi 第 31 號 PR 提議 Hoodi 在 epoch 132352(起始槽位 4235264)啟用 Glamsterdam,時間戳 1793036568(2026-10-26 17:42:48 UTC),算式為 1742213400 + 132352 × 384。ethereum/pm 的 PR 2263 追加提交後 Hoodi 列也是 epoch 132352 與同一個 UTC,但 Unix 欄仍是 1793134872(2026-10-27 21:01:12)。
2. 主網歷次共識層分叉間隔(天):Altair→Bellatrix 314.0、→Capella 218.5、→Deneb 335.6、→Electra 419.8、→Fulu 210.5,平均 299.7。Hoodi 到主網的領先時間:Electra 41.8、Fulu 36.1;Sepolia 到主網:Electra 63.1、Fulu 50.6。
3. ACDE 第 247 次的 AI 摘要同時寫「26 日 1742 UTC」與「26 日 11 UTC」,並寫客戶端需在 10 月 16 日前發布。
請幫我:
(a) 用 創世時間 + epoch × 384 驗算上述三個時間戳與兩個間隔表,指出任何算錯的格子;
(b) 查 ACDE 第 247 次的逐字稿或影片,確認 Hoodi 的最終時間(11 UTC 還是 17:42:48 UTC);若 11:00 UTC,請算出最接近的 epoch 起點時間戳;
(c) 說明「一年四次硬分叉」在我列的數字下還缺什麼(測試網管線、平行分叉、BPO 類只改參數的分叉如何算),用利特爾法則做一個清楚標示為「假設」的舉例;
(d) 回答時分三類標示:「文件或來源明說的」、「你另外查證到的(附網址)」、「你的推論」,不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。