Hoodi 的 Glamsterdam 日期有了第一個具體提案:ethereum/pm 的 PR 2263 號在 10 月 7 日 14:50:24 UTC 開出,只改一行,把 glamsterdam-pm.md 裡 Hoodi 的 TBD 換成 epoch 132608、UTC 10 月 27 日 21:01:12。承 昨天的區塊鏈 的待辦,結果先列:ACDE 第 247 次會議還沒開(10 月 8 日 14:00 UTC,台北 22:00),所以 Hoodi 還沒有決議;昨天預測一(gas limit 在 03:00 UTC 落在 1.99 億到 2.00 億)對了,但「01:37 UTC 到頂」錯了,實際最晚 01:00 UTC 就到頂;Geth 仍沒有含 eth_call 修復的發布版;Erigon 與 Nethermind 的兩則問題單都還開著。查證時間約 10 月 7 日 23:00 UTC(台北 10 月 8 日 07:00),也就是 Sepolia 分叉後 33 小時 7 分。另外,我這次抓了 24 個連續區塊,把 gas limit 的「鋸齒」拆到整數,發現昨天沒解釋的 199,999,809 這類數字有簡單的算術來源。

📖 學

一、Hoodi 提案的數字:自己用創世時間算一遍

Hoodi 的創世時間是 1742213400,這是 Lodestar 的 /eth/v1/beacon/genesis 回傳的 genesis_time,也等於 eth-clients/hoodi 設定檔裡 MIN_GENESIS_TIME 1742212800 加 GENESIS_DELAY 600。信標鏈的換算很機械:起始槽位等於 epoch 乘 32,UTC 時間等於創世時間加槽位乘 12。PR 的檔案變更(patch)給的是這一列:

項目數值我的驗算
epoch132608132608 × 32 = 4,243,456(與 PR 的起始槽位相同)
Unix17931348721,742,213,400 + 4,243,456 × 12 = 1,793,134,872(吻合)
UTC2026-10-27(週二)21:01:12換算吻合;台北為 10 月 28 日(週三)05:01:12

PR 內文還有一列「another option」,epoch 132352、起始槽位 4235264、UTC 10 月 26 日(週一)17:42:48,但 Unix 欄寫的是 1793134872。這一列內部對不上:132352 × 32 = 4,235,264,往上算 Unix 是 1,742,213,400 + 4,235,264 × 12 = 1,793,036,568,正是 10 月 26 日 17:42:48,不是 1793134872(那是 132608 的值)。我用兩次獨立讀取確認內文都是這樣,應該是複製時沒改 Unix 欄。它只出現在 PR 內文,不在合併後會變成正式檔案的 patch,所以無害,但這說明提案表格不能只看 UTC 那欄,要自己用 epoch 回推 Unix。

兩個選項相差整整 256 個 epoch:256 × 32 × 12 = 98,304 秒,27 小時 18 分 24 秒。256 的倍數不是巧合。我讀到的設定檔裡,Sepolia 從 Capella 起的所有分叉 epoch 都是 256 的倍數(56832、132608、222464、272640、353024 分別是 256 的 222、518、869、1065、1379 倍),Hoodi 的 Fulu 是 50688(198 倍)。我沒有找到規格明文要求,只能說「我看到的都是」。順帶一個容易混淆的巧合:Sepolia 的 Deneb 分叉 epoch 恰好也是 132608,與 Hoodi 提案的 epoch 同一個數字,但是不同網路的不同分叉。

距離 Sepolia 的間隔:選項一(10 月 26 日)是 20 天 3 小時 49 分 12 秒,選項二(10 月 27 日)是 21 天 7 小時 7 分 36 秒。對照 Sepolia 自己:Geth v1.17.6(含 Sepolia 分叉時間戳 1791294816)在 9 月 23 日發布,距 10 月 6 日分叉 13 天。如果 Hoodi 用同樣的提前量,含 Hoodi 時間戳的客戶端版本大約要在 10 月 13 到 14 日出現,而 ACDT 第 100 次排在 10 月 12 日 14:00 UTC(ethereum/pm 第 2264 號 issue,10 月 7 日 15:19 UTC 建立,議程尚為 TBD)。這是類比推算,不是已公布的時程。

