我今天 10 月 14 日 23:01 UTC(台北 10 月 15 日 07:01)重讀 Hoodi 的 Glamsterdam 記分板:距分叉 11.78 天,距 10 月 16 日 23:59:59 UTC 的發布期限 2 天 0 小時 59 分。執行層從 4/6 變成 5/6,Ethrex 的第 7391 號 PR 在 10 月 14 日 19:02:06 UTC 合併,承 昨天的區塊鏈,昨天預測四(Ethrex 期限前合併)提早成立。其餘沒動:Geth 的 hoodi.json 仍只到 bpo2Time,含 Hoodi 時間戳的穩定版仍只有 Lodestar v1.50.0,12 個客戶端倉庫過去 24 小時沒有任何新穩定版,共識規格第 5734 號 PR 仍 open(最後更新 10 月 13 日 22:49 UTC,我今天重查 API 沒有新動靜)。
今天有三件新東西:11 個客戶端 PR 從開出到合併的等待時間(共識層中位數 1.7 小時,執行層 81 小時);用自助法(bootstrap)給昨天模型的不確定性畫出區間,結果寬到 16% 到 83%;以及把 Sepolia 的六個期限前發布換成「離期限幾小時」,發現全部落在期限前 47 小時內,而 Hoodi 的同一個窗口大約再 2 小時就開始。
📖 學
一、記分板:只多了 Ethrex
資料用 GitHub API(gh api)在 10 月 14 日 23:01 UTC 讀取,「距分叉」是自己算的(分叉時間 10 月 26 日 17:42:48 UTC)。
| 10/13 23:01 UTC | 10/14 23:01 UTC | |
|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 |
| 執行層已合併 | 4/6 | 5/6(Ethrex,距分叉 11.94 天) |
| 含 Hoodi 時間戳的穩定版 | 1 | 1(Lodestar v1.50.0) |
| 執行層沒合併 | Geth、Ethrex | Geth |
穩定版我逐一讀了 12 個倉庫的最新發布:Teku 26.10.0(10/8 22:05)、Nimbus v26.10.0(10/4)、Prysm v7.2.1(10/5)、Lighthouse v8.2.3(10/1)、Nethermind 2.1.0(10/1)、Besu 26.9.0(9/25)、Reth v2.7.0(9/28)、Geth v1.17.8(10/8)、Erigon v3.7.1(10/2)、Ethrex v29.0.1(10/5)、Grandine 2.0.6(8/3),全部和昨天一樣。這些版本的發布時間都早於各自的 Hoodi 合併時間(Teku 的 26.10.0 在 22:05:15 發布,它的 Hoodi PR 在 22:20:07 合併),所以不可能含 Hoodi 時間戳;唯一的例外 Lodestar 昨天已確認。Lighthouse 另有 v8.3.0-rc.0,是 10 月 1 日的預發布,也早於它 10 月 12 日的合併,同樣不含。Nimbus 的 nightly 10 月 14 日 05:38 UTC 又重建了一次,但那不是穩定版。
二、Ethrex 第 7391 號 PR:第六個獨立的 fork ID 測試值
Ethrex 的 PR 10 月 9 日 21:57:22 UTC 開出,10 月 14 日 19:02:06 UTC 合併,歷時 5 天 0 小時 4 分,5 個檔案 +39 -6。它有兩個核准(jrchatruc 與 juanbono,都在 10 月 14 日 18:19 UTC,合併前 43 分鐘)。改動內容:hoodi/genesis.json 加一行 "amsterdamTime": 1793036568;networks.rs 新增 test_hoodi_amsterdam_activation 測試,註解直接寫出算式 1742213400 + 132352 * 32 * 12 = 1793036568,和我歷來的算術相同;fork_id.rs 新增兩列測試(分叉前一秒 1793036567 仍是 0x23aa1351 且下一分叉 1793036568,分叉當秒 1793036568 是 0x3d068b59),並把原本遠未來時間戳 2740434112 的期望值從 0x23aa1351 改成 0x3d068b59。另有 rpc.rs 與 docs/roadmaps/forks-roadmap.md 兩個檔案,我只看到檔名與增刪行數,沒讀內容。
我今天又用同一個 CRC32 腳本重算(創世雜湊依序餵 Prague、Osaka、BPO1、BPO2、Amsterdam 的時間戳,得 0x0929e24e、0xe7e0e7ff、0x3893353e、0x23aa1351、0x3d068b59),與 Ethrex 的測試值一致。現在 Besu、Nethermind、Reth、Erigon、Ethrex 五個執行層客戶端寫的測試,都落在 0x3d068b59,且 Ethrex 的已進主分支。Geth 沒有對應的測試,因為它沒有排程:params/config.go 的 HoodiChainConfig 是 readChainSpec("chainspecs/hoodi.json"),而那個 JSON 沒有 amsterdamTime(Sepolia 的 JSON 則有 "amsterdamTime": 1791294816)。我也用 PR 搜尋找了 hoodi、amsterdam、glamsterdam 三組關鍵字,Geth 倉庫更新過的相關 PR 都是 eth_simulateV1、BAL(區塊級存取清單)之類,沒有 Hoodi 排程;主分支自 10 月 12 日以來的 7 個提交也沒有。這是「沒找到」,不是證明沒有。
三、PR 的等待時間:共識層是小時,執行層是天
11 個排程 PR 都有開出與合併時間,我算了「開出到合併」,以及「合併時間相對於 eth-clients/hoodi 第 31 號 PR(官方排程設定,10 月 9 日 21:31:02 UTC 合併)」。
| 客戶端 | 開出到合併(小時) | 合併相對設定合併(小時) | 檔案數 |
|---|---|---|---|
| Lodestar | 1.70 | −25.0 | 2 |
| Teku | 1.53 | −23.2 | 2 |
| Nimbus | 1.62 | +5.1 | 2 |
| Prysm | 50.36 | +19.2 | 2 |
| Lighthouse | 4.80 | +55.4 | 1 |
| Grandine | 0.37 | +84.4 | 1 |
| Nethermind | 58.80 | +51.2 | 5 |
| Besu | 81.03 | +57.0 | 3 |
| Reth | 97.49 | +68.8 | 3 |
| Erigon | 2.19 | +90.2 | 4 |
| Ethrex | 117.08 | +117.5 | 5 |
共識層 6 個的開出到合併中位數是 1.66 小時,執行層 5 個是 81.03 小時,差 49 倍。共識層裡 Lodestar 與 Teku 在官方設定合併之前(負值)就合併了,時間上對得上 10 月 7 日開的 ethereum/pm 第 2263 號議題(提案 Hoodi 在 10 月 26 日分叉),共 2/11 個(這是我的推論,我沒讀兩個 PR 的討論)。
這個差距有三個可能解釋,我只能排除一個。檔案數:執行層 PR 動 3 到 5 個檔案、共識層 1 到 2 個,但 Erigon 動 4 個檔案只花 2.19 小時,所以檔案數不是唯一原因。開出時間:Nethermind、Besu、Reth、Ethrex 都在設定合併前後(10/8 到 10/9)就開了、然後等了 2 到 5 天,而 Erigon 與 Grandine 是在 10/13 才開,開了就合。這支持「等待主要發生在被擱置的那段」,但我沒有證據知道它們是不是草稿或在等什麼(合併後的 PR 看不到當時的草稿狀態),那是推論。Ethrex 的情況比較清楚:兩位審查者 10 月 14 日 18:19 才核准,之前 PR 沒有審查。
四、更新模型:區間很寬,而兩個模型相差一倍
昨天的模型 B 用 Sepolia 上 10 個「合併到穩定版」的延遲(1.71 到 15.41 天,中位 6.6 天),對每個已合併客戶端算「在期限前發版」的條件機率,再用泊松二項分布加總。今天加入 Ethrex 並把時間推到 10 月 14 日 23:01:02 UTC:
| 客戶端 | 合併後已過(天) | 機率 |
|---|---|---|
| Teku | 6.03 | 0.500 |
| Nimbus | 4.85 | 0.429 |
| Prysm | 4.26 | 0.250 |
| Grandine | 1.54 | 0.200 |
| Erigon | 1.31 | 0.200 |
| Lighthouse | 2.76 | 0.125 |
| Besu | 2.69 | 0.125 |
| Nethermind | 2.94 | 0.125 |
| Reth | 2.19 | 0.111 |
| Ethrex | 0.17 | 0.100 |
共識層穩定版總數(含 Lodestar):1 個 15%、2 個 37%、3 個 33%、4 個 13%、5 個 2.2%,至少 3 個是 47.9%(昨天是 58%),平均 2.50。執行層(5 個已合併):0 個 49%、1 個 38%、2 個 11%、3 個 1.7%,至少 1 個 51%(昨天 4 個客戶端是 65%),平均 0.66。機率下降的原因是,昨天到今天沒人發版,把短延遲的樣本(1.71、2.48 天)從「還有可能」的集合裡排除了,剩下的都是長延遲;這個過去 24 小時全部 10 個客戶端沒發版的觀察,在模型下本身的機率是 43%,不算被否定。
昨天我要的是「樣本只有 10 個時該怎麼表達不確定性」,今天做了自助法:把 10 個延遲有放回地重抽 20000 次,每次重算整個分布。至少 3 個共識層穩定版的機率,5% 到 95% 區間是 16% 到 83%(中位 46%);執行層至少 1 個是 19% 到 75%(中位 51%)。所以昨天寫 58% 與 65% 這種精確度並不誠實,區間才是真正能講的話。
另一個模型我叫它 C,完全不看延遲,只看期限群聚。我昨天的 Sepolia 資料整理加上今天重讀各倉庫的發布時間:Sepolia 期限 9 月 29 日 23:59:59 UTC,六個在期限前發布的客戶端依序距期限的小時數是:Teku 26.9.1 為 46.7、Reth v2.7.0 為 35.2、Lodestar v1.49.0 為 34.1、Prysm v7.2.0 為 32.2、Ethrex v28.0.0 為 19.9、Nimbus v26.9.0 為 8.3。全部落在期限前 47 小時內。照這個節奏,Hoodi 的同一個窗口從 10 月 15 日 01:16 UTC 開始,離我寫這段只剩約 2 小時。模型 C 的設定:「期限前 3 天已合併、尚未發版」的 8 個客戶端裡有 6 個發版,以 Laplace 平滑得每個 0.7,獨立,則共識層其餘 5 個至少 2 個發版(總數至少 3)是 96.9%,執行層 5 個至少 1 個是 99.8%。
兩個模型相差一倍:48% 對 97%、51% 對 99.8%。它們的差異是哲學性的:B 認為發布時間由各團隊自己的工作量決定,C 認為由共同的期限決定。Sepolia 的 8 個樣本比較偏向 C,但 C 只有一次事件的 8 個樣本;獨立假設下 5 個客戶端「一個都不發」的機率極小,現實裡客戶端之間不會這麼獨立;而且 Hoodi 的期限到分叉有 9.7 天、Sepolia 是 6.6 天,期限效應可能較弱。我自己的判斷是介於兩者之間,偏向 C:共識層至少 3 個約 75%、執行層至少 1 個約 80%。這是主觀數字,不是模型輸出。
五、提案議題裡的一個筆誤,以及主網候選日期
ethereum/pm 第 2263 號議題(現為 closed,我只讀了開頭的提案文字,沒讀關閉原因)提出兩個 Hoodi 選項:epoch 132352(2026-10-26 17:42:48 UTC)與 epoch 132608(2026-10-27 21:01:12 UTC)。我用公式驗算,Hoodi 創世 1742213400 加上 epoch × 32 × 12:132352 對應 1793036568,132608 對應 1793134872,與兩個 UTC 日期相符。但議題表格裡第一列的 Unix 欄位也寫了 1793134872,那是第二列的值,差 98304 秒,正好是 256 個 epoch(256 × 32 × 12);第一列的 epoch 與 UTC 欄位是對的。實際合併的設定用 epoch,所以沒有造成影響(Ethrex 與 Erigon 的測試也都用 1793036568),只是示範「同一張表裡的欄位不是彼此獨立的核對」。
同一個議題還列了三個「潛在主網時間」:epoch 493056(2026-12-01 20:38:47 UTC)、494592(12 月 8 日 16:29:11)、494848(12 月 9 日 19:47:35)。我用主網創世 1606824023 加 epoch × 384 驗算,三個 Unix 值都吻合。對比 Hoodi 分叉(10 月 26 日)有 36.1、42.9、44.1 天的距離;Sepolia 到 Hoodi 是 20 天 3 小時 49 分。主網日期還沒決定,這只是議題內的候選,不是公告。
另外兩個 eth-clients/hoodi 的相關改動:第 30 號 PR(10 月 13 日合併)更新時程圖,說明 Hoodi 有 5 年一般運行期到 2029 年、LTS 在 2030 年,Holesky 在 Hoodi 開始時結束、沒有 LTS,Sepolia 的 LTS 移到 2027 年(PR 描述明說);第 32 號 PR(同日合併)刪掉 metadata/besu.json 與 metadata/chainspec.json,共 −2330 行,理由是「客戶端自己內建網路設定」。後者和上面 Ethrex、Erigon 的改法互相對得上:設定現在是在各客戶端倉庫維護,而不是從 Hoodi 倉庫複製。
🧠 記
- 記分板(10 月 14 日 23:01 UTC): 共識層 6/6;執行層 5/6(Ethrex 第 7391 號 10/14 19:02:06,缺 Geth);穩定版仍 1 個;距分叉 11.78 天、距期限 2 天 0 小時 59 分。
- 昨天預測的結算: 預測四(Ethrex 期限前合併,70%)成立;預測一、二、三與五仍在期限內。
- PR 等待時間: 開出到合併,共識層中位 1.66 小時、執行層 81.03 小時;Ethrex 5 天 0 小時 4 分,Erigon 2 小時 11 分。
- 模型更新: 模型 B 今天算共識層至少 3 個 47.9%、執行層至少 1 個 51%;自助法 5% 到 95% 區間 16% 到 83% 與 19% 到 75%。模型 C(期限群聚)給 96.9% 與 99.8%。我的判斷 75% 與 80%。
- Sepolia 群聚: 六個期限前發布都在期限前 8.3 到 46.7 小時,Hoodi 同窗口從 10 月 15 日 01:16 UTC 開始。
- 筆誤: ethereum/pm 第 2263 號的第一列 Unix 欄位與 epoch 差 98304 秒(256 個 epoch),實際設定用 epoch,沒有影響。
- 主網候選: 議題列了 12 月 1、8、9 日三個候選,距 Hoodi 分叉 36 到 44 天,未決定。
邊界: 資料主要是 GitHub API,時間點是 10 月 14 日 23:01 UTC;Geth「沒有 PR」是三組關鍵字加主分支提交檢查的結果,不是證明。PR 的草稿狀態合併後無法回看,所以第三節的「為什麼等待」是推論。模型 B 的 10 個延遲與模型 C 的 8 個樣本都來自 Sepolia 同一次事件,模型 C 是依 Sepolia 的 6/8 手算的玩具模型,獨立假設不成立。Sepolia 的發布時間我只讀了版本標籤與時間,沒有逐一確認每個版本的更新說明是否明列 Sepolia 時間戳(昨天的整理為準)。自助法只呈現「10 個延遲抽樣」的不確定性,沒有涵蓋「模型本身是否正確」。不構成任何投資、質押或營運建議。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 重算 11 個 PR 的等待時間(約 5 分鐘),不用輸出以外的工具:
for r in ChainSafe/lodestar:10313 Consensys/teku:11452 status-im/nimbus-eth2:9250 OffchainLabs/prysm:17650 sigp/lighthouse:10304 grandinetech/grandine:980 NethermindEth/nethermind:14489 hyperledger/besu:11531 paradigmxyz/reth:27811 erigontech/erigon:24847 lambdaclass/ethrex:7391; do
repo=${r%%:*}; n=${r##*:}
echo -n "$repo $n "; gh api repos/$repo/pulls/$n --jq '"\(.created_at) \(.merged_at) \(.changed_files)f"'
done- 自己做自助法(約 10 分鐘):把 10 個延遲有放回地重抽,重算「至少 1 個執行層穩定版」的機率,看分布寬度。
import random, datetime as dt
lags=[1.71,2.48,4.44,15.41,7.09,10.44,5.82,10.86,6.56,6.65]
now=dt.datetime(2026,10,14,23,1,2); dead=dt.datetime(2026,10,16,23,59,59)
exe=[dt.datetime(2026,10,12,6,32,24),dt.datetime(2026,10,12,0,45,20),dt.datetime(2026,10,12,18,21,26),
dt.datetime(2026,10,13,15,41,10),dt.datetime(2026,10,14,19,2,6)]
def p(lg,m):
e=(now-m).total_seconds()/86400; r=(dead-m).total_seconds()/86400
a=[x for x in lg if x>e]
return sum(1 for x in a if x<=r)/len(a) if a else 0.0
res=[]
for _ in range(20000):
lg=[random.choice(lags) for _ in lags]
q=1.0
for m in exe: q*=1-p(lg,m)
res.append(1-q)
res.sort(); print(res[1000], res[10000], res[19000])- 驗算議題表格(約 3 分鐘):
1742213400 + 132352*32*12應為 1793036568,+ 132608*32*12應為 1793134872;主網用1606824023 + epoch*384驗三個候選。 - 查 Geth(約 5 分鐘):
gh api repos/ethereum/go-ethereum/contents/params/chainspecs/hoodi.json --jq .content | base64 -d | grep -i time
gh api "repos/ethereum/go-ethereum/releases?per_page=3" --jq '.[]|"\(.tag_name) \(.published_at)"'- 想一想:Sepolia 6 個發布都落在期限前 47 小時內,你會用什麼資料決定「是期限在驅動」還是「各團隊本來就有固定發版週期」?
可證偽預測(沒特別註明的都在 10 月 16 日 23:59:59 UTC 到期):
- 預測一: 含 Hoodi 時間戳的共識層穩定版(非預發布,含 Lodestar)至少 3 個;模型 B 給 48%、模型 C 給 97%,我給 75%。
- 預測二: 含 Hoodi 時間戳的執行層穩定版至少 1 個;模型 B 給 51%、模型 C 給 99.8%,我給 80%。
- 預測三: Geth 的
hoodi.json在期限前出現amsterdamTime: 1793036568的把握降到約 65%;含 Hoodi 的 Geth 穩定版在期限前出現約 25%。若依它自己在 Sepolia 的 1.71 天延遲,需要 10 月 15 日 06:57 UTC 前合併,這已是今天台北下午 2 點 57 分。 - 預測四: 10 月 15 日 14:00 UTC 的第 189 次共識層電話會議結束後,Hoodi 分叉時間到期限仍是 10 月 26 日 17:42:48 UTC(把握約 95%)。
- 預測五(10 月 23 日 23:59 UTC 到期): consensus-specs 第 5734 號 PR 在這之前合併進主分支(延續昨天,今天仍 open、狀態 behind、1 則一般留言、0 則審查留言)。
明天接的待辦:第 189 次共識層電話會議結果、Geth 的 Hoodi PR、模型 C 的 47 小時窗口是否開始出現發布、Lighthouse 與 Teku 與 Nimbus 的新版。
🔗 延伸學習
- lambdaclass/ethrex 第 7391 號 PR:schedule Amsterdam on Hoodi(GitHub) — 本文第二節與第三節的 5 天 PR,附 fork ID 測試與兩個核准。
- eth-clients/hoodi 第 30 號 PR:Sepolia LTS 2027 與 Holesky 結束的時程圖(GitHub) — Hoodi 5 年運行期與 2030 年 LTS 的官方說明,本文第五節的來源。
- eth-clients/hoodi 第 32 號 PR:移除 besu.json 與 chainspec.json(GitHub) — 說明為何網路設定改由各客戶端內建。
- ethereum/pm 第 2247 號議題:ACDC 第 189 次議程(GitHub) — 今天 14:00 UTC 會議的議程,含硬分叉流程與敏捷性討論。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度(查證時間 2026-10-14 23:01 UTC,資料來自 GitHub API)。以下是我自己整理的主張與兩個模型,請協助查證並嚴格區分來源:
1. 事實:共識層 6 個客戶端與執行層 5 個(Nethermind、Besu、Reth、Erigon、Ethrex)已合併 Hoodi 的 Glamsterdam 排程(epoch 132352,時間戳 1793036568);Geth 沒有;含 Hoodi 時間戳的穩定版只有 Lodestar v1.50.0;發布期限 2026-10-16 23:59:59 UTC,分叉 2026-10-26 17:42:48 UTC。
2. PR 等待時間:11 個排程 PR 開出到合併,共識層中位數 1.66 小時、執行層 81.03 小時。
3. 模型 B:用 Sepolia 上 10 個「合併到穩定版」延遲(1.71、2.48、4.44、15.41、7.09、10.44、5.82、10.86、6.56、6.65 天)算條件機率再用泊松二項分布加總:共識層穩定版至少 3 個 47.9%、執行層至少 1 個 51%;自助法 5% 到 95% 區間分別是 16% 到 83% 與 19% 到 75%。
4. 模型 C:Sepolia 6 個期限前發布都在期限前 8.3 到 46.7 小時內,以 6/8 的 Laplace 平滑 0.7 估,得 96.9% 與 99.8%。
請幫我:
(a) 檢查兩個模型的統計設計:條件機率的定義、獨立假設、10 個延遲做自助法的限制,以及「截止期群聚」應該怎麼用更合理的方式建模(例如危險率模型或把期限當協變數);
(b) 提出能驗證兩個模型誰比較好的設計:需要哪些其他分叉或測試網的公開資料(Holesky、Sepolia 先前的分叉、Fusaka 等),如何做留一法或時間序列式回測;
(c) 說明 Ethereum 的客戶端為何在期限前集中發版,以及「各團隊本來就有固定發版週期」這個替代假說要怎麼和它區分;
(d) 分三類標示每個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押或節點營運建議。