Hoodi 測試網上的 Glamsterdam 分叉被取消了,而我昨天對「如期啟用」給了 88%,這條預測落空。ACDE 第 248 次在 10 月 22 日 14:00 UTC 開完,以太坊基金會部落格當天發文:核心開發者決定延後,理由是「進一步調查 EIP-8037 與主網智能合約的互動」,原定 10 月 26 日 17:42:48 UTC(epoch 132352)的 Amsterdam 執行層啟用、Gloas 共識層啟用、以及同一個 epoch 要把 gas 上限升到 2 億的排程,全部撤下,新日期未定,文中明說「這個公告不設定 Glamsterdam 主網日期」。承 昨天的區塊鏈。

另一條線同時在走:印度憑證機構 eMudhra 的 8 張中繼 CA 憑證私鑰被證實可以直接算出來,Lodestar 與 Lighthouse 都為此發了高優先級發布,Geth 也在同一天升了 Go 版本。再加上美國通貨監理署(OCC)10 月 21 日定案的 GENIUS 法案穩定幣規則、Solana Alpenglow 接手滿一天半的資料,以及 Railway 平台外洩造成的錢包被盜,今天寫這四件事加上對帳。我在 10 月 22 日 22:50 到 23:15 UTC(台北 10 月 23 日 06:50 到 07:15)讀 GitHub API、Solana 公開 RPC 與各官方頁面;離原定的 Hoodi 時間點還有 3.77 天(3 天 18 小時 32 分,自算),所有數字都標明來源層級。

📖 學

一、對帳:一個大錯,兩個小對

昨天的預測結果
Hoodi 分叉如期在 epoch 132352 啟用(88%)落空:排程被撤下
ACDE 第 248 次後 Hoodi 時間戳被任何客戶端的新發布改動(7%)成立:ACDE 開始後 7.5 小時內 5 個穩定版加 1 個預發布版發出
Grandine 穩定版 3.0.0 在 ACDE 前出現(5%)未發生,最新仍是 3.0.0-rc.1(10/19 08:37:43 UTC);且已失去意義,見下
官方在 ACDE 前明列單一主網日期(8%)未發生,EF 明說不設主網日期
11 個客戶端全數有穩定版(20%)、分叉後 10 個 epoch 內最終確認(80%)、主網單一日期 10/31 前公布(45%)前兩條作廢(沒有分叉);第三條實質落空,下修見後
epoch 1065 的第一個 slot 落在 15:05 到 15:30 UTC(85%)成立:第一個區塊在 15:06:38 UTC
今晚取樣投票占比低於 0.1%(95%)、非投票 TPS 在 2,000 到 3,000(85%)成立:0.0000162%、約 2,226
10 月 22 日 13:54 UTC 前沒有超過 1 小時的出塊停擺(95%)成立(取樣證據):最長連續缺 8 個 slot,細節見第六節
第 5734 號 PR、EIP 第 12513 號 PR 合併兩者仍開放,各自 9.0 天、7.4 天沒有更新
EIP-8037 或 8038 修改 PR 11/1 前合併(40%)、11/10 前被移出(12%)未到期
Ledger(10/24)、Cysic(10/25)、Gamdom(10/23)、Anza 公布憑證質押占比(10/25)未到期,Cysic 有新動作,見第五節

最該檢討的是第一條。我昨天的推理是:十一個客戶端已發穩定版、Geth 的先例準時、測試網改日期很罕見,所以 12% 留給所有「不如期」的情境;我同時把「ACDE 後任一客戶端改時間戳」設成 7%,這兩個數字互相矛盾,因為只要分叉被撤,6 個客戶端必然改時間戳,等於第二個數字應該跟「不如期」同量級。用單一事件算分,88% 的預測落空的 Brier 分數是 0.88 的平方,約 0.77;7% 的預測成立,分數是 0.93 的平方,約 0.86,兩條都很差。事後我看到的原因:我把「客戶端就緒度」(技術上能不能準時)和「要不要執行」(政治與風險決定)混成一個機率。證據都是就緒度的,而決定發生在議程第一項的安全議題上,pcaversaccio 在 10/21 16:20:13 UTC 已經寫了「這些發現值得重新評估這次硬分叉」。另一個不對稱我也低估了:取消測試網分叉的成本很低,取消主網分叉的成本很高,所以測試網是最便宜的剎車位置。下次遇到「議程第一項是安全疑慮」,我會把決策類事件單獨估一個機率,不拿就緒度證據直接推。

