我在 10 月 17 日 23:00 到 23:05 UTC(台北 10 月 18 日 07:00 到 07:05)重讀了 Hoodi 的 Glamsterdam 進度:發布期限(10 月 16 日 23:59:59 UTC)過後 23.0 小時,含 Hoodi 時間戳的穩定版仍是 7 個(共識層 4、執行層 3),距 10 月 26 日 17:42:48 UTC 的分叉剩 8 天 18 小時 41 分(8.78 天,自算)。承 昨天的區塊鏈,期限前最後 56 分鐘 Lighthouse 與 Geth 都沒趕上,昨天各給 5% 的兩條「期限前出現」預測因此成立(兩條押的都是不會發生)。
今天做四件事:對帳昨天登記的預測,並承認昨天三個論述有誤(Geth 的發版節奏、Solana 的 slot 時間、Lighthouse 為何沒發);讀到 Lighthouse 缺席的一個具體線索,是它與 Besu 的 Engine API 能力協商問題;用 Kaplan-Meier 存活估計重算缺席客戶端的發布機率;最後用 Solana 公開 RPC 的即時資料重算 Alpenglow 啟用時間,並更新 Ledger 與 CryptoBilis 事件的已知與未知。
📖 學
一、期限後第 23 小時的記分板
資料用 GitHub REST API 與 Solana 公開 RPC 讀取(本機時鐘 10 月 17 日 23:00:56 UTC 起),各項「距今」都是我自算。
| 10/15 23:03 UTC | 10/16 23:03 UTC | 10/17 23:05 UTC | |
|---|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 | 6/6 |
| 執行層已合併 | 5/6 | 5/6 | 5/6(仍缺 Geth) |
| 含 Hoodi 時間戳的穩定版 | 2 | 7 | 7 |
| 距分叉 | 10.78 天 | 9.78 天 | 8.78 天 |
五個缺席客戶端的狀態,「合併後天數」是從各自把 Hoodi 排程併進主分支的時刻算到今天 23:05 UTC:
| 客戶端 | Hoodi 排程併入(UTC) | 合併後天數 | 合併到分叉 | 最新穩定版(是否含 Hoodi) |
|---|---|---|---|---|
| Lighthouse | 10/12 04:53:40 | 5.76 | 14.53 | v8.2.3(10/1,否);v8.3.0-rc.0 為預發布 |
| Grandine | 10/13 09:56:48 | 4.55 | 13.32 | 2.0.6(8/3,否);3.0.0-rc.0 為預發布 |
| Reth | 10/12 18:21:26 | 5.19 | 13.97 | v2.7.0(9/28,否) |
| Erigon | 10/13 15:41:10 | 4.31 | 13.08 | v3.7.1(10/2,否) |
| Geth | 無 | 不適用 | 不適用 | v1.17.8(10/8,否);hoodi.json 仍只到 bpo2 設定,沒有 amsterdamTime |
這五項我分別查了 PR 的合併時間(Lighthouse 第 10304 號、Grandine 第 980 號、Reth 第 27811 號、Erigon 第 24847 號),期限後 23 小時內沒有任何一個客戶端出新的穩定版,Nimbus 只有每日 nightly(10 月 17 日 05:35:12 UTC,預發布)。Geth 主分支近兩日的提交是 Go 版本升級、交易歷史、過濾器與 RPC 修正,開著的 PR 有 EIP-8297 二元樹相關工作,沒有任何 Hoodi 或 Amsterdam 排程;hoodi.json 的歷史只有 10 月 6 日的 chainspecs 搬移提交。
二、昨天的預測對帳與三個我昨天寫錯的地方
| 預測(昨天登記) | 結果 |
|---|---|
| Lighthouse v8.3.0 非預發布在期限前出現,約 5% | 未發生,成立(押不發) |
Geth hoodi.json 在期限前出現 amsterdamTime,約 5% | 未發生,成立 |
| 10/22 14:00 UTC 前 Lighthouse 穩定版含 Hoodi 約 80%;Geth 約 50%;缺席五個至少 3 個約 55% | 未到期 |
| 10/26 如期分叉約 90% | 未到期;Nethermind 2.2.0 與 EF 公告的時間昨天已核對一致,今天未重讀 |
| Alpenglow 10/21 啟用約 80% | 未到期;Anza 已把 Agave v4.3.2 列為建議版本(10/16) |
| 第 5734 號 PR 10/23 前合併約 35%、EIP 第 12513 號 PR 約 25% | 未到期,見第六節,我下調 |
| Gamdom 10/23 前公開儲備證明約 25% | 未到期;我查的幾篇報導都說尚未公布 |
兩個 5% 預測的 Brier 分數各是 0.05² = 0.0025,但單看這兩條沒有資訊量:押低機率的事沒發生,誰都會押中。真正的檢驗是下週的 10/22 那三條。
昨天有三處論述我今天認定是錯的。第一,Geth 發版節奏。我昨天用 v1.17.6 到 v1.17.7(7.4 天)與 v1.17.7 到 v1.17.8(8.2 天)兩個間隔推「大約每週一版」,並說約 10 月 16 日本該有下一版。我今天補查 v1.17.5(7 月 27 日 08:17:40 UTC)到 v1.17.6(9 月 23 日 02:21:47 UTC)的間隔是 57.75 天,所以那兩個間隔只是 Sepolia 分叉前後的趕工,不是週期;v1.17.8 到今天已 9.27 天,這個數字本身不構成異常。「Geth 該發版了」的論述作廢。
第二,Solana 的 slot 時間。我昨天用 0.4 秒算「epoch 432,000 個 slot 剛好 2 天」,並因此不採用報導的「5,000 個 slot 約 18 分鐘」。今天我直接讀公開 RPC 的效能取樣,實測 slot 時間約 0.2175 秒,五千個 slot 是 18.1 分鐘,報導的 17 到 18 分鐘成立;昨天那句「0.4 秒剛好 2 天」的前提是我憑記憶寫的舊數字,現在不成立。細節見第七節。
第三,Lighthouse 為何沒發。我昨天寫「我沒有查到說明」。今天在 Lighthouse 的議題清單裡找到第 10186 號,內容就是發布前測試與 Besu 的相容問題,見下一節。這只是候選解釋,不是團隊對「為什麼延後」的聲明。
三、Lighthouse 與 Besu:能力協商出錯怎麼讓一個版本卡住
第 10186 號議題(10 月 1 日建立,至今 open,5 則留言)的標題是「v8.3.0-rc.0:Besu 26.9.0 在 forkchoiceUpdated 與 getBlobs 的相容問題」。回報者的描述:Besu 26.9.0 回應 engine_exchangeCapabilities 時,是從自己的 RPC 方法列舉直接列出能力,沒有檢查該網路實際註冊了哪些方法;Lighthouse v8.3.0-rc.0 從列表裡挑兩個方法呼叫,於是呼叫到 Besu 會拒絕的方法。
| 網路 | Besu 宣稱支援的方法 | Besu 實際回應 |
|---|---|---|
| 主網、Hoodi | engine_forkchoiceUpdatedV4、engine_getBlobsV4 | -32604(方法未啟用) |
| Sepolia,Amsterdam 之前 | engine_getBlobsV4 | -38005(不支援的分叉) |
議題裡的關鍵設計細節:沒有 payload attributes 的 forkchoiceUpdated 分支,Lighthouse 會從宣告的版本中挑最高的(V5、V4、V3 的順序),而且這個分支沒有分叉檢查、出錯後也不會退到較低版本;v8.2.3 則是從 V3 開始。留言者指出兩種錯誤碼要分開處理:-38005 在分叉啟用後會自行消失,所以能力應該保留;-32604 則對那個 Besu 版本是永久的,所以「出錯就一律作廢能力快取」的做法是錯的。這是議題留言者的分析,留言者自述用了大型語言模型輔助打字,我沒有獨立重現。
時間線:Lighthouse 的維護者 10 月 6 日說 Besu 已在上游修好、傾向不改 Lighthouse;10 月 15 日 08:19 UTC 又說「Besu 因此完全無法運作,而且他們還沒發版,所以我認為 8.3 應該繞過這個問題」。Besu 26.10.0 在 10 月 16 日 10:53:52 UTC 發布,它的發布說明寫:「engine_exchangeCapabilities 宣告的每個方法現在都有註冊;沒有 Amsterdam 的網路上,Amsterdam 的 Engine 方法在有分叉檢查的地方回 -38005,而不是 -32604;engine_getBlobsV4 從 Osaka 起提供」(PR 11425 號)。
我讀得出的只有這些:Lighthouse 的 release-v8.3.0 分支 10 月 15 日 05:32:02 UTC 之後沒有新提交(已 62.6 小時);Besu 的修正在 10 月 16 日才進穩定版;但議題上沒有人說「用 Besu 26.10.0 測過可以」。更微妙的是,Besu 的新行為把 -32604 換成 -38005,而議題第一張表裡 -38005 本來就是 Sepolia 上的問題之一;Lighthouse 對 forkchoiceUpdatedV4 在 Amsterdam 之前被呼叫會不會仍然出錯,我從文件讀不出,要實測才知道。這是推論,不是結論。合理的下一個觀察點是:Lighthouse 是否在 unstable 合併繞過修正,或直接在議題上說用 Besu 26.10.0 驗過。
這件事的教學點在協議層:能力協商是「雙方信任對方的宣告」,宣告錯誤的後果不在宣告當下顯現,而在某個特定分叉狀態下呼叫時才顯現;而 Hoodi 是主網與測試網的最後一次彩排,所以兩個客戶端的版本組合(共識層 × 執行層)本身也是要測試的對象,不只是各自的版本。
四、Geth:Sepolia 的先例有多快
Geth 在 Sepolia 的紀錄可以當對照。Sepolia 排程的 PR(第 35734 號,標題「core, params: schedule amsterdam fork on sepolia」)2026 年 9 月 21 日 09:13:51 UTC 合併;v1.17.6 在 9 月 23 日 02:21:47 UTC 發布,發布說明寫明 Sepolia 在時間戳 1791294816(10 月 6 日 13:53:36 UTC)啟用 Amsterdam、營運者必須在那之前升級。換算:合併到發布 1.71 天,發布到分叉 13.48 天,合併到分叉 15.19 天。
Hoodi 這邊,Geth 到今天沒有合併,離分叉 8.78 天。如果 Geth 照 Sepolia 的速度(合併到發布 1.71 天)今天就合併,發布會落在約 10 月 19 日 16:00 UTC,距分叉 7.1 天,比 Sepolia 先例的 13.48 天少了將近一半的營運者升級時間;這是自算。EF 公告列的執行層版本裡沒有 Geth,我也沒有查到 Geth 團隊或任何人公開說明原因,所以沒有證據顯示 Geth 不打算合併,也沒有證據顯示它很快會合併。我把「Geth 到 10/22 14:00 UTC 前發出含 Hoodi 的穩定版」從 50% 下調到 40%,理由只是「合併尚未出現,而 Sepolia 先例中合併後還要 1.7 天」,而不是任何更具體的訊號。
五、缺席客戶端:加上刪失資料後的機率重算
昨天我寫模型 B 被否定,理由之一是樣本被期限截尾。今天用 Kaplan-Meier 做一次比較整齊的估計:事件資料是 Sepolia 的 10 個「合併到穩定版」延遲(1.71、2.48、4.44、15.41、7.09、10.44、5.82、10.86、6.56、6.65 天)加 Hoodi 已發版的 6 個(2.09、4.18、4.65、6.19、6.24、6.9956 天,其中除 Teku 外是用昨天的表反推,約 0.01 天誤差,Lodestar 的延遲我沒有可靠數字,排除);刪失資料是四個尚未發版、但已有合併時間的客戶端今天的年齡(4.31 到 5.76 天)。對每個缺席客戶端,算「已活過它目前的年齡」之後,在接下來的時間內發版的條件機率,即 1 − S(年齡 + h) ÷ S(年齡)。
| 客戶端 | 目前年齡(天) | 到 10/22 14:00(+4.62 天)的條件機率 | 到分叉(+8.78 天)的條件機率 | 只用 Sepolia 10 點(10/22) |
|---|---|---|---|---|
| Lighthouse | 5.76 | 0.70 | 0.90 | 0.57 |
| Grandine | 4.55 | 0.72 | 0.91 | 0.57 |
| Reth | 5.19 | 0.70 | 0.90 | 0.57 |
| Erigon | 4.31 | 0.74 | 0.91 | 0.63 |
結論先講限制:Hoodi 的 6 個資料點全部是在期限壓力下發出的,延遲被壓縮在 7 天以內,所以合併資料的 0.70 到 0.74 很可能偏高;只用 Sepolia(沒有這種期限壓力)是 0.57 到 0.63,比較保守,但 Sepolia 只有 10 點、且發生在不同的客戶端組合。我把兩者當區間,預測取 60% 到 70%。五個客戶端各自的機率代入獨立假設(Lighthouse 70%、Grandine 60%、Reth 60%、Erigon 60%、Geth 40%,和為 2.9),用 Poisson-binomial 算「至少 3 個」約 65%,「至少 4 個」約 30%,「0 個」約 1%;真實情況應有正相關(共用期限、共用 ACDE 第 248 次的壓力),所以尾端都會比獨立算法更厚,我把「至少 3 個」登記為 60%,比昨天的 55% 微幅調高。
兩點誠實聲明:KM 估計在這裡等於「把已發版的 16 筆和 4 筆刪失樣本合併重算」,四個客戶端的結果幾乎一樣,是因為這四個的年齡落在同一段;它並沒有針對 Lighthouse 的特殊問題(第三節)做調整。再者,16 個事件的 KM 曲線在尾端只剩幾個點,「到分叉 0.90」的上限靠的是 15.41 天那一個點恰好超出。
六、共識層 PR 與會議行事曆
consensus-specs 第 5734 號 PR(標題「Reject slashed proposers when drawn in Heze」)10 月 12 日 14:19:18 UTC 建立,標籤 testing、gloas、heze,1 個提交、0 則審查、1 則留言,狀態「落後主分支」,最後更新 10 月 13 日 22:49:25 UTC(今天已 4.0 天沒動靜)。EIP 第 12513 號 PR(EIP-8365:改成延後啟用而不是拒絕 0x00 存款)標籤含 s-draft,合併狀態為 blocked,沒有審查紀錄,最後更新 10 月 15 日 12:35:19 UTC(2.4 天前)。
我試著用歷史量一個基準:取 consensus-specs 最近 50 個已合併的 PR(7 月 7 日到 10 月 16 日),建立到合併的中位數 0.92 天、四分位 0.11 與 3.95 天,其中 9 個(18%)花了 6 天以上;而目前仍開著的 43 個 PR 中,33 個已超過 5.36 天(第 5734 號現在的年齡)、19 個超過 30 天。這個樣本只含「後來合併」的,漏掉從未合併的,所以不能直接算條件機率;但至少表示「已經 5 天沒審查」的 PR,通常不是下週就會合併的那一群。我把第 5734 號 10/23 前合併的機率從 35% 下調到 15%,第 12513 號從 25% 下調到 10%。後者的額外理由是:ACDC 第 189 次留言裡的提案本身(EIP-8365 配合 EIP-8433 的退出計畫)是 10 月 15 日才提出、要先得到方向共識;而下一次 ACDC(第 190 次)排在 10 月 29 日,在 Hoodi 分叉(10 月 26 日)之後,10 月 23 日前不會有它的會議決議。
行事曆:ACDT 第 101 次 10 月 19 日;ACDE 第 248 次 10 月 22 日 14:00 UTC,議程 Glamsterdam、Hegotá、雜項,目前只有 2 則留言,其中一則是 Nethermind 想把 EIP-8304(留言者描述為朝向可驗證 RPC 的一步)在 Hegotá 的排名升到 A;ACDC 第 190 次 10 月 29 日。10 月 22 日這場是下一個能聽到 Lighthouse、Geth 說明的地方。
七、Alpenglow:用公開 RPC 重算啟用時間
昨天我引用報導的 epoch 1064、約 10 月 21 日 15:00 UTC。今天的來源更細:SolanaCompass 引 Anza 的說法是「約 10 月 21 日 14:50 UTC」,並推算 epoch 1064 實際開始在約 14:55 到 15:10 UTC、移交約 17 到 18 分鐘後;報導的前提是目前 slot 時間約 200 毫秒。Agave v4.3.2 在 10 月 16 日被列為建議版本(修正含 Alpenglow 的交易緩衝、slot 計時、BLS 憑證驗證的選用執行緒池等);Firedancer 與 Frankendancer 在移轉期間不支援;Jito BAM 節點要進入維護模式;Rotor 仍無排程。
我直接向 Solana 公開 RPC(api.mainnet-beta.solana.com)讀了 10 月 17 日 23:04:22 UTC 的資料:epoch 1060、slotIndex 292,143、absoluteSlot 458,212,143(驗算:1060 × 432,000 = 457,920,000,加 292,143 等於 458,212,143,成立)。效能取樣 241 筆(每筆 60 秒,約 4 小時)共 66,499 個 slot、14,460 秒,平均每 slot 0.21745 秒;最近 60 筆是 16,542 個 slot,0.21763 秒。
- 到 epoch 1064 開始還需 (432,000 − 292,143) + 3 × 432,000 = 1,435,857 個 slot。
- 以 0.21745 秒計是 312,230 秒,86.73 小時,即 10 月 21 日約 13:48 UTC;以 0.21763 秒計是 13:52 UTC。
- 要對上 SolanaCompass 的 14:55 到 15:10,需要平均 slot 時間 0.2202 到 0.2209 秒,比我量到的高約 1.3%。
- 以 200 毫秒的名目值算是 79.77 小時,即 10 月 21 日約 06:50 UTC,與實測差 8.7%,所以「名目 200 毫秒」不能直接當時間表。
- 移交:5,000 × 0.21745 = 1,087 秒 = 18.1 分鐘,與報導一致;若是昨天我用的 0.4 秒則是 33.3 分鐘。epoch 長度實測是 432,000 × 0.21745 ÷ 3,600 = 26.1 小時,不是 2 天。
這個差異不是定論:我只量了 4 小時的取樣,且 slot 時間在未來 3.6 天內會隨網路負載飄動;官方時間可能是以其他來源(例如排程的 epoch 邊界公告)推出。預測我登記成區間:epoch 1064 的第一個 slot 時間落在 10 月 21 日 13:30 到 15:30 UTC 之間。移交後 Votor 接手的 slot 是 459,653,000(= 1064 × 432,000 + 5,000,與昨天的算式一致)。重點的實務結論:這 18 分鐘內區塊只含驗證者投票,使用者交易不會結算,所以不是「無感」升級;SOL 持有者不需要動作,但要避開那段時間的交易與清算。這些細節來自報導引述 Anza,我沒有讀官方 SIMD 或 Anza 公告原文。
八、Ledger 與 CryptoBilis:已知、未知與一個要小心的詐騙
承昨天的新聞篇。已知(Ledger 或多家報導一致):CryptoBilis 銷售的 Ledger 裝置內有未授權的硬體植入物,內含微控制器與 LTE eSIM,在使用者設定時辨識螢幕上的 24 字復原詞,解碼後經行動網路傳出;報導引述 Ledger 稱植入物沒有改動安全元件或作業系統,也沒有改交易與簽章;Ledger 建議未初始化的 CryptoBilis 裝置不要初始化,已使用者把資產轉到新裝置、用新產生的復原詞。損失:Bitquery 估計 10 月 9 日到 10 日間 315 個錢包、六條鏈共 9,320 萬美元,Ledger 沒有證實這個總額;Tether 凍結 1,000 萬美元 USDT。自算:9,320 萬 ÷ 315 = 29.6 萬美元(每個錢包平均);1,000 萬 ÷ 9,320 萬 = 10.7%(被凍結的比例,假設凍結的全部屬於這起)。平均值受少數大額錢包影響,沒有中位數,所以只能當量級。
未知:受影響裝置的總數、植入的是哪一批、Ledger 是否掌握 CryptoBilis 以外的通路。CoinDesk 與 The Block 的報導提到歐洲連鎖零售商 MediaMarkt Saturn 在德國發現一台疑似遭改動的裝置後停售,而 Ledger 同時說所有已確認案例都追溯到 CryptoBilis;兩者的關係我沒有讀到 Ledger 官方的說明。目前我查到沒有任何報導說已有逮捕或資金追回。
另一個延伸風險:SlowMist 10 月 16 日示警,有假冒 Ledger 韌體更新的釣魚頁面,有假的「正品檢查」介面、選裝置畫面與「立即更新」按鈕,目的是騙出 24 字復原詞。教學點:這種事件之後的第二波常是釣魚,而任何網頁、更新或客服要你輸入復原詞,都不是官方流程。
🧠 記
- 期限後第 23 小時: 穩定版仍是 7 個(共識層 4、執行層 3);缺席五個:Lighthouse、Grandine、Reth、Erigon 已合併排程(合併後 4.31 到 5.76 天)、Geth 未合併;距分叉 8.78 天。
- 昨天 5% 的兩條成立,但沒資訊量;三處我昨天寫錯:Geth 週期(前一個間隔 57.75 天)、Solana slot 時間(實測 0.2175 秒,不是 0.4)、Lighthouse 無說明(第 10186 號議題是候選原因)。
- Lighthouse–Besu: Besu 26.9.0 宣告了沒註冊的 Engine 方法(主網與 Hoodi 回
-32604、Sepolia 回-38005);Lighthouse 挑最高版本且不退回;Besu 26.10.0 的修正在 10/16 才發,是否解決要實測。 - Geth 先例: Sepolia 合併到發布 1.71 天、發布到分叉 13.48 天;Hoodi 目前未合併,距分叉 8.78 天。
- KM 重算: 缺席客戶端到 10/22 的條件機率 0.57 到 0.74(Sepolia-only 到合併資料);預測取 60% 到 70%。至少 3 個約 65%(獨立算法)、登記 60%。
- 共識層 PR: 第 5734 號 4.0 天無動靜、第 12513 號 blocked;近 50 個已合併 PR 中位 0.92 天、18% 花 6 天以上;ACDC 第 190 次 10/29 在分叉之後。
- Alpenglow: 實測 slot 0.2175 秒;epoch 長度 26.1 小時;epoch 1064 估計 10/21 約 13:48 到 13:52 UTC(官方約 14:55 到 15:10);移交 18.1 分鐘、期間無使用者交易。
- Ledger: 9,320 萬美元是 Bitquery 估計、Ledger 未證實;每錢包平均 29.6 萬美元;Tether 凍結約 10.7%;假更新釣魚在擴散。
邊界: GitHub 與 Solana RPC 資料是 10 月 17 日 23:00 到 23:05 UTC 的讀取結果。KM 估計樣本只有 16 個事件加 4 個刪失、且 Hoodi 部分被期限壓縮。Besu 26.10.0 與 Lighthouse 的相容性是我從文件讀不出,沒有實測。Alpenglow 的 slot 時間是 4 小時取樣,不是 3.6 天的預報。Ledger 與損失數字來自二手報導,未讀 Ledger 原文公告。這些內容是技術研究,不構成任何投資、質押、購買或節點營運建議。
✍️ 實踐
全部唯讀,約 25 分鐘。
- 重查五個缺席客戶端的最新發布與 Geth 設定(約 6 分鐘):
for r in sigp/lighthouse grandinetech/grandine paradigmxyz/reth erigontech/erigon ethereum/go-ethereum; do
echo "== $r"; gh api "repos/$r/releases?per_page=2" --jq '.[]|"\(.tag_name) \(.published_at) pre=\(.prerelease)"'
done
gh api repos/ethereum/go-ethereum/contents/params/chainspecs/hoodi.json --jq .content | base64 -d | grep -n -i amsterdam- 自己量 Solana 的 slot 時間並預報 epoch 1064(約 8 分鐘):
curl -s https://api.mainnet-beta.solana.com -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getEpochInfo"}'
curl -s https://api.mainnet-beta.solana.com -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getRecentPerformanceSamples","params":[60]}'用 sum(samplePeriodSecs) / sum(numSlots) 得到每 slot 秒數,再算 (432000 - slotIndex) + 3 * 432000 個 slot 還要多久,與官方公布的時間相比差多少。
-
讀第 10186 號議題全文與 Besu 26.10.0 發布說明的 PR 11425 號(約 6 分鐘),自己畫一張表:Besu 在哪個網路、哪個方法會回哪個錯誤碼,Lighthouse 收到後會做什麼。
-
算 KM(約 5 分鐘):用第三節給的 16 個延遲加 4 個刪失年齡,自己建立生存曲線,再把 Hoodi 的 6 個點拿掉重算,看結論變多少。
-
想一想:如果 Lighthouse 在分叉前 3 天才發 v8.3.0,營運者需要什麼條件才能在剩下的時間完成共識層與執行層的配對升級?你會用什麼指標判斷「來得及」?
可證偽預測(新登記與調整;時間點都是 UTC):
- 預測一(10 月 22 日 14:00,ACDE 第 248 次開始前): Lighthouse 含 Hoodi 的穩定版 70%(昨天 80%);Geth 含 Hoodi 的穩定版 40%(昨天 50%);Geth 主分支
hoodi.json出現amsterdamTime: 179303656855%;Grandine、Reth、Erigon 各自出含 Hoodi 的穩定版 60%;缺席五個中至少 3 個 60%。 - 預測二(10 月 22 日 23:59): Lighthouse 第 10186 號議題關閉,或有繞過 Besu 能力宣告問題的 PR 合併 55%。
- 預測三(10 月 26 日 17:42:48): Hoodi 分叉如期在 epoch 132352 啟用 90%;分叉後 10 個 epoch(約 64 分鐘)內最終確認(finalize)出現 80%,依據是 Sepolia 在分叉後 7 個 epoch 才見到終局(報導的說法,我沒查到原始資料)。
- 預測四(10 月 21 日 23:59): epoch 1064 的第一個 slot 時間落在 13:30 到 15:30 之間 90%;Votor 在 slot 459,653,000 接手、使用者交易恢復,且與 epoch 開始相差 15 到 25 分鐘 80%;之後 24 小時內沒有超過 1 小時的出塊停擺 80%(沿用)。
- 預測五(10 月 23 日 23:59): consensus-specs 第 5734 號 PR 合併 15%(昨天 35%);EIP 第 12513 號 PR 合併 10%(昨天 25%)。
- 預測六(10 月 24 日 23:59): Ledger 官方公告受影響裝置數或確認損失總額其中之一 25%;Ledger 官方點名 CryptoBilis 以外的通路有遭改動裝置 20%;有公開報導的逮捕或起訴 10%。
- 預測七(10 月 23 日 23:59): Gamdom 公開儲備證明或儲備地址 25%(沿用)。
- 沿用: 10 月 22 日 14:00 前官方明列主網日期 45%(若有,12 月 8 日約 70%)。
明天接的待辦:Geth 是否合併 Hoodi 排程、Lighthouse 是否有發布分支以外的動作、Alpenglow 啟用前 72 小時的 slot 時間重量、ACDT 第 101 次的資訊、Ledger 事件的官方更新。
🔗 延伸學習
- sigp/lighthouse 第 10186 號議題:Besu 26.9.0 的 forkchoiceUpdated 與 getBlobs 相容問題(GitHub) — 第三節 Lighthouse 與 Besu 的錯誤碼表、維護者留言與時間線。
- ethereum/go-ethereum 第 35734 號 PR:在 Sepolia 排程 Amsterdam(GitHub) — 第四節 Geth 在 Sepolia 的合併時間,對照 Hoodi 目前沒有的那個 PR。
- ethereum/pm 第 2267 號議題:ACDE 第 248 次議程(GitHub) — 10 月 22 日 14:00 UTC 的會議議程與留言。
- Anza Sets Alpenglow Mainnet Date(SolanaCompass) — 第七節的 14:50 UTC、5,000 個 slot、200 毫秒前提、客戶端要求與 Jito BAM。
- Agave v4.3.2: Anza Tells Solana Validators to Upgrade Now(SolanaCompass) — 建議版本與驗證者檢查表。
- Ledger finds covert cellular implant(CoinDesk,10 月 13 日) — 第八節的植入物運作方式、Ledger 的建議與損失口徑。
- Fake Ledger Firmware Update Scam(Crypto Times) — SlowMist 的釣魚示警與事件時間線。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度,並同時追蹤 Solana 的 Alpenglow 啟用(查證時間 2026-10-17 23:00 到 23:05 UTC,資料來自 GitHub API 與 Solana 公開 RPC)。以下是我整理的主張與模型,請協助查證並嚴格區分來源:
1. 事實:Hoodi 分叉排在 2026-10-26 17:42:48 UTC(epoch 132352);發布期限 10/16 23:59:59 UTC 後 23 小時,含 Hoodi 時間戳的穩定版仍是 7 個(共識層 Lodestar、Teku、Nimbus、Prysm;執行層 Besu、Nethermind、Ethrex);缺席 Lighthouse、Grandine、Reth、Erigon(已合併排程)與 Geth(未合併、hoodi.json 無 amsterdamTime)。
2. Lighthouse 第 10186 號議題:Besu 26.9.0 的 engine_exchangeCapabilities 宣告了未註冊的 Engine 方法(主網與 Hoodi 回 -32604、Sepolia 回 -38005),Lighthouse v8.3.0-rc.0 挑最高版本(V5、V4、V3)且出錯不退回。Besu 26.10.0(10/16)聲稱已讓宣告的方法全部註冊,並在有分叉檢查處回 -38005。
3. Geth 在 Sepolia:排程 PR 9/21 09:13:51 UTC 合併,v1.17.6 於 9/23 02:21:47 UTC 發布,Sepolia 分叉 10/6 13:53:36 UTC;前一個發布間隔是 57.75 天。
4. Kaplan-Meier:事件為 Sepolia 10 個合併到穩定版延遲(1.71、2.48、4.44、15.41、7.09、10.44、5.82、10.86、6.56、6.65 天)加 Hoodi 6 個(2.09、4.18、4.65、6.19、6.24、6.9956 天),刪失為四個缺席客戶端目前年齡(4.31 到 5.76 天)。
5. Solana:epoch 1060、slotIndex 292143、absoluteSlot 458212143;60 秒取樣平均每 slot 約 0.2175 秒;到 epoch 1064 還需 1,435,857 個 slot;官方說約 10/21 14:50 UTC,我估約 13:48 到 13:52 UTC。
6. Ledger:Bitquery 估計 9,320 萬美元、315 個錢包、六條鏈,Ledger 未證實;Tether 凍結 1,000 萬美元 USDT。
請幫我:
(a) 說明能力協商(capability negotiation)宣告錯誤為何只在特定分叉狀態下才出問題,以及客戶端應如何區分 -32604(永久)與 -38005(分叉啟用後消失)來設計退回邏輯,並檢查我「Besu 26.10.0 可能仍讓 Lighthouse 出錯」的推論是否成立;
(b) 檢查我的 KM 估計:把 Hoodi 在期限壓力下的 6 個點與 Sepolia 合併是否違反同分布假設,並建議更好的處理方式(例如把期限當時變共變數、分開估計、區間報告);
(c) 驗算 Solana 的 slot 算術(1,435,857 個 slot、0.2175 秒、5,000 個 slot 的時間、epoch 長度),並解釋我估的 13:48 UTC 與官方 14:50 到 15:10 UTC 的 1 小時差距可能來自哪裡(取樣窗口、slot 時間飄動、epoch 邊界公告的來源);
(d) 說明硬體錢包供應鏈攻擊(植入物在設定時讀取復原詞)的威脅模型,以及用戶在拿到裝置時能做的自行檢查與其限制(例如只用自己產生的復原詞、不使用預先寫好的復原詞),並指出哪些部分是 Ledger 已證實、哪些只是第三方估計;
(e) 分三類標示每個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押、購買或節點營運建議。