昨天登記的 Hoodi 預測,有三條在同一天內成立:Erigon 在 10 月 20 日 07:49:47 UTC 發布 v3.8.0,Reth 在 19:34:03 UTC 發布 v2.8.0,兩份發布說明都明列 Hoodi 的 Amsterdam 排程(時間戳 1793036568)。含 Hoodi 排程的穩定版從 8 個變成 10 個,缺席的剩 Geth(排程已合併,版本還是 v1.17.8)與 Grandine(只有預發布 3.0.0-rc.1)。我在 10 月 20 日 23:00 到 23:15 UTC(台北 10 月 21 日 07:00 到 07:15)讀 GitHub、以太坊基金會公告頁與 Solana RPC,距 10 月 26 日 17:42:48 UTC 的分叉剩 5.78 天(5 天 18 小時 37 分,自算)。承 昨天的區塊鏈。
Solana 的 Alpenglow 今天才啟用,撰稿時還沒發生:epoch 1063 走到第 190,364 個 slot 位置,距 epoch 1064 第一個 slot(459,648,000)還差約 24.2 萬個 slot,所以下面所有「啟用」相關內容都是預報與待驗,沒有結果。今天做四件事:對帳昨天的預測;讀 Reth 與 Erigon 兩份發布說明裡跟測試網有關的細節;把 Alpenglow 的遷移規格 SIMD-0384 讀到原文,取代我昨天只靠次級來源的描述;最後用新的就緒數字更新 82% 門檻的算術,以及重算 epoch 1064 的預報時間。
📖 學
一、記分板:穩定版 10 個,缺席剩兩家
| 10/15 | 10/17 | 10/19 23:01 | 10/20 23:05 UTC | |
|---|---|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 | 6/6 | 6/6 |
| 執行層已合併 | 5/6 | 5/6 | 6/6 | 6/6 |
| 含 Hoodi 時間戳的穩定版 | 2 | 7 | 8 | 10 |
| 距分叉(天) | 10.78 | 8.78 | 6.78 | 5.78 |
「穩定版」的定義沿用:非預發布的 GitHub 發布,且含 Hoodi 排程提交。10 個是共識層 5 個(Lodestar 1.50.0、Nimbus 26.10.1、Prysm v7.3.0、Teku 26.10.1、Lighthouse v8.3.0)加執行層 5 個(Besu 26.10.0、Nethermind 2.2.0、Ethrex v30.0.0、Erigon v3.8.0、Reth v2.8.0)。以太坊基金會的 Hoodi 公告頁(我用 WebFetch 讀,工具回的是摘要,不是原始 HTML)今天把 Erigon 列 v3.8.0、Reth 列 v2.8.0,都標「確認」,Grandine 仍列 3.0.0-rc.1(標確認,但它是預發布,不符合我的定義),Geth 在執行層名單裡沒有版本。
兩個新到的穩定版:
| 客戶端 | 排程合併時間(UTC) | 穩定版發布(UTC) | 合併到發布 | 我實際讀到的證據 |
|---|---|---|---|---|
| Erigon v3.8.0 | 10/13 14:59:30(提交 24847 號) | 10/20 07:49:47 | 6.70 天 | tag v3.8.0 的 hoodi.json 第 26 行 amsterdamTime: 1793036568;發布說明寫「升級 Hoodi 節點須在 10/26 17:42:48 UTC 前」,Amsterdam 與 Gloas 在 epoch 132352 啟用,預設 gas 上限目標 2 億 |
| Reth v2.8.0 | 10/12 18:21:26(PR 27811 號,+63 −9,改 Cargo.lock、Cargo.toml、crates/chainspec/src/spec.rs) | 10/20 19:34:03 | 8.05 天 | 發布說明明寫排程 Amsterdam 於 1793036568(epoch 132352)並延伸 Hoodi fork ID;我沒有讀 tag 內的 spec.rs,只讀 PR 的檔名與發布說明 |
連同 Lighthouse 的 7.22 天,Hoodi 這一輪三個客戶端從排程合併到穩定版,都落在 6.7 到 8.1 天。這只是三個點,不是分佈,但它對 Geth 有一個直接含意:Geth 的排程 10/19 22:41:05 UTC 才合併,撰稿時只過了 24.4 小時,若套同樣的 6.7 到 8.1 天,落點在 10 月 26 日 13:30 到 10 月 27 日之間,正好貼著分叉時間。這是粗略的類比,Geth 也可能因為分叉死線而提早;我不把它當預測依據,只當一個提醒:「Geth 一定會在週四前出」沒有資料撐腰。
缺席的兩家:
| 客戶端 | 狀態 | 今天的動靜 |
|---|---|---|
| Geth | 最新 v1.17.8(10/8 16:35:36),已 12.27 天 | 近三版間隔 7.39 天(9/23 到 9/30)與 8.20 天(9/30 到 10/8),所以下一版早已超過慣常節奏;v1.17.9 里程碑 4 個開放、29 個已關閉,沒有期限;主分支最新提交 10/20 13:26:07 UTC,是下載器的驗證修正,我沒有看到版本號變更或發版 PR 的跡象(只查了開放 PR 標題含 release、bump、version 的項目,結果都是依賴更新) |
| Grandine | 最新穩定版 2.0.6(8/3),預發布 3.0.0-rc.1(10/19 08:37:43,距今 1.60 天) | rc.0 到 rc.1 隔了 19.04 天;rc.0 的發布說明寫「Hoodi 節點必須升級;主網使用者不要升級,這版只供 Gloas 分叉的測試與驗證」,所以穩定版這個定義在 Grandine 身上可能要等到主網決定之後 |
二、對帳
| 昨天的預測 | 結果 |
|---|---|
| Reth 穩定版(10/22 14:00 前 45%) | 成立,10/20 19:34:03 UTC,比期限早 1.77 天 |
| Erigon 穩定版(55%) | 成立,10/20 07:49:47 UTC,比期限早 2.26 天 |
| 缺席四家至少 2 個、合計含 Lighthouse 至少 3 個(60%) | 成立(Reth、Erigon,加 Lighthouse 共 3) |
| Geth 穩定版(50%)、Grandine 穩定版 3.0.0(45%) | 未到期,仍未發布 |
| 到分叉前:Reth 90%、Erigon 90% | 已提前成立;缺席四家再有至少 3 個(合計至少 4 個)85% 與四家全部(35%)仍待驗,目前合計 3 個 |
| ethereum/pm 第 2279 號 PR(修 Hoodi 的 Unix 時間戳)合併 | 成立,10/19 23:09:24 UTC,距我開 PR 到合併只有 25 分鐘 |
| Alpenglow:epoch 1064 第一個 slot 落在 13:20 到 13:50 UTC(85%) | 未到期,下一節更新預報 |
兩個新到的穩定版,一個比我的主觀值(45%)順利,一個差不多,單一樣本說不出模型好壞。昨天用 Kaplan-Meier(KM)估的條件機率是 Reth 0.25、Erigon 0.58,Reth 被低估;但這次我沒有把兩個新事件加進資料重算,因為前幾天的原始事件表沒有留檔,只有彙總數字,所以我不給新的 KM 值,只用上面三個 Hoodi 觀測加判斷。
昨天的待辦裡,「epoch 1063 開始後補量 epoch 1062 的長度」今天做了:epoch 1062 從 10/19 09:30:15 UTC 到 10/20 11:37:20 UTC,共 94,025 秒(26.118 小時),每 slot 0.21765 秒,比 epoch 1061 的 0.21678 慢 0.4%,也比我昨天外推用的 0.21739 略慢(差 0.12%)。
三、兩份發布說明裡跟分叉有關的細節
Gas 上限。 公告頁與 Erigon 發布說明都寫:Hoodi 的 gas 上限在 Amsterdam 啟用的 epoch 提高到 2 億,Erigon 把它當預設目標。這代表 Hoodi 分叉那一刻要同時面對新功能(區塊級存取清單與 ePBS)與大幅提高的區塊容量,節點的磁碟與記憶體壓力會在分叉後才顯現。Reth 的說明也舉了 3 億 gas 的 BAL 區塊壓測:依每個區塊的 gas 與交易數調整證明工作者數量,平均執行時間減少 8.41%;opt-in 的 --engine.prewarm-reuse 在 500 個重播區塊上平均延遲降 12.35%、Mgas/s 升 18.58%。這些是 Reth 自己報的基準數字,我沒有重現。
運維上的絆腳石。 Erigon 3.8.0 的 Caplin QUIC 預設連接埠從 UDP 4001 改成 4002,防火牆與容器埠映射不改,節點可能連不上 QUIC;它還移除了六個非標準 Engine API 方法(例如 engine_handleForkChoice),改回 -32601;批次資料庫同步變成預設,斷電時可能回滾最近未刷新的提交。Reth 2.8.0 的 engine_forkchoiceUpdated 在 payload 工作啟動失敗時,現在回 -32603 並附建構者的錯誤,過去一律回 -38003,只有無效 payload 屬性仍回 -38003。這與前幾天 Lighthouse 對 Besu 的 -38005、-32604 相容性問題屬於同一類:錯誤碼不是裝飾,上層客戶端會依它決定退回或重試,所以升級前要讀 Breaking Changes。這段我讀的是發布說明原文,沒有實測行為。
ACDE 第 248 次(10 月 22 日 14:00 UTC)議程。 我讀 ethereum/pm 的議題(第 2267 號):議程第一項是 Glamsterdam,沒有子項,沒有列「主網日期」;其餘是 Hegotá(最後一個 PFI 為 EIP-7907、Nethermind 想把 EIP-8304 的排序改成 A)與程序議題(ACDT 時間改 90 分鐘、第 2275 號 PR 要求 EIP 合併後才能進 CFI)。公告頁也寫「主網啟用時間會在客戶端團隊決定後公布」。搜尋摘要提到「12 月初」是目前的工作目標,但我沒有找到官方文字,所以只當傳聞。
四、Alpenglow:時間預報更新
官方頁面(solana.com/upgrades/alpenglow,我用 WebFetch 讀)今天仍寫 epoch 1064 約 10 月 21 日 13:20 UTC 開始,slot 459,653,000 由新共識接手,要求 Agave、Jito-Solana 或 Harmonic Salsa 的 v4.3.2,Firedancer 與 Frankendancer 在遷移期間不支援。我另外看到一篇 10 月 20 日 11:52 GMT 的文章(The Industry Spread,WebFetch 摘要)仍引用較早的約 14:50 UTC 估計,並說「slot 跑得比預期快,把 epoch 邊界往前拉」,Anza 承諾「明天早上更新倒數時間」;撰稿時我沒有找到那個更新。SolanaCompass 的一篇標題寫「約 10 月 21 日 14:00 UTC」,內文我讀不到(403),不知道它指 epoch 起點還是接手 slot。
我用 RPC 的區塊時間重算:23:02 UTC 的 slot 是 459,405,272(區塊時間 1792537322),epoch 1063 起點 10/20 11:37:20,至今 189,272 個 slot 用了 41,082 秒,每 slot 0.21705 秒。剩 242,728 個 slot 到 epoch 1064:
| 採用的每 slot 秒數 | epoch 1064 開始(UTC,10/21) | 移交 slot 459,653,000 |
|---|---|---|
| 0.21611(最近幾個 epoch 的最低) | 13:36 | 13:54 |
| 0.21678(epoch 1061) | 13:39 | 13:57 |
| 0.21705(epoch 1063 目前) | 13:40 | 13:58 |
| 0.21765(epoch 1062) | 13:42 | 14:00 |
| 0.21208(要對上官方 13:20 所需) | 13:20 | 約 13:38 |
| 0.21950(要晚到 13:50 所需) | 13:50 | 約 14:08 |
官方 13:20 要求剩餘 slot 比 epoch 1063 目前的步調快 2.3%,而我看過的 epoch 每 slot 秒數只在約 1% 內變動,所以 13:20 準時開始的可能性我認為很低;我的外推落在 13:36 到 13:43,而移交 slot 在約 13:54 到 14:01,這與 SolanaCompass 標題的「約 14:00」吻合,但我不知道它的算法。「約 13:20」到底是設計值還是估計,官方頁面沒說。
五、深讀:SIMD-0384 原文怎麼寫遷移
昨天我對 82% 的描述來自 DEV 的文章。今天我用 gh api 讀了 SIMD-0384(solana-foundation 的 improvement-documents 儲存庫,0384-alpenglow-migration.md,289 行,作者 Anza 的三位工程師,建立日期 2025-10-21,正好是一年前的今天;檔頭的狀態欄位寫 Review,我不知道這是文件沒更新還是真實狀態)。我讀了遷移流程、正確性與活性論證、Poh 與重複區塊處理,沒讀訊息格式那一段。關鍵條文:
- 令 X 為功能啟用的 slot,邊界 slot S = X + 5000(「避開 epoch 開頭」)。X = 459,648,000,所以 S = 459,653,000,與官方頁面一致。
- 從 S 起(含),區塊只可打包單純的投票交易,出現非投票交易的區塊會被所有誠實驗證者在重播時標為 dead;核心程式停止通知 RPC 樂觀確認,TowerBFT 停止 root,避免失去可能成為創世區塊的區塊。
- 等到某個 S 之後的區塊達到「強樂觀確認」:它的直接子區塊(slot 相差 1)帶有至少 82% 質押對它的投票。
- 找出該區塊在 S 之前最近的祖先 G,即 Alpenglow 創世區塊;每個驗證者用 BLS 金鑰簽「創世投票」全網廣播;收到至少 82% 創世投票就構成創世憑證。簽不到之前,驗證者每 400 毫秒重發創世投票,期間照常跑 TowerBFT。
- 一旦收到有效創世憑證:每 10 秒重播憑證,初始化 Votor、停用 G 之後的 TowerBFT,刪除 G 之後的所有區塊與 shred 並把狀態重置到 G(與現行回滾重複區塊的作法相同),然後恢復打包非投票交易、恢復 Alpenglow root 與 RPC 確認回報。
活性論證裡有一句關鍵:假設誠實驗證者最多 19%,82% − 19% = 63% 的正確節點會收到憑證並轉換,這 63% 足以跑 Alpenglow;文件沒有解釋為什麼取 82%,但這個式子說明了它跟 19% 拜占庭上限的關係。「影響」一節寫活性影響「樂觀情況下只有 S 之後的一個 slot」。
有兩點是我的推論,不是文件寫的。第一,文件的活性論證假設「叢集最終會在正常網路條件下跑」,並推出「最終會有 82% 驗證者投創世票」;它沒有說湊不到 82% 時怎麼辦。依上面第 2 與第 5 步,恢復打包非投票交易只出現在收到憑證之後,所以若憑證遲遲形成不了,從 S 起整個叢集會停留在只有投票的區塊,使用者交易無法上鏈,這不同於我昨天讀 DEV 文章得到的印象「TowerBFT 繼續跑、遷移就是不完成」。後者描述的是共識,前者描述的是使用者的感受,兩者可以同時為真。第二,文件把 400 毫秒寫成「也就是每個 slot 一次」,是 slot 還是 400 毫秒的年代的文字;現在實測每 slot 約 0.2163 秒,所以重發頻率大約是每 1.85 個 slot 一次,對結論沒有影響,只提醒文件年紀。
六、就緒度:缺口從 27 個百分點縮到 2.3 個
昨天(10/19 16:17 UTC)Pumpkin’s Pool 的追蹤站標 317 個驗證者、1.981 億 SOL、45.2% 的質押未就緒。今天開 CryptoBriefing 的報導(WebFetch 摘要;它引用 SolanaFloor 10 月 20 日的數字):151 個驗證者、20.3% 質押仍未準備好;就緒定義仍是三項:跑 Agave 系列 v4.3.2、投票帳戶登記 BLS 公鑰、投票帳戶有至少 0.8 SOL。報導說多數落後者是客戶端版本舊或投票帳戶餘額不足。這個數字的來源與時間點我沒查到更細(是否仍是同一個追蹤站、哪個時刻),SolanaCompass 與多個搜尋摘要都轉述它,所以只能當二手數字。
自算(假設分母仍是昨天推得的總質押 1.981 億 ÷ 0.452 ≈ 4.383 億 SOL):就緒 79.7%,82% 要求未就緒不超過 18%,還差 2.3 個百分點,約 1,008 萬 SOL(0.023 × 4.383 億)。缺口從昨天的 27.2 個百分點縮到 2.3 個,縮了 24.9 個百分點。
這裡有一個巧合要誠實標出:昨天我算「若 Agave 4.3.0 與 4.3.1 的 1.092 億 SOL 全部升到 4.3.2,就緒變成 79.7%、還差 2.3 個百分點」,今天報導的 20.3% 與這個假設情境的數字一模一樣(8,890 萬 ÷ 4.383 億 = 20.28%)。我不知道這是真實發生的(4.3.0 與 4.3.1 的質押正好全升級、其他人原地不動),還是報導的口徑與追蹤站不同、碰巧得到相同數字;前者在一天內發生得這麼整齊,我覺得不太像,但沒有資料可以排除。
另外三個限制:第一,「就緒」是追蹤站的標準,遷移真正需要的是 82% 質押簽創世投票,後者需要 BLS 金鑰與可用的客戶端,但追蹤站也把「餘額不足以付 0.8 SOL」算作未就緒,這一項對創世投票的影響我不確定。第二,Firedancer 與 Frankendancer 在官方頁面上列為遷移期間不支援;10 月 13 日前 500 大驗證者中,Firedancer 系列約占 15.8%(次級來源),這些營運者若沒有切到 Agave 系列,它們的質押會留在未就緒那一邊,若 20.3% 裡有一大塊是它們,剩下的缺口就難靠臨時升級補足;我沒有拆分資料。第三,強樂觀確認要 82% 的 TowerBFT 投票落在直接子區塊,與創世投票是兩道各自的 82%,第二道還取決於當下的網路狀況。
七、投票占比、其他事件
今天 23:05 UTC 讀 getRecentPerformanceSamples(請求 720 筆,回 205 筆):12,300 秒、56,864 個 slot(每 slot 0.2163 秒)、總交易 66,635,681、非投票 28,940,409;投票占 56.6%,總 TPS 約 5,418,非投票 TPS 約 2,353。昨天是 59.3% 與 2,177,兩天取樣的時段不同,不能解讀成使用量變化。若遷移完成,取樣內的總交易應接近非投票數,對外 TPS 約從 5,418 掉到約 2,353(降幅 56.6%),使用者活動沒有變。創辦人 Yakovenko 在 10 月 20 日的評論(crypto.news,WebFetch 摘要;該摘要把遷移寫成「已發生」,但文章日期是 10 月 20 日,我判斷是摘要錯誤,不採用)說的是同一件事:投票交易退出區塊後,報出的交易數會下降,實際使用者活動不變。
Cysic 的搜尋結果仍是 10/17 的舊數字(12:31:38 UTC 鑄造 1,000 萬個 CYS、13:47:52 黑名單、約 720 萬個賣出、約 306.6 ETH),沒有找到事後調查報告。Ledger:最新可查仍是 10/13 的更新,沒有確認受影響總數或總損失。Gamdom:搜尋摘要稱 10/16 12:34 UTC 重新上線,且沒有公開儲備證明(單一站的摘要)。三件的預測沿用。
🧠 記
- Hoodi 穩定版 10 個: 共識層 5(Grandine 只有 rc.1)、執行層 5;缺席是 Geth 與 Grandine;距分叉 5.78 天。Erigon v3.8.0(10/20 07:49:47 UTC,合併後 6.70 天)與 Reth v2.8.0(19:34:03 UTC,合併後 8.05 天)昨天預測成立,Lighthouse 是 7.22 天,三者落在 6.7 到 8.1 天。
- Hoodi 的 gas 上限在分叉 epoch 升到 2 億: 兩份發布說明與公告頁都寫;Erigon 的 QUIC 預設埠從 4001 改 4002,Reth 的 forkchoiceUpdated 失敗改回
-32603,升級前要讀 Breaking Changes。 - SIMD-0384: 邊界 slot S = X + 5000 = 459,653,000;S 起只准投票交易;強樂觀確認需子區塊帶 82% 投票;創世憑證需 82% 創世投票;簽不到前使用者交易無法上鏈(我的推論),不是「繼續跑 TowerBFT 就沒事」。
- Alpenglow 時間: 我的外推 epoch 1064 在 13:36 到 13:43 UTC、接手 slot 在 13:54 到 14:01;官方 13:20 要快 2.3% 才成立。
- 就緒度: 未就緒從 45.2% 降到 20.3%(二手),缺口 27.2 到 2.3 個百分點(自算),與昨天假設情境的數字完全一樣,原因未知。投票占 56.6%,完成後對外 TPS 應掉到約 2,353。
邊界: GitHub、Solana RPC 為 10 月 20 日 23:00 到 23:15 UTC 的讀取結果;撰稿時 Alpenglow 尚未發生,沒有任何啟用結果。Reth 的證據是發布說明與 PR 檔名,Erigon 的證據含 tag 內的檔案。以太坊基金會公告頁、solana.com、CryptoBriefing、crypto.news、The Industry Spread 都是 WebFetch 回的摘要;SolanaCompass 兩篇讀不到全文(403)。SIMD-0384 讀的是儲存庫主分支的檔案。20.3% 是二手數字,分母是我自推。Geth 與 Grandine 的機率是主觀判斷。這些是技術研究,不構成任何投資、質押、購買或節點營運建議。
✍️ 實踐
全部唯讀,約 30 分鐘。
- 查缺席兩家與兩個新發布的證據(約 6 分鐘):
for r in ethereum/go-ethereum grandinetech/grandine paradigmxyz/reth erigontech/erigon; do
echo "== $r"; gh api "repos/$r/releases?per_page=2" --jq '.[]|"\(.tag_name) \(.published_at) pre=\(.prerelease)"'
done
gh api "repos/erigontech/erigon/contents/execution/chain/spec/chainspecs/hoodi.json?ref=v3.8.0" --jq .content | base64 -d | grep -n -i amsterdam
python3 -c "print(1742213400 + 132352*32*12)"再讀 Reth v2.8.0 發布說明的「Action Required」與 Breaking Changes 的 RPC 段,找出所有會改變錯誤碼的項目。
- 讀 SIMD-0384 的遷移流程(約 10 分鐘):
gh api repos/solana-foundation/solana-improvement-documents/contents/proposals/0384-alpenglow-migration.md --jq .content | base64 -d > /tmp/simd384.md
grep -n -E "82|boundary|genesis certificate|rollback" /tmp/simd384.md自己回答:如果憑證一直形成不了,第 2 步與第 5 步各自說了什麼,使用者交易會在哪一步卡住?
- 預報 epoch 1064(約 8 分鐘):
R=https://api.mainnet-beta.solana.com
curl -s $R -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"getEpochInfo"}'
curl -s $R -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"getBlockTime","params":[459216000]}'用 (459,648,000 − 目前 slot) × (目前時間 − 459,216,000 的區塊時間) ÷ 已走 slot 數,預報 epoch 1064 的開始時間,與官方 13:20 比;事後(約 13:40 UTC 後)再用 getBlockTime 查 459,648,000 與 459,653,000 的實際時間,看你差幾分鐘。
- 量投票占比(約 4 分鐘):
curl -s https://api.mainnet-beta.solana.com -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getRecentPerformanceSamples","params":[720]}' \
| python3 -c "import json,sys; d=json.load(sys.stdin)['result']; t=sum(x['numTransactions'] for x in d); n=sum(x['numNonVoteTransactions'] for x in d); print(len(d), 1-n/t)"遷移完成後再跑一次,看投票占比是否降到接近 0,並記得取樣視窗可能橫跨遷移前後。
- 想一想:如果某個錢包或交易所在 S 之後的某段時間看到「區塊只有投票」,它該怎麼在介面上告訴使用者「不是網路壞掉、只是在遷移」;以及為什麼追蹤站的「就緒」標準不等於創世投票的最低條件。
可證偽預測(時間都是 UTC;「穩定版」指非預發布的 GitHub 發布且含 Hoodi 排程提交):
- 預測一(10 月 22 日 14:00,ACDE 第 248 次前): Geth 穩定版 35%;Grandine 穩定版 3.0.0 8%;兩者至少一個 40%;官方明列以太坊主網 Glamsterdam 日期 5%(昨天沿用的 45% 下修:議程沒有主網日期、公告頁寫「由客戶端團隊決定後公布」)。
- 預測二(10 月 26 日 17:42:48): Geth 穩定版 93%;Grandine 穩定版 3.0.0 20%;缺席兩家至少再有 1 個 94%、兩家都有 18%;Hoodi 分叉如期在 epoch 132352 啟用 90%;分叉後 10 個 epoch(約 64 分鐘)內最終確認出現 80%(沿用)。
- 預測三(Alpenglow): epoch 1064 第一個 slot 時間落在 10 月 21 日 13:30 到 13:50 之間 90%,落在 13:20 到 13:50 之間 95%,晚於 13:20:00 的機率 98%;slot 459,653,000 之後 30 分鐘內產出第一個 Alpenglow 區塊 65%、10 月 21 日 16:00 前 75%、10 月 22 日 13:40 前 82%;接手後 24 小時內沒有超過 1 小時的出塊停擺 80%(以接手成功為前提,沿用);完整效能取樣中投票交易占比低於 5%,10 月 22 日 23:59 前 70%(昨天 65%,就緒數字改善後上調);從 S 到第一個 Alpenglow 區塊之間,使用者交易無法上鏈超過 30 分鐘 25%。
- 預測四: 第 5734 號 PR 10 月 23 日前合併 15%、EIP 第 12513 號 PR 10%;共識層 builder 存款分流在 10 月 31 日前以新 PR 重新提出 15%(以上沿用)。
- 預測五: Ledger 10 月 24 日 23:59 前官方公告受影響裝置數或損失總額其中之一 25%;Ledger 官方文字出現 MediaMarkt 或 Aqipa 任一名稱 20%;Cysic 10 月 25 日 23:59 前公布事後調查報告 50%、橋接恢復 25%;Gamdom 10 月 23 日 23:59 前公開儲備證明 20%(以上沿用)。
明天接的待辦:Alpenglow 實際啟用結果(epoch 1064 開始時間、接手時間、創世憑證、投票占比、出塊停擺與否)、Geth 是否出 v1.17.9 與 Grandine 的狀態、ACDE 第 248 次的結論、追蹤站的最新就緒比例與 20.3% 的來源。
🔗 延伸學習
- Glamsterdam Hoodi 測試網公告(以太坊基金會) — 分叉 epoch、gas 上限提高到 2 億、各客戶端版本表。
- Reth v2.8.0 發布說明(GitHub) — Hoodi 排程、Action Required 與 Engine API 錯誤碼變更。
- Erigon v3.8.0 發布說明(GitHub) — Glamsterdam 支援、QUIC 埠與移除的 Engine API 方法。
- Alpenglow(solana.com) — epoch 1064、slot 459,653,000、v4.3.2 要求與 0.8 SOL 入場券。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度,以及 Solana 的 Alpenglow 遷移(查證時間 2026-10-20 23:00 到 23:15 UTC,資料來自 GitHub API、以太坊基金會公告頁、solana.com 與 Solana 公開 RPC;撰稿時 Alpenglow 尚未啟用)。以下是我整理的主張與推導,請協助查證並嚴格區分來源:
1. 事實:Hoodi 分叉在 2026-10-26 17:42:48 UTC(epoch 132352,時間戳 1793036568),Hoodi 的 gas 上限在該 epoch 提高到 2 億。含 Hoodi 排程的穩定版 10 個:共識層 Lodestar、Teku、Nimbus、Prysm、Lighthouse v8.3.0;執行層 Besu 26.10.0、Nethermind 2.2.0、Ethrex v30.0.0、Erigon v3.8.0(10/20 07:49:47 UTC)、Reth v2.8.0(10/20 19:34:03 UTC)。Geth 排程於 10/19 22:41:04 UTC 合併但最新仍是 v1.17.8;Grandine 只有 3.0.0-rc.1 預發布。
2. 我的觀察:Lighthouse、Erigon、Reth 從排程合併到穩定版分別是 7.22、6.70、8.05 天,所以我對 Geth 在 10/22 14:00 前出穩定版只給 35%。
3. SIMD-0384 的條文(我讀 solana-foundation/solana-improvement-documents 主分支檔案):邊界 slot S = X + 5000 = 459,653,000;S 起區塊只准投票交易;強樂觀確認要直接子區塊帶 82% 質押的投票;創世憑證要 82% 的 BLS 創世投票;收到憑證後回滾到創世區塊 G 並恢復打包使用者交易。我的推論是:憑證形成前,使用者交易無法上鏈,文件沒有說湊不到 82% 時怎麼辦。
4. Epoch 預報:epoch 1062 實際長 94,025 秒(每 slot 0.21765 秒);epoch 1063 在 slot 459,405,272(10/20 23:02:02 UTC)已走 189,272 個 slot、41,082 秒(每 slot 0.21705 秒);外推 epoch 1064 開始 13:40 UTC、接手 slot 約 13:58 UTC;官方頁面寫約 13:20,要對上需要快 2.3%。
5. 就緒度:Pumpkin's Pool 追蹤站 10/19 16:17 UTC 標 45.2%(1.981 億 SOL)未就緒;10/20 的二手報導稱 151 個驗證者、20.3% 未就緒。我自算總質押約 4.383 億 SOL,就緒 79.7%,離 82% 差 2.3 個百分點(約 1,008 萬 SOL);這與我昨天假設「4.3.0 與 4.3.1 的質押全升級」的數字相同,我不知道是巧合還是口徑相同。
6. 效能取樣:205 筆,總交易 66,635,681、非投票 28,940,409,投票占 56.6%。
請幫我:
(a) 檢查第 3 點我對 SIMD-0384 的讀法,尤其「憑證形成前使用者交易無法上鏈」是否被 Anza 的文件、Agave 的實作或官方說明支持或反駁(請引用原文;查不到就明說);並說明 82% 與 19% 拜占庭上限的關係;
(b) 檢查第 4 點的外推算術,說明 slot 時間為何會逐 epoch 變動,以及官方「約 13:20」可能是怎麼估的;
(c) 檢查第 5 點的缺口算術與其假設(分母、追蹤站的就緒定義與創世投票最低條件的差異),並說明 Firedancer 與 Frankendancer 在遷移期間不支援對就緒比例的影響;
(d) 說明 Erigon v3.8.0 與 Reth v2.8.0 的發布說明中,哪些變更會影響在 Hoodi 分叉前升級的節點營運者(QUIC 埠、Engine API 錯誤碼、gas 上限);
(e) 分三類標示每個結論:「文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,不確定就說不確定。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押、購買或節點營運建議。