目前 Hoodi 的設定檔(eth-clients/hoodi 主分支的 metadata/config.yaml)只有到 Fulu:FULU_FORK_EPOCH: 50688,blob 排程是 epoch 52480 上限 15、epoch 54016 上限 21,沒有任何 Gloas 欄位。也就是說 Hoodi 的 Glamsterdam 設定還沒進到網路設定庫,PR 2263 只是把日期放進協調用的計畫檔。該 PR 在我查證時 0 則留言、狀態 open、mergeable_state 為 clean。

ACDE 第 247 次的議程(ethereum/pm 第 2234 號 issue,9 月 26 日建立,10 月 6 日 12:18 UTC 最後更新)只有三行:Glamsterdam、Hegotá、雜項。issue 內有三則人工留言:Ben Adams 想把 EIP-7907 放進 Hegotá 的 PFI/CFI 討論(根據 JumpDest 基準測試)、Lukasz Rozmej 提議一項他在 ACDC 沒輪到的加速案(我只讀到摘要,沒有細節),第三則是玩笑。Hoodi 日期應該落在「Glamsterdam」那一行下討論,議程沒有單獨列出。

二、昨天預測一的驗證:時間錯了,數值對了

昨天預測一的條件是:03:00 UTC 的 gas limit 落在 1.99 億到 2.00 億,整段期間沒有任何區塊超過 2 億。我抽了 20 個間隔不等的槽位,再抓連續 24 個槽位(共 44 個區塊),每個區塊都取 signed_execution_payload_bid.message.gas_limit:

時間(UTC)槽位gas limit備註
10-06 23:19:0011299595158,181,145昨天的最後一筆
00:10:0011299850175,926,188
00:40:0011300000192,449,925
01:00:0011300100200,000,000已到頂
01:20:0011300200200,000,000
01:37:0011300285198,828,524昨天預測到頂的時間點,反而低 117 萬
03:00:0011300700200,000,000預測一的驗證時間
06:00:0011301600199,999,428
15:20:0011304400199,999,809
23:00:0011306700200,000,000

結論分三塊。第一,數值:03:00 UTC 為 200,000,000,落在預測區間,44 個區塊沒有任何一個高於 2 億,最低是 198,828,524(低於 2 億 0.59%)。但我不是全掃 01:30 到 03:00 的每個區塊,所以「整段沒有超過」只能說「抽樣未被推翻」,不能說已證實。第二,時間:昨天推算要 690 個槽位到頂(01:37 UTC),實際在 11299595 之後最多 505 個槽位(01:00 UTC)就到了,從分叉到到頂不超過 3,332 個槽位,即 11 小時 6 分 24 秒。這是我的平均速率偏慢。第三,速率:11299595 到 11299850 的 255 個槽位,每槽成長約 0.0417%,相當於每槽淨 0.427 個滿步(昨天的平均是 0.362);11299850 到 11300000 的 150 個槽位每槽約 0.0598%,淨 0.613 個滿步。以昨天的上推 67.8%、下拉 31.6% 估計,每槽淨步的標準差約 0.93,150 個槽位的標準誤約 0.076,0.613 比 0.362 高 3.3 個標準誤,255 個槽位那一段只高 1.1 個標準誤。換句話說第二段的速度不太像單純的運氣,但我只有兩端的值,看不到那段時間哪些提案者在推,所以不歸因(可能是提案者組成變了,也可能是我的樣本不夠)。

三、鋸齒的算術:為什麼是 199,999,809

昨天我預測到頂後會在 2 億附近鋸齒,今天的連續 24 個槽位把鋸齒拆開了。規則是相鄰區塊的 gas limit 差必須小於父區塊的 1/1024(取整),實測每一步都是「父區塊除以 1024、取整、減 1」或碰到 2 億就被截斷。逐步驗算:

  • 200,000,000 除以 1024 取整是 195,312,減 1 為 195,311。往下一步:200,000,000 − 195,311 = 199,804,689,與槽位 11306652 吻合。
  • 199,804,689 除以 1024 取整是 195,121,減 1 為 195,120。往上一步:199,804,689 + 195,120 = 199,999,809,與槽位 11306653 吻合。
  • 下一個往下一步是 199,999,809 − 195,311 = 199,804,498(槽位 11306654),再往上 199,804,498 + 195,120 = 199,999,618(槽位 11306655),再往上被截在 200,000,000(加 382,槽位 11306656)。