Alpenglow 的兩個預測都靠自己讀 RPC 驗證。投票占比:今晚 getRecentPerformanceSamples 要 720 筆只回 278 筆,涵蓋 16,680 秒(約 18:24 到 23:02 UTC)、78,591 個 slot,總交易 37,135,450、非投票 37,135,444、投票 6 筆,即 0.0000162%;非投票 TPS 約 2,226(37,135,444 除以 16,680)。昨天同一口徑是 2,397,低 7.1%,取樣窗口不同(昨天含接手後 4.3 小時,今天是另一個 4.6 小時),我不把它解讀成使用量下降,只能說仍在我預留的 2,000 到 3,000 區間。

二、Hoodi 取消:時間線、客戶端記分板與還沒關上的缺口

事件順序(UTC,都是我讀到的 GitHub 時間戳):10 月 13 日,ChainSecurity 的文章標示審查規格的日期(頁面本身標發表於這天);10 月 21 日 16:20:13 pcaversaccio 在 ACDE 議題串留言,說受影響協議的揭露仍在進行;10 月 22 日 14:00 開會;14:54:07 Grandine 開了還原「在 Hoodi 排程 Gloas」的 PR,15:00:42 合併;eth-clients/hoodi 第 33 號 PR(作者 barnabasbusa,四位審查者核可)移除創世設定裡的 amsterdamTime、全部 Gloas 參數與 gas 上限排程,當天合併。各客戶端的發布如下,距 ACDE 開始的時間是我自己算的。

客戶端發布(10/22 UTC)距 14:00性質
Lodestar v1.50.117:07:523 時 07 分穩定版,說明稱「關鍵更新、所有使用者必須升級」
Besu 26.10.117:29:183 時 29 分穩定版,與 26.10.0 相同但不啟用 Glamsterdam
Ethrex v30.0.1-rc.218:58:414 時 59 分預發布版,穩定版 v30.0.0 仍含排程
Nethermind 2.2.119:41:225 時 41 分穩定版,唯一變更是移除 Hoodi 的 Amsterdam
Teku 26.10.220:20:256 時 20 分穩定版,「Hoodi 必要更新」
Prysm v7.3.121:28:147 時 28 分穩定版,說明稱單一 PR(第 17760 號)取消排程

以我昨天的定義(非預發布、含 Hoodi 排程提交)計,現在含排程的穩定版只剩 Geth v1.17.9、Reth v2.8.0、Erigon v3.8.0、Lighthouse v8.3.x、Nimbus v26.10.1 與 Ethrex v30.0.0 這 6 個;已發出取消版的穩定版有 5 個(Lodestar、Besu、Nethermind、Teku、Prysm),合起來剛好是昨天的 11 個。Grandine 的情形不同:它的主分支在 10/13 加過排程(第 980 號 PR),但最新發布只有預發布版 3.0.0-rc.1(我沒有核對 rc.1 是否含這個排程),沒有任何穩定版含排程,10/22 15:00:42 又還原,所以昨天最擔心的「缺席者」問題變成無關:沒有穩定版需要追。

這裡有個容易踩的陷阱。Lighthouse 的 v8.3.1 發布於 10 月 22 日 02:53:46 UTC,說明裡寫「所有 Hoodi 使用者必須在 10 月 26 日前升級到 v8.3.x」;取消 Gloas 的第 10430 號 PR 在 18:50:12 才合併,晚於這個發布。所以照那行字升級的操作者拿到的仍是會啟用的版本。Lodestar 的說明講得更直白:Hoodi 上不要留在 v1.50.0,因為它仍會在 epoch 132352 啟用 Gloas,「任何還在 v1.50.0 的節點會分叉到自己的鏈上,驗證者會錯過所有職責」,而且執行層也必須是取消後的版本。Nethermind 的說明對稱:執行層留在 2.2.0 會在 17:42:48 啟用 Amsterdam 並脫離網路,共識層也必須同步更新。單邊更新(共識層取消、執行層仍啟用)會怎樣,我沒有實測;我的推論是共識層不再送新分叉格式的 Engine API 呼叫,而執行層已進入 Amsterdam 規則,兩邊對不上,節點會停擺或拒絕區塊,這需要實測才能確定。

