我在 10 月 18 日 23:00 到 23:05 UTC(台北 10 月 19 日 07:00 到 07:05)重讀了 Hoodi 的 Glamsterdam 進度:發布期限(10 月 16 日 23:59:59 UTC)過後 47.07 小時,含 Hoodi 時間戳的穩定版仍是 7 個(共識層 4、執行層 3),距 10 月 26 日 17:42:48 UTC 的分叉剩 7 天 18 小時 38 分(7.78 天,自算)。承 昨天的區塊鏈,缺席的五個客戶端(Lighthouse、Grandine、Reth、Erigon、Geth)這一天沒有任何一個發出新的穩定版,昨天登記的預測沒有一條在今天到期。
今天做五件事:重算缺席客戶端的發布機率,並說明為什麼 Lighthouse 的數字一天內從 0.70 掉到 0.40;讀 Lighthouse 發布分支的原始碼,查出昨天我「從文件讀不出」的那個問題在程式裡長什麼樣,以及一個我昨天漏掉的修正 PR;看共識層新出現的 builder 入場路由議題;用 Solana 鏈上區塊時間(不是取樣)重算 Alpenglow 啟用時間,結果比昨天早了約 14 分鐘,與官方的「約 15:00 UTC」差了 75 分鐘左右;最後整理 Cysic 橋接事件、Hacken 的第三季損失統計、Ledger 與 Gamdom 的最新狀態。
📖 學
一、期限後第 47 小時的記分板
資料用 GitHub REST API 與 Solana 公開 RPC 讀取(本機時鐘 10 月 18 日 23:00:56 UTC 起),各項「距今」以 23:04:22 UTC 為基準,是我自算。
| 10/15 23:03 UTC | 10/16 23:03 UTC | 10/17 23:05 UTC | 10/18 23:04 UTC | |
|---|---|---|---|---|
| 共識層已合併 Hoodi 時間戳 | 6/6 | 6/6 | 6/6 | 6/6 |
| 執行層已合併 | 5/6 | 5/6 | 5/6 | 5/6(仍缺 Geth) |
| 含 Hoodi 時間戳的穩定版 | 2 | 7 | 7 | 7 |
| 距分叉 | 10.78 天 | 9.78 天 | 8.78 天 | 7.78 天 |
七個已發穩定版的客戶端,最晚的一個是 Prysm v7.3.0(10 月 16 日 21:08:47 UTC),其餘 Nethermind 2.2.0(16:26:20)、Besu 26.10.0(10:53:52)、Nimbus v26.10.1(08:28:20)都在期限前;期限後沒有新增。缺席五個的狀態,「合併後天數」是從各自把 Hoodi 排程併進主分支的時刻算到 10 月 18 日 23:04:22 UTC:
| 客戶端 | Hoodi 排程併入(UTC) | 合併後天數 | 合併到分叉 | 最新穩定版與新動靜 |
|---|---|---|---|---|
| Lighthouse | 10/12 04:53:40 | 6.76 | 14.53 | v8.2.3(10/1);v8.3.0-rc.0 為預發布;release-v8.3.0 分支最後提交 10/15 05:32:02,已 89.5 小時沒動 |
| Grandine | 10/13 09:56:48 | 5.55 | 13.32 | 2.0.6(8/3);新出現 3.0.0-rc.1 標籤,指向 10/16 13:29:59 的提交,但沒有對應的 GitHub 發布 |
| Reth | 10/12 18:21:26 | 6.20 | 13.97 | v2.7.0(9/28);主分支近期提交是 pipeline 與測試修正 |
| Erigon | 10/13 15:41:10 | 5.31 | 13.08 | v3.7.1(10/2);近期提交是共識層 fork-choice 鎖順序與訂閱修正 |
| Geth | 無 | 不適用 | 不適用 | v1.17.8(10/8);hoodi.json 最後一次提交仍是 10/6 的 chainspecs 搬移,沒有 amsterdamTime;主分支最新提交 10/18 08:21:59 是輕客戶端事件鎖的修正 |
Grandine 那個標籤是今天新讀到的一條線索:3.0.0-rc.1 指向的提交晚於 Hoodi 排程合併(10 月 13 日),所以程式內容含 Hoodi;但 GitHub 的發布列表只到 3.0.0-rc.0(9 月 30 日,預發布),我看不到草稿發布,所以不能判斷這是「準備發布的信號」還是單純的標記。就算發出來,rc 也是預發布,不符合我對「穩定版」的定義(非預發布的 GitHub 發布、且含 Hoodi 排程提交)。Nimbus 另有每日 nightly(10 月 18 日 05:36:08 UTC),不計入。
二、昨天的預測對帳與一個昨天漏掉的事實
| 預測(昨天登記) | 結果 |
|---|---|
| 10/22 14:00 UTC 前 Lighthouse 穩定版含 Hoodi 70%;Geth 40%;缺席五個至少 3 個 60% | 未到期,見第四節重算 |
Geth hoodi.json 在 10/22 14:00 前出現 amsterdamTime 55% | 未到期;今天仍沒有 |
| 10/26 如期分叉 90% | 未到期;10/16 到 10/17 的多篇報導仍寫同一個時間(epoch 132352),我今天沒有讀到延期消息 |
| Alpenglow epoch 1064 落在 10/21 13:30 到 15:30 UTC 90% | 未到期;第六節用新資料縮窄 |
| 第 5734 號 PR 10/23 前合併 15%、EIP 第 12513 號 PR 10% | 未到期;兩者分別已 5.01 天、3.44 天沒有更新 |
| Ledger 10/24 前公布受影響數或損失總額 25% | 未到期;我查到沒有 Ledger 新的數字 |
| Gamdom 10/23 前公開儲備證明 25% | 未到期;見第七節 |
昨天我寫「合理的下一個觀察點是 Lighthouse 是否在 unstable 合併繞過修正」,並說議題上沒有人說用 Besu 26.10.0 測過可以。今天補一個昨天沒找到的事實:Lighthouse 其實有一個專門處理這件事的 PR,第 10206 號(標題「Fix fallback for unavailable forkchoice methods」)。它 10 月 3 日由貢獻者 mark0-cn 建立,10 月 6 日 01:20:22 UTC 被維護者以「改用 Besu 上游修正」為由關閉,10 月 15 日 08:23:01 UTC 又被同一位維護者重新開啟,時間就在他於第 10186 號議題留言「Besu 完全無法運作,所以我認為 8.3 應該繞過這個問題」的 4 分鐘之後。重新開啟距今 3.61 天,沒有審查、沒有新留言,合併狀態是 blocked。unstable 最新一筆提交是 10 月 16 日 04:54:29 UTC(距今 66.2 小時),與這件事無關。
三、讀程式:Lighthouse 到底怎麼選 forkchoiceUpdated 的版本
我讀了 release-v8.3.0 分支 beacon_node/execution_layer/src/engine_api/http.rs 的 forkchoice_updated 函式(約第 1579 到 1660 行),規則整理如下,這一段是我讀原始碼的結果,沒有執行。
| 呼叫情境 | 選擇的版本 | 遇到錯誤時 |
|---|---|---|
| 帶 payload attributes(V1 或 V2) | 能力表有 V2 就用 V2,否則 V1 | 直接回傳錯誤 |
| 帶 payload attributes(V3、V4、V5) | 必須剛好對應的版本,能力表沒有就回報「必要方法不支援」 | 直接回傳錯誤 |
| 不帶 payload attributes | 能力表裡由高到低:V5、V4、V3、V2、V1,取第一個有的 | 直接回傳錯誤,不往下退 |
關鍵在第三列:選版本只看 engine_exchangeCapabilities 的宣告,沒有看目前的分叉,出錯也不退回。第 10206 號 PR 的修改只在 http.rs 一個檔案(+215、−17),內容是:不帶 payload attributes 時,遇到 -32601(方法不存在)或 -32604(方法未啟用)就退到下一個宣告的較低版本,其他錯誤(含 INVALID 狀態)立刻回傳,能力快取保持不變,讓較高版本之後能用時還能用;PR 描述寫了五組回歸測試、execution_layer 的 45 個測試通過,並自述這個貢獻有 AI 輔助。PR 明說不處理 getBlobsV4 的退回。
這裡有一個我今天才看出來的缺口,屬於推論:昨天第 10186 號議題的表格顯示,Besu 26.10.0 的修正把「沒有 Amsterdam 的網路上,有分叉檢查的 Amsterdam 方法」改回 -38005(不支援的分叉),而第 10206 號 PR 的退回條件只含 -32601 與 -32604,不含 -38005。如果 Besu 26.10.0 在分叉前仍宣告 V4 或 V5、而 Lighthouse 照上表挑最高版本,那麼這個呼叫在 Hoodi 分叉(10 月 26 日)之前會得到 -38005,PR 不會退回。但我不知道 Besu 對「沒有 payload attributes 的 forkchoiceUpdated」是否做分叉檢查(發布說明只說「有分叉檢查的地方」),也沒有實測,所以這個缺口是否真的存在,只有實測能決定。這也回答了昨天第三節留下的問題:我從文件讀不出的,從程式讀得出一半;另一半(Besu 的實際行為)還是要實測。
四、缺席客戶端: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 天;Lodestar 無可靠數字,排除),只更新四個尚未發版客戶端的刪失年齡(5.31 到 6.76 天)。時間窗改成「從 10 月 18 日 23:04 UTC 起」:到 10 月 22 日 14:00 UTC 是 3.62 天,到分叉是 7.78 天。
| 客戶端 | 目前年齡(天) | 全部資料,到 10/22 14:00 | 全部資料,到分叉 | Sepolia 加刪失,到 10/22 | Sepolia 加刪失,到分叉 |
|---|---|---|---|---|---|
| Lighthouse | 6.76 | 0.40 | 0.80 | 0.25 | 0.75 |
| Grandine | 5.55 | 0.67 | 0.89 | 0.52 | 0.84 |
| Reth | 6.20 | 0.60 | 0.87 | 0.46 | 0.82 |
| Erigon | 5.31 | 0.67 | 0.89 | 0.52 | 0.84 |
最後兩欄的定義與昨天的「只用 Sepolia 10 點」不同:昨天沒有納入刪失樣本,今天納入,所以不能直接與昨天比較。
Lighthouse 從昨天的 0.70 掉到 0.40,原因不是它出了什麼事,而是 KM 的機制:昨天它年齡 5.76 天,後面還有 6.19、6.24、6.9956(Hoodi 的三個點)、7.09、10.44、10.86、15.41 天這些事件,風險集大;今天它年齡 6.76 天,那三個 Hoodi 的點已經「用完」,剩下 6.9956、7.09、10.44、10.86、15.41 這五個事件加它自己,風險集只剩 5 到 6 個。要到 10 月 22 日 14:00(年齡約 10.38 天),窗內只有 6.9956 與 7.09 兩個事件,結果 0.40。這是「樣本稀疏尾端」的典型現象:條件機率不一定隨等待時間單調,因為資料不是均勻的。同理 15.41 天之後曲線歸零,是因為最長的那個樣本之後沒有資料,不是真的「到了 15.41 天一定會發」。
這個數字我不全採信。Lighthouse 目前的卡點(第三節)是與特定 Besu 版本的相容問題,與 Hoodi 其他五個客戶端被期限壓縮的情況是兩回事;但距分叉只剩 7.78 天,分叉後仍沒有穩定版的客戶端,營運者在 Hoodi 上就沒有官方版本可用,這個壓力不在樣本裡。因此我把個別機率登記成「模型區間與主觀混合」,並明說這是主觀調整、不是模型輸出:Lighthouse 60%(昨天 70%)、Grandine 60%、Reth 55%(昨天 60%)、Erigon 60%、Geth 35%(昨天 40%,理由只有「合併仍未出現,Sepolia 先例中合併後還要 1.71 天」)。代入獨立假設,Poisson-binomial 算「至少 3 個」57.7%、「至少 4 個」23.6%、「0 個」1.9%;真實情況有正相關,尾端比這更厚,我登記「至少 3 個」55%(昨天 60%)。若把時間窗延到分叉前(個別機率取 0.75、0.85、0.80、0.85、0.50),「至少 3 個」約 91%,我登記 85%。
五、共識層:builder 入場路由的新議題,以及行事曆
昨天追的第 5734 號 PR(拒絕在 Heze 中被抽中的被罰沒提案者)10 月 13 日 22:49:25 UTC 之後沒有更新,今天已 5.01 天;EIP 第 12513 號 PR 10 月 15 日 12:35:19 UTC 之後沒有更新,3.44 天。兩者的預測維持昨天的 15% 與 10%。
新出現的是 consensus-specs 第 5736 號 PR(標題「Separate builder and validator deposits at the Gloas fork」),10 月 12 日 17:12:40 UTC 建立,修的是第 5735 號議題,狀態 open,2 則留言、2 則審查留言,最後更新 10 月 14 日 08:42:43 UTC。它處理的是 Gloas 分叉當下「待處理存款」的分流邏輯:依提款憑證把存款分到兩個登記簿。PR 描述的規則是:
- 驗證者存款留在驗證者佇列,即使同一把金鑰也被 builder 使用。
- 有效的 builder 存款會註冊或補充 builder,即使同一把金鑰也被驗證者使用。
- 已存在 builder 的存款一律補充,不看簽章。
- 無效且無對應 builder 的 builder 存款,只有在「已有同金鑰驗證者或更早的有效驗證者存款在佇列中」時才留在佇列,否則丟棄。
PR 指出目前的分叉路由會在「同金鑰已有驗證者」時擋住有效的 builder 註冊,與 EIP-8282 描述的「兩個獨立登記簿」不一致。ACDT 第 101 次的議程留言裡,留言者 jtraglia 在 10 月 16 日 19:26 UTC 寫下他的立場「已偏向支持這個修改」,並提出五步:Hoodi 不做這個改動(「船已經開了」);請客戶端先做原型確認難度;Hoodi 成功升級後合併並出版本;用短命 devnet(例如 devnet-12)驗證;不因此延後主網的 Glamsterdam。這是 jtraglia 的主張,不是會議決議。對我登記預測有用的是:他明說 Hoodi 之前不會合併,所以第 5736 號在分叉前合併的機率很低;分叉後的合併則取決於客戶端原型。
另外兩條議程:fselmo 要在第 101 次釐清 heze-devnet-2 的 blob 排程(執行層)與 slot 時長(共識層);eth2353 要在共識層分組會議再討論 beacon-APIs 第 627 號 PR(新增 produceBlockV4WithBid),理由是多節點驗證者客戶端(Vero、Vouch)與 DVT(Obol)需要,並願意標為實驗性。另外 consensus-specs 的版本號提交 v1.7.0-beta.5 10 月 9 日已合併,但 releases 列表最新仍是 v1.7.0-beta.4(10 月 8 日 19:27:03 UTC,預發布)。
行事曆:ACDT 第 101 次今天 10 月 19 日 14:00 UTC(台北 22:00);Frame Transaction 分組第 7 次 10 月 20 日;P2P 網路第 10 次 10 月 21 日;ACDE 第 248 次 10 月 22 日 14:00 UTC;ACDC 第 190 次 10 月 29 日 14:00 UTC,在 Hoodi 分叉之後。
六、Alpenglow:用鏈上區塊時間重算啟用時間
昨天我用 4 小時的效能取樣(每 slot 0.21745 秒)估 epoch 1064 的開始是 10 月 21 日約 13:48 UTC。今天改用一個更乾淨的資料:getBlockTime 回傳的是區塊本身的時間戳,所以每個 epoch 的第一個 slot(epoch 編號乘以 432,000)都能查到實際開始時間,相鄰兩個相減就是整個 epoch 的實際長度,不需要取樣。
| epoch | 實際長度(小時) | 每 slot 秒數 |
|---|---|---|
| 1048 到 1052 | 32.07 到 32.23 | 0.2672 到 0.2686 |
| 1053 | 26.195 | 0.21829 |
| 1054 | 26.202 | 0.21835 |
| 1055 | 26.231 | 0.21859 |
| 1056 | 26.214 | 0.21845 |
| 1057 | 26.032 | 0.21693 |
| 1058 | 25.962 | 0.21635 |
| 1059 | 25.933 | 0.21611 |
| 1060 | 26.039 | 0.21699 |
兩個階梯式變化:epoch 1053(起點 10 月 9 日 14:40:56 UTC)每 slot 時間從約 0.2685 秒降到約 0.2183 秒(降 18.7%);epoch 1057(起點 10 月 13 日 23:31:30 UTC)再降約 0.7%。我不知道原因,資料裡沒有任何說明,所以不下推論。對預測的意義是:昨天我說「slot 時間在未來 3.6 天會隨負載飄動」,實測顯示過去兩週的飄動主要是階梯,不是隨機噪音;近四個 epoch 的值落在 0.21611 到 0.21699 之間。另外,今天用鏈上時間算 24 小時平均:slot 458,212,143(昨天 23:04:15 UTC)到 slot 458,610,303(今天讀取時約 23:03:22 UTC),398,160 個 slot、86,347 秒,0.21687 秒;昨天 4 小時取樣的 0.21745 偏高了 0.27%。
今天 23:03:22 UTC 讀到 epoch 1061、slotIndex 258,303、absoluteSlot 458,610,303(驗算:1061 × 432,000 = 458,352,000,加 258,303 等於 458,610,303,成立)。epoch 1064 的第一個 slot 是 1064 × 432,000 = 459,648,000,還差 1,037,697 個 slot;移交的 slot 459,653,000(= 459,648,000 + 5,000)還差 1,042,697 個。
| 採用的每 slot 秒數 | epoch 1064 開始(UTC,10/21) | 移交 slot 459,653,000 |
|---|---|---|
| 0.21611(epoch 1059,最低) | 13:21 | 13:39 |
| 0.21686(24 小時平均) | 13:34 | 13:52 |
| 0.21699(epoch 1060) | 13:36 | 13:54 |
| 0.21845(epoch 1056,階梯前) | 約 14:01 | 約 14:19 |
官方的說法有兩個錨點:solana.com 的 Alpenglow 頁面寫「epoch 1064 在 10 月 21 日約 15:00 UTC 開始,於 slot 459,653,000 切換,約為 epoch 開始後 18 分鐘」;昨天引用的 SolanaCompass 說 Anza 稱「約 14:50 UTC」(若這是切換時間,epoch 開始約 14:32)。要對上 15:00 的 epoch 開始,平均每 slot 需要 0.22184 秒,比 epoch 1060 的 0.21699 高 2.2%,比階梯前的 0.21845 高 1.6%;要對上 14:50 的切換,需要 0.22020 秒。我量到近期沒有任何一個 epoch 到過這個數字。可能的解釋(都是推測):官方用較舊或較保守的 slot 時間;「約」字吸收了誤差;或官方預期啟用前網路會變慢。我不下結論,預測登記成區間:epoch 1064 的第一個 slot 時間落在 10 月 21 日 13:20 到 14:10 UTC 之間 75%;昨天的寬區間(13:30 到 15:30)90% 沿用。若實際落在 14:50 之後,表示我的外推方法失效,這會是比「對不對」更有資訊的結果。
其他官方細節(來自 solana.com 頁面與 Decrypt 10 月 14 日的報導):啟用需要 Agave 系客戶端(Agave、Jito-Solana 或 Harmonic Salsa)且基於 Agave 4.3.0;Firedancer 與 Frankendancer 在移轉期間不支援;每個投票帳戶要在免租金餘額之外多留 0.8 SOL,因為新的 Validator Admission Ticket(VAT)是每個 epoch 0.8 SOL、從投票帳戶扣、燒毀,而且提前一個 epoch 收:epoch 1064 開始時的第一筆付的是 epoch 1065 的參與資格,餘額不夠的驗證者下一個 epoch 不能投票或出塊。自算:以 0.21699 秒計,一天有 0.9217 個 epoch,VAT 約每天 0.737 SOL、每年約 269 SOL(假設 slot 時間與費用不變)。共識門檻方面,Decrypt 引述:第一輪 80% 以上質押立即最終確認,60% 到 80% 走第二輪;設計容忍 20% 惡意加 20% 離線;SIMD-0326 在 2025 年 9 月以 98.27% 的支持通過。我沒有查到最新的 Agave 4.3.x 質押比例,最近能找到的是 9 月初的 0.39%(6 個驗證者),那是 alpha 與 beta 階段,不能代表現在。
另一個可以自己驗證的數字:投票交易會離開區塊,所以對外顯示的 TPS 會大跌。我讀了今天 23:04 UTC 的效能取樣(217 筆、13,020 秒、59,859 個 slot),總交易 68,286,916 筆,其中非投票 28,513,659 筆,投票占 58.2%;總 TPS 約 5,245,非投票 TPS 約 2,190。如果其他條件不變,啟用後取樣中的 numTransactions 會接近 numNonVoteTransactions,對外 TPS 的數字會掉到約 2,190 左右,降幅 58%,而實際的使用者活動沒有變。這是自算與假設,實際要看啟用後的取樣。
七、安全事件:Cysic、Hacken 的第三季、Ledger 與 Gamdom
Cysic 橋接事件(10 月 17 日)。 Crypto Times 與其他多家報導一致的事實:10 月 17 日 12:31:38 UTC,攻擊者在 BNB Smart Chain 鑄造 10,000,000 個 CYS;Cysic 在 13:47:52 UTC 把接收地址加入合約黑名單,距鑄造 76.2 分鐘;黑名單生效前約 720 萬個(72%)已轉到其他地址;報導說攻擊者在 5 分鐘內賣出 720 萬個,換得 588,315 USDT 與約 220 BNB,再轉成約 306.6 ETH(約 72.7 萬美元)送到以太坊。Cysic 的初步說法是攻擊者取得橋接服務所用資料庫的未授權存取,並利用橋接處理邏輯的缺陷送出偽造的鑄造訊息,沒有動到既有使用者持有的 CYS,也沒有影響 Cysic 主網;並說「鑄造量本身不能決定美元損失」。這句話可以用數字檢查(自算):按報導的價格 0.1144 美元,10,000,000 個名目 114.4 萬美元,實際換得約 72.7 萬美元,是名目的 63.5%;720 萬個換 72.7 萬,平均約 0.101 美元,是報導價的 88%。這個比例有個前提:0.1144 是事發後的報價,事發當下的價格我沒查到;72.7 萬美元的換算與 ETH 價格有關,反推隱含 ETH 價格約 2,371 美元,只是一致性檢查,不是我另外查到的價格。對橋接設計的教學點(一般做法,不是 Cysic 專屬分析):鑄造權限若取決於「某個資料庫裡出現一筆訊息」,資料庫被入侵就等於偽造簽發權;常見緩解是對單位時間鑄造量設上限、鑄造量與鎖定抵押對帳、多方獨立證明。我沒有讀 Cysic 的原始公告,事後調查報告尚未公布。
Hacken 第三季報告。 CoinDesk 10 月 18 日報導 Hacken 的統計:第三季損失 11.8 億美元、107 起事件,比第二季多 55%;其中 9.068 億美元(自算 76.8%,報導稱 77%)與被入侵的供應商或開發工具、未及時安裝的安全修補、或不在審計範圍內的元件有關,Hacken 的結論是審計徽章會給人「全系統都被覆蓋」的錯覺。誠實聲明:我取得的幾份摘要對單一事件的金額不一致(例如 Bitget 有 3.52 億與 3.87 億兩種寫法,Tectonic 有「7,500 萬以上」與 1.2 億兩種),我沒有讀 Hacken 報告原文,所以只採用總額、事件數、增幅與 77% 這幾個多處一致的數字。
Ledger 與 MediaMarkt。 昨天寫的「Ledger 官方說所有已確認案例都追溯到 CryptoBilis」仍是官方立場。今天補的是另一條線:研究者 0xJohannes_ 說他在 MediaMarkt 的另一家分店買到第二台被改動的裝置,店內紀錄顯示貨源是歐洲經銷商 Aqipa GmbH,改動方式與 CryptoBilis 案相同(多出的線路與 LTE 模組、插在主板與螢幕連接器之間的軟性電路板);搜尋結果摘要稱 MediaMarktSaturn 已在歐洲門市與網店停售所有 Ledger 硬體錢包。Yahoo Tech 的報導說 Ledger 10 月 13 日的更新只點名 CryptoBilis,沒有提 MediaMarkt,並提到一名交易者透過該通路損失 660 萬美元的比特幣,Ledger 沒有披露受影響裝置總數或總損失,也沒有說明賠償。這些是研究者的主張與二手報導,我沒有讀 Ledger 官方原文,也沒有查到任何獨立的實驗室確認;Ledger 與 Aqipa、CryptoBilis 是否為同一批貨源,目前仍是未知。
Gamdom。 平台 10 月 13 日一小時內有超過 230 萬美元離開五條鏈上的熱錢包,兩小時後網站下線;創辦人稱損失略高於 300 萬美元,鏈上分析者 vxdb 計 420.8 萬美元(自算:是創辦人說法的 1.40 倍,兩者口徑不同,我沒有查出差異來源);網站 10 月 16 日 12:34 UTC 重新上線,以排行榜、20% 存款獎勵與 5 萬美元抽獎補償玩家;報導說截至目前沒有公布儲備地址或餘額快照。我把「10 月 23 日前公開儲備證明」從 25% 下調到 20%,理由是它選擇先用獎勵而不是證明恢復信任,屬弱證據。
🧠 記
- 期限後第 47 小時: 穩定版仍 7 個(共識層 4、執行層 3);缺席五個沒有任何新穩定版;距分叉 7.78 天。Grandine 出現
3.0.0-rc.1標籤但無 GitHub 發布。 - Lighthouse 的修正 PR: 第 10206 號(10/3 建立、10/6 關閉、10/15 重新開啟)只處理
-32601、-32604的退回;程式讀取顯示不帶 attributes 的 forkchoiceUpdated 取能力表最高版本、不看分叉、出錯不退回;-38005不在退回條件內是缺口推論,未實測。 - KM 重算: Lighthouse 條件機率 0.70 → 0.40 是風險集縮到 5 到 6 個點的稀疏尾端效應;其他三個 0.60 到 0.67。個別登記 Lighthouse 60%、Grandine 60%、Reth 55%、Erigon 60%、Geth 35%;至少 3 個 55%。
- 共識層: 第 5736 號 PR(builder 與驗證者存款分流)jtraglia 明說 Hoodi 不做、成功後再合併;第 5734 號 5.01 天、第 12513 號 3.44 天無更新。
- Alpenglow: 鏈上 epoch 長度 25.9 到 26.2 小時(epoch 1053 起從 32.2 小時階梯式降下);epoch 1064 估 10/21 13:21 到 14:01 UTC,官方約 15:00 需要每 slot 0.2218 秒;VAT 每 epoch 0.8 SOL(自算約 269 SOL/年);投票占交易 58.2%,啟用後對外 TPS 應掉到約 2,190。
- 安全事件: Cysic 鑄造 1,000 萬個 CYS、賣出 720 萬個、約 72.7 萬美元,黑名單遲了 76.2 分鐘;Hacken 第三季 11.8 億美元、77% 在審計範圍外;Ledger 與 Aqipa 的關係未知;Gamdom 無儲備證明。
邊界: GitHub 與 Solana RPC 資料是 10 月 18 日 23:00 到 23:05 UTC 的讀取結果。KM 估計只有 16 個事件加 4 個刪失,尾端只剩幾個點;個別機率是主觀混合,不是模型輸出。Lighthouse 與 Besu 的缺口是讀程式與發布說明的推論,沒有實測。Alpenglow 的預報假設近四個 epoch 的 slot 時間延續,而過去兩週出現過兩次階梯變化。Cysic、Hacken、Ledger、Gamdom 的內容來自二手報導與摘要,未讀原始公告與報告原文。這些內容是技術研究,不構成任何投資、質押、購買或節點營運建議。
✍️ 實踐
全部唯讀,約 30 分鐘。
- 重查五個缺席客戶端的最新發布與標籤,並看 Grandine 的 rc.1 有沒有變成發布(約 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/grandinetech/grandine/tags --jq '.[0:2][].name'
gh api repos/ethereum/go-ethereum/contents/params/chainspecs/hoodi.json --jq .content | base64 -d | grep -n -i amsterdam
gh api repos/sigp/lighthouse/pulls/10206 --jq '"\(.state) \(.updated_at) \(.mergeable_state)"'- 自己讀 Lighthouse 的版本選擇邏輯(約 8 分鐘):
gh api "repos/sigp/lighthouse/contents/beacon_node/execution_layer/src/engine_api/http.rs?ref=release-v8.3.0" --jq .content | base64 -d > /tmp/lh_http.rs
grep -n "pub async fn forkchoice_updated(" /tmp/lh_http.rs找到那個函式後,畫一張表:有無 payload attributes、各自選哪個版本、出錯怎麼辦;再讀第 10206 號 PR 的差異,指出它的退回條件包含哪些錯誤碼、不包含哪些。
- 用區塊時間算 epoch 長度並預報 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":"getBlockTime","params":[458352000]}'
curl -s https://api.mainnet-beta.solana.com -X POST -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getBlockTime","params":[458784000]}'第二、三個呼叫是 epoch 1061 與 1062 的第一個 slot(1061 × 432,000 與 1062 × 432,000;epoch 1062 要等到 10 月 19 日 09:30 UTC 左右才有資料,在那之前會回傳空值)。相減得 epoch 1061 的實際長度,再用 (1064 × 432000 − absoluteSlot) × 每 slot 秒數 預報,與官方時間比。
-
重做 KM,並看「風險集縮小」的效果(約 6 分鐘):用第四節的 16 個事件與 4 個刪失年齡,自己建立生存曲線;把 Lighthouse 的年齡設成 5.76 與 6.76 各算一次到 10/22 的條件機率,數一數兩次的風險集各有幾個點。
-
計算投票交易占比(約 3 分鐘):對
getRecentPerformanceSamples的結果加總numTransactions與numNonVoteTransactions,算 1 − 非投票 ÷ 總數;10 月 21 日啟用後再算一次,看是否接近 0。 -
想一想:如果 Lighthouse 發出的 v8.3.0 只修了
-32604的退回,而 Besu 26.10.0 在分叉前回的是-38005,營運者要用什麼檢查(不需要等分叉)才能確認自己的共識層與執行層配對在 Hoodi 分叉前能正常同步?
可證偽預測(新登記與調整;時間點都是 UTC;「穩定版」指非預發布的 GitHub 發布且含 Hoodi 排程提交):
- 預測一(10 月 22 日 14:00,ACDE 第 248 次開始前): Lighthouse 穩定版 60%(昨天 70%);Geth 穩定版 35%(昨天 40%);Geth 主分支
hoodi.json出現amsterdamTime: 179303656850%(昨天 55%);Grandine 60%、Reth 55%(昨天 60%)、Erigon 60%;缺席五個中至少 3 個 55%(昨天 60%)。 - 預測二(10 月 22 日 23:59): Lighthouse 第 10206 號 PR 合併、或第 10186 號議題關閉、或另有處理 forkchoiceUpdated 退回的 PR 合併進
unstable或release-v8.3.050%(昨天 55%)。 - 預測三(10 月 26 日 17:42:48): 缺席五個中至少 3 個已有穩定版 85%;Hoodi 分叉如期在 epoch 132352 啟用 90%;分叉後 10 個 epoch(約 64 分鐘)內最終確認出現 80%(沿用)。
- 預測四(10 月 21 日 23:59): epoch 1064 的第一個 slot 時間落在 13:20 到 14:10 之間 75%(昨天的 13:30 到 15:30 區間 90% 沿用);Votor 在 slot 459,653,000 接手、且與 epoch 開始相差 15 到 25 分鐘 80%(沿用);接手後的第一批完整效能取樣中,投票交易占比低於 5% 75%;之後 24 小時內沒有超過 1 小時的出塊停擺 80%(沿用)。
- 預測五: consensus-specs 第 5736 號 PR 在 10 月 26 日 17:42:48 前合併 8%,11 月 9 日 23:59 前合併 40%;第 5734 號 PR 10 月 23 日前合併 15%、EIP 第 12513 號 PR 10%(沿用)。
- 預測六(10 月 24 日 23:59): Ledger 官方公告受影響裝置數或確認損失總額其中之一 25%(沿用);Ledger 官方點名 CryptoBilis 以外的通路有遭改動裝置 20%(沿用);Ledger 官方文字出現 MediaMarkt 或 Aqipa 任一名稱 20%;有公開報導的逮捕或起訴 10%(沿用)。
- 預測七: Gamdom 10 月 23 日 23:59 前公開儲備證明或儲備地址 20%(昨天 25%);Cysic 10 月 25 日 23:59 前公布事後調查報告 50%、橋接恢復運作 25%。
- 沿用: 10 月 22 日 14:00 前官方明列主網日期 45%(若有,12 月 8 日約 70%)。
明天接的待辦:ACDT 第 101 次(今天 14:00 UTC)的紀錄、Geth 是否合併 Hoodi 排程、Lighthouse 第 10206 號 PR 是否有動靜、Grandine rc.1 是否變成發布、epoch 1062 開始後補量一個 epoch 長度、Cysic 與 Ledger 的官方更新。
🔗 延伸學習
- sigp/lighthouse 第 10206 號 PR:Fix fallback for unavailable forkchoice methods(GitHub) — 第三節的退回條件、測試與重新開啟的時間線。
- sigp/lighthouse 第 10186 號議題:Besu 26.9.0 的 forkchoiceUpdated 與 getBlobs 相容問題(GitHub) — 昨天的錯誤碼表與維護者留言,今天與 PR 對讀。
- ethereum/consensus-specs 第 5736 號 PR:Separate builder and validator deposits at the Gloas fork(GitHub) — 第五節的存款分流規則。
- ethereum/pm 第 2271 號議題:ACDT 第 101 次議程(GitHub) — heze-devnet-2、beacon-APIs 第 627 號與第 5736 號的議程留言。
- Alpenglow(solana.com) — 第六節的 epoch 1064、slot 459,653,000、VAT 與客戶端要求。
- Hacken report warns audit badges create false security as Q3 crypto losses hit $1.18B(CoinDesk,10 月 18 日) — 第七節的第三季總額、77% 與審計範圍。
- Cysic Bridge Hack(Crypto Times,10 月 19 日) — 時間線、金額與 Cysic 的初步說法。
- Buyer Reports Second Tampered Ledger From MediaMarkt, Calls for Recall(The Defiant) — 第二台被改動裝置與 Aqipa 的說法。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 在 Hoodi 測試網的客戶端就緒度,並同時追蹤 Solana 的 Alpenglow 啟用(查證時間 2026-10-18 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 後 47 小時,含 Hoodi 時間戳的穩定版仍是 7 個(共識層 Lodestar、Teku、Nimbus、Prysm;執行層 Besu、Nethermind、Ethrex);缺席 Lighthouse、Grandine、Reth、Erigon(已合併排程,合併後 5.31 到 6.76 天)與 Geth(未合併、hoodi.json 無 amsterdamTime)。
2. Lighthouse release-v8.3.0 分支 http.rs 的 forkchoice_updated:帶 payload attributes 時依 attributes 版本呼叫對應版本;不帶時從 engine_exchangeCapabilities 的宣告由高到低挑 V5、V4、V3、V2、V1 第一個有的,不看分叉、出錯不退回。第 10206 號 PR(+215、-17,1 個提交,狀態 open,10/6 關閉、10/15 重新開啟)讓不帶 attributes 的呼叫在遇到 -32601 或 -32604 時退回較低版本,不含 -38005,也不含 getBlobsV4。Besu 26.10.0 聲稱在沒有 Amsterdam 的網路上、有分叉檢查的 Amsterdam 方法回 -38005 而不是 -32604。
3. 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 天),刪失為四個缺席客戶端目前年齡(6.76、5.55、6.20、5.31 天)。Lighthouse 到 10/22 14:00 的條件機率從昨天的 0.70 變成今天的 0.40。
4. Solana:getBlockTime 取得 epoch 1053 到 1060 的實際長度 25.93 到 26.23 小時(每 slot 0.2161 到 0.2186 秒),epoch 1048 到 1052 為 32.07 到 32.23 小時(約 0.268 秒);epoch 1061、slotIndex 258303、absoluteSlot 458610303;到 epoch 1064 還需 1,037,697 個 slot;我估 10/21 13:21 到 14:01 UTC 開始,solana.com 寫約 15:00 UTC,對應每 slot 需 0.2218 秒。
5. 效能取樣 217 筆:總交易 68,286,916、非投票 28,513,659,投票占 58.2%;VAT 每 epoch 0.8 SOL(約 269 SOL/年,假設 slot 時間不變)。
6. Cysic:10/17 12:31:38 UTC 鑄造 10,000,000 CYS,13:47:52 UTC 加黑名單,賣出約 720 萬個、換得 588,315 USDT 與約 220 BNB、約 72.7 萬美元;報導價 0.1144 美元,實際約為名目的 63.5%。Hacken 第三季 11.8 億美元、107 起、其中 9.068 億美元(76.8%)在審計範圍外。
請幫我:
(a) 檢查我讀 Lighthouse 版本選擇邏輯的結論,並說明 Besu 26.10.0 在 Amsterdam 前宣告 V4 或 V5、而 Lighthouse 挑最高版本時,-38005 是否會讓第 10206 號 PR 的退回失效;也請說明 Engine API 規格對「沒有 payload attributes 的 forkchoiceUpdated」是否要求做分叉檢查;
(b) 解釋 Kaplan-Meier 的條件機率為何可能隨等待時間下降(風險集縮小的稀疏尾端),並建議更穩健的做法(例如把期限當時變共變數、分開估計、區間報告、對尾端做平滑);
(c) 驗算 Solana 的 slot 算術(1,037,697 個 slot、epoch 長度、每 slot 秒數、5,000 個 slot 的時間),並說明 epoch 1053 起每 slot 時間從約 0.268 秒降到約 0.218 秒可能的原因,以及我估的 13:21 到 14:01 UTC 與官方約 15:00 UTC 的差距可能來自哪裡;
(d) 說明橋接合約的鑄造權限若依賴鏈下資料庫訊息會有什麼風險,以及常見的緩解設計(鑄造上限、抵押對帳、多方證明);
(e) 分三類標示每個結論:「規格或文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,查不到就說查不到。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押、購買或節點營運建議。