關鍵是「往下與往上的步長不同」:因為步長是父區塊的函數,從 2 億往下走 195,311,從 199,804,689 往上走 195,120,差 191。一次「下一上」的循環回不到原點,每圈少 191;兩圈少 382,三圈少約 572(槽位 11306668 的 199,999,428 就是 2 億減 572)。所以 199,999,809、199,999,618、199,999,428 不是某個客戶端設了奇怪的目標,而是下上循環的指紋;碰到上推的提案者時,若離 2 億不到一步,就被截回 2 億。這個算術同樣解釋了我昨天、今天抽樣裡出現的 199,804,498、199,804,499(差 1 是起點不同)與 199,609,569(兩步往下,194,930 是它的下一步上推)。

這 24 個槽位(11306650 到 11306673,全部有區塊)的完整紀錄如下。「自建」是 builder_index 為 UINT64_MAX、value 為 0 的自建出價;編號 1、3 是外部建構者。

槽位出價者gas limit與前一區塊差
113066501199,999,618(起點)
113066511200,000,000+382(截斷)
113066521199,804,689−195,311
11306653自建199,999,809+195,120
11306654自建199,804,498−195,311
11306655自建199,999,618+195,120
11306656自建200,000,000+382(截斷)
11306657自建200,000,0000
113066581200,000,0000
11306659自建200,000,0000
11306660自建200,000,0000
113066613200,000,0000
113066623200,000,0000
11306663自建199,804,689−195,311
11306664自建199,609,569−195,120
113066651199,804,499+194,930
11306666自建199,999,619+195,120
11306667自建199,804,308−195,311
113066681199,999,428+195,120
113066691200,000,000+572(截斷)
113066701199,804,689−195,311
11306671自建199,609,569−195,120
11306672自建199,804,499+194,930
113066733199,999,619+195,120

23 次相鄰變化的分類:往上 10 次(其中 3 次被截在 2 億)、往下 7 次、持平 6 次(全部在 2 億,碰頂的推升者沒得推)。「想往上」的區塊是上推加持平共 16 次(69.6%),往下 7 次(30.4%),與昨天 2,660 次的 67.8% 對 31.6% 幾乎一樣,可見到頂之後提案者的組成沒有變。所有 17 次非持平變化的幅度,逐一都等於「父區塊除以 1024 取整減 1」或截斷,沒有例外。

穩態可以估:若上推機率 p、下拉機率 q,到頂後的狀態是「在頂」、「低一步」、「低兩步」…,各狀態機率與 (q/p) 的次方成正比。取 p = 16/23、q = 7/23,q/p = 0.4375,在頂機率 1 − 0.4375 = 56%,平均低 0.4375 / (1 − 0.4375) = 0.78 步。實測:24 個連續槽位中 9 個在頂(37.5%),先前 17 個間隔抽樣中 10 個在頂(58.8%),合併 41 個有 19 個(46%),平均低 0.54 步。模型與實測同一個量級,但 41 個樣本彼此相關(連續區塊不獨立),不足以分辨 46% 與 56%。

四、ePBS 第二天:自建與外部建構者還是約五五對

同樣 24 個連續槽位:自建 13 個(54.2%)、外部建構者 11 個(45.8%),昨天首日 2,683 個區塊是 55.8% 對 44.2%。外部建構者只看到編號 1(8 個區塊)與編號 3(3 個區塊),昨天出現過的 0、2、4 號這 24 個槽位沒露面。編號 3 的三個出價 value 全是 0,也就是外部建構者出價但不付錢給提案者;編號 1 的 8 個出價都大於 0,從 57,314,944 到 88,899,571 Gwei(0.0573 到 0.0889 Sepolia ETH),中位數 62,413,340 Gwei(約 0.0624 ETH)。昨天首日外部出價 75.6% 大於零、中位數 21,816,880 Gwei,今天的 8 個正出價中位數是它的 2.9 倍,但只有 8 筆且全是同一個建構者,不能說行情變了。我沒有查規格是否允許外部建構者的 value 為 0,所以不判斷這三筆是設計內的行為還是測試用的出價。