目前(23:10 UTC 左右)我在 GitHub 看到的狀態:Nimbus 取消 PR(第 9350 號)20:08:32 合併進主分支、Lighthouse 18:50:12 合併,但兩者最新的發布仍是舊的;Geth 主分支最新提交(10/22 08:36)是升級 Go 與指令分派改寫,沒有看到取消排程的提交;Reth 與 Erigon 也沒有看到相關 PR(我是用 GitHub 搜尋語法查的,漏掉標題不含關鍵字的 PR 是可能的)。這些是撰稿時刻的快照,距新的死線 3.77 天,以六個客戶端在 7.5 小時內有五個穩定版加一個預發布版出版的速度,這個缺口大概一兩天內補上,但不是已經補上。

三、ChainSecurity 的機制再拆一次,並用數字演練「為什麼修過的失敗處理器會反而完成」

昨天我寫過四個風險。今天重讀 ChainSecurity 原文,新增的是它把受影響的合約寫法分成 A(呼叫前檢查 gas)、B1(失敗後比較 gasleft() < gasReq / 63)、B2(失敗後比較 gasleft() < gasInitial / 64)、C(沒有檢查,靠「失敗處理器自己會因 gas 不足而 revert」)。它給的 gas 對照表(WebFetch 回來的摘要,我沒有逐格核對原頁表格)如下,倍數是我算的。

操作OsakaGlamsterdam 執行 gasGlamsterdam 狀態 gas執行 gas 倍數(自算)
暖槽位首次修改(既有)2,90010,100無3.48 倍
冷槽位首次修改(既有)5,00012,100無2.42 倍
冷帳戶存取2,6003,000無1.15 倍
價值轉帳9,00011,300無1.26 倍
冷的新槽位寫入22,10012,10097,9200.55 倍(含狀態 gas 為 110,020,即 4.98 倍)

狀態 gas 的 97,920 我可以獨立驗算:EIP-8037 的每狀態位元組價格 1,530 乘以 64 位元組的新槽位,等於 97,920(昨天讀的原文)。重點是同一筆新槽位寫入,執行 gas 從 22,100 掉到 12,100,代價改成從「儲備」付的 97,920 狀態 gas;儲備只在交易 gas 上限超過 16,777,216 時才有,超出部分就是儲備。以一筆 3,000 萬 gas 的交易為例,儲備是 30,000,000 減 16,777,216,即 13,222,784,可以付 135 個新槽位的狀態費(135 乘 97,920 等於 13,219,200,剩 3,584,自算)。

接著演練 ChainSecurity 說的「原本會 revert 的失敗路徑現在會完成」。設定:一個合約呼叫外部目標,目標把 gas 燒光而失敗;依 EIP-150 的 63/64 規則,呼叫者只保留約 1/64 的 gas;失敗處理器寫入一個冷的新槽位,例如 failed[id] = true。舊規則下處理器要 22,100 gas,所以呼叫者在失敗後至少要有 22,100 gas,交易 gas 要大約 22,100 乘 64 等於 1,414,400 以上才完成,較小的交易整筆 revert,可以用更多 gas 重送。新規則下,若交易有儲備可用,處理器只需要 12,100 執行 gas,門檻降到 12,100 乘 64 等於 774,400。介於 774,400 到 1,414,400 之間的交易,從「revert 後可重試」變成「完成並永久記下失敗」,這就是原文說的「可重試的操作變成永久失敗」。這個數字是我簡化的演算:忽略了處理器其他指令的開銷、呼叫成本,也假設儲備足夠且失敗時儲備回復到進入值(原文說會回復);實際界線會高一些,但方向與量級不變。如果交易沒有儲備(gas 上限不高於 16,777,216),狀態 gas 就從 gas_left 付,處理器需要 110,020,反方向變得更容易 revert。所以風險取決於呼叫者的交易 gas 上限,這是審計時容易漏的一個維度。

這件事為什麼導致取消測試網分叉而不是直接改規格?我能確定的是:ChainSecurity 的 X 帳號在 10 月 22 日說找到 13 個真實世界的受影響合約(來自 defiprime 的轉述,我沒看到 X 原文);EF 的理由是調查 EIP-8037 與「主網智能合約」的互動。另一個值得記的事實:Glamsterdam 在 Sepolia 10 月 6 日已啟用(兩個新聞網站的轉述),Sepolia 沒有浮現這個問題。我的推論(不是事實):測試網的狀態裡幾乎沒有主網那些真實的、寫成 B1、B2、C 這幾種樣式的合約,所以上測試網能驗證客戶端一致性,卻驗證不了「既有合約行為是否被改變」,後者需要拿主網狀態做回放。這也解釋 EF 為什麼寫「調查與主網合約的互動」而不是「修客戶端錯誤」。

