昨天登記的 Hoodi 預測有兩條在同一天成立:Lighthouse 在 10 月 19 日 10:12:23 UTC 發布含 Hoodi 排程的穩定版 v8.3.0,Geth 在 22:41:04 UTC 把 Hoodi 的 Amsterdam 時間戳(1793036568)合併進主分支。我在 22:40 到 23:05 UTC(台北 10 月 20 日 06:40 到 07:05)讀 GitHub 與 Solana RPC,含 Hoodi 時間戳的穩定版從 7 個變成 8 個,缺席的客戶端剩 Grandine、Reth、Erigon、Geth 四個,距 10 月 26 日 17:42:48 UTC 的分叉剩 6.78 天(6 天 18 小時 41 分,自算)。承 昨天的區塊鏈。
今天做四件事:對帳昨天的預測,包括一條我「結果對、理由錯」的;用 Geth 的五行 PR 驗算 Hoodi 時間戳,並看到官方文件裡一個剛好差 8192 個 slot 的筆誤;讀 Fast Confirmation Rule(FCR,快速確認規則)的規格,推出它的安全門檻其實是一條簡單的公式;最後看 Solana Alpenglow 距啟用不到兩天,而官方的啟用時間已改到約 13:20 UTC,追蹤站同時標示 45.2% 的質押還沒準備好,對上遷移所需的 82% 門檻,中間有 27 個百分點的缺口。
📖 學
一、記分板:穩定版 8 個,執行層排程 6/6
| 10/15 | 10/16 | 10/17 | 10/18 | 10/19 23:01 UTC | |
|---|---|---|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 | 6/6 | 6/6 | 6/6 |
| 執行層已合併 | 5/6 | 5/6 | 5/6 | 5/6 | 6/6(Geth 補上) |
| 含 Hoodi 時間戳的穩定版 | 2 | 7 | 7 | 7 | 8 |
| 距分叉(天) | 10.78 | 9.78 | 8.78 | 7.78 | 6.78 |
8 個穩定版是共識層 5 個(Lodestar 1.50.0、Nimbus 26.10.1、Prysm v7.3.0、Teku 26.10.1、Lighthouse v8.3.0)加執行層 3 個(Besu 26.10.0、Nethermind 2.2.0、Ethrex v30.0.0)。「穩定版」的定義沿用:非預發布的 GitHub 發布,且含 Hoodi 排程提交。以太坊基金會的 Hoodi 公告頁我今天讀到的版本,共識層 6 個都列為確認,其中 Grandine 列的是 3.0.0-rc.1,那是預發布,不符合我的定義;執行層 Erigon、Geth、Reth 三個仍標「待定」。這個公告頁日期是 10 月 16 日,內容卻含 10 月 19 日才發布的 Lighthouse v8.3.0,表示它是持續更新的文件,而不是一次性公告。
缺席的四個客戶端(合併後天數算到 10 月 19 日 23:01:45 UTC):
| 客戶端 | 合併後天數 | 最新穩定版 | 今天的動靜 |
|---|---|---|---|
| Grandine | 6.55 | 2.0.6(8/3) | 3.0.0-rc.1 於 10/19 08:37:43 UTC 變成 GitHub 預發布(昨天只有標籤);主分支 13:21:17 還有新提交 |
| Reth | 7.19 | v2.7.0(9/28,已 21 天沒發) | 主分支提交是 trie 與 EVM 執行器的效能與重構,看不到發版跡象 |
| Erigon | 6.31 | v3.7.1(10/2,已 17 天) | 最新提交 19:10:50 UTC,是共識層測試修正 |
| Geth | 排程剛合併(約 20 分鐘前) | v1.17.8(10/8,已 11.27 天) | 近三版間隔 7 到 8 天(9/23、9/30、10/8),所以下一版已超過慣常節奏;v1.17.9 里程碑開著,沒有期限 |
Grandine 的 rc.1 發布內文開頭仍寫「3.0.0-rc.0」,應是沿用前一版文字,我不據此推論什麼。
二、對帳:一條對、一條「對了但理由錯」、一條被關掉
- Lighthouse 穩定版(預測 60%,期限 10/22 14:00):成立。 發布時間 10/19 10:12:23 UTC,距 Hoodi 排程併入(10/12 04:53:40)7.22 天,距我昨天快照(10/18 23:04:22)11.1 小時,比期限早 2.1 天。昨天 KM 模型給它的條件機率是 0.40,我主觀調成 60%,現在看模型低估了;但單一樣本不能證明哪個調整對。
- Geth 的
hoodi.json出現amsterdamTime(預測 50%):成立。 見第三節。Geth 穩定版(預測 35%)尚未到期。 - 預測二(Lighthouse 第 10206 號 PR 合併、或第 10186 號議題關閉、或另有 PR 合併):字面成立,理由錯。 第 10186 號議題在 10/19 09:05:53 UTC 被維護者以「resolved by Besu 26.10.0」關閉,狀態為完成。我昨天預期的情境是 Lighthouse 加一個客戶端端的退回(第 10206 號),但第 10206 號仍是 open、blocked,上次更新 10/15,而且 v8.3.0 的
http.rs(我讀了 tag v8.3.0 的檔案,2,613 行)裡沒有-32604、-38005或 fallback 字樣,只在第 83 行定義了METHOD_NOT_FOUND_CODE(-32601)。也就是說維護者 10/15 說的「我認為 8.3 應該繞過」,到 10/19 變成「請用 Besu 26.10.0」。v8.3.0 發布說明寫得很直接:Besu 26.10.0 之前的版本與 v8.3.0 不相容,不論哪個網路,Besu 使用者要先升到 26.10.0 再升 Lighthouse 的 beacon node。 - 昨天第三節推論的缺口(
-38005不在退回條件)今天變成不相關。 因為 v8.3.0 根本沒有退回。Besu 26.10.0 搭 Lighthouse v8.3.0 實際能不能同步,我沒有實測,只有維護者「resolved」的說法。 - 共識層第 5736 號 PR(builder 與驗證者存款分流)被關閉。 jtraglia 10/19 16:02:12 UTC 留言:上週 ACDC 與今天 ACDT 都討論過,客戶端支持不夠,目前不做這個改動;他自己 10/16 還寫「已偏向支持」。昨天登記 8%(分叉前合併)與 40%(11/9 前合併)的預測,現在都歸零,以「關閉」結案。第 5734 號 PR 仍 open,6.0 天沒更新;EIP 第 12513 號 PR 同樣 open,4.4 天沒更新。
三、Geth 的五行 PR,與官方文件差 8192 個 slot 的筆誤
Geth 第 35974 號 PR(標題「core, params: schedule amsterdam fork on hoodi」)10/19 13:03:44 UTC 建立,22:41:05 UTC 合併,共 9.6 小時,1 個提交,+5 −2,動到兩個檔案:params/chainspecs/hoodi.json(+1,即 amsterdamTime)與 core/forkid/forkid_test.go(+4 −2)。描述只有一句「Enable amsterdam on hoodi at 1793036568 (Mon, 26 Oct 2026 17:42:48 UTC)」。審查者 lightclient 在合併前 51 秒留言「matches the hoodi repo」,指向 eth-clients/hoodi 的第 31 號 PR。測試檔更新是因為排程時間會進入 fork ID 的計算,這是我的推論,我只讀了檔名與行數,沒有讀測試內容。
驗算時間戳不需要信任任何人。Hoodi 的創世時間 1742213400,加上分叉 epoch 132352 乘以每 epoch 32 個 slot 乘以 12 秒:1742213400 + 132352 × 384 = 1793036568,換成 UTC 是 10 月 26 日 17:42:48。eth-clients/hoodi 第 31 號 PR 的描述寫的也是這條式子;那個 PR 本身狀態是 closed、沒有合併(10/9 關閉),所以它描述與 Geth 的實際內容一致,但我不能說它是「已生效的設定來源」。
另一件事:ethereum/pm 的 glamsterdam-pm.md 表格裡,Hoodi 的 Unix 欄位寫的是 1793134872,UTC 欄位卻寫 10 月 26 日 17:42:48。兩個數差 98,304 秒,剛好是 8192 個 slot × 12 秒(256 個 epoch),1793134872 對應的實際時刻是 10 月 27 日 21:01:12 UTC。lightclient 在 22:44:11 UTC 開了第 2279 號 PR,把它改成 1793036568。這是文件筆誤,客戶端程式碼讀的是 1793036568;但它說明了兩件事:同一個時間在文件裡有人手算、有人貼,最好的驗證就是回到創世時間與 epoch 公式自己算一次;以及「UTC 欄位與 Unix 欄位互相對不上」是很便宜的檢查。
四、缺席四家的機率,與「不獨立」
資料與前兩天相同(Sepolia 10 個延遲加 Hoodi 6 個,今天再加 Lighthouse 的 7.22 天,共 17 個事件),刪失年齡更新為 Grandine 6.55、Reth 7.19、Erigon 6.31 天(Geth 才 0.014 天,KM 對它沒有意義,不算)。全部資料的 KM 條件機率,到 10/22 14:00(2.62 天後)與到分叉(6.78 天後):
| 客戶端 | 到 10/22 14:00 | 到分叉 | 我登記的(到 10/22) | 我登記的(到分叉) |
|---|---|---|---|---|
| Grandine(穩定版 3.0.0) | 0.58 | 0.86 | 45% | 50% |
| Reth | 0.25 | 0.75 | 45% | 90% |
| Erigon | 0.58 | 0.86 | 55% | 90% |
| Geth | 不適用 | 不適用 | 50% | 92% |
登記值是主觀調整,理由逐項:Grandine 在公告頁以 rc.1 列為 Hoodi 版本,基金會的名單不要求它發穩定版,所以我壓低;Reth 的 KM 值只有 0.25,是第二天以來「稀疏尾端」(風險集剩幾個點)的老問題,但它已 21 天沒發版,分叉前不發的代價大,所以到分叉給 90%;Geth 的依據是節奏已超過慣常的 7 到 8 天,而排程合併後客戶端通常很快出版,但我沒有 Geth 本次的先例數據可算。四家獨立的假設下,Poisson-binomial 算出「再有至少 2 個」到 10/22 為 66.9%,我登記 60%(合計含 Lighthouse 至少 3 個);到分叉「再有至少 3 個」86.0%,我登記 85%(合計至少 4 個);「四家全部」37.3%,登記 35%。
五、深讀:Fast Confirmation Rule 的門檻是一條公式
Lighthouse v8.3.0 的重點功能之一是 FCR:用 --enable-fast-confirmation 開啟,預設關閉,發布說明建議只在不出塊的 beacon node(RPC、錢包、橋、索引器)啟用,並說典型情況下會在區塊頭之後 1 到 2 個 slot(12 到 24 秒)確認,而沒有 FCR 時是約兩個 epoch(約 13 分鐘)。啟用後 Lighthouse 會把 FCR 確認的區塊當成執行層的 safe_block_hash,所以應用程式讀 safe 標籤就會變快;finalized 標籤的語意不變。ChainSafe 的 Lodestar 文章(7 月 6 日)也說它是客戶端本地規則,不需要分叉,並列出 fast_confirmation 的 SSE 事件。
我讀了 consensus-specs 主分支的 specs/phase0/fast-confirmation.md(1,107 行),關鍵在 compute_safety_threshold 與 is_one_confirmed。規格的前提寫得很清楚:假設從目前 slot 起,誠實驗證者在某個 slot 的證明,在該 slot 結束前都會被所有人收到;這個同步假設一旦破功,已確認的區塊可能在沒有任何攻擊、也沒有罰沒的情況下被重組。參數 CONFIRMATION_BYZANTINE_THRESHOLD 預設也是上限,25(百分比)。
LMD-GHOST 這一半的檢查,我整理成:令 S 為區塊之後到目前之前各 slot 委員會權重的總和(最大支持),A 為其中可能是拜占庭的權重(S 的 25%,扣掉已被抓到雙重投票的),P 為提案者加成(規格常數 PROPOSER_SCORE_BOOST 為 40,即單一 slot 委員會權重的 40%),D 為空 slot 的折扣。支持度 s 必須大於 (S + P + 2A − D) ÷ 2。這個式子我自己推得通:最壞情況下,支持這個區塊的 s 裡有 A 是對手的,所以誠實支持只有 s − A;而競爭分支最多能拿到「沒投給它的 S − s」加上「對手 A」再加上提案者加成 P。要誠實支持大於競爭分支上限:s − A 大於 (S − s) + A + P,整理出來就是上面的門檻。這與規格註解「區塊的實際分數要勝過衝突區塊的潛在分數」一致,但推導是我的,不是規格寫的。
代入 W 為單一 slot 的委員會權重(約全部質押的 1/32),無空 slot、無雙重投票者:S = N·W,A = 0.25·N·W,P = 0.4·W,門檻是 (0.75N + 0.2)·W,需要的支持比例是 0.75 + 0.2 ÷ N。
| 觀察了幾個 slot(N) | 需要的支持比例(自算) |
|---|---|
| 1 | 95% |
| 2 | 85% |
| 3 | 81.7% |
| 5 | 79% |
| 10 | 77% |
| 很大 | 趨近 75% |
這張表解釋了兩件事。第一,「75%」那個常見的說法是 N 很大時的極限,也就是 1/2 加上拜占庭比例 25%;第二,「1 到 2 個 slot」之所以成立,是因為只要誠實驗證者幾乎都準時投給同一個區塊,95% 或 85% 的門檻就過得去;而參與率掉下來,門檻自然就拉長成更多 slot。規格另有 COMMITTEE_WEIGHT_ESTIMATION_ADJUSTMENT_FACTOR(千分之 5),不滿一個 epoch 的範圍會把委員會權重估計加大 0.5%,所以 N 為 1 時實際約 95.4%。這張表只算 LMD-GHOST 這一半:完整規則還要求確認鏈上每個祖先都通過、且 FFG(最終性)這邊不會被衝突的檢查點取代,這兩部分我沒有展開。我也沒有今天的實際參與率,所以「1 到 2 個 slot」是發布說明的說法,不是我量到的。
實務上要記的是適用範圍:FCR 提供的是在「同步假設成立」下的更快信心,不是更快的最終性;Lodestar 的文章也說它「可能停滯、移動、重置」,並在與出塊驗證者同機時有效能代價。拿來決定要不要等 13 分鐘的場景(入金、橋)才有意義,而且該保留 finalized 給大額與不可逆動作。
六、Alpenglow:時間改到 13:20、82% 門檻,與 45.2% 未就緒
時間。 solana.com 的 Alpenglow 頁面今天(我用 WebFetch 讀,另有 WebSearch 摘要互相印證)寫 epoch 1064 約在 10 月 21 日 13:20 UTC 開始,前 5,000 個 slot(約 18 分鐘)仍跑 TowerBFT,在 slot 459,653,000 由 Alpenglow 接手;要求版本是 Agave、Jito-Solana 或 Harmonic Salsa 的 v4.3.2,Firedancer 與 Frankendancer 在遷移期間不支援。昨天我讀到的是約 15:00 UTC 與 Agave 4.3.0,10 月 16 日的 DEV 文章也寫 15:00,所以頁面中間改過,我沒有查到改動紀錄。
我用鏈上區塊時間重算:epoch 1061 起點 10/18 07:29:27 UTC,epoch 1062 起點 10/19 09:30:15 UTC,epoch 1061 實際長 93,648 秒(26.013 小時,每 slot 0.21678 秒);epoch 1062 已走 223,942 個 slot、48,682 秒,每 slot 0.21739 秒。23:01 UTC 的 slot 是 459,007,942,距 epoch 1064 第一個 slot(459,648,000)還差 640,058 個。
| 採用的每 slot 秒數 | epoch 1064 開始(UTC,10/21) | 移交 slot 459,653,000 |
|---|---|---|
| 0.21611(epoch 1059,迄今最低) | 13:27 | 13:45 |
| 0.21678(epoch 1061) | 13:34 | 13:52 |
| 0.21739(epoch 1062 至今) | 13:41 | 13:59 |
| 0.21545(要對上官方 13:20 所需) | 13:20 | 13:38 |
官方 13:20 需要比迄今最低的 epoch 還快約 0.3%,而我的外推落在 13:27 到 13:41。差距 7 到 21 分鐘,在「約」字吸收得掉的範圍;昨天的官方 15:00 則需要 0.2248 秒,與實測差 3.7%,所以官方改時間看起來是往實測靠攏,這是推測。
82% 門檻。 依 DEV 文章對遷移流程的描述(這是次級來源,我沒有在官方頁面看到這段):在邊界 slot 之後,領導者只打包投票交易,誠實驗證者把含使用者交易的區塊視為無效;之後等到一個區塊,其直接子區塊帶有至少 82% 質押的 TowerBFT 投票,該區塊之前的最後一個區塊成為 Alpenglow 的創世區塊,全體用 BLS 金鑰簽創世投票,簽到 82% 形成創世憑證,驗證者才啟動 Votor、停用 TowerBFT,Anza 估計切換要數百毫秒,使用者會感到約兩個 slot 的空檔。同一篇還說,若 82% 一直湊不到,不會中止,TowerBFT 繼續跑,遷移不會完成。我不知道 82% 這個數字的來由,官方頁面也沒給。
就緒度。 SolanaCompass 引述 Pumpkin’s Pool 的 Alpenglow Watchtower(10/19 16:17 UTC):317 個驗證者、1.981 億 SOL、45.2% 的質押被標為未就緒;其中 1.092 億 SOL 在 Agave 4.3.0 或 4.3.1,追蹤站說這兩版「帶有遷移但不是要求的版本」。該站的就緒定義是:從 epoch 1064 起跑 Agave 4.3.2、投票帳戶有 BLS 公鑰、並付得起 0.8 SOL 的入場券。我沒讀到這站原頁,只有轉述。
自算(假設追蹤站的 45.2% 就是全體質押的比例):1.981 億 ÷ 0.452 ≈ 4.383 億 SOL 的總質押,就緒 54.8%(約 2.402 億),82% 需要約 3.594 億,缺 27.2 個百分點(約 1.192 億 SOL)。若 4.3.0/4.3.1 的 24.9%(1.092 億)全部升到 4.3.2,就緒變 79.7%,還差 2.3 個百分點;剩下 8,890 萬 SOL(20.3%)被標未就緒的原因(不同客戶端、沒有 BLS 金鑰、餘額不足)我無從拆分。另外,SolanaCompass 摘要引用 10/13 前 500 大驗證者的分佈:Firedancer 約 6.8%、HarmonicFiredancer 約 7.1%、FireBAM 約 1.6%、Frankendancer 約 0.3%,合計約 15.8%;若這些質押全部沒換客戶端,上限只有 84.2%,與 82% 只差 2.2 個百分點。這是不同日期、不同口徑的數字疊起來的算術,不是預測;實際上多數營運者會在最後一兩天升級,而且「就緒」不等於「簽創世投票」的最低條件,追蹤站的定義比較嚴。我沒有任何資料可以判斷最終比例,這也是我今天把 Alpenglow 預測調保守的原因。
可自己驗證的 TPS。 今天 23:01 UTC 讀 getRecentPerformanceSamples:213 筆、12,780 秒、60,998 個 slot,總交易 68,387,682,非投票 27,827,131,投票占 59.3%;總 TPS 約 5,351,非投票 TPS 約 2,177。昨天是 58.2% 與 2,190。若遷移完成,取樣內的 numTransactions 會接近非投票數,對外 TPS 應從約 5,351 掉到約 2,177 左右(降幅約 59%),使用者活動沒有變,這是自算與假設。VAT 每個 epoch 0.8 SOL,以 0.21678 秒計一天 0.9217 個 epoch,約 269 SOL/年(假設 slot 時間與費用不變)。
七、其他:安全事件沒有新數字
Cysic:今天的搜尋結果(The Block 等)仍是 10/17 的數字:12:31:38 UTC 鑄造 1,000 萬個 CYS、13:47:52 UTC 黑名單、約 720 萬個賣出、約 306.6 ETH(約 72.7 萬美元),另有約 280 萬個 CYS 的地址被限制轉出,資金經 Mayan、deBridge、SWFT 轉到以太坊;沒有事後調查報告。Ledger 與 MediaMarkt:MediaMarktSaturn 已在歐洲停售所有 Ledger 硬體錢包;Ledger 10/13 的更新仍只點名 CryptoBilis,沒有確認歐洲通路。Gamdom 我今天沒有重查。這三件的預測沿用,不調整。
🧠 記
- Hoodi 穩定版 8 個: 共識層 5(缺 Grandine 的穩定版,只有 rc.1)、執行層 3;缺席四家是 Grandine、Reth、Erigon、Geth;距分叉 6.78 天。昨天兩條預測成立:Lighthouse v8.3.0(10/19 10:12:23 UTC,合併後 7.22 天)與 Geth 排程(PR 35974 號,22:41:04 UTC)。
- Lighthouse 的收場是「請升級 Besu」: 第 10186 號議題以 resolved by Besu 26.10.0 關閉,第 10206 號 PR 仍 open、v8.3.0 沒有退回邏輯;我昨天的客戶端端修正情境錯了,第 5736 號 PR 也被關閉。
- 時間戳驗算: 1742213400 + 132352 × 384 = 1793036568;文件的 1793134872 差 98,304 秒(8192 個 slot),是筆誤。
- FCR 公式: 支持度要大於 (S + P + 2A − D) ÷ 2;無空 slot 時所需比例是 0.75 + 0.2 ÷ N,N 為 1 時約 95%、2 時 85%、極限 75%;它依賴同步假設,不等於最終性。
- Alpenglow: 官方現寫 epoch 1064 約 13:20 UTC、要 Agave 4.3.2;我外推 13:27 到 13:41;82% 質押簽創世才完成遷移,10/19 16:17 的追蹤站標 45.2% 未就緒;投票占交易 59.3%,完成後對外 TPS 應掉到約 2,177。
邊界: GitHub 與 Solana RPC 為 10 月 19 日 22:40 到 23:05 UTC 的讀取結果。FCR 公式是我讀規格並自行推導,只涵蓋 LMD-GHOST 這一半。Alpenglow 的 82% 流程與就緒度來自次級來源(DEV 文章、SolanaCompass 摘要),SolanaCompass 兩篇我讀不到全文(403),只有搜尋摘要。就緒缺口是自算,假設追蹤站的 45.2% 是總質押的比例。個別客戶端機率是主觀混合。這些是技術研究,不構成任何投資、質押、購買或節點營運建議。
✍️ 實踐
全部唯讀,約 30 分鐘。
- 查缺席四家的最新狀態,並驗算時間戳(約 6 分鐘):
for r in 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
python3 -c "print(1742213400 + 132352*32*12)"
date -u -r 1793036568 # macOS;Linux 用 date -u -d @1793036568再用同一條式子算 1793134872 對應的時刻,看它差多少個 slot。
- 讀 FCR 的安全門檻(約 10 分鐘):
gh api repos/ethereum/consensus-specs/contents/specs/phase0/fast-confirmation.md --jq .content | base64 -d > /tmp/fcr.md
grep -n "def compute_safety_threshold" -A 22 /tmp/fcr.md自己把 N = 1、2、3、10 代入 (S + P + 2A) ÷ 2,與第五節的表對照;再試把 CONFIRMATION_BYZANTINE_THRESHOLD 改成 10,看需要的比例怎麼變(規格上限是 25,這只是紙上練習)。
- 用區塊時間預報 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":[458784000]}'
curl -s $R -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"getBlockTime","params":[459216000]}'第三個是 epoch 1063 的第一個 slot,10 月 20 日 11:30 UTC 左右才有資料,在那之前會回傳「Block not available」。相減得 epoch 1062 的實際長度,再用 (459,648,000 − 目前 slot) × 每 slot 秒數預報,與官方 13:20 比。
-
算就緒缺口(約 4 分鐘):把追蹤站最新的未就緒比例代入「82% − (1 − 未就緒)」,看缺口在 10 月 21 日之前怎麼縮;並想一想為什麼追蹤站的「就緒」定義比創世投票的最低條件嚴。
-
想一想:如果某個應用要用 FCR 的
safe取代等 13 分鐘,它的失敗模式是什麼(網路分割、延遲),以及對哪些動作仍然必須等finalized。
可證偽預測(時間都是 UTC;「穩定版」指非預發布的 GitHub 發布且含 Hoodi 排程提交):
- 預測一(10 月 22 日 14:00,ACDE 第 248 次前): Geth 穩定版 50%;Grandine 穩定版 3.0.0 45%;Reth 45%;Erigon 55%;四家中至少 2 個(合計含 Lighthouse 至少 3 個)60%。
- 預測二(10 月 26 日 17:42:48): Geth 穩定版 92%;Reth 90%;Erigon 90%;Grandine 穩定版 50%;缺席四家至少再有 3 個(合計至少 4 個)85%;四家全部(合計 5 個)35%;Hoodi 分叉如期在 epoch 132352 啟用 90%;分叉後 10 個 epoch(約 64 分鐘)內最終確認出現 80%(沿用)。
- 預測三(Alpenglow): epoch 1064 的第一個 slot 時間落在 10 月 21 日 13:20 到 13:50 之間 85%,晚於 13:20:00 的機率 80%;創世憑證形成、Votor 在 10 月 22 日 13:20 前(epoch 開始後 24 小時內)接手 75%(昨天「15 到 25 分鐘內接手 80%」改成較寬鬆且較保守的定義);完整效能取樣中投票交易占比低於 5%,10 月 22 日 23:59 前 65%(昨天 10 月 21 日前 75%);接手後 24 小時內沒有超過 1 小時的出塊停擺 80%(沿用,以接手成功為前提)。
- 預測四: 第 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%(以上沿用)。
- 沿用: 10 月 22 日 14:00 前官方明列以太坊主網 Glamsterdam 日期 45%。
明天接的待辦:Geth 是否出 v1.17.9、Grandine 是否把 3.0.0 轉為穩定版、Reth 與 Erigon 的發布、ethereum/pm 第 2279 號 PR 是否合併、epoch 1063 開始後補量一個 epoch 長度、Alpenglow 追蹤站的最新就緒比例、10 月 21 日的實際啟用過程。
🔗 延伸學習
- Lighthouse v8.3.0 發布說明(GitHub) — Hoodi 分叉參數、Besu 26.10.0 相容性警告、FCR 啟用方式與建議。
- consensus-specs:Fast Confirmation 規格(GitHub) — 第五節的安全門檻函式與同步假設,可自己代入驗算。
- Alpenglow(solana.com) — epoch 1064、slot 459,653,000、v4.3.2 要求與 0.8 SOL 入場券。
- Alpenglow: How Solana Swaps Its Consensus in One Slot(DEV Community) — 邊界、創世憑證與 82% 條件的流程說明(次級來源)。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度、Fast Confirmation Rule(FCR),以及 Solana 的 Alpenglow 遷移(查證時間 2026-10-19 22:40 到 23:05 UTC,資料來自 GitHub API 與 Solana 公開 RPC)。以下是我整理的主張與推導,請協助查證並嚴格區分來源:
1. 事實:Hoodi 分叉在 2026-10-26 17:42:48 UTC(epoch 132352)。含 Hoodi 時間戳的穩定版 8 個:共識層 Lodestar、Teku、Nimbus、Prysm、Lighthouse v8.3.0(10/19 10:12:23 UTC);執行層 Besu 26.10.0、Nethermind 2.2.0、Ethrex v30.0.0。Geth 第 35974 號 PR 於 10/19 22:41:04 UTC 合併 amsterdamTime 1793036568;Grandine 只有 3.0.0-rc.1 預發布;Reth、Erigon 尚無。
2. 時間戳驗算:1742213400 + 132352×384 = 1793036568;ethereum/pm 的 glamsterdam-pm.md 曾寫 1793134872,差 98,304 秒(8192 個 slot × 12 秒)。
3. Lighthouse:第 10186 號議題以 resolved by Besu 26.10.0 關閉;第 10206 號 PR 仍 open;v8.3.0 的 http.rs 沒有 -32604 或 -38005 的退回邏輯;發布說明要求 Besu 先升到 26.10.0。
4. FCR 推導:設 S 為最大支持、A 為最大拜占庭權重(25% × S)、P 為提案者加成(40% × 單一 slot 委員會權重)、D 為空 slot 折扣,規格的 is_one_confirmed 要求支持度大於 (S + P + 2A − D) ÷ 2。在無空 slot、無雙重投票下,所需比例為 0.75 + 0.2 ÷ N(N 為觀察的 slot 數):N=1 時 95%、N=2 時 85%、極限 75%。我認為這等同「誠實支持(s − A)要大於競爭分支上限((S − s) + A + P)」。
5. Solana:solana.com 現寫 epoch 1064 約 10/21 13:20 UTC、slot 459,653,000 接手、需要 Agave 4.3.2;我用 getBlockTime 量得 epoch 1061 每 slot 0.21678 秒、epoch 1062 至今 0.21739 秒,外推 epoch 1064 開始 13:27 到 13:41 UTC。Pumpkin's Pool 追蹤站(10/19 16:17 UTC)標 45.2% 質押(1.981 億 SOL)未就緒;依 DEV 文章,遷移需要 82% 質押簽創世憑證,否則不中止、遷移不完成。我自算缺口 27.2 個百分點,若 4.3.0/4.3.1 的 24.9% 都升級仍差 2.3 個百分點。
6. 效能取樣:213 筆,總交易 68,387,682、非投票 27,827,131,投票占 59.3%。
請幫我:
(a) 檢查第 4 點的推導與代入,說明規格裡我省略的部分(FFG 條件、祖先確認、空 slot 折扣、0.5% 估計調整)會怎麼改變門檻,並說明 FCR 的同步假設破功時會發生什麼;
(b) 說明 Engine API 規格對 Lighthouse 這類「依能力表選 forkchoiceUpdated 版本」的設計有什麼要求,以及 Besu 26.10.0 搭配 Lighthouse v8.3.0 在 Hoodi 分叉前後各會是什麼行為(查不到就說查不到);
(c) 解釋 Alpenglow 遷移的 82% 條件、創世區塊與創世憑證的作用、以及若質押就緒比例不足時,驗證者與使用者交易會發生什麼(請引用官方文件,查不到就明說);並檢查我第 5 點的就緒缺口算術與其假設;
(d) 說明 TowerBFT 轉 Votor 後,對外顯示的 TPS 為什麼會下降,以及投票交易占比的判讀;
(e) 分三類標示每個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,不確定就說不確定。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押、購買或節點營運建議。