昨天看的另一個指標是 EMPTY(新出價的 parent_block_hash 不等於上一個區塊出價的 block_hash)。這 24 個槽位有 23 組相鄰區塊,我逐一比對,23 組的父雜湊全部等於前一區塊雜湊,0 次 EMPTY。昨天首日的比例是 0.82%,23 組中預期出現 0.19 次,0 次的機率是 0.9918 的 23 次方約 83%,所以這個樣本無法驗證或推翻 0.82%。

五、昨天其他待辦的現況

待辦現況(約 10 月 7 日 23:00 UTC 查)
鏈健康頭部槽位 11306705 屬 epoch 353334,最終確認 epoch 353332,落後 2 個 epoch(最低值);距分叉 308 個 epoch,32 小時 51 分 12 秒
Geth 含 PR 35845 的發布否,最新仍是 v1.17.7(9 月 30 日);近期合併的 PR 沒有提到 Glamsterdam
Teku 發含 200M 排程的版本否,最新仍是 26.9.1(9 月 28 日)
Erigon 第 24620 號問題單仍 open,3 則留言,最後更新 10 月 6 日 14:42:56 UTC,標籤 Glamsterdam,沒有找到連結的修復 PR
Nethermind 第 14334 號問題單仍 open,0 則留言,最後更新 10 月 6 日 14:56:48 UTC;內文新提到處理時間「中位數高約 24%、平均高約 30%」(昨天寫的是掃描約 10.5 分鐘)
Hoodi 日期ethereum/pm 第 2263 號 PR 提案 10 月 27 日 21:01:12 UTC(選項為 26 日 17:42:48),待 ACDE 第 247 次

另外有兩個 10 月 6 日的相關 PR,只讀到內文,圖片本身沒看:eth-clients/sepolia 第 131 號與 eth-clients/hoodi 第 30 號(同一位作者 barnabasbusa,皆 open,只改一張時程圖)。內文說 Sepolia 到 2026 年底完整支援(含 Glamsterdam),長期支援階段移到 2027 年。測試網壽命的改動值得追:Hoodi 日期定下來之後,Sepolia 是應用開發者的主要測試網這件事也就有了明確的終點。

🧠 記

  • 提案表要用 epoch 回推。 Hoodi 提案的「另一選項」那列,UTC 與 epoch 對得上,Unix 欄卻是另一個 epoch 的值;兩個選項相差剛好 256 個 epoch(27 小時 18 分 24 秒)。
  • 預測的對錯要分開記。 數值預測(2 億附近)對了,時間預測(01:37 UTC 到頂)錯了,而且是估計速率偏慢造成,不是模型方向錯。
  • 鋸齒是整數除法的副作用。 步長取父區塊除以 1024 再減 1,往下一步與往上一步差 191,每個「下一上」循環少 191,所以 2 億下方會出現 199,999,809、199,999,618 這類數字,不需要有人設奇怪的目標。
  • ePBS 的組成比例跨兩天穩定。 自建約五五、外部約四五,但外部出價者集中在兩個編號,而且有 value 為 0 的外部出價。

邊界: 這是單一測試網兩天的資料。連續 24 個槽位只代表那 4.8 分鐘,間隔抽樣 20 個槽位是點狀資料,兩者都不是全量掃描;「無區塊超過 2 億」只能說抽樣未被推翻。網頁內容是經抓取工具轉成摘要後再讀,所以我用算術交叉驗證:Hoodi 兩列的 Unix 以創世時間回推吻合,步長公式對 17 次非持平變化逐一吻合,這些在亂抄數字的情況下不可能全部對上。PR 2263 還沒有合併,ACDE 第 247 次的結果未知,不能把「提案」當成「已定案」。外部建構者出價 value 為 0 的原因我沒有查證。Lukasz Rozmej 的議程留言我只讀到摘要。

✍️ 實踐

用 25 分鐘重現,全是唯讀。

  1. 驗算 Hoodi 提案:下面這段 Python 把 epoch 換成 Unix 與 UTC,你應該得到 132608 對 1793134872(10 月 27 日 21:01:12)與 132352 對 1793036568(10 月 26 日 17:42:48)。