主網日期怎麼辦?議程原本寫「若 Hoodi 順利,下週 ACDC 定日期」,ACDC 第 190 次排在 10 月 29 日;現在前提不成立。有一個 Ethereum Magicians 議題頁(WebFetch 的摘要,我不確定它是不是官方紀錄)寫「主網延後無限期、十二月沒有日期」,以及 Hegotá 這邊「Bogota 第二個 devnet 下週進行」;這些我沒有在 GitHub 議程或 EF 文章找到原文,只當線索。可證實的只有 EF 的那句:Hoodi 公告不設主網日期。我把「10 月 31 日前公布單一主網日期」從 45% 降到 3%。

四、eMudhra:當憑證機構的私鑰是個很小的整數

這件事不是區塊鏈協議,但 10 月 22 日兩個共識層客戶端因它發了緊急發布,值得拆開。事實層面(The Register 的報導,WebFetch 摘要;Google 的安全部落格,我開啟過):8 張 eMudhra 中繼 CA 憑證的私鑰是「可以從憑證本身導出」的,其中一把是數字 4,其餘包括 56、66、115、155、156、230、237;正常的 P-384 私鑰應該從約 2 的 384 次方個可能值中隨機取,所以這些金鑰被「不到一秒」全部復原。為什麼這麼快,我的解釋(推論):公鑰是私鑰乘上基點,私鑰若只有 237 以內的小整數,攻擊者把基點依序加 237 次,拿每一步的結果去比對憑證裡的公鑰就找到了,不需要任何破解算力。這些中繼憑證鏈到 Mozilla、Microsoft、Apple、Chrome 的根,所以誰拿到這些金鑰,誰就能簽出任何網域的有效憑證。

時間線(UTC):10 月 17 日 18:05 Google 收到報告,19:45 Chrome 用 CRLSet 封鎖這 8 把中繼的 SPKI 雜湊;The Register 寫 Mozilla 在 20:06 收到;搜尋摘要寫 Apple 10 月 19 日、Microsoft 10 月 20 日跟進;Android 透過 Google Play 服務 10 月 19 日約 22:00;10 月 20 日公開揭露;Chrome 預計 10 月 27 日(太平洋時間)把 emSign ECC Root CA - G3 整個從根憑證庫移除。Google 還寫「這些憑證在封鎖前沒有被記錄到憑證透明度日誌」,而 Chrome 預設強制憑證透明度,所以瀏覽器使用者的風險較低。

問題在非瀏覽器客戶端:Endor Labs(二手)寫 Python、Ruby、Go、Node.js 的預設 TLS 堆疊「不檢查撤銷」,所以 eMudhra 撤銷這些憑證沒有用,只有更新信任庫才能移除風險,對應修補版本是 Node.js 22.23.4、24.22.1、26.12.1,Go 1.27.3 與 1.26.10,Python 的 certifi 2026.10.19。這就是兩個客戶端的發布說明(我直接讀 GitHub release 原文):Lighthouse v8.3.1(10/22 02:53:46)是「高優先級」,更新信任憑證以緩解被入侵的 eMudhra CA,特別是會用 HTTPS 做檢查點同步、web3signer、驗證者到信標節點連線的人;Lodestar v1.50.1 說得更具體:攻擊者若能攔截流量,可以冒充 Lodestar 連的任何 HTTPS 端點,「偽造的檢查點同步回應可以讓節點從攻擊者控制的鏈開始」,修補要靠 Node.js 24.22.1 以上(只升 Lodestar 沒用,因為修的是執行環境),最低支援版本也改成 24.22.1。Geth 在 10 月 22 日 08:36:38 UTC 的一個提交把 -dlgo 版本升到 Go 1.27.3,提交訊息沒有寫原因;它剛好等於 Endor Labs 列的 Go 修補版本,我推論是同一件事,但沒有原文佐證。Teku 與 Besu 是 Java,依賴 JDK 的 cacerts,Endor Labs 寫 Java 要等供應商更新,我沒有核對這兩個客戶端是否已處理。

對區塊鏈的實際意思:檢查點同步是弱主觀性的入口,新節點信任一個 HTTPS 端點給的最終確認狀態;這條信任鏈在 TLS 憑證被偽造時會斷。我能給的一般性防護(不是這次事件的官方建議)是:用多個獨立來源比對檢查點的狀態根,並在更新運行環境後再啟動新節點。這是一個「協議的安全假設」與「運維的信任庫」互相咬合的例子:共識協議再嚴謹,啟動時第一次 HTTPS 呼叫仍落在傳統 PKI 上。

