Hoodi 的 Glamsterdam 分叉在 10 月 26 日 17:42:48 UTC,我查證時(10 月 11 日 23:30 UTC,台北 10 月 12 日清晨 07:30)距分叉 14.76 天。把 Sepolia 倒推到同樣的距離(9 月 21 日 19:40:48 UTC),當時 6 個執行層客戶端已有 5 個把排程合進主分支;Hoodi 今天是 0 個合併、4 個開著的 PR,共識層則是 4 個已合併(Sepolia 同一時點只有 2 個)。承 昨天的區塊鏈,昨天的五個預測都還沒到期,所以今天不結算,改做三件昨天沒做的事:用 Sepolia 的真實發布紀錄建一個「基準率」,檢驗 10 月 16 日的發布期限有多緊;自己算出 Hoodi 分叉後的 fork ID(0x3d068b59)並對照四個客戶端的 PR;以及發現 10 月 8 日合併的共識規格 consensus-specs v1.7.0-beta.4 帶了一個 Sepolia 分叉後才出現的 Gloas 狀態轉換改動,Prysm 還沒合。
今天(10 月 12 日)14:00 UTC 就是第 100 次測試電話會議(ACDT),議程第二項是「提醒 Hoodi 的發布期限是 10 月 16 日週五」,CL 分組議程要求「確認你們的 Hoodi 版本支援 v1.7.0-beta.4」。這兩件事正好是下面第三、四節的主題。
📖 學
一、24 小時內的變化與行事曆
先交代變化:幾乎沒有。資料用 GitHub API(gh api)讀,和昨天同一套方法。
| 項目 | 昨天 | 今天 |
|---|---|---|
| Lodestar、Teku、Nimbus、Prysm 的 Hoodi 時間合併 | 4 個已合併 | 同,沒有新增 |
| Besu 第 11531 號 PR | open | 仍 open,10 月 11 日 03:42 UTC 更新,狀態「落後主分支」 |
| Nethermind 第 14489 號 PR | open | 仍 open,10 月 11 日 01:06 UTC 更新,狀態可合併、非草稿 |
| Reth 第 27811 號 PR | open | 仍 open,是草稿,Cargo.toml 用 [patch.crates-io] 指向 alloy-hardforks 的 git commit,註解寫「等 alloy-hardforks 發布」 |
| Ethrex 第 7391 號 PR | open | 仍 open,非草稿,落後主分支 |
| Geth、Erigon | Hoodi 設定檔無 Amsterdam | 仍無(hoodi.json 只到 bpo2Time);我用 PR 搜尋沒找到相關 PR,搜尋不等於證明沒有 |
| 新發布版 | 12 個倉庫的最新發布與昨天相同,只有 Nimbus 的 nightly 在 10 月 11 日 05:42 UTC 重建 | |
| ethereum/pm 第 2263 號、2266 號 PR | open | 仍 open(最後更新 10 月 8 日) |
eth-clients/hoodi metadata | genesis.json 有 amsterdamTime: 1793036568,config.yaml 有 GLOAS_FORK_EPOCH: 132352(我直接讀了檔案) |
Reth 那一筆值得注意:它是這四個執行層 PR 裡唯一的草稿,而且依賴一個還沒發布的上游函式庫版本,所以它要進穩定版,至少要先等 alloy-hardforks 發布。我只讀了 PR 的差異,不知道上游的時程。
另外 ethereum/pm 開了三個新的議程議題,連同昨天的整理,行事曆是:
| 會議 | 時間(UTC) | 距分叉 | 備註 |
|---|---|---|---|
| ACDT 第 100 次 | 10 月 12 日 14:00 | 14 天 3 小時 42 分 | 議程:提醒 Hoodi 發布期限 10 月 16 日 |
| ACDC 第 189 次 | 10 月 15 日 14:00 | 11 天 3 小時 42 分 | 議程只寫「Glamsterdam」,沒有細項 |
| ACDE 第 248 次 | 10 月 22 日 14:00 | 4 天 3 小時 42 分 | 議程只寫「Glamsterdam」 |
(距分叉的數字是自算。)兩週一次的節奏讓這件事有個結構性後果:在 10 月 16 日發布期限之前,只剩 10 月 15 日的 ACDC 一次正式電話會議(ACDT 是測試會議,今天開),而執行層的 ACDE 下一次是 10 月 22 日,離分叉只剩 4 天。要延期的話,實質上只有 15 日這個窗口與 22 日的最後關頭。
二、自己算 fork ID:0x3d068b59
四個執行層的 Hoodi PR(Besu、Nethermind、Reth、Ethrex)都把「分叉後的 fork ID」寫進測試,值是 0x3d068b59。這個數字是怎麼來的?我自己算了一遍。
規格是 EIP-2124(原始定義)加 EIP-6122(加入時間戳分叉)。fork hash 是「創世區塊雜湊與所有已過去的分叉區塊號或時間戳」依序餵進 IEEE CRC32 的結果,數字一律是 8 位元組大端 uint64;同一個值只算一次;創世時就設定好的規則不算分叉。fork ID 是 [FORK_HASH, FORK_NEXT],後者是下一個分叉的時間戳(沒有則是 0)。
Hoodi 的創世雜湊 0xbbe312868b376a3001692a646dd2d7d1e4406380dfd86b98aa8a34d1557c971b 是我從 Geth 的 params/config.go 讀到的(HoodiGenesisHash)。Shanghai 與 Cancun 的時間戳是 0,屬於創世即啟用,不進雜湊,所以要餵的只有五個時間戳:
| 步驟 | 時間戳 | 累積 CRC32 | 對照 |
|---|---|---|---|
| 創世 | 0xbef71d30 | Besu 測試的第一項 | |
| Prague | 1742999832 | 0x0929e24e | Besu 測試 |
| Osaka | 1761677592 | 0xe7e0e7ff | Besu 測試 |
| BPO1 | 1762365720 | 0x3893353e | Besu 測試 |
| BPO2 | 1762955544 | 0x23aa1351 | Besu 測試,目前 Hoodi 的值 |
| Amsterdam | 1793036568(十六進位 0x6adf9118) | 0x3d068b59 | 四個執行層 PR 的測試一致 |
前五行與 Besu 測試檔 ForkIdsNetworkConfigTest.java 完全吻合,第六行與四個 PR 吻合。吻合本身就是創世雜湊正確的證據(雜湊錯一個位元,後面全部對不上)。我順便驗了 Sepolia:創世雜湊 0x25a5cc10…、區塊分叉 1735371(merge netsplit)加 7 個時間戳,算出 9 個值(0xfe3366e7、0xb96cbd13、……、0x268956b6、0x6c1d9423)全部與 Besu 測試檔的 Sepolia 列一致,最後一個 0x6c1d9423 就是 Sepolia 分叉後(10 月 6 日起)的 fork ID。
這個驗算有一個很實際的用途:沒升級的節點在分叉前不會被任何人發現。 照 EIP-2124 的驗證規則(我讀的是 EIP 原文與它的「過時軟體」範例表):
- 分叉時間之前,已升級節點宣告
[0x23aa1351, 1793036568],沒升級的宣告[0x23aa1351, 0]。雜湊相同,規則 1b(「沒有遠端宣告的分叉,或尚未到達」)判定連線,對方宣告的下一個分叉不要求一致。所以升級與否在點對點層看不出來。 - 到了 1793036568,已升級節點的雜湊變成
0x3d068b59。沒升級的那一端依表中最後一列:遠端的雜湊是自己已知分叉的超集合,但本地不知道那個未來分叉,「本地需要升級軟體」,規則 4 拒絕;反過來,已升級的那一端看到對方還停在0x23aa1351且下一個分叉為 0,與自己「接下來就是 Amsterdam」不符,同樣拒絕。
換句話說,斷線只會在分叉那一秒發生。這是我對規格文字的閱讀,沒有實際用客戶端測過;而且這只是執行層的點對點(devp2p)。共識層有類似的 ENR 欄位,我沒查。它也解釋了為什麼發布期限要留給節點營運者:升級窗口內不會有網路層警報。
三、Sepolia 先例:十個客戶端從合併到穩定版花了多久
昨天的預測一(共識層穩定版至少 4 個)與預測二(執行層至少 3 個)當時沒有基準率可參照。這次我回頭量了 Sepolia:找每個客戶端把「Sepolia 的 Glamsterdam 排程」合進主分支的 PR,再用 compare/<合併 commit>...<tag> 找第一個「狀態為 ahead 或 identical」的穩定版(非預發布)。分叉時間 10 月 6 日 13:53:36 UTC。
| 客戶端 | 排程 PR | 合併(UTC) | 距分叉 | 第一個穩定版 | 發布(UTC) | 距分叉 | 合併到穩定版 |
|---|---|---|---|---|---|---|---|
| Geth | 35734 | 9/21 09:13 | 15.19 天 | v1.17.6 | 9/23 02:21 | 13.48 天 | 1.71 天 |
| Erigon | 24246(24225 的回移) | 9/22 19:26 | 13.77 天 | v3.7.0 | 9/25 07:04 | 11.28 天 | 2.48 天 |
| Besu | 11333 | 9/21 11:43 | 15.09 天 | 26.9.0 | 9/25 22:22 | 10.65 天 | 4.44 天 |
| Nethermind | 13455 | 9/16 12:58 | 20.04 天 | 2.1.0 | 10/1 22:43 | 4.63 天 | 15.41 天 |
| Reth | 27350 | 9/21 10:32 | 15.14 天 | v2.7.0 | 9/28 12:45 | 8.05 天 | 7.09 天 |
| Ethrex | 7287 | 9/18 17:36 | 17.85 天 | v28.0.0 | 9/29 04:03 | 7.41 天 | 10.44 天 |
| Prysm | 17512 | 9/22 20:10 | 13.74 天 | v7.2.0 | 9/28 15:50 | 7.92 天 | 5.82 天 |
| Lodestar | 10119 | 9/17 17:09 | 18.86 天 | v1.49.0 | 9/28 13:54 | 8.00 天 | 10.86 天 |
| Nimbus | 9100 | 9/23 02:13 | 13.49 天 | v26.9.0 | 9/29 15:40 | 6.93 天 | 6.56 天 |
| Teku | 11308 | 9/21 09:34 | 15.18 天 | 26.9.1 | 9/28 01:16 | 8.53 天 | 6.65 天 |
| Grandine | 941 | 9/25 11:58 | 11.08 天 | 無穩定版,只有預發布 3.0.0-rc.0 | 9/30 07:45 | 6.26 天 | |
| Lighthouse | 沒找到 | v8.3.0-rc.0(預發布,10/1) |
全部是自算,距離單位是天(合併時間與發布時間都取 GitHub API 的 UTC 時間戳)。三個技術註記:Erigon 的穩定版是從 release/3.7 分支切的,主分支那筆 24225 與 v3.7.0 的比對是「diverged」,所以我改用回移的 24246;Nethermind 的 2.0.0(9 月 22 日)與該合併 commit 也是 diverged,我找到的第一個 ahead 是 2.1.0,若 2.0.0 是以挑選提交(cherry-pick)帶入,這個比對看不出來,所以它實際的穩定版時點可能比表中早;Lighthouse 我沒找到 Sepolia 的 Gloas 排程 PR,它 unstable 的 Sepolia config.yaml 現在仍是 GLOAS_FORK_EPOCH: 18446744073709551615,但 10 月 5 日 ACDT 第 99 次逐字稿裡 Pawan 說「我們已發布 8.3.0 rc0,那是給 Sepolia 的」,所以它可能是用別的方式帶入,我沒追下去。PR 的標題是用 GitHub 搜尋挑的,「排程 Sepolia 的 Glamsterdam」這類標題,我沒逐一核對 diff。
從這 10 個有穩定版的客戶端,我算出三個基準:
1. 合併到穩定版的中位數 6.61 天(最短 1.71、最長 15.41)。
2. 穩定版距分叉的中位數 8.02 天(排序:4.63、6.93、7.41、7.92、8.00、8.05、8.53、10.65、11.28、13.48)。Hoodi 的發布期限落在 9.74 天前(10 月 16 日 23:59:59 UTC 到 10 月 26 日 17:42:48 UTC),比 Sepolia 實際的中位數早 1.7 天。在 Sepolia 上達到「9.74 天前已有穩定版」的客戶端是 Geth、Erigon、Besu 三個,共識層是 0 個。
3. Sepolia 當時的期限比較寬。 第 187 次共識層電話會議逐字稿裡,stokes 說期限「29 日」,「最晚 29 日,請盡量更早」。到 9 月 29 日 23:59:59 UTC,10 個有穩定版的客戶端裡有 9 個到位(只缺 Nethermind 的 2.1.0,10 月 1 日);共識層 4 個(Prysm、Lodestar、Nimbus、Teku),執行層 5 個(Geth、Erigon、Besu、Reth、Ethrex)。這個期限距分叉 6.58 天,但 Hoodi 的期限是 9.74 天。
同一場會議裡 Fredrik 還指出協議升級流程規定「客戶端發布就緒到第一個測試網上線之間至少 14 天」,這 14 天用於內部資安審查、加入賞金計畫與外部審查,Sepolia 為了趕時程壓到 7 天,stokes 回「我們有這兩週是有原因的」。Hoodi 的 14 天線是 10 月 12 日 17:42:48 UTC,就是今天;10 月 16 日的 9.74 天比 Sepolia 的 6.58 天多出約 3.2 天,但離流程規定的 14 天仍差 4.3 天(自算)。
用這些基準回頭看昨天的預測:
- 預測一(10 月 16 日前共識層穩定版至少 4 個): 目前合併時間戳的只有 Lodestar、Teku、Nimbus、Prysm 四個,Lighthouse 與 Grandine 還沒有,所以要達標必須四個全部在期限前出穩定版。以 6.61 天的中位數往後推:Lodestar 10 月 15 日、Teku 10 月 15 日、Nimbus 10 月 16 日 17:13、Prysm 10 月 17 日 07:14 UTC(用各自 Hoodi 合併時間加 6.61 天,自算)。Prysm 落在期限之後,但這只是單一中位數,離散很大(1.71 到 15.41 天)。Lodestar 已有 v1.50.0-rc.0(10 月 9 日 21:44 UTC),而 v1.49.0 的預發布到穩定版隔了 2.7 天,可以推測穩定版在今天前後出現,這是推論。Teku 的 26.10.0 在合併前 15 分鐘就發了,下一版得等它的節奏(9 月 17 日、9 月 28 日、10 月 8 日,約 10 到 11 天一次),大約 10 月 18 日前後,這也是推論。我現在認為預測一偏不利。
- 預測二(執行層至少 3 個): Sepolia 在同樣 9.74 天的距離上恰好是 3 個(Geth、Erigon、Besu),但 Hoodi 今天 Geth、Erigon 連 PR 都沒有、Besu 還在 open。基準上是「剛好壓線」,現況是落後 Sepolia。
另一個基準是 potuz 在 10 月 8 日提醒的現象:Sepolia 分叉前客戶端又發了補丁版。我數了 9 月 29 日 23:59:59 到分叉前發布的穩定版:Lighthouse(v8.2.3,10 月 1 日)、Geth(v1.17.7,9 月 30 日)、Erigon(v3.7.1,10 月 2 日)、Nethermind(2.1.0,10 月 1 日)、Nimbus(v26.9.1 與 v26.10.0)、Prysm(v7.2.1,10 月 5 日 21:18:08 UTC,分叉前 16 小時 35 分 28 秒)、Ethrex(v29.0.0、v29.0.1,10 月 5 日),共 7 個客戶端,Lodestar、Teku、Besu、Reth 沒有,Grandine 只有預發布。我只讀了 Prysm 那一次的原因:ACDT 第 99 次逐字稿裡 james 說「有一些最後一刻的設定問題,這會是補丁版」。其餘幾個發布版的內容我沒讀,所以不能說它們都是為 Sepolia 修補。
四、Sepolia 之後才合併的共識改動:consensus-specs v1.7.0-beta.4
consensus-specs 在 10 月 8 日 19:27:03 UTC 發布了 v1.7.0-beta.4(預發布),比 Sepolia 分叉晚 2 天 5 小時 33 分(自算)。ACDT 第 100 次要求 Hoodi 的版本支援它。發布說明裡有兩個影響 Gloas 週邊的改動,我讀了 PR 本文與差異:
共識規格 PR 5719 號(10 月 8 日 14:22:11 UTC 合併,Sepolia 分叉後 2 天 28 分): 在 Gloas 裡,建構者(builder)出價後,若提案者被抓到雙重提案(equivocation),其待付款項(builder_pending_payments)應被清除。舊版只在 process_proposer_slashing 裡清,而且清之前先斷言「提案者仍可被罰沒」。PR 本文描述的繞過方式:提案者先用別的方式被罰沒,例如在攜帶出價的那個區塊裡放進一個針對自己的證明者罰沒(attester slashing),於是雙重提案證明被拒絕,建構者卻要為「不可能含有它 payload 的區塊」付款。修法是把清除搬進 slash_validator,任何形式的罰沒都清,並刪掉 Gloas 版 process_proposer_slashing。PR 本文自己承認副作用:提案者在付款窗口內因無關原因被罰沒,該筆付款也會被清。這是狀態轉換規則的改動,不是客戶端內部實作的細節:同一個區塊,新舊規格算出的狀態根不同。
共識規格 PR 5679 號(10 月 7 日 21:05:45 UTC 合併,Phase0 分叉選擇): calculate_committee_fraction 改成排除被罰沒的驗證者。理由:提案者加成與重組門檻是委員會權重的比例,但分叉選擇不計被罰沒者的投票;大規模罰沒時,加成相對剩下的票數偏大,更容易重組區塊。本文提到 Lighthouse 倉庫的第 10057 號議題是相關背景。這是分叉選擇,不是狀態轉換,各客戶端不一致不會讓同一個區塊算出不同的狀態根,但會讓頭部選擇不同。
客戶端現況,查證時間 10 月 11 日 23:30 UTC 前後:
| 客戶端 | 狀態 | 我怎麼判斷 |
|---|---|---|
| Lodestar | 第 10314 號 PR「更新共識規格到 v1.7.0-beta.4」10 月 9 日 05:49:49 UTC 合併 | 改動含 processProposerSlashing.ts(減 28 行)與 slashValidator.ts(加 13 行);我只讀檔名與增刪行數 |
| Teku | 第 11459 號 PR「更新參考測試到 v1.7.0-beta.4」10 月 9 日 10:36:38 UTC 合併 | 差異含 AbstractBlockProcessor(減 7 行)與 BeaconStateMutators(加 1 行);檔名推論,沒讀內容 |
| Nimbus | 第 9246 號 PR「使用 v1.7.0-beta.4 共識參考測試」10 月 9 日 12:52:05 UTC 合併 | 標題只說參考測試,差異有 fork_choice 等多個檔案,我沒逐一讀 |
| Prysm | 第 17662 號 PR「清除被罰沒提案者的每一筆待付款項」(10 月 9 日 19:12 UTC 開)與第 17664 號 PR「升級規格到 beta.4」(10 月 9 日 22:06 UTC 開,疊在第 17663 號之上)都 仍 open | PR 本文寫明「對應 beta.4 的 slash_validator」 |
| Lighthouse | 我看到的是第 962 號 PR「更新共識規格測試到 v1.7.0-beta.3」仍 open;找不到 beta.4 的對應 PR | 搜尋結果,可能有漏 |
| Grandine | 沒找到 | 搜尋結果 |
Prysm 的組合特別值得注意:第 17650 號 PR(Hoodi 時間)在 10 月 10 日 16:40:37 UTC 併入 develop,但同一個分支上 beta.4 的狀態轉換修正還沒進。也就是說,Prysm 若今天就打包 Hoodi 版本,它在帶有罰沒與建構者付款的區塊上的行為與 Lodestar 不同,這是我對「第 17662 號未合併」的推論,沒有實測。這類差異正是 Hoodi 上要被測出來的東西,但前提是它在分叉前合併並進入穩定版。
還有一個我沒有答案的問題:Sepolia 已經在 10 月 6 日用 beta.3 之前的規則分叉了(我不知道 Sepolia 上的客戶端實際對齊哪一版;beta.3 發布於 10 月 5 日 19:28:33 UTC,分叉前 18 小時 25 分,beta.4 在分叉後)。若新版客戶端把 PR 5719 對所有網路一體適用,Sepolia 的歷史區塊只要曾出現「持有待付款項的提案者在窗口內被罰沒」就會算出不同的狀態根。我沒有查 Sepolia 上有沒有發生過這種罰沒,所以不知道這是理論風險還是實際風險。這適合在 10 月 15 日的 ACDC 問一次,或自己用 beacon API 掃 Sepolia 10 月 6 日以後的罰沒事件。
🧠 記
- Hoodi 現況(10 月 11 日 23:30 UTC): 共識層 4 個合併時間戳(Lodestar、Teku、Nimbus、Prysm),執行層 0 個合併、4 個 PR(Besu、Nethermind、Reth 草稿、Ethrex);穩定版含時間戳的 0 個;24 小時內沒有新合併、沒有新發布。
- 同距離比較: 距分叉 14.76 天時,Sepolia 的 6 個執行層有 5 個已合併排程、共識層 5 個有 PR 的客戶端裡 2 個已合併;Hoodi 是執行層 0/6、共識層 4/6。Sepolia 的日期早在 9 月 3 日就定了,Hoodi 的日期 10 月 8 日才定,今天只過了 3 天 9 小時,所以不能直接解讀為怠慢。
- Sepolia 基準(10 個有穩定版的客戶端): 合併到穩定版中位數 6.61 天、穩定版距分叉中位數 8.02 天;9.74 天前有穩定版的客戶端 3 個(Geth、Erigon、Besu),共識層 0 個。Sepolia 的期限(6.58 天前)比 Hoodi(9.74 天前)寬 3.16 天,流程規定的 14 天線則是今天 17:42:48 UTC。
- fork ID: Hoodi 分叉後是
0x3d068b59(自己用 CRC32 算出,與四個執行層 PR 一致);Sepolia 分叉後是0x6c1d9423。沒升級的節點在分叉那一秒才會被點對點層拒絕,之前看不出來。 - 規格差: consensus-specs 的 PR 5719 號(建構者待付款項隨任何罰沒清除)是 Sepolia 分叉後才合併的狀態轉換改動;beta.4 於 10 月 8 日發布;Prysm 的對應 PR 17662 與 17664 仍 open。
- 行事曆: 發布期限(10 月 16 日)之前只剩 10 月 15 日的 ACDC 一次電話會議;ACDE 下一次是 10 月 22 日,距分叉 4.15 天。
邊界: GitHub 資料用 gh api 讀,PR 狀態以 10 月 11 日 23:30 UTC 前後為準;「沒找到」的 Geth、Erigon、Lighthouse、Grandine 是搜尋結果,不是不存在的證明。Sepolia 基準的排程 PR 是用標題搜尋挑的,「第一個穩定版」依 compare 判斷,diverged 的發布分支(Erigon、Nethermind)的處理在第三節說明,可能有誤。Lighthouse 的 Sepolia 路徑我沒找清楚。第 187 次與第 99 次逐字稿是校正版(含 AI 校正),我讀了與引用相關的段落,沒對照影片,議程題目取自 ethereum/pm 議題本文。fork ID 的驗算是自己算的,創世雜湊取自 Geth 原始碼,最後值與四個 PR 一致;EIP-2124 規則的套用是我的閱讀,沒有用客戶端實測。規格 PR 5719 的客戶端對應狀態,Lodestar、Teku、Nimbus 只讀檔名與行數,不確定內容。consensus-specs 是否對 Sepolia 造成影響屬推論,我沒掃鏈。
✍️ 實踐
用 20 分鐘重現,全是唯讀。
- 自己算 fork ID(約 3 分鐘),你應該得到
0x23aa1351與0x3d068b59:
import zlib, struct
g = bytes.fromhex("bbe312868b376a3001692a646dd2d7d1e4406380dfd86b98aa8a34d1557c971b") # Hoodi 創世雜湊
c = zlib.crc32(g)
for name, t in [("prague", 1742999832), ("osaka", 1761677592), ("bpo1", 1762365720),
("bpo2", 1762955544), ("amsterdam", 1793036568)]:
c = zlib.crc32(struct.pack(">Q", t), c) # 8 位元組大端
print(name, t, "0x%08x" % c)把 Sepolia 的創世雜湊 25a5cc106eea7138acab33231d7160d69cb777ee0c2c553fcddf5138993e6dd9 換進去,先餵區塊 1735371,再餵 7 個時間戳(Shanghai 1677557088、Cancun 1706655072、Prague 1741159776、Osaka 1760427360、BPO1 1761017184、BPO2 1761607008、Amsterdam 1791294816),最後一個應是 0x6c1d9423。
- 重做第三節任一列(約 5 分鐘):
M=$(gh api repos/ethereum/go-ethereum/pulls/35734 --jq .merge_commit_sha)
gh api repos/ethereum/go-ethereum/compare/$M...v1.17.6 --jq '{status,ahead_by,behind_by}'
# ahead 或 identical:該版本含這個合併;behind:不含;diverged:發布分支與主分支分叉,要另外看是否 cherry-pick- 看 Hoodi 的執行層設定落地了沒(約 2 分鐘):
gh api repos/ethereum/go-ethereum/contents/params/chainspecs/hoodi.json --jq .content | base64 -d | grep -i time,有沒有amsterdamTime;Erigon 的路徑是execution/chain/spec/chainspecs/hoodi.json。 - 讀 consensus-specs 的 PR 5719 號
specs/gloas/beacon-chain.md差異(約 10 分鐘),找slash_validator新增的那段迴圈,自己想一遍:為什麼只在process_proposer_slashing清除會被「先被別的方式罰沒」繞過。
可證偽預測(都到期於 10 月 16 日 23:59:59 UTC,除非註明):
- 預測一: 共識層穩定版(非預發布)含 epoch 132352 的客戶端不超過 3 個。這是我與昨天的預測相反的押注,理由是 Sepolia 基準 0/5 與 Prysm 的中位數推算落在期限之後。驗證:用第三節的 compare 法逐一比對。若 4 個以上,我的判斷錯。
- 預測二: Geth 的主分支
params/chainspecs/hoodi.json在期限前出現amsterdamTime: 1793036568(目前沒有,也沒找到 PR)。驗證:讀該檔案。我對這個沒把握,Sepolia 上 Geth 是最快的客戶端之一。 - 預測三: Prysm 的第 17662 號與第 17664 號 PR 在期限前都合併。驗證:查 PR 狀態。
- 預測四: Lighthouse 或 Grandine 至少一個把 Hoodi 的 Gloas 時間合進開發分支(目前兩個都沒有)。驗證:Lighthouse 的
config.yaml的GLOAS_FORK_EPOCH,Grandine 找 Hoodi 設定檔。 - 預測五(10 月 23 日 23:59 UTC 到期): Hoodi 分叉時間仍是 10 月 26 日 17:42:48 UTC。驗證:eth-clients/hoodi 的
metadata與 ethereum/pm 的相關 PR。這條沿用昨天的預測四;只有 10 月 15 日 ACDC 與 10 月 22 日 ACDE 兩個正式窗口。
昨天預測的結算:預測一、二、三、五都未到期。昨天的預測四(10 月 16 日前 Lighthouse、Nethermind、Erigon、Besu 四個裡至少三個發布含時間戳的版本):基線仍是 0,今天沒有新發布;Nethermind 與 Besu 的 PR 仍 open,Lighthouse 與 Erigon 無。
明天接的待辦:ACDT 第 100 次的結果(是否討論發布期限)、ACDC 第 189 次的議程細項、Prysm 第 17662 號與 17664 號、Reth 的 alloy-hardforks 依賴、Besu 與 Nethermind 的合併、Geth 與 Erigon 是否出現 PR、Sepolia 在 PR 5719 號後有沒有罰沒事件。
🔗 延伸學習
- EIP-2124:Fork identifier for chain compatibility checks(eips.ethereum.org) — fork hash 的計算、四條驗證規則與「過時軟體」範例表,本文第二節的依據;EIP-6122 補上時間戳分叉的雜湊規則。
- ethereum/consensus-specs 第 5719 號 PR:Clear pending builder payments of slashed proposers(GitHub) — beta.4 裡的 Gloas 狀態轉換修正,附問題描述與測試。
- ethereum/forkcast:ACDC 第 187 次會議產物(GitHub) — Sepolia 發布期限「29 日」與 14 天流程規定的討論都在
transcript_corrected.vtt。 - ethereum/pm 第 2264 號議題:ACDT 第 100 次議程(GitHub) — Hoodi 發布期限提醒與 beta.4 支援的議程出處。
💬 問 AI
我在研究 Ethereum Glamsterdam 在 Hoodi 測試網的排程(查證時間 2026-10-11 23:30 UTC,資料來自 GitHub API 與 ethereum/forkcast 逐字稿),以下是我自己整理的主張,請協助查證並嚴格區分來源:
1. Hoodi 分叉時間 1793036568(2026-10-26 17:42:48 UTC,epoch 132352)。創世雜湊 0xbbe312868b376a3001692a646dd2d7d1e4406380dfd86b98aa8a34d1557c971b,依 EIP-2124 與 EIP-6122,只餵 Prague 1742999832、Osaka 1761677592、BPO1 1762365720、BPO2 1762955544、Amsterdam 1793036568 五個時間戳,CRC32 依序是 0xbef71d30(創世)、0x0929e24e、0xe7e0e7ff、0x3893353e、0x23aa1351、0x3d068b59。
2. 分叉前,已升級與未升級的執行層節點可互相連線(EIP-2124 規則 1b);分叉那一秒起,兩邊會因 fork hash 不一致互相拒絕。
3. Sepolia 先例(分叉 2026-10-06 13:53:36 UTC):10 個有穩定版的執行層與共識層客戶端,從「排程合併」到「第一個穩定版」中位數 6.61 天;穩定版距分叉中位數 8.02 天;在「距分叉 9.74 天前」已有穩定版的是 Geth、Erigon、Besu 三個,共識層為 0。
4. consensus-specs 的 PR 5719 號(2026-10-08 合併)把 Gloas 的建構者待付款項清除移到 slash_validator,屬於狀態轉換改動;v1.7.0-beta.4 於 2026-10-08 19:27:03 UTC 發布,晚於 Sepolia 分叉。Prysm 對應的 PR 17662 與 17664 仍 open。
5. ACDT 第 100 次(2026-10-12)要求客戶端確認 Hoodi 版本支援 beta.4,Hoodi 客戶端發布期限是 2026-10-16。
請幫我:
(a) 用 Python 的 zlib.crc32 驗算第 1 點的每一個 CRC32 值,並說明為什麼 Shanghai 與 Cancun(時間戳 0)不用餵進去;
(b) 依 EIP-2124 的四條規則,逐步推演「未升級節點 vs 已升級節點」在分叉前後各自的連線判斷,並說明共識層是否有對應機制;
(c) 解釋為什麼「把建構者待付款項的清除放在 process_proposer_slashing 裡」可以被「先被其他方式罰沒」繞過,以及搬到 slash_validator 的副作用;
(d) 若 Sepolia 客戶端已採 beta.4 之前的規則分叉,新版客戶端對 Sepolia 歷史區塊套用 PR 5719 號會在什麼條件下算出不同的狀態根?如何用 beacon API 檢查 Sepolia 10 月 6 日之後有沒有符合條件的罰沒事件?
(e) 分三類標示每一個結論:「文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。