Sepolia 的 Glamsterdam 升級在 2026-10-06 13:53:36 UTC 準時啟用,共識層 epoch 353024、槽位 11296768 是第一個 Gloas 區塊,我查證的時間是 10 月 6 日 23:19 UTC(台北 10 月 7 日 07:19),升級後 9 小時 25 分鐘。承 昨天的區塊鏈 的待辦,結果先列:鏈有繼續最終確認(查到最終確認 epoch 為 353108,距分叉 84 個 epoch);gas limit 從分叉時的 6000 萬爬到 1.58 億;Teku 沒有發含 200M 排程的新版;Hoodi 日期還沒定;eth_call 的 16.76M 問題有了結論,Geth 在升級後 56 分 51 秒把修復合進 master,但還沒有發布版。另外鏈上資料也讓我看到 ePBS(提案者與建構者分離)上線第一天的實際分布,以及三個客戶端在分叉後冒出的問題。
📖 學
一、分叉發生了:怎麼確認、看到什麼
我用公開的信標節點 API 直接問鏈。/eth/v1/beacon/states/head/fork 回傳 previous_version 為 0x90000075(Fulu)、current_version 為 0x90000076(Gloas)、epoch 為 353024。再取分叉前後兩個區塊:槽位 11296767 的版本是 fulu,區塊本體帶完整的 execution_payload,gas limit 6000 萬、用掉 59,990,877(99.98%);槽位 11296768 的版本是 gloas,區塊本體沒有 execution_payload,換成 signed_execution_payload_bid 與 payload_attestations。這就是 ePBS 的外觀:信標區塊只承諾「這個槽位的執行內容會是哪個 block_hash、誰來出價」,真正的交易內容之後以獨立的信封(envelope)送出。
幾個可以自己核對的小數字。分叉的 Unix 時間 1791294816 等於 Sepolia 創世時間 1655733600 加上 11296768 乘以 12,兩邊完全吻合,Nethermind 的問題單裡寫的執行層轉換時間戳 0x6ac4fd60 換成十進位也正是 1791294816。執行層區塊標頭也變了:公開節點回傳的最新區塊有 blockAccessListHash 與 slotNumber 兩個新欄位,slotNumber 為 11299595,和當時的信標槽位一致。
自建區塊(沒有外部建構者)的出價有固定樣子,規格寫得很死:builder_index 取 UINT64_MAX(BUILDER_INDEX_SELF_BUILD),value 必須是 0,簽名必須是 BLS 的無窮遠點。我在第一個 Gloas 區塊看到的簽名是 0xc000…0000,就是無窮遠點的壓縮編碼,builder_index 是 18446744073709551615。
二、gas limit 的爬升:實測比例是 67.8% 往上、31.6% 往下
昨天我說「推 200M 的提案者占比 p 查不到」。今天不必查客戶端占比,因為區塊本身就是結果:每個區塊的出價都帶 gas_limit,我把槽位 11296768 到 11299540 的 2,773 個槽位逐一抓下來(2,683 個區塊、90 個空槽,共 9 小時 14 分鐘),看相鄰區塊的變化。
規則是每個區塊的 gas limit 與父區塊的差必須小於父區塊的 1/1024。我驗證了這個上限:60,000,000 除以 1024 取整為 58,593,再減 1 得 58,592,第一個非零變化正是 60,000,000 到 60,058,592;下一步 60,058,592 除以 1024 取整減 1 為 58,649,實際是 60,117,241,差 58,649。也就是說步幅是「父區塊除以 1024、取整、減 1」,而且每一步都踩滿。
扣掉前後兩個區塊對不上(中間有空槽或上一槽 payload 沒到)的情形,我得到 2,660 次相鄰變化:1,804 次往上(67.8%)、841 次往下(31.6%)、15 次持平。我逐一檢查,2,660 次變化的幅度全部恰好等於「父區塊除以 1024、取整、減 1」,沒有半步,也就是每個提案者不是推滿就是拉滿(持平的 15 次是變化為零)。每個區塊的淨變化是 (1,804 減 841) 除以 2,660 約 0.362 個滿步,再乘上每步約 0.0976% 並計入 3.2% 的空槽,預期每槽對數成長約 0.034%,和我直接用首尾算的 0.0339% 相符。這是個自洽檢查,不是新資訊,但它說明了模型是對的:往上的區塊是目標值高於當前值的提案者(含 200M 排程的版本),往下的區塊是目標值低於當前值的提案者(例如仍用 6000 萬預設的設定)。我無法從區塊判斷各自是哪個客戶端,所以不做歸因。
| 時間(UTC) | 槽位 | gas limit | 相對 6000 萬 |
|---|---|---|---|
| 13:53:36(分叉) | 11296768 | 60,000,000 | 1.000 |
| 14:53:36 | 11297068 | 64,551,747 | 1.076 |
| 16:53:36 | 11297668 | 78,377,079 | 1.306 |
| 18:53:36 | 11298268 | 94,883,894 | 1.581 |
| 20:53:36 | 11298868 | 117,361,322 | 1.956 |
| 22:53:36 | 11299468 | 149,625,855 | 2.494 |
| 23:19:00(最新) | 11299595 | 158,181,145 | 2.636 |
推算到 2 億:ln(2 億 除以 1.5818 億) 約 0.2345,除以每槽 0.034% 約 690 個槽位,約 2 小時 18 分,落在 10 月 7 日 01:37 UTC(台北 09:37)前後。到頂之後我預期不會繼續升:200M 目標的提案者碰到上限就持平,31% 往下的區塊會把它拉低約千分之一,下一個往上的區塊再推回,所以會在 2 億附近鋸齒。這是依 EIP-8261「預設與建議上限同值」做的推論,前提是沒有任何提案者手動設更高的目標。
三、ePBS 第一天:自建與外部建構者各占一半
在同一份 2,683 個區塊的資料裡,自建 1,496 個(55.8%),外部建構者 1,187 個;外部建構者的編號只有 0 到 4 五個,其中 0 號 467 個、1 號 357 個、3 號 175 個、2 號 166 個、4 號 22 個。分叉後第一個 epoch(32 個槽位)的 24 個區塊全是自建,第一個外部建構者的出價出現在槽位 11296877,距分叉 109 個槽位(21 分 48 秒),0 號建構者、出價 27,065,724 Gwei(約 0.0271 Sepolia ETH,value 單位依規格是 Gwei)。最近 600 個槽位的自建占比是 49.7%,所以已經從 100% 降到一半左右。1,187 個外部出價裡 898 個大於零(75.6%),中位數 21,816,880 Gwei(約 0.0218 ETH),最大 146,935,864 Gwei(約 0.147 ETH)。
對照 ACDT 第 99 次的說法:Barnabas 說升級前不會讓建構者進場,因為 Sepolia 的存款合約只收 Sepolia 專用代幣,建構者要在分叉後用一般 Sepolia ETH 存款。鏈上看到的和這個說法一致,但我看不到存款是什麼時候發生的,所以不能說「3.4 個 epoch 是存款到啟用的時間」。同一場會議裡 Lighthouse 提到分叉前有個「提案偏好沒有正確發布」的問題,最壞情況是第一個 epoch 自建;我的資料 24 比 24 全是自建,和這個說法相容,但也和「當時還沒有建構者上線」相容,無法分辨。
第二個 ePBS 專屬的數字是「上一槽的 payload 有沒有送到」。規格的判斷寫在 process_parent_execution_payload:新區塊出價的 parent_block_hash 若不等於上一個區塊出價的 block_hash,就視為父區塊是 EMPTY,不會有執行請求。照這個定義我數 2,682 次相鄰區塊,22 次為 EMPTY(0.82%),全部發生在「父區塊是自建」之後(22 比 1,496,1.5%),父區塊是外部建構者的 1,186 次為 0。我一開始抓資料時有 22 個槽位因為網路錯誤失敗,會讓這個數字虛高成 38,補抓之後才修正;統計時務必先排除抓取失敗再比對。0 比 22 這種小樣本的差異我不下結論,只能說這一天自建區塊比較常沒有把 payload 送到。
四、分叉後冒出的三件事(都是一手 issue)
Erigon 的 24620 號問題單(10 月 6 日 14:28 UTC 開,仍開啟)是最完整的一則:驗證者 340 跑 Erigon 的 Caplin,分叉後出現「wrong head block」而無法出塊。留言裡的分析(問題單作者與另一位留言者各一則,我只引用有日誌佐證的部分):信標節點的 fork choice 在 14:17 重啟後被重新錨定在檢查點,而執行層已經執行到更後面的區塊,要求建構的父區塊落後 26 個區塊;節點在約 14:31 自行恢復。我核對鏈上,日誌裡的槽位 11296885、11296916 確實都是空槽。同一則留言還提到第二件事:恢復後槽位 11296978 的區塊被孤立,原因是資料欄(column)還沒到,節點在 EMPTY 父區塊上建構,而下一槽(11296979)建在 FULL 父區塊上。我核對:槽位 11296978 不在標準鏈上,槽位 11296979 出價的 parent_block_hash 等於槽位 11296977 的 block_hash(0xc2c4f13c…),吻合。至於「槽位 11296979 是 Nimbus 出的」我無法從區塊判斷,照引用。
Nethermind 的 14334 號問題單(10 月 6 日 14:51 UTC,0 則留言):已同步的節點在分叉後重新進入區塊存取清單(BAL)同步,從樞紐點 11,856,360 附近一路掃到區塊 1,在 fork-sp-lighthouse 上花了約 10.5 分鐘,期間區塊處理變慢。根因是設定 AncientBlockAccessListsBarrierCalc 取 max(1, …),而預設的屏障值是 0,所以下界永遠是 1,而不是分叉區塊。Prysm 的 PR 17632 則是修 Gloas 下的回填(backfill),操作方式是在 Sepolia 加 --backfill。三則都是分叉後約 6 小時內開的,類型很一致:不是共識分歧,而是同步、重啟與回填這類「不在共識測試裡」的路徑。
五、eth_call 的結論:不是改 EIP,是改 API 規格,Geth 先修
ACDT 第 99 次的逐字稿(自動轉錄,有誤字,例如把 Glamsterdam 轉成「Glastonbury」,我只採用語意明確的部分)裡,議程提出者說明這不是共識變更,Geth 的 eth_call 套用了與交易相同的 16M 執行 gas 上限,而唯讀合約(鏈上 SVG 渲染、報價器、聚合器)在舊行為下沒有這個限制。Marius 的意見是這件事應該寫進 execution-apis 規格庫,因為那是 API 的正本;議程提出者的結論是回到 Ethereum Magicians 說明「會隨 execution API 的發布修正」。另一位開發者問到若解除上限,gas 要放進哪一個計數器,答案是全部放進執行 gas,因為它可同時被狀態操作與純運算使用。
Geth 的實際修復是 PR 35845(2026-09-30 06:34:53 UTC 開,是 wighawag 在 issue 35838 開單後 19 小時 41 分),2026-10-06 14:50:27 UTC 合併,距分叉 56 分 51 秒,距開 PR 6 天 8 小時 15 分,8 個檔案、加 278 行刪 27 行。做法和 wighawag 當初猜的「SkipTransactionChecks 沒檢查」不一樣:Geth 把訊息上原本兩個公開旗標(SkipNonceChecks、SkipTransactionChecks)改成四個,skipNonceCheck、skipEOACheck、skipGasLimitCapCheck,以及新增的 skipExecutionGasCap;後者讓 initRuntimeGasBudget 在 Amsterdam 之後不再把執行 gas 切在 MaxTxGas,全部留給執行,涵蓋 eth_call、追蹤與模擬。Geth 的發布頁最新標籤仍是 v1.17.7(9 月 30 日),所以這個修復目前只在 master。Reth 這邊 10 月 1 日合併的 PR 27633 方向相反(加上限);會議上點名 Reth 與 Erigon 時沒有人出席,所以這兩家對新方向還沒有表態。execution-apis 我搜到的相關 PR 與這題無關(都是其他方法的規格),沒有找到對應的修改。
六、實驗:昨天的預測,對上了
昨天我把一個實驗留給「升級之後」:用狀態覆寫塞一段只回傳剩餘 gas 的合約碼,送 eth_call,請求的 gas 為 5,000 萬。今天我送到兩個公開 Sepolia 端點,兩者的最新區塊相同(11859036、gas limit 156,951,378,且都有 blockAccessListHash)。PublicNode 的 web3_clientVersion 是 Geth/v1.17.7-stable,回傳 16,762,214。推算:2 的 24 次方 16,777,216 減 EIP-2780 之後的基本 gas 15,000,再減合約碼裡 GAS 指令本身的 2,得 16,762,214,逐位吻合。昨天我寫的是「接近 1,676 萬」,方向和量級對,但少算了 GAS 指令自己的 2,今天補上。
另一個端點 1rpc.io 的版本字串是 sentio-super-node,回傳 49,978,998,也就是 50,000,000 減 21,000 再減 2,沒有 16.76M 的切分,而且基本 gas 是 21,000 而不是 15,000。它是什麼客戶端、為什麼是 21,000,我沒有證據,也無法判斷這個差異是「還沒套用 EIP-2780」還是其他實作選擇;我只能說同一條鏈、同一個區塊高度,兩個公開端點對同一個呼叫給出完全不同的答案,正好印證 Geth 發布版(v1.17.7)確實還有昨天描述的限制。
七、昨天待辦逐項
| 待辦 | 結果 | 查證時間與出處 |
|---|---|---|
| 升級準時啟用 | 是,epoch 353024、版本 0x90000076 | 信標 API,23:01 UTC |
| 最終確認 | 是,最終確認 epoch 353108(23:19 UTC) | 信標 API |
| gas limit 朝 200M 爬 | 是,6000 萬到 1.58 億,預計 01:37 UTC 前後到頂 | 逐區塊,見上表 |
| Teku 發含排程的版本 | 否,最新發布仍是 26.9.1(9 月 28 日);會議上 Teku 說不會在 Sepolia 前發版 | GitHub 發布頁 + ACDT 第 99 次 |
| Hoodi 日期 | 未定,計畫檔仍是 TBD;ACDC 第 188 次說約 10 月 26 或 27 日,等 Sepolia 順利後在 ACDE 第 247 次(10 月 8 日 14:00 UTC)討論 | ethereum/pm、逐字稿 |
ACDT 第 99 次紀錄與 eth_call 結論 | 有,見上節 | nixorokish/eth-protocol-transcripts |
| Geth 對 issue 35838 的回應 | 10 月 6 日 14:50:28 UTC 關閉,對應 PR 35845;0 則留言 | GitHub |
🧠 記
- 鏈本身是最好的資料來源。 昨天我為了估提案者占比查客戶端,查不到;今天直接量區塊的上下步,67.8% 對 31.6% 就是答案,而且能預測 2 小時後的值。
- ePBS 的新失敗模式是「EMPTY 父區塊」。 它不是共識錯誤,而是下一個提案者在「上一槽的內容沒到」時選擇建在哪裡;Erigon 的孤立區塊就是這個選擇的後果,以及 22 次 EMPTY 全來自自建區塊的統計。
- 共識測試不到的路徑會在第一天出事。 三則問題單都是同步、重啟、回填,不是出塊規則。
- 統計要先清資料。 抓取失敗的 22 個槽位把 EMPTY 次數從 22 灌成 38,補抓才對。
邊界: 這是單一測試網 9 小時的資料,Sepolia 的客戶端組合與 mainnet 不同,67.8% 不能外推;上下步比例我無法歸因到客戶端。EMPTY 的 0 比 22 是小樣本,22 次的原因沒有逐一查,Erigon 的案例只是其中一個可能。ACDT 的逐字稿是機器轉錄,我只採用語意清楚的句子,「Geth 說修好了」這類轉述的人名以 PR 作者為準。公開 RPC 端點的版本與設定我控制不了,1rpc 的結果沒有解釋。eth_call 在 Geth 的修復只在 master,實際上線時間要看發布。
✍️ 實踐
用 25 分鐘重現三件事,全是唯讀。
- 確認分叉:
curl -s https://lodestar-sepolia.chainsafe.io/eth/v1/beacon/states/head/fork,看current_version是否為0x90000076、epoch是否為 353024;再用/eth/v2/beacon/blocks/11296767與/eth/v2/beacon/blocks/11296768比對version與本體欄位。 - 量 gas limit:對
/eth/v2/beacon/blocks/{slot}每隔 300 個槽位取一次,讀data.message.body.signed_execution_payload_bid.message.gas_limit,對照上表。想算上下步比例,就把連續槽位都抓下來,只比較parent_block_hash等於前一個區塊block_hash的相鄰對,並且把 HTTP 404(空槽)與網路錯誤分開處理。 - 重做
eth_call:對 PublicNode 與你自己的節點送下面的請求。
curl -s -X POST -H 'content-type: application/json' https://ethereum-sepolia-rpc.publicnode.com --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x00000000000000000000000000000000000000aa","gas":"0x2faf080"},"latest",{"0x00000000000000000000000000000000000000aa":{"code":"0x5a60005260206000f3"}}]}'回傳的十六進位換成十進位,Geth v1.17.7 預期為 16,762,214;自己編譯 master(含 PR 35845)後預期接近 4,998 萬(5,000 萬減去基本 gas 15,000 與 GAS 指令的 2,約 49,984,998;基本 gas 依節點實作而定,我沒有實測 master,這個數字是推算)。
可證偽預測,附驗證條件:
- 預測一: Sepolia 的 gas limit 在 10 月 7 日 03:00 UTC(台北 11:00)落在 1.99 億到 2.00 億之間,且整段期間沒有任何區塊超過 200,000,000。若超過,表示有提案者手動設了更高的目標;若 03:00 UTC 仍低於 1.9 億,表示上推占比下降,我的模型要修。驗證:取當時的區塊,並掃 01:30 到 03:00 UTC 的區塊最大值。
- 預測二: ACDE 第 247 次紀錄會出現 Hoodi 的日期,落在 10 月 26 日到 28 日。依據是 ACDC 第 188 次主持人說的「約 26 或 27 日,等 Sepolia 順利後討論」,但他自己也說記不清楚,所以只是押注。驗證:ethereum/pm 的計畫檔 Hoodi 那一列不再是 TBD。
- 預測三: Geth 在 10 月 10 日 UTC 前發出含 PR 35845 的標籤。驗證:
gh api repos/ethereum/go-ethereum/compare/df4c52482b598933d691e3b0c1655f200ff9b7f1...<新標籤> --jq '.status'回ahead或identical。
明天接的待辦:Erigon 的 24620 號與 Nethermind 的 14334 號是否有修復或發版、Teku 是否發版、eth_call 在 execution-apis 的規格文字、EMPTY 比例在第二天是否維持低於 1%、外部建構者占比是否維持約五成。
🔗 延伸學習
- ACDT 第 99 次逐字稿(eth-protocol-transcripts) — 升級前一天的各客戶端就緒回報、
eth_call議題、建構者存款的說明,機器轉錄需對照原意讀。 - go-ethereum PR 35845:skip the execution gas cap on eth_call — 四個旗標的拆法與測試,看
initRuntimeGasBudget的修改。 - Erigon issue 24620:Erigon can’t build blocks on Sepolia after Glamsterdam — 分叉後第一手事故分析,含 EMPTY 父區塊與資料欄遲到的案例。
- consensus-specs:Gloas beacon-chain 規格 —
ExecutionPayloadBid、自建出價規則與process_parent_execution_payload的原文。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 於 Sepolia 的升級(2026-10-06 13:53:36 UTC,epoch 353024,Gloas 分叉版本 0x90000076)。以下是我自己用信標 API 與 GitHub 查到的事實,請協助查證並嚴格區分來源:
1. 2026-10-06 23:19 UTC 時,最新最終確認 epoch 為 353108;分叉後 2,773 個槽位中有 2,683 個區塊、90 個空槽。
2. 區塊出價的 gas_limit 從 60,000,000 升到 158,181,145;相鄰區塊的變化是 67.8% 往上一個滿步(父區塊除以 1024 取整減 1)、31.6% 往下、0.6% 持平。
3. 外部建構者(編號 0 到 4)占區塊 44.2%,自建占 55.8%;以規格的 EMPTY 定義(新出價的 parent_block_hash 不等於前一個出價的 block_hash)計,22 次 EMPTY 全發生在自建區塊之後。
4. Geth 的 PR 35845 在 2026-10-06 14:50:27 UTC 合併,新增 skipExecutionGasCap 讓 eth_call 不再受 EIP-8037 的執行 gas 切分;最新發布標籤仍是 v1.17.7,公開節點(Geth v1.17.7)對 5,000 萬 gas 的 eth_call 只剩 16,762,214。
請幫我:
(a) 查 ACDT 第 99 次與 ACDE 第 247 次的紀錄,確認 eth_call 是否有人主張修改 execution-apis 的規格文字,以及 Hoodi 日期有沒有決議;
(b) 解釋為什麼 31.6% 的區塊會把 gas limit 往下拉,哪些客戶端設定會造成這個行為(要附出處,查不到就說查不到);
(c) 評估在 ePBS 下「上一槽 payload 沒到」對下一個提案者的決策(建在 EMPTY 還是 FULL)有哪些取捨,並對照 Erigon issue 24620 的描述;
(d) 回答時請分成三類標示:「文件或來源明說的」、「你另外查證到的(附網址)」、「你的推論」,不要用舊記憶補。
這是技術研究,僅供學習,不需要也請不要給任何投資建議。