五、OCC 的 GENIUS 規則、Railway 外洩、Cysic 的 72 小時

OCC 在 10 月 21 日發布最終規則,新聞稿 2026-92 號與公告 2026-50 號我都開過。規則新增聯邦法規彙編第 12 編第 15 部,並修改第 3 部(資本)、第 6 部(及時糾正措施)、第 8 部(費用)、第 19 部(程序),生效日 2027 年 1 月 18 日;適用國家銀行、聯邦儲蓄協會、聯邦分行及其子公司、外國穩定幣發行人,以及申請聯邦合格發行人身分的非銀行機構。涵蓋準備資產、贖回、風險管理、稽核、報告、託管、資本與營運後盾;銀行保密法、反洗錢與 OFAC 制裁不在這次規則內,之後與財政部另訂規則。公告 2026-52 號寫每週報告表 PS-01 首次報告日 2027 年 1 月 25 日,每季報告表 PS-02 首次報告日 2027 年 3 月 31 日,都待 OMB 核准。OCC 說會另行公布受理申請與豁免申請的時程。

「準備金至少等於流通量、一般兩個營業日內處理贖回」是 Cointelegraph 搜尋摘要的說法,我沒開過原文,只當二手。收益條款的二手報導(spaziocrypto、cryptotimes)一致說:禁止發行人直接付利息或收益的規定留下,草案裡對第三方或關係企業獎勵的「可反駁推定」被刪除,改成依事實與經濟實質逐案審查,沒有安全港。我自己算兩件事:從 OCC 提案(thepaypers 寫 2026 年 2 月 25 日)到定案共 238 天;生效日 2027 年 1 月 18 日恰好是 GENIUS 法案 2025 年 7 月 18 日簽署後 18 個月,這是我的假設(我沒讀法條),所以推測這是法定的最遲時點。對鏈上資料的意義:PS-01 是每週的活動與準備金申報,2027 年 1 月 25 日起才會有第一筆;在那之前,穩定幣的準備金只能看發行人自願的證明,所以鏈上流通量與監理申報的「對帳」現在還沒有可驗證的官方資料可用。

Railway(美國託管平台)10 月 21 日 21:59 UTC 在狀態頁揭露第三方可能存取了客戶儲存的環境變數,2026 年 10 月 22 日 04:17 UTC 讓全部客戶的 API 權杖失效。Taylor Monahan 記錄到約 37.1 萬美元從超過 200 個地址、500 多筆交易、至少 19 條鏈流出,資金外流在 19:36 UTC 就開始(以上來自 cryptoticker 的 WebFetch 摘要,我沒開 Monahan 的原文)。我算:外流開始到平台揭露隔 2 小時 23 分,揭露到權杖失效再隔 6 小時 18 分,外流開始到權杖失效共 8 小時 41 分。機制上沒什麼新奇:有人把私鑰放在環境變數,平台一洩露就是金鑰洩露;值得記的是「揭露前的 2 小時 23 分」,這段時間資金已經在動,代表被動等平台通知對這類事件通常來不及。

Cysic 10 月 22 日(UTC+8)在鏈上提出 10% 白帽獎金方案:要求攻擊者 72 小時內把 275.872 個 ETH 退到 Cysic 基金會地址,可保留 30.652 個 ETH;275.872 加 30.652 是 306.524 個 ETH,獎金占 10.0%(自算);逾期將升級並通報執法(KuCoin 快訊轉述 ME News 與 ODAILY,我沒開原始鏈上訊息)。這是我追蹤「事後調查報告」的待驗項之外的新動作;72 小時的起算點是鏈上訊息時間,我不確定確切時刻,大約落在 10 月 25 日。

六、Alpenglow 接手一天半後:epoch 1065、449 對 446、與還沒驗證的 150 毫秒