import datetime as d
genesis = 1742213400  # Hoodi genesis_time
for epoch in (132352, 132608):
    t = genesis + epoch * 32 * 12
    print(epoch, epoch * 32, t, d.datetime.fromtimestamp(t, d.timezone.utc))
  1. 重現鋸齒:對 https://lodestar-sepolia.chainsafe.io/eth/v2/beacon/blocks/{slot} 取連續 20 個槽位,讀 data.message.body.signed_execution_payload_bid.message.gas_limit。對每一對相鄰區塊檢查差是否等於「父區塊 // 1024 − 1」,或結果為 200,000,000。想看哪種差最常出現,就統計往上、往下、持平的比例,並分開記錄 builder_index 為 18446744073709551615 的自建區塊。
  2. 回頭查 PR 2263:ACDE 第 247 次結束後,看 ethereum/pm 的 glamsterdam-pm.md Hoodi 那列是否不再是 TBD,以及 PR 是否合併、用的是哪個 epoch。

可證偽預測,附驗證條件:

  • 預測一: PR 2263 在 10 月 9 日 23:59 UTC 前合併,且 Hoodi 欄位是 epoch 132608 或 132352 兩者之一。依據是 ACDC 第 188 次已提到「約 26 或 27 日」,現在有提案人且 mergeable_state 為 clean;風險是 ACDE 第 247 次討論後改到別的日期。驗證:glamsterdam-pm.md 當天的內容。
  • 預測二: 10 月 8 日(UTC)隨機抽 20 個區塊,至少 15 個的 gas limit 落在 1.98 億到 2.00 億,且沒有一個高於 2 億。依據是 44 個樣本全落在 198,828,524 以上。若有任何一個超過 2 億,表示有提案者設了更高的目標,模型要修。
  • 預測三: Geth 在 10 月 10 日 UTC 前沒有發出含 PR 35845 的標籤(與昨天預測三相反,因為近期合併的 PR 都與 Glamsterdam 無關,最新發布仍是 9 月 30 日的 v1.17.7;風險是它們隨時可以趕在 Hoodi 之前出補丁版)。驗證:gh api repos/ethereum/go-ethereum/releases/latest --jq .tag_name。

明天接的待辦:ACDE 第 247 次的決議、Hoodi 的設定檔 PR 是否出現、Teku 與 Geth 是否發版、Erigon 24620 與 Nethermind 14334 的修復、ePBS 外部建構者占比在第三天是否仍約四五到五成。

🔗 延伸學習

💬 問 AI

我在追蹤 Ethereum Glamsterdam 的測試網部署。以下是我自己查到的事實(查證時間 2026-10-07 約 23:00 UTC),請協助查證並嚴格區分來源:
 
1. ethereum/pm 的 PR 2263(2026-10-07 14:50:24 UTC,nixorokish)提案 Hoodi 的 Glamsterdam 於 epoch 132608、Unix 1793134872(2026-10-27 21:01:12 UTC);內文另列選項 epoch 132352(2026-10-26 17:42:48 UTC),但該列 Unix 欄仍寫 1793134872。Hoodi 創世時間 1742213400。
2. Sepolia 在 2026-10-06 13:53:36 UTC(epoch 353024)分叉;分叉後 gas limit 從 6000 萬升到 2 億,11 小時內到頂。連續 24 個區塊的相鄰變化,每一步都等於「父區塊 // 1024 − 1」或被截在 2 億,例如 200,000,000 → 199,804,689(−195,311)→ 199,999,809(+195,120)。
3. 24 個連續區塊中 13 個自建、11 個外部建構者出價(編號 1 與 3);編號 3 的三個出價 value 為 0。23 組相鄰區塊的 parent_block_hash 全等於前一區塊 block_hash。
 
請幫我:
(a) 用 Hoodi 創世時間與 32 × 12 秒換算,驗證兩個選項的 Unix 與 UTC 是否正確,並指出表格哪一格有錯;
(b) 查 consensus-specs 的 gloas 規格,說明外部建構者的出價 value 是否允許為 0,以及 value 為 0 時提案者與建構者的支付流程;
(c) 解釋為什麼 gas limit 步長是「父區塊 // 1024 − 1」而非「父區塊 // 1024」,並用我的數字算一次「下一上」循環為何少 191;
(d) 回答時請分成三類標示:「文件或來源明說的」、「你另外查證到的(附網址)」、「你的推論」,不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。