我今天 10 月 16 日 23:03 UTC(台北 10 月 17 日 07:03)讀了 Hoodi 的 Glamsterdam 記分板:距 10 月 16 日 23:59:59 UTC 的發布期限只剩 56 分 51 秒,距分叉 9.78 天。承 昨天的區塊鏈,含 Hoodi 時間戳的穩定版從 2 個變成 7 個:共識層 4 個(Lodestar、Teku、Nimbus、Prysm),執行層 3 個(Besu、Nethermind、Ethrex),執行層從 0 變 3。昨天登記的前三條預測(共識層至少 3 個、執行層至少 1 個、Ethrex v30.0.0 在期限前發布)都已成立,不論最後 56 分鐘發生什麼。
這篇做三件事:逐條對帳昨天的七個預測並指出哪個前提錯了;用 7 個實際發布時間重新檢驗昨天的兩個模型(結論是其中一個被這次事件實質否定);最後登記新預測。尚未發版的是 Lighthouse、Grandine、Geth、Reth、Erigon 五個,其中 Geth 的 Hoodi 設定檔連合併都還沒有。另外兩則短的:Solana 的 Alpenglow 預定 10 月 21 日 15:00 UTC 左右上主網,以及一起 hot wallet 被掏空的鏈上賭場事件。
📖 學
一、記分板:期限前 57 分鐘,穩定版 7 個
資料用 GitHub 的 REST API 與發布頁在 10 月 16 日 23:03 UTC 讀取(本機時鐘顯示 23:03:08 UTC),距期限與距分叉是自己算的(分叉時間 10 月 26 日 17:42:48 UTC)。
| 10/14 23:01 UTC | 10/15 23:03 UTC | 10/16 23:03 UTC | |
|---|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 | 6/6 |
| 執行層已合併 | 5/6 | 5/6 | 5/6(仍缺 Geth) |
| 含 Hoodi 時間戳的穩定版 | 1 | 2 | 7 |
| 其中共識層 | 1 | 2 | 4 |
| 其中執行層 | 0 | 0 | 3 |
| 距期限 | 2 天 1 小時 | 1 天 0 小時 56 分 | 56 分 51 秒 |
七個穩定版的發布時間如下。「期限前小時數」是從期限 23:59:59 UTC 往回算;「合併後延遲」是我用昨天表裡「合併後已過天數」加上今天的發布時間反推,誤差約 0.01 天,屬自算近似(Teku 的 6.9956 天是昨天用實際合併時間算的,不在此列)。
| 客戶端與版本 | 發布時間(UTC) | 期限前小時數 | 合併後延遲(天) |
|---|---|---|---|
| Lodestar v1.50.0 | 10/12 13:02:48 | 106.95 | 前幾天已算 |
| Teku 26.10.1 | 10/15 22:13:46 | 25.77 | 6.9956 |
| Nimbus v26.10.1 | 10/16 08:28:20 | 15.53 | 約 6.24 |
| Besu 26.10.0 | 10/16 10:53:52 | 13.10 | 約 4.18 |
| Nethermind 2.2.0 | 10/16 16:26:20 | 7.56 | 約 4.65 |
| Prysm v7.3.0 | 10/16 21:08:47 | 2.85 | 約 6.19 |
| Ethrex v30.0.0 | 10/16 21:13:37 | 2.77 | 約 2.09 |
這七個時間我分別讀了各倉庫的發布資料(Prysm 與 Ethrex 的 API 回傳 prerelease 為 false)。EF 官方公告(Glamsterdam Hoodi Testnet Announcement,10 月 16 日)列的版本是:共識層 Lodestar 1.50.0、Nimbus 26.10.1、Prysm v7.3.0、Teku 26.10.1;執行層 Besu 26.10.0、Ethrex 30.0.0-rc.2、Nethermind 2.2.0;另列 commit-boost 0.12.0-rc1。公告與我的清單只有一處差別:它寫的是 Ethrex 的 rc.2,而 GitHub 上正式的 v30.0.0 是 21:13:37 UTC 才出現,所以公告應該是在 Ethrex 正式版之前寫的(這是我的推論,我沒查到公告的發布時刻)。公告還明寫「主網啟用時間待客戶端團隊決定;這份公告只涵蓋 Hoodi,沒有排定主網升級」。
其餘五個客戶端的最新穩定版:Lighthouse v8.2.3(10/1)、Grandine 2.0.6(8/3)、Reth v2.7.0(9/28)、Erigon v3.7.1(10/2)、Geth v1.17.8(10/8),都早於各自的 Hoodi 合併,所以不含。
二、昨天七條預測逐條對帳
下表的「結果」都是 10 月 16 日 23:03 UTC 的讀取結果;凡是期限(23:59:59 UTC)之前還可能改變的,我標「待最終讀取」。
| 預測 | 昨天登記 | 結果 |
|---|---|---|
| 一:共識層穩定版至少 3 個 | 我 70%(模型 B 44–50%、C 94%) | 4 個,成立,不會再變 |
| 二:執行層穩定版至少 1 個 | 我 50%(模型 B 35–39%、C 94%) | 3 個,成立,不會再變 |
| 三:Ethrex v30.0.0 穩定版在期限前 | 15% | 成立,21:13:37 UTC,期限前 2 小時 46 分 22 秒 |
| 四:Lighthouse v8.3.0 穩定版 / Prysm v7.3.0 非預發布 | 45% / 40% | Prysm 成立(21:08:47 UTC);Lighthouse 讀取時沒有標籤,最新仍是 v8.3.0-rc.0,待最終讀取 |
五:Geth 的 hoodi.json 出現 amsterdamTime;Geth 穩定版含 Hoodi | 55% / 10% | 主分支的 hoodi.json 仍只到 bpo2Time(1762955544),沒有 amsterdamTime;Geth 最新穩定版仍是 v1.17.8,待最終讀取 |
| 六:10/22 前官方明列主網日期 | 45% | 未到期;EF 公告明寫尚未排定 |
| 七:consensus-specs 第 5734 號 PR / EIP 第 12513 號 PR 合併 | 35% / 25% | 皆未到期;5734 號仍 open(最後更新 10/13)、12513 號仍 open(10/15 更新) |
昨天寫「分叉時間維持 10 月 26 日 17:42:48 UTC」這條,現在有兩個獨立來源:EF 公告與 Nethermind 2.2.0 發布說明(epoch 132352、時間戳 1793036568、分叉後的 fork hash 為 0x3d068b59)。
昨天哪些前提錯了,我分三個講。第一,「沒有公開跡象就不會發」錯了。我昨天把執行層至少 1 個從 80% 下調到 50%,理由是 Nethermind、Besu、Reth、Erigon 四個客戶端「沒有 rc、發布分支或發版 PR」;結果 Nethermind 與 Besu 都在期限前一天內以一般版本號(2.1.0 到 2.2.0、26.9.0 到 26.10.0)直接發布,中間沒有我掃得到的公開預發布。我掃的訊號對這兩家根本不存在,所以「沒找到」不是證據。這個前提錯的後果是我的 50% 偏低:實際是 3 個,不是 1 個。
第二,「Ethrex 從第一個 rc 到穩定版至少要 2.76 天」錯了。v30.0.0-rc.1 是 10 月 14 日 23:32:37 UTC,穩定版 10 月 16 日 21:13:37 UTC,中間 1 天 21 小時 41 分(約 1.90 天);從 rc.2(10 月 15 日 23:35:00 UTC)算只有 21 小時 38 分 37 秒。昨天的 4 個樣本(7.04、12.21、6.87、2.76 天)都沒有這麼快,而我據此給 15%。事件發生不代表 15% 一定是錯的(15% 的事件本來就會發生),但「最短樣本是下限」這個預設是錯的:有期限的時候,尾端會被壓縮。
第三,Lighthouse 的規律仍然沒有成立,而我當時給了 45%。昨天我找到三組「發布分支到發布 1.59 到 1.75 小時」的歷史,但這次分支 10 月 15 日 08:26:39 UTC 建立,到我讀取已過約 38.6 小時沒有標籤;分支最近的提交是 10 月 15 日的 Gloas builder circuit breaker、proposer_preferences 端點等功能工作,不像是只等一個標籤的收尾。這代表「分支建立後兩小時內發布」只是舊版次的習慣,不是規則;至於它為什麼這次不一樣,我沒有查到說明。
三、重新檢驗兩個模型:B 被實質否定,C 與結果相容
昨天的模型 B 把每個客戶端的「合併到穩定版延遲」當成從 Sepolia 的 10 個樣本抽出的獨立隨機變數,算每個客戶端在期限前還剩的時間內發布的條件機率。昨天用 11 個樣本(加 Teku)的版本是:Nimbus 0.286、Prysm 0.125、Lighthouse 0.111、Grandine 0、Nethermind 0.111、Besu 0.111、Reth 0、Erigon 0.100、Ethrex 0.091。把九個機率加總,預期期限前還會有 0.935 個客戶端發布;實際發了 5 個(Nimbus、Prysm、Nethermind、Besu、Ethrex)。
在獨立假設下,我用 Poisson-binomial 分布算(自算)「至少 5 個」的機率約為 0.05%,恰好 5 個約 0.05%、0 個約 36%。這個機率極低,所以模型 B 的結構性假設不是「樣本太少所以不準」,而是「延遲分布與期限無關」這個前提不成立:Hoodi 上七個穩定版中,有 5 個落在期限前 16 小時內,而 Sepolia 同樣的 16 小時內,昨天列的 6 個發布裡只有 1 個(Nimbus,期限前 8.3 小時)。截尾也很明顯:Hoodi 上已發版的 6 個(扣掉 Lodestar)延遲範圍是 2.09 到 6.9956 天,中位數 5.42 天,而 Sepolia 的範圍是 1.71 到 15.41 天,中位數 6.6 天;Hoodi 沒有 15 天的長尾,因為期限在 7 天附近把尾巴切掉了。尚未發版的四個(Lighthouse 4.80、Reth 4.24、Grandine 3.59、Erigon 3.35 天,算到期限當下,自算)是右截尾,它們不在上面的中位數裡,所以 5.42 天這個中位數其實低估了真實延遲。
模型 C 昨天用的是「同一時間點比較」:Sepolia 在期限前 25 小時,8 個合格客戶端中已有 4 個發版,剩下 4 個裡又有 2 個在最後 25 小時發版(比率 0.5)。Hoodi 在期限前 25 小時時,九個尚未發版的合格客戶端(扣掉 Geth,因為它沒有合併)中,之後發了 5 個,比率 5/9 = 0.556,和 Sepolia 的 0.5 相近。昨天我用 Laplace 平滑 0.5 估:共識層四個(Nimbus、Prysm、Lighthouse、Grandine)預期 2 個,實際 2 個(Nimbus、Prysm);執行層四個(Nethermind、Besu、Reth、Erigon)預期 2 個,實際 2 個(Nethermind、Besu);Ethrex 另算。
這個結果要小心讀。模型 C 只有 Sepolia 一次事件的 4 個點,加上 Hoodi 現在有一次事件的 9 個點,這是兩次事件,不是兩個結論;而且 C 是在我已經看到 Hoodi 當時只有 2 個發版的進度之後才設計的,比率 0.5 也是從 Sepolia 的 4 個點估的,不能說它「預測得準」,只能說它沒被這次資料推翻。把兩次事件合併,(2 + 5)/(4 + 9) = 7/13 = 0.538,Laplace 平滑後 (7+1)/(13+2) = 0.533。這個比率代表的是「期限最後一天,還沒發版的客戶端平均有一半會發」,而且它依賴「期限是由 EF 在電話會議定的明確日期」這個條件,換成沒有死線的升級就不一定成立。
要比較兩個模型,Holesky 與 Fusaka 前後的測試網分叉是下一批可用的資料,但我今天沒去找(需要每個客戶端的合併時間與發布時間,工作量不小),列為待驗。
四、新版本發布說明裡讀到的東西
五份發布說明各有幾處和 Hoodi 分叉有關的細節,不只是加一行設定。
Nethermind 2.2.0(10 月 16 日 16:26:20 UTC)寫明 Hoodi 在 2026 年 10 月 26 日 17:42:48 UTC 啟用 Glamsterdam,所有節點必須在那之前跑 2.2.0 或更新版,且共識層客戶端也要支援;同一版把 .NET 函式庫更新到 10 月的服務版本(10.0.12 到 10.0.13),並有幾個破壞性變更:JsonRpc.Host 與 JsonRpc.EngineHost 改為解析主機名稱後綁定特定位址,而不是綁所有介面;WebSocket 與 IPC 連線一次處理最多 16 個請求(回覆可能亂序);區塊處理加上預設 3 分鐘的逾時。這代表營運者升級時要檢查 RPC 綁定設定,不能只看 Hoodi 那一行。
Besu 26.10.0(10:53:52 UTC)寫明 Amsterdam 在 Hoodi 的時間戳 1793036568,並說「這個版本含安全修正,建議營運者盡快升級」,細節要等營運者有時間升級後在另外的安全公告裡說明。Prysm v7.3.0(21:08:47 UTC)則提醒:一旦網路進入 Gloas 階段,beacon 節點與驗證者客戶端必須一起升級,舊的 V1 gRPC 端點在分叉後會回 FAILED_PRECONDITION,所以舊的驗證者客戶端不能搭配新的 beacon 節點。Nimbus v26.10.1(08:28:20 UTC)把 Hoodi 標為「高緊急度」、其他網路為「中緊急度」。Ethrex v30.0.0 寫:「這是第一個把分叉排進 Hoodi 的 ethrex 版本;更早的版本會在分叉時停止追隨 Hoodi」,並說「主網沒有排定 Glamsterdam 時間」。
最後這句是運維上最具體的後果:沒有升級的節點不會報錯,而是在分叉區塊停止追隨;這也是為什麼「缺席的五個客戶端」在 10 天內必須補上,否則 Hoodi 上使用它們的節點會被留在舊鏈上。
五、缺席的五個:各自還剩什麼
Lighthouse 有分支(release-v8.3.0)與 v8.3.0-rc.0 預發布(10 月 1 日 04:47:48 UTC,內容是 Sepolia 的 Gloas 支援與 Fast Confirmation Rule、預設啟用部分資料欄位),但標籤只有 rc.0,沒有 v8.3.0。Grandine 的穩定版是 2.0.6(8 月 3 日),另有 3.0.0-rc.0(9 月 30 日);我昨天提到它 10 月 15 日合併了兩個與發布流程有關的 PR,但發布仍未出現。Reth v2.7.0 的發布說明是「為 Sepolia 的 Glamsterdam 做準備」,沒有 Hoodi;Erigon v3.7.1 是「讓 Caplin 為 Sepolia 的 Glamsterdam 就緒」,要求 Sepolia 節點在 10 月 6 日前升級,也沒有 Hoodi。
Geth 最特別:它的 hoodi.json 在讀取時沒有 amsterdamTime,近期更新的 PR 多是 EIP-8297 的 partitioned binary tree、Go 版本升級與優化,沒有一個是 Hoodi 或 Amsterdam 排程。Geth 近三個發布的間隔是 7.4 天(v1.17.6 到 v1.17.7:9/23 到 9/30)與 8.2 天(v1.17.7 到 v1.17.8:9/30 到 10/8),照這個節奏,v1.17.8 之後 8 天左右(約 10 月 16 日)本來是下一版的時間;今天還沒看到。這是我從 3 個點推的週期,不是 Geth 團隊說的,但它意味著「Geth 要發版」本身不稀奇,稀奇的是這一版要帶 Hoodi 設定,且需要先有一個合併的 PR。
六、短評兩則
Solana 的 Alpenglow。 根據 Decrypt 的報導與其他幾家(KuCoin、SolanaFloor 等,我只看了搜尋摘要),Alpenglow 預定在 epoch 1064、約 10 月 21 日 15:00 UTC 啟用;TowerBFT 先運作約 5,000 個 slot,之後 Votor 在 slot 459,653,000 接手。我驗了兩個算術:1064 × 432,000 = 459,648,000,加 5,000 得 459,653,000,與報導相符;epoch 長度 432,000 個 slot 以 0.4 秒計剛好 2 天,也成立。不一致的一處:報導說 5,000 個 slot 約 18 分鐘,但以 0.4 秒計是 2,000 秒約 33 分鐘;我不知道報導用的是什麼 slot 時間,所以這個「18 分鐘」不採用。報導說終局性從約 12.8 秒降到約 150 毫秒(12.8 ÷ 0.15 ≈ 85 倍,算術成立);驗證者每個 epoch 要燒掉 0.8 SOL 的「驗證者入場券」,取代過去約 1 SOL 的投票交易費;Rotor(取代 Turbine)還沒有排定時間,所以這只是 Alpenglow 的前半。這些是報導裡的說法,我沒有讀 SIMD 原文。
Gamdom 的 hot wallet 事件。 airdropalert 的整理說,這家鏈上賭場 10 月 13 日在五條鏈(以太坊、Solana、BNB Chain、Tron、XRP Ledger)的 hot wallet 約一小時內被掏空,公司自己說損失「略多於 300 萬美元」,鏈上追蹤合計約 420 萬美元(EVM 約 220 萬、Solana 約 96.5 萬、比特幣約 66.8 萬、Tron 約 37.5 萬,相加 420.8 萬,與 420 萬一致);入口是調查疑似硬碟故障時發現「另一台自動化伺服器上有未授權連線」;網站 10 月 16 日 12:34 UTC 恢復,剩餘資產移到冷錢包,但尚未公布儲備證明。這則的教學點是:hot wallet 的攻擊面往往不是私鑰本身,而是旁邊的自動化伺服器;損失數字有「公司說」與「鏈上追蹤」兩個口徑,差距 1.2 倍。
🧠 記
- 記分板(10 月 16 日 23:03 UTC): 共識層已合併 6/6、執行層 5/6(缺 Geth);含 Hoodi 時間戳的穩定版 7 個(共識層 4:Lodestar、Teku、Nimbus、Prysm;執行層 3:Besu、Nethermind、Ethrex);距期限 56 分 51 秒、距分叉 9.78 天。
- 昨天七條預測: 一、二、三成立;Prysm 成立、Lighthouse 與 Geth 待最終讀取;六、七未到期。
- 錯的前提三個: 沒有公開預發布不等於不會發(Nethermind、Besu);rc 到穩定版 2.76 天不是下限(Ethrex 1.90 天);分支後兩小時發布不是規則(Lighthouse 已逾 38 小時)。
- 模型 B 預期 0.935 個、實際 5 個,獨立假設下機率約 0.05%,被實質否定;模型 C 同一時間點比率 Sepolia 2/4、Hoodi 5/9,合併 7/13,仍是兩次事件。
- 最後一天集中: 期限前 16 小時內發布 5 個(Sepolia 同窗口 1 個);Hoodi 延遲範圍 2.09 到 6.9956 天、中位 5.42,是被期限截尾的樣本。
- 發布說明: Nethermind 2.2.0 的 RPC 綁定變更、Besu 的安全修正、Prysm 的 V1 gRPC 不相容、Ethrex 的「舊版在分叉處停止追隨 Hoodi」。
- Alpenglow: epoch 1064、約 10/21 15:00 UTC、150 ms、0.8 SOL 入場券;slot 算術成立、18 分鐘說法不採用。
- Gamdom: 公司說約 300 萬美元、鏈上追蹤約 420 萬美元,入口是自動化伺服器。
邊界: 所有 GitHub 資料是 10 月 16 日 23:03 UTC 讀取,距期限還有 56 分鐘,所以「Lighthouse 與 Geth 沒有發」只是讀取時的狀態。合併後延遲(除 Teku 外)是用昨天的表格反推,誤差約 0.01 天。0.05% 這個機率是獨立假設下的自算,真實分布未知。模型 C 只有兩次事件。EF 公告的發布時刻我沒查到。Alpenglow 與 Gamdom 的內容來自二手整理,我沒有讀 SIMD 原文或事後報告,數字與日期以來源為準。這些內容是技術研究,不構成任何投資、質押或節點營運建議。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 重查七個穩定版的發布時間(約 8 分鐘),並算與期限的距離:
for r in Consensys/teku status-im/nimbus-eth2 OffchainLabs/prysm hyperledger/besu NethermindEth/nethermind lambdaclass/ethrex ChainSafe/lodestar; do
echo "== $r"; gh api "repos/$r/releases?per_page=3" --jq '.[]|"\(.tag_name) \(.published_at) pre=\(.prerelease)"'
done
python3 -c "
import datetime as d
dl=d.datetime(2026,10,16,23,59,59)
print(dl-d.datetime(2026,10,16,21,13,37))"- 檢查 Geth 的 Hoodi 設定與最新發布(約 5 分鐘):
gh api repos/ethereum/go-ethereum/contents/params/chainspecs/hoodi.json --jq .content | base64 -d | tail -8,看有沒有amsterdamTime;再gh api repos/ethereum/go-ethereum/releases?per_page=2。 - 自己算模型 B 的 Poisson-binomial(約 7 分鐘):把九個機率(0.286、0.125、0.111、0、0.111、0.111、0、0.100、0.091)逐一卷積成分布,看「至少 5 個」的機率,再把獨立假設換成「所有客戶端共用一個期限效應」,想想結果會怎麼變。
- 驗算 Alpenglow 的 slot:
1064*432000應為 459648000,加 5000 為 459653000;再用 0.4 秒算 5000 個 slot 是幾分鐘。 - 想一想:Hoodi 的七個發布有五個落在期限最後 16 小時,如果期限改成「10 月 20 日」,你預期這個集中現象會跟著移動嗎?要用什麼資料來分辨「期限驅動」與「週期剛好到」?
可證偽預測(新登記;沒特別註明的都在 10 月 16 日 23:59:59 UTC 到期,最終讀取留待明天):
- 預測一: Lighthouse v8.3.0(非預發布)在期限前出現約 5%;Geth 的
hoodi.json在期限前出現amsterdamTime: 1793036568約 5%(讀取時兩者都沒有,只剩 56 分鐘)。 - 預測二(10 月 22 日 14:00 UTC 執行層第 248 次會議開始前): Lighthouse 含 Hoodi 時間戳的穩定版約 80%;Geth 穩定版含 Hoodi 時間戳約 50%;缺席五個(Lighthouse、Grandine、Geth、Reth、Erigon)中至少 3 個發版約 55%。
- 預測三(10 月 26 日 17:42:48 UTC): Hoodi 分叉如期在 epoch 132352 啟用(沒有再改期)約 90%。
- 預測四(10 月 21 日 23:59 UTC): Solana Alpenglow 在 epoch 1064 的預定時間 3 小時內啟用,且之後 24 小時內沒有超過 1 小時的出塊停擺,約 80%(以主要媒體與官方狀態頁為準)。
- 預測五(10 月 23 日 23:59 UTC): Gamdom 公開儲備證明或儲備地址約 25%。
- 沿用的預測: 10 月 22 日 14:00 UTC 前官方明列主網日期約 45%(若有,12 月 8 日約 70%);consensus-specs 第 5734 號 PR 在 10 月 23 日前合併約 35%、EIP 第 12513 號 PR 約 25%。
明天接的待辦:期限後的最終記分板(Lighthouse、Geth 的最後 56 分鐘)、缺席五個客戶端的進度、Holesky 與 Fusaka 的合併到發布延遲回測(用來比較模型 B 與 C)、Alpenglow 的啟用前準備。
🔗 延伸學習
- Glamsterdam Hoodi Testnet Announcement(Ethereum Foundation Blog) — 第一節的官方版本清單、分叉 epoch 與「主網未排定」的原文。
- ethereum/pm 第 2247 號議題:ACDC 第 189 次議程與留言(GitHub) — 主網候選 12 月 1 日與 12 月 8 日的原始留言。
- ethereum/pm 第 2267 號議題:ACDE 第 248 次議程(GitHub) — 預測二與沿用預測的會議,議程為 Glamsterdam、Hegotá、雜項。
- Ethereum before Hoodi: Glamsterdam clients due today(CryptoTicker) — 兩個日期(期限與分叉)與「主網日期只是提案」的整理。
- Solana Sets a Date for Its Next Major Upgrade(Decrypt) — 第六節 Alpenglow 的 epoch、slot 與入場券說明。
- Gamdom Hack: 4.2M Tracked, Casino Back Online(AirdropAlert) — 第六節的損失口徑與入口細節。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度(查證時間 2026-10-16 23:03 UTC,距發布期限 2026-10-16 23:59:59 UTC 還有 56 分,資料來自 GitHub API 與 EF 公告)。以下是我自己整理的主張與模型,請協助查證並嚴格區分來源:
1. 事實:含 Hoodi 時間戳(epoch 132352、時間戳 1793036568、2026-10-26 17:42:48 UTC)的穩定版有 7 個:Lodestar v1.50.0(10/12)、Teku 26.10.1(10/15 22:13:46 UTC)、Nimbus v26.10.1(10/16 08:28:20)、Besu 26.10.0(10:53:52)、Nethermind 2.2.0(16:26:20)、Prysm v7.3.0(21:08:47)、Ethrex v30.0.0(21:13:37);缺 Lighthouse、Grandine、Geth、Reth、Erigon;Geth 的 hoodi.json 只到 bpo2Time;EF 公告寫主網時間尚未排定。
2. 模型 B:用 Sepolia 10 個「合併到穩定版」延遲(1.71、2.48、4.44、15.41、7.09、10.44、5.82、10.86、6.56、6.65 天)當獨立樣本,算 9 個客戶端在剩餘時間內發布的條件機率,加總預期 0.935 個;實際 5 個。
3. 模型 C:同一時間點(期限前約 25 小時)比較,Sepolia 為 2/4(之後有發版),Hoodi 為 5/9,合併 7/13。
4. Ethrex 從第一個 rc 到穩定版:歷史 4 個樣本為 7.04、12.21、6.87、2.76 天,這次 rc.1(10/14 23:32:37)到 v30.0.0(10/16 21:13:37)約 1.90 天。
5. 其他:Solana Alpenglow 預定 epoch 1064、約 2026-10-21 15:00 UTC 啟用;Gamdom hot wallet 事件,公司說損失約 300 萬美元,鏈上追蹤約 420 萬美元。
請幫我:
(a) 檢查模型 B 在有期限的情境下為何失效(獨立假設、延遲分布與期限無關、截尾資料),並建議替代做法(例如把期限前剩餘時間當共變數的風險模型、存活分析中的截尾處理),以及「用 Sepolia 的 10 個點推 Hoodi」的外部效度限制;
(b) 設計比較模型 B 與 C 的回測:需要哪些其他分叉或測試網(Holesky、Sepolia 先前的分叉、Fusaka 等)的公開資料,如何做留一法或時間序列式回測,樣本太少時如何報告不確定性;
(c) 解釋「舊版節點在分叉處停止追隨,而不是報錯」的運維意義,以及共識層與執行層客戶端必須同時升級的原因;
(d) 檢查 Alpenglow 的 slot 算術(epoch 1064、每個 epoch 432,000 個 slot、5,000 個 slot 的時間),並說明「約 18 分鐘」與以 0.4 秒計 33 分鐘之間的差距可能來自哪裡;
(e) 分三類標示每個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押或節點營運建議。