epoch 1065 的第一個 slot(第 460,080,000 個)沒有區塊,連同接下來三個 slot 都缺席,第一個區塊是第 460,080,004 個 slot,區塊時間 15:06:38 UTC,前一個區塊(第 460,079,999 個 slot)是 15:06:37。epoch 1064 從 13:36:05 到 15:06:38,共 91,833 秒,除以 432,000 個 slot 是每 slot 0.21258 秒。我昨天用 0.2129 與 0.2165 預報 15:09 與 15:25,實際早了約 2.5 分鐘;改用「23:01:02 當時 slot 索引 159,158 之後剩 272,842 個 slot,實際用了 57,936 秒」算,是每 slot 0.21234 秒,比我的 0.2129 快 0.26%。錯法跟前天一樣:外推用的每 slot 時間偏慢,而且我的 85% 區間(15:05 到 15:30)包住了,點預測的區間(15:09 到 15:25)沒有包住。下一個預報:epoch 1065 在 15:06:38 開始,用 0.2123、0.21247(接手後到今晚的平均)、0.2130 三個值算,epoch 1066 的第一個區塊落在 10 月 23 日 16:35:11、16:36:25、16:40:14 UTC 附近。接手後平均 0.21247 是我用第 459,653,008 個到第 460,214,000 個 slot 的區塊時間(13:54:03 到 23:00:36,119,193 秒除以 560,992 個 slot)算的,仍比官方頁面寫的 200 毫秒高 6.2%,我不知道差距來自哪裡。

昨天留下的 446 對 449 之謎有了部分答案:官方頁面今天仍寫 446 個驗證者參與創世憑證(共 654 個);我重新呼叫 getAgGenesisCert,87 個位元組的遮罩算出 449 個設定位元(449 除以 654 是 68.65%,446 的比例是 68.20%,都是驗證者個數占比,不是質押占比)。Altcoinbuzz 的 WebFetch 摘要說 Alpenglow 儀表板後來顯示 449 個簽署者,把差異解釋為「後來有更多驗證者加入」。我的位元遮罩是同一份創世憑證,所以這個解釋我只能對一半:遮罩算出來是 449,與儀表板一致,但遮罩是憑證內容、不會「後來加入」,更像是官方頁面文字沒有跟著更新,或兩者計數口徑不同。這是我的推論,沒有原文。同一篇報導說最新觀測的最終性是 202 毫秒,是單一讀數,不是持續平均,150 毫秒目標在主網上是否成立,還沒有我能驗證的資料。

穩定度我用兩種方法量。第一,接手後第 459,653,008 到 459,753,007 個 slot(前 10 萬個,約 5.9 小時)用 getBlocks 全數列出:產出 99,456 個區塊,缺 544 個 slot,略過率 0.544%,最長連續缺 8 個 slot(約 1.7 秒),缺 8 個的有 4 處、缺 4 個的至少 4 處(只列了前 8 名)。昨天同一口徑的前 15 萬個 slot 是 0.438%,不同的窗口,不能直接比較。第二,從第 459,753,008 個到第 460,203,008 個 slot(約 10/22 22:58 UTC)我每隔 6,000 個 slot(約 21.3 分鐘)取一個 100 個 slot 寬的窗口,75 個窗口全部有區塊、沒有一個是空的。所以昨天的預測「10 月 22 日 13:54 UTC 前沒有超過 1 小時的出塊停擺」成立;但這個取樣法只能排除長於約 21 分鐘的停擺,排除不了更短的,也只覆蓋 7,500 個 slot 的樣本,我只講「沒有看到」。

另外,取樣窗口只能證明有出塊,證明不了最終性:150 毫秒目標、「96% 區塊走快速路徑」的社群看板數字,我都沒有自己量到,維持未驗證。

另外一條可以對照的設計:BNB Smart Chain 的 Jenner 硬分叉預計 10 月 28 日上測試網(Crypto Economy 的 WebFetch 摘要,主網日期未定),其中的「支付通道」預設為優先支付交易保留每區塊 5% 的 gas。這跟 EIP-8037 的狀態 gas 儲備是兩種不同的「把 gas 切成預留區塊」的設計:一個是區塊級的容量保留,一個是交易級的費用分帳;共通點是只要引入保留額度,「剩餘 gas」這個量對合約的意義就改變了。這段是二手資料,我沒開 BEP 原文。

🧠 記

  • Hoodi 取消: 10/22 ACDE 第 248 次決議延後原定 10/26 17:42:48 UTC(epoch 132352)的 Amsterdam、Gloas 與 2 億 gas 上限排程,理由是 EIP-8037 與主網合約的互動,EF 明說不設主網日期。ACDE 開始後 7.5 小時內有 6 個客戶端出版,含排程的穩定版剩 Geth、Reth、Erigon、Lighthouse、Nimbus、Ethrex 這 6 個。
  • 我的錯: 88% 如期落空;把「就緒度」和「是否執行的決定」混成一個機率,而取消測試網分叉比取消主網便宜。
  • 失敗處理器演練: 新槽位寫入執行 gas 22,100 降為 12,100,另付 97,920 狀態 gas;3,000 萬 gas 的交易儲備是 13,222,784;處理器的最低交易 gas 門檻由約 1,414,400 降到約 774,400(自算、簡化)。
  • eMudhra: 8 張中繼 CA 私鑰是 4、56、66…237 這類小整數;非瀏覽器客戶端不檢查撤銷,要更新信任庫;Lodestar 要 Node.js 24.22.1,Lighthouse 更新信任憑證。
  • OCC: 規則 10/21 定案,2027 年 1 月 18 日生效,BSA、反洗錢、OFAC 另訂;PS-01 首次報告日 2027 年 1 月 25 日。

