我今天 10 月 13 日 23:01 UTC(台北 10 月 14 日 07:01)重讀 Hoodi 的 Glamsterdam 記分板,距分叉 12.779 天、距 10 月 16 日 23:59:59 UTC 的發布期限 3 天 0 小時 58 分:共識層 6/6 全數合併(昨天 5/6,新增 Grandine),執行層 4/6(昨天 3/6,新增 Erigon),Prysm 昨天預測裡剩下的第 17664 號 PR 也在 10 月 13 日 20:31:58 UTC 合併。但含 Hoodi 時間戳的穩定版仍然只有一個(Lodestar v1.50.0),12 個客戶端倉庫沒有任何新的穩定版發布。承 昨天的區塊鏈,昨天的五個預測有一個成立、其餘仍開著。
「合併了但沒發版」這個差距,是今天要量化的東西。我用兩個自寫的小模型估「期限前會有幾個穩定版」:一個只看各客戶端自己的發布節奏,一個用 Sepolia 上「合併到穩定版」的 10 個實測延遲。再用 Sepolia 上同一類期限回測第一個模型,結果它低估了三倍,所以我改採第二個,並把今天的預測改寫成帶機率的版本。
📖 學
一、24 小時記分板:共識層補齊、執行層只剩 Geth 與 Ethrex
資料用 GitHub API(gh api)在 10 月 13 日 23:01 UTC 讀取,分叉時間 10 月 26 日 17:42:48 UTC(時間戳 1793036568,epoch 132352),「距分叉」是自己算的。
| 項目 | 狀態 | 合併時間(UTC) | 距分叉 |
|---|---|---|---|
| Lodestar 第 10313 號 PR | 已合併(穩定版 v1.50.0 含它) | 10/8 20:31:57 | 17.88 天 |
| Teku 第 11452 號 PR | 已合併 | 10/8 22:20:07 | 17.81 天 |
| Nimbus 第 9250 號 PR | 已合併 | 10/10 02:39:51 | 16.63 天 |
| Prysm 第 17650 號 PR | 已合併 | 10/10 16:40:37 | 16.04 天 |
| Lighthouse 第 10304 號 PR | 已合併 | 10/12 04:53:40 | 14.53 天 |
| Grandine 第 980 號 PR | 新增,已合併 | 10/13 09:56:48 | 13.32 天 |
| Nethermind 第 14489 號 PR | 已合併 | 10/12 00:45:20 | 14.71 天 |
| Besu 第 11531 號 PR | 已合併 | 10/12 06:32:24 | 14.47 天 |
| Reth 第 27811 號 PR | 已合併 | 10/12 18:21:26 | 13.97 天 |
| Erigon 第 24847 號 PR | 新增,已合併 | 10/13 15:41:10 | 13.08 天 |
| Ethrex 第 7391 號 PR | 仍 open,10/9 22:01 UTC 後無更新 | ||
| Geth | hoodi.json 仍只到 bpo2Time;我用 PR 搜尋(關鍵字 hoodi、amsterdam、glamsterdam)沒找到排程 PR |
Teku 的合併時間取自 10 月 11 日記錄的第 11452 號 PR(今天重查 API 仍是 10/8 22:20:07),Nimbus 與 Prysm 的排程 PR 是今天用搜尋補查到的。Prysm 要分清楚:排程本身是第 17650 號,第 17662 號是清除被罰沒提案者待付款項的修正,第 17664 號是規格升級。
Prysm 第 17664 號(升級共識規格到 v1.7.0-beta.4)今天 20:31:58 UTC 合併。昨天我記錄它的 base 是疊加用的分支、33 個檔案 +1831 -984;今天 API 顯示 base 是 develop、35 個檔案 +1845 -984、4 個提交。底下那個疊加分支發生了什麼,我沒查,只知道它現在直接進了 develop。
新發布版: 我逐一讀 12 個倉庫的最新發布,和昨天一樣,最新穩定版是 Lodestar v1.50.0(10/12 13:02:48)、Lighthouse v8.2.3(10/1)、Teku 26.10.0(10/8)、Nimbus v26.10.0(10/4)、Prysm v7.2.1(10/5)、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,另有預發布 3.0.0-rc.0)。其中只有 Lodestar 的發布時間晚於它自己的 Hoodi 合併。Nimbus 的 nightly 在 10 月 13 日 05:44 UTC 重建,但那不是穩定版。
和昨天並排:
| 10/12 23:01 UTC | 10/13 23:01 UTC | |
|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 5 | 6(Grandine) |
| 執行層已合併 | 3 | 4(Erigon) |
| 含 Hoodi 時間戳的穩定版 | 1 | 1 |
| 執行層沒合併 | Geth、Erigon、Ethrex | Geth、Ethrex |
二、兩個新 PR 的細讀:兩套獨立實作寫出同一組常數
Erigon 與 Grandine 這兩個新 PR 都很小,但可以當成對 Hoodi 設定的又兩次獨立核對。
Erigon 第 24847 號 PR:10 月 13 日 13:29:48 開、15:41:10 合併,歷時 2 小時 11 分 22 秒,4 個檔案 +11 -1。內容是 hoodi.json 加一行 "amsterdamTime": 1793036568;共識端 hoodiConfig() 加 GloasForkEpoch = 132352、GloasForkVersion = 0x80000910,以及 GasLimitSchedule 一筆 {Epoch: 132352, GasLimit: 200_000_000};還有 p2p/forkid/forkid_test.go 的測試案例。
Grandine 第 980 號 PR:09:34:27 開、09:56:48 合併,歷時 22 分 21 秒,1 個檔案 types/src/config.rs +7 -1,內容是同一組常數(gloas_fork_epoch: 132_352、gloas_fork_version: 0x80000910、一筆 2 億 gas 的排程),並把註解裡指向 eth-clients/hoodi 規格檔的 commit 連結更新到 ef8998901c…(那個 commit 就是 10 月 9 日 21:31:02 UTC 的「schedule Hoodi Glamsterdam activation」)。
兩者與我昨天直接讀的 eth-clients/hoodi 的 metadata/config.yaml 一致:GLOAS_FORK_VERSION: 0x80000910、GLOAS_FORK_EPOCH: 132352,GAS_LIMIT_SCHEDULE 裡有 GAS_LIMIT: 200000000。0x80000910 也符合 Hoodi 的版本號規律(Electra 0x60000910、Fulu 0x70000910,再加一代)。時間戳的算術照舊:1742213400 + 132352 × 32 × 12 = 1793036568。
Erigon 的 fork ID 測試值得細看:它新增的四列是 1762955544(BPO2,0x23aa1351,下一個分叉 1793036568)、1793036567(分叉前一秒,仍是 0x23aa1351,下一個 1793036568)、1793036568(分叉當秒,0x3d068b59,下一個 0)、以及 1800000000 的未來時間戳(0x3d068b59)。我用昨天寫的 CRC32 腳本重算,創世雜湊 0xbbe312868b376a3001692a646dd2d7d1e4406380dfd86b98aa8a34d1557c971b 依序餵 Prague、Osaka、BPO1、BPO2、Amsterdam 的時間戳,得 0x0929e24e、0xe7e0e7ff、0x3893353e、0x23aa1351、0x3d068b59,和 Erigon 的測試值一一吻合。加上昨天已核對的 Besu、Nethermind、Reth、Ethrex,現在是五個執行層客戶端寫的測試都得到同一個 0x3d068b59(Ethrex 的那個在尚未合併的 PR 裡)。仍沒有 Hoodi 分叉設定進主分支的執行層是 Geth 與 Ethrex。
三、同一距離的對照:Sepolia 在 12.78 天前是什麼樣子
把 Sepolia 倒推到同樣距離。Sepolia 分叉時間 10 月 6 日 13:53:36 UTC,減去 12.779 天是 9 月 23 日 19:12:06 UTC。依我 10 月 12 日整理的 Sepolia 合併時間表(那張表是自算,我今天沒重做),那個時點:
| Sepolia(9/23 19:12 UTC) | Hoodi(今天) | |
|---|---|---|
| 執行層已合併排程 | 6/6(Nethermind 9/16、Ethrex 9/18、Geth 9/21、Besu 9/21、Reth 9/21、Erigon 9/22) | 4/6(缺 Geth、Ethrex) |
| 共識層已合併排程 | 4(Lodestar、Teku、Prysm、Nimbus;Grandine 9/25 才合,Lighthouse 沒找到排程 PR) | 6/6 |
| 含排程的穩定版 | 1(Geth v1.17.6,9/23 02:21) | 1(Lodestar v1.50.0) |
穩定版數量一樣,但結構顛倒:Sepolia 是執行層早、共識層晚,Hoodi 是共識層早、執行層晚。合併時間離分叉的中位數也呈現同樣的方向:Hoodi 共識層 6 個的中位數是 16.34 天(Sepolia 的 5 個是 13.74 天),Hoodi 執行層已合併的 4 個是 14.22 天(Sepolia 的 6 個是 15.17 天);後者我要誠實標註,Hoodi 的 4 個是「已完成的那幾個」,還沒合併的 Geth 與 Ethrex 沒算進去,所以這個中位數偏樂觀。
Geth 的缺席是今天最值得注意的一點。Sepolia 上 Geth 是第一個合併的執行層之一(分叉前 15.19 天),也是第一個發穩定版的(合併到穩定版只花 1.71 天)。Hoodi 上它到 12.78 天前還沒有 PR。這件事的算術很硬:若 Geth 想在期限前發出含 Hoodi 時間戳的穩定版,即使複製它自己在 Sepolia 上最快的 1.71 天,也必須在 10 月 15 日 06:57 UTC(10 月 16 日 23:59:59 減 1.71 天,自算)前合併。這是「若按 Sepolia 的紀錄」的條件,Geth 可能在發布流程上有我看不到的安排,Geth 最近的發布日是 9 月 23 日、9 月 30 日、10 月 8 日,大致每週一次。
四、兩個「期限前會有幾個穩定版」模型,以及一次回測
先宣告方法與限制:以下全是我自己寫的小模型,不是任何官方預測;資料只有 GitHub API 的發布與合併時間,樣本很小。
模型 A(只看節奏)。 對每個客戶端取最近最多 14 個穩定版(排除預發布),算相鄰發布的間隔。已知「距上一版已過去 e 天、距期限 r 天」時,估計機率 = 歷史間隔裡落在 (e, r] 的個數 ÷ 大於 e 的個數。它假設期限本身不會改變客戶端的發布行為。
以今天的資料算(r 是期限減上一版發布時間):
| 客戶端 | 上一版 | 已過 e(天) | 到期限 r(天) | 機率 |
|---|---|---|---|---|
| Lighthouse | 10/1 | 12.87 | 15.91 | 0.00 |
| Teku | 10/8 | 5.04 | 8.08 | 0.00 |
| Nimbus | 10/4 | 9.48 | 12.52 | 0.11 |
| Prysm | 10/5 | 8.07 | 11.11 | 0.00 |
| Grandine | 8/3 | 71.64 | 74.69 | 0.00(只有 3 個符合條件的間隔) |
| Nethermind | 10/1 | 12.01 | 15.05 | 0.11 |
| Besu | 9/25 | 18.03 | 21.07 | 0.20 |
| Reth | 9/28 | 15.43 | 18.47 | 0.00 |
| Erigon | 10/2 | 11.62 | 14.66 | 0.50 |
加總後,共識層除了 Lodestar 以外預期再多 0.11 個、執行層(只算 Hoodi 已合併的 4 個)預期 0.81 個。
回測。 這個模型有個明顯風險,所以我把它搬到 Sepolia 上驗證。Sepolia 的發布期限是 9 月 29 日 23:59:59 UTC(第 187 次共識層電話會議逐字稿裡 stokes 說的「29 日」,我 10 月 12 日讀的),往前推同樣的 3.04 天,時間點是 9 月 26 日 23:01 UTC。用那一刻以前的發布歷史,對 8 個「當時已合併但還沒發版」的客戶端做同樣的估計,結果預期 2.04 個會在期限前發版,實際是 6 個(Reth、Prysm、Lodestar、Teku、Ethrex、Nimbus 都在 9 月 28 到 29 日發版,Nethermind 與 Grandine 沒有)。其中 Prysm(上一版是 7 月 29 日)與 Nimbus(8 月 28 日)的模型機率是 0,實際卻發了。結論:**期限會改變發布行為,只看節奏的模型低估約三倍。**它在今天算出的「共識層多 0.11 個」不可信,我保留這個數字只是為了公開失敗。
模型 B(合併到穩定版的延遲)。 用我 10 月 12 日量的 Sepolia 10 個延遲(天):1.71、2.48、4.44、15.41、7.09、10.44、5.82、10.86、6.56、6.65。對每個已合併的客戶端,令 e = 現在 − 合併時間、r = 期限 − 合併時間,機率 = 延遲落在 (e, r] 的個數 ÷ 大於 e 的個數,各客戶端視為獨立,再用泊松二項分布加總:
| 客戶端 | 合併後已過 e(天) | 到期限 r(天) | 機率 |
|---|---|---|---|
| Teku | 5.03 | 8.07 | 0.57 |
| Nimbus | 3.85 | 6.89 | 0.50 |
| Besu | 1.69 | 4.73 | 0.30 |
| Prysm | 3.26 | 6.31 | 0.25 |
| Lighthouse | 1.76 | 4.80 | 0.22 |
| Nethermind | 1.93 | 4.97 | 0.22 |
| Grandine | 0.54 | 3.59 | 0.20 |
| Reth | 1.19 | 4.24 | 0.20 |
| Erigon | 0.31 | 3.35 | 0.20 |
共識層(Lodestar 已有,另外 5 個)的「穩定版總數」分布:1 個 10%、2 個 32%、3 個 36%、4 個 18%、5 個 3.9%、6 個 0.3%,中位數 3,平均 2.74。執行層(4 個已合併)的穩定版數:0 個 35%、1 個 42%、2 個 19%、3 個 3.7%、4 個 0.3%,平均 0.92,至少 1 個 65%。
兩個誠實的限制。第一,模型 B 的延遲就取自 Sepolia 這一次事件,回測它是樣本內的,不能當獨立驗證;我能說的只有「模型 A 在回測上明顯失敗,模型 B 至少沒被同一個回測否定」。第二,獨立假設可能不對:客戶端團隊之間有共同的壓力(同一個期限),分布的尾端(全部都發或全部不發)實際上會比算出來的厚。執行層的數字也沒有把 Geth 與 Ethrex 算進去,它們若在今明兩天合併,執行層的數字會往上修,但上一節算過,Geth 的窗口已經很窄。
五、一個小註記:Prysm 的版本推算
Prysm 的穩定版間隔很不規則(v7.1.8 在 7 月 29 日,v7.2.0 在 9 月 28 日,v7.2.1 在 10 月 5 日),9 月 28 日這一版是 Sepolia 的期限驅動、10 月 5 日是 Sepolia 分叉前 16 小時的補丁版。所以對 Prysm 這類「平時很久才發版、期限前才趕」的客戶端,模型 A 一定失效,模型 B 給 0.25。我不確定 0.25 是否合理,因為 Prysm 第 17650 號與 17664 號都已在 10 月 10 日與 10 月 13 日合併,「差一個發布」的工作量可能比 Sepolia 時小。這是推論。
🧠 記
- 記分板(10 月 13 日 23:01 UTC): 共識層 6/6 合併(Grandine 第 980 號 10/13 09:56:48);執行層 4/6(Erigon 第 24847 號 10/13 15:41:10;缺 Geth、Ethrex);含 Hoodi 時間戳的穩定版仍 1 個(Lodestar v1.50.0);距分叉 12.779 天,距期限 3 天 0 小時 58 分。
- Prysm: Hoodi 排程是第 17650 號(10/10 16:40:37 UTC);第 17664 號(規格升到 v1.7.0-beta.4)10/13 20:31:58 UTC 合併,base 已是
develop。 - 一致性: Erigon 與 Grandine 的 PR 都寫
0x80000910、epoch 132352、2 億 gas;Erigon 的 fork ID 測試0x3d068b59與我的 CRC32 重算相符,現在五個執行層測試值相同。 - 同距離對照: Sepolia 在 12.78 天前是執行層 6/6、共識層 4、穩定版 1;Hoodi 是執行層 4/6、共識層 6/6、穩定版 1。
- Geth 算術: 要在期限前發含 Hoodi 的穩定版,依它自己 Sepolia 的 1.71 天延遲,PR 要在 10 月 15 日 06:57 UTC 前合併。
- 模型: 只看節奏的模型 A 在 Sepolia 回測預期 2.04 個、實際 6 個,低估三倍,棄用;用 Sepolia 10 個合併到穩定版延遲的模型 B,共識層穩定版總數中位數 3(平均 2.74),執行層(4 個已合併)平均 0.92、至少 1 個 65%。
- 昨天預測的結算: 預測三(Prysm 第 17662 與 17664 號都合併)成立;預測四(Lighthouse 或 Grandine 至少一個合併)昨天已成立,今天 Grandine 也補上;其餘(穩定版數量、Geth、第 5734 號 PR、日期不變)仍在期限內。
邊界: 資料主要是 GitHub API,時間點是 10 月 13 日 23:01 UTC;Teku 倉庫的 PR 搜尋對我的存取會失敗,所以 Teku 的合併時間沿用 10 月 11 日的紀錄並用單一 PR 查詢重驗。Geth「沒有 PR」是用三組關鍵字搜尋的結果,不是證明。Sepolia 的合併與發布時間來自 10 月 12 日的自算表,今天沒有重做,Lighthouse 在 Sepolia 沒有找到對應 PR 所以不在延遲樣本。兩個模型是自寫、樣本僅 10 個延遲與 8 個回測客戶端、獨立假設可能不成立;模型 B 的回測是樣本內。不構成任何投資、質押或營運建議。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 重做記分板(約 5 分鐘):
for r in grandinetech/grandine:980 erigontech/erigon:24847 OffchainLabs/prysm:17664 NethermindEth/nethermind:14489 hyperledger/besu:11531 paradigmxyz/reth:27811 lambdaclass/ethrex:7391; do
repo=${r%%:*}; n=${r##*:}
echo "$repo $n"; gh api repos/$repo/pulls/$n --jq '"\(.state) merged=\(.merged_at) \(.title)"'
done
# Geth 是否已有 amsterdamTime
gh api repos/ethereum/go-ethereum/contents/params/chainspecs/hoodi.json --jq .content | base64 -d | grep -i time
# 各客戶端最新穩定版
for repo in ChainSafe/lodestar sigp/lighthouse Consensys/teku status-im/nimbus-eth2 OffchainLabs/prysm; do
gh api "repos/$repo/releases?per_page=4" --jq '.[] | "\(.tag_name) \(.published_at) pre=\(.prerelease)"' | head -2
done- 重算 fork ID(約 3 分鐘),確認和 Erigon 的測試相符:
import zlib, struct
c = zlib.crc32(bytes.fromhex("bbe312868b376a3001692a646dd2d7d1e4406380dfd86b98aa8a34d1557c971b"))
for t in (1742999832, 1761677592, 1762365720, 1762955544, 1793036568):
c = zlib.crc32(struct.pack(">Q", t), c)
print(t, "0x%08x" % c) # 最後一行應為 0x3d068b59- 自己跑模型 B(約 10 分鐘):把 10 個延遲放進去,對任一客戶端的合併時間算機率,再試著改成「只用該客戶端自己的 Sepolia 延遲」看結果差多少。
import 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, 13, 23, 1, 18)
deadline = dt.datetime(2026, 10, 16, 23, 59, 59)
def p_release(merged):
e = (now - merged).total_seconds() / 86400
r = (deadline - merged).total_seconds() / 86400
alive = [x for x in lags if x > e]
return sum(1 for x in alive if x <= r) / len(alive)
print(p_release(dt.datetime(2026, 10, 8, 22, 20, 7))) # Teku,應為 0.571- 回測自己的模型(約 5 分鐘):挑 Sepolia 另一個時間點(例如期限前 5 天),看模型 B 的預期數與實際差多少;這會直接暴露樣本內的問題。
- 讀 Erigon 第 24847 號的
forkid_test.go,想一想為什麼要測「分叉前一秒」與「分叉當秒」兩列,而不是只測分叉之後。
可證偽預測(沒特別註明的都在 10 月 16 日 23:59:59 UTC 到期):
- 預測一: 含 Hoodi 時間戳的共識層穩定版(非預發布,含 Lodestar)至少 3 個。模型 B 給 58%,是偏多的押注;與昨天「2 或 3 個」的預測並存,昨天那條在模型 B 下是 68%,若最後是 4 個以上,昨天那條算錯、今天這條算對。
- 預測二: 含 Hoodi 時間戳的執行層穩定版至少 1 個(模型 B 在 4 個已合併的客戶端給 65%)。若是 0 個,我的判斷錯。
- 預測三: Geth 的
hoodi.json在期限前出現amsterdamTime: 1793036568(把握中等,約 70%),但 Geth 含 Hoodi 的穩定版在期限前不會出現(依 Sepolia 的 1.71 天延遲,需要 10 月 15 日 06:57 UTC 前合併)。這兩段分開驗證。 - 預測四: Ethrex 第 7391 號 PR 在期限前合併(約 70%;它自 10 月 9 日後沒動,但 Ethrex 發版快,10 月 5 日同一天出了 v29.0.0 與 v29.0.1)。
- 預測五(10 月 23 日 23:59 UTC 到期): consensus-specs 第 5734 號 PR 在這之前合併進主分支,且 Hoodi 分叉時間仍是 10 月 26 日 17:42:48 UTC(沿用;今天 PR 仍 open、標籤 testing、gloas、heze,狀態落後主分支,10 月 13 日 22:49 UTC 有更新,尚無審查)。
明天接的待辦:10 月 15 日 14:00 UTC 的第 189 次共識層電話會議(議程只寫 Glamsterdam、Hegotá〔含吉祥物〕與硬分叉流程敏捷性)的結果、Geth 與 Ethrex 的 Hoodi PR、Hoodi 的客戶端發布公告是否出現、Lighthouse 與 Teku 的新版、ethereum/pm 第 2263 號與第 2266 號 PR。
🔗 延伸學習
- erigontech/erigon 第 24847 號 PR:chainspec, clparams: schedule Glamsterdam on Hoodi(GitHub) — 本文第二節的 fork ID 測試與 Hoodi 設定常數,歷時 2 小時 11 分的小 PR。
- grandinetech/grandine 第 980 號 PR:Schedule Gloas fork activation on Hoodi(GitHub) — 22 分鐘合併、補齊共識層 6/6 的最後一塊。
- ethereum/pm 第 2247 號議題:ACDC 第 189 次議程(GitHub) — 10 月 15 日 14:00 UTC 電話會議的議程,「硬分叉流程與敏捷性」與本文第四節的發布期限直接相關。
- Glamsterdam Testnet Announcement(Ethereum Foundation Blog) — Sepolia 與 Hoodi 時程與客戶端發布清單的官方公告,Hoodi 的公告格式可對照這篇。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度(查證時間 2026-10-13 23:01 UTC,資料來自 GitHub API 的 PR 合併時間與發布時間)。以下是我自己整理的主張與兩個自寫的小模型,請協助查證並嚴格區分來源:
1. 事實:共識層 6 個客戶端(Lodestar、Teku、Nimbus、Prysm、Lighthouse、Grandine)都已合併 Hoodi 的 Gloas 排程(epoch 132352,時間戳 1793036568);執行層 4/6 已合併(Nethermind、Besu、Reth、Erigon),Geth 與 Ethrex 尚未;含 Hoodi 時間戳的穩定版目前只有 Lodestar v1.50.0;發布期限是 2026-10-16 23:59:59 UTC,分叉在 2026-10-26 17:42:48 UTC。
2. 模型 A:用每個客戶端自己最近最多 14 個穩定版的發布間隔,估「距上次發布已過 e 天、到期限還有 r 天」時在期限前發版的機率。我在 Sepolia 上回測(把時間點放在期限前 3.04 天),預期 2.04 個客戶端發版、實際 6 個,所以我認為它低估了期限對發布行為的影響。
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、執行層(4 個已合併)平均 0.92 個、至少 1 個 65%。這個延遲樣本取自同一次 Sepolia 事件,所以我知道回測是樣本內。
4. Erigon 第 24847 號 PR 的 fork ID 測試值 0x3d068b59 與我用 EIP-2124(加 EIP-6122 的時間戳分叉)以 CRC32 重算 Hoodi 創世雜湊 0xbbe312868b376a3001692a646dd2d7d1e4406380dfd86b98aa8a34d1557c971b 加五個時間戳的結果相同。
請幫我:
(a) 檢查模型 A 與 B 的統計設計:條件機率的定義、泊松二項分布的獨立假設、樣本只有 10 個延遲時應該怎麼表達不確定性(例如信賴區間或自助法),以及「期限壓力使各客戶端的發布時間相關」會讓分布尾端如何改變;
(b) 提出一個比我的樣本內回測更站得住腳的驗證設計(例如用其他分叉或其他測試網的資料,或留一法交叉驗證),並說明需要哪些公開資料;
(c) 解釋 EIP-2124 的驗證規則為什麼讓「沒升級的節點在分叉前不會被發現」,以及 Erigon 測試裡「分叉前一秒」與「分叉當秒」兩列各驗證什麼;
(d) 分三類標示每一個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押或節點營運建議。