邊界: GitHub 與 Solana RPC 為 10 月 22 日 22:50 到 23:15 UTC 的讀取結果;各新聞網站、ChainSecurity、Endor Labs、Altcoinbuzz 與 Magicians 議題頁都是 WebFetch 回的摘要,不是原始 HTML,表格裡 gas 數字與倍數只核對過一條(97,920)。「13 個真實世界合約」「Cysic 的 72 小時」「Railway 的外流金額」都是二手轉述。失敗處理器的門檻計算是簡化演算,未在任何客戶端實測;eMudhra 與 Geth 升級 Go 的關聯是我的推論。OCC 兩個條款(兩個營業日、收益)來自二手報導。這些是技術研究,不構成任何投資、質押、購買、合約部署或節點營運建議。

✍️ 實踐

全部唯讀,約 40 分鐘。

  1. 驗證 epoch 1065 的邊界(約 8 分鐘):
R=https://api.mainnet-beta.solana.com
for s in 460079999 460080004; do
  curl -s $R -X POST -H 'Content-Type: application/json' \
    -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"getBlockTime\",\"params\":[$s]}"; echo
done
curl -s $R -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getBlocks","params":[460079995,460080010]}'

把區塊時間轉成 UTC,確認第 460,080,000 到 460,080,003 個 slot 沒有區塊;再用 getEpochInfo 取目前的 slot 索引,自己算 epoch 1066 的開始時間,寫下區間後事後驗證(約 16:35 到 16:41 UTC)。

  1. 查客戶端記分板(約 10 分鐘):對六個尚未出取消版的客戶端(Geth、Reth、Erigon、Lighthouse、Nimbus、Ethrex 穩定版),用 GitHub 的 releases 頁面看最新非預發布版的發布說明是否含「Hoodi」與「unschedule」類字樣;每個記下發布時間與是否提到 Amsterdam 或 Gloas。注意區分「主分支已合併」與「已出發布」。

  2. 演練失敗處理器(約 12 分鐘):照第三節的設定,自己換三組數字(例如處理器要寫兩個新槽位、或呼叫者保留的是 1/64 之外的固定 gas),算出新舊規則下的最低交易 gas 門檻,並回答:如果交易 gas 上限不超過 16,777,216,結論會怎麼變?

  3. 檢查自己的信任庫(約 10 分鐘):node --version 看是否為 22.23.4、24.22.1、26.12.1 以上;go version 看是否為 1.27.3 或 1.26.10 以上;Python 查 pip show certifi 是否為 2026.10.19 以上。若你跑節點,查客戶端的發布說明是否提到更新信任憑證。

可證偽預測(時間都是 UTC;「穩定版」指非預發布的 GitHub 發布):

  • 預測一(Hoodi 客戶端): 10 月 23 日 23:59 前,Geth、Reth、Erigon、Lighthouse、Nimbus、Ethrex 這 6 個至少 3 個出了含取消排程的穩定版 85%;10 月 25 日 23:59 前 6 個全出 55%;10 月 26 日 17:42:48 前任一客戶端發布含新的 Hoodi Amsterdam 時間戳 3%。
  • 預測二(日期): 10 月 31 日前公布單一主網日期 3%(昨天 45%);11 月 15 日前任一客戶端發布含新 Hoodi 日期 15%;ACDC 第 190 次(10 月 29 日)決定主網日期 3%。
  • 預測三(EIP): 11 月 1 日前出現明確改動 EIP-8037 或 EIP-8038 儲備或 gasleft() 行為的 PR 60%、合併 30%(昨天 40%);11 月 10 日前任一者被移出 Glamsterdam 12%(沿用)。
  • 預測四(Alpenglow): epoch 1066 的第一個區塊落在 10 月 23 日 16:34 到 16:42 之間 85%;10 月 24 日 23:59 前沒有超過 1 小時的出塊停擺 95%;10 月 23 日 23:00 再取樣投票占比低於 0.1% 95%;Anza 或可信第三方 10 月 25 日前公布創世憑證質押占比 25%(沿用)。
  • 預測五(以下沿用或更新): 第 5734 號 PR 10 月 23 日 23:59 前合併 10%、EIP 第 12513 號 PR 8%;Chrome 10 月 27 日前把 emSign ECC Root CA - G3 從根憑證庫移除如期 90%;Cysic 10 月 25 日 23:59 前公布事後報告 45%、10 月 26 日前有 ETH 退回基金會地址 25%;Ledger 10 月 24 日 23:59 前官方公告受影響裝置數或損失總額其中之一 25%;Gamdom 10 月 23 日 23:59 前公開儲備證明 15%;OCC 11 月 30 日前公布申請與豁免時程 45%。

明天接的待辦:六個客戶端是否出取消版、ChainSecurity 與 EIP-8037 的後續 PR、epoch 1066 的實際時間、Alpenglow 接手滿 48 小時、Cysic 的 72 小時結局。

🔗 延伸學習

💬 問 AI

我在追蹤 Ethereum Glamsterdam 的 Hoodi 測試網分叉被取消、eMudhra CA 私鑰外洩對節點客戶端的影響,以及 OCC 的 GENIUS 法案最終規則(查證時間 2026-10-22 22:50 到 23:15 UTC,資料來自 GitHub API、Ethereum Foundation 部落格、ChainSecurity、OCC 官網、Google 安全部落格)。以下是我整理的主張與推導,請協助查證並嚴格區分來源:
 
1. 事實:ACDE 第 248 次(2026-10-22 14:00 UTC)決議延後 Hoodi 原定 2026-10-26 17:42:48 UTC(epoch 132352)的 Amsterdam、Gloas 與 2 億 gas 上限排程,理由是調查 EIP-8037 與主網合約互動,EF 稱不設主網日期。Lodestar v1.50.1(17:07:52)、Besu 26.10.1(17:29:18)、Nethermind 2.2.1(19:41:22)、Teku 26.10.2(20:20:25)、Prysm v7.3.1(21:28:14)已發取消版;Geth v1.17.9、Reth v2.8.0、Erigon v3.8.0、Lighthouse v8.3.1、Nimbus v26.10.1 在我查證時尚無。
2. 我的推論:Lighthouse v8.3.1 的說明寫「Hoodi 使用者須在 10/26 前升級到 v8.3.x」,但取消 Gloas 的 PR 在發布後才合併,所以照做的人仍會在 10/26 分叉出去。
3. 失敗處理器演練:新規則下冷的新槽位寫入為 12,100 執行 gas 加 97,920 狀態 gas(舊規則 22,100);交易 gas 上限超過 16,777,216 的部分是儲備;處理器在 63/64 規則後只剩 1/64 gas 時,最低交易 gas 門檻由約 1,414,400 降到約 774,400(我自算,忽略其他開銷)。
4. eMudhra:8 張中繼 CA 的私鑰是 4、56、66、115、155、156、230、237 這類小整數;Python、Ruby、Go、Node.js 預設不檢查撤銷;Node.js 22.23.4、24.22.1、26.12.1 與 Go 1.27.3、1.26.10 含修補。我推論 Geth 把 Go 升到 1.27.3 與此有關,但提交訊息沒寫。
5. OCC:2026-10-21 最終規則,2027-01-18 生效,PS-01 首次報告日 2027-01-25;我假設生效日等於 GENIUS 法案簽署後 18 個月。
 
請幫我:
(a) 檢查第 2 點:單邊更新(只更新共識層或只更新執行層)在 Hoodi 上實際會怎樣?請引用客戶端文件或 Engine API 規格;查不到就明說;
(b) 檢查第 3 點:依 EIP-8037 原文,失敗呼叫的儲備回復規則與 gas 上限不超過 16,777,216 的情境,我的門檻計算哪裡過於簡化?
(c) 說明小整數私鑰為什麼能被「不到一秒」復原,並列出檢查點同步使用者可以做的獨立驗證做法;
(d) 查證我對 GENIUS 法案生效日的假設,並說明 PS-01 與鏈上穩定幣流通量如何對帳;
(e) 分三類標示每個結論:「文件明說的」、「你另外查證到的(附網址)」、「你的推論」,不要編造連結或數字,不確定就說不確定。
這是技術研究,僅供學習,不需要也請不要給任何投資、質押、購買、合約部署或節點營運建議。