距離 Sepolia 的 Glamsterdam 升級(2026-10-06 13:53:36 UTC,台北時間當天 21:53:36)只剩四天,昨天留下的三條線今天各有結果:ACDT 第 98 次那則 misilva73 的澄清,重新拉 GitHub 留言仍是四則、沒有逐字稿;EIP-7773 追蹤清單第三次查證依舊是 18 個納入的 EIP、沒有 EIP-8254;而 crtahlin/wasp 的 issue 541 底下,其實早在 09-28 就貼出了 Sepolia 升級前的基準測量,昨天漏看了。除此之外,今天查到一個昨天完全沒碰的風險面:ePBS 讓「假 builder 搶標不交貨」在 Sepolia 上成本幾乎為零,而這正是 ACDC 第 188 次(10-01)議程上「incident response」要處理的事。
📖 學
昨天三條線的結算
重新呼叫 gh api repos/ethereum/pm/issues/2230/comments:仍是四則(會議資源機器人、Ma-Julian 的 safe 區塊標籤、misilva73 的澄清提案、barnabasbusa 的 shadowfork genesis.json bug),issue 狀態已是 closed,最後更新 09-28 15:04 UTC。澄清的實質內容依然查不到。EIP-7773 重新讀一次:納入 18 個(2780、7688、7708、7732、7778、7843、7928、7954、7976、7981、7997、8024、8037、8038、8045、8061、8246、8282),網路層 5 個(7975、8070、8136、8159、8189),資訊性 2 個(7904、8261),EIP-8254 不在任何一欄。
wasp 這條線有更新:crtahlin 在 09-28 16:56 UTC 補了一則「Sepolia 升級前基準」留言,用拋棄式測試網輕節點實測三筆支票簿交易。結果是舊版 v0.1.5(寫死上限)與修法後的 main(commit 870dbd54)在今天的 gas 規則下都成功,gas 用量幾乎一致:
| 交易 | v0.1.5 上限 / 實用 | 修法後上限 / 實用 |
|---|---|---|
| 支票簿部署 | 175,000 / 141,905 | 190,241 / 141,893 |
| 首次存入(token 轉帳) | 90,000 / 48,823 | 90,000 / 48,835 |
| 提現至無 sBZZ 的 owner | 95,000 / 67,182 | 95,000 / 67,182 |
這張表可以反推修法的估算值:190,241 ÷ 1.33 ≈ 143,038,比實用 141,893 高約 0.8%,所以「估算加 33%」在今天的規則下上限寬鬆、不會誤傷。另外留言附註一個與升級無關的現象:公開 Sepolia 端點會限流,節點在部署後曾兩次因「429 Too Many Requests」中止,而且 setup 不會重試 429;修法版因為多一次估算呼叫更容易撞到,等 90 秒就避開。
驗算 EIP-8037 的常數,並用它推演另外兩筆交易
issue 表格裡的兩個新常數可以自己驗:183,600 ÷ 1,530 = 120 與 97,920 ÷ 1,530 = 64,都是整數,等於把新帳戶算成 120 byte、新 storage slot 算成 64 byte 的狀態成長,每 byte 1,530 gas。內部一致,至少表格沒有抄錯。
但我重算部署那筆時,與 issue 的 616,000 有出入。照表格逐項相減:CREATE 由 32,000 變 183,600 是 +151,600(issue 用 +163,600);45 byte 程式碼 45 × (1,530 − 200) = +59,850(吻合);3 個新 slot 每個 +77,920,共 +233,760(issue 用約 +257,000);再加上 intrinsic 的 −6,000。總和 141,900 − 6,000 + 151,600 + 59,850 + 233,760 = 581,110,比 616,000 低約 5.7%。差額可能來自 EIP-8038(狀態存取加價)或 CREATE 的其他固定成分,我沒有查到 issue 作者的逐項細帳,所以只能說「兩種算法都落在寫死上限 175,000 的 3.3 到 3.5 倍」,結論不變,但精確值要等 10 月 6 日之後實測。用修法版的規則,581,110 × 1.33 ≈ 772,900,仍低於 1,000,000 的夾限上限;若真值是 616,000,則 819,300,同樣沒碰頂。
基準留言裡另外兩筆轉帳,issue 沒有逐項推算,我用同一套邏輯試算(推論,忽略退款與其他加價):首次存入是 token 轉帳寫入一個全新的餘額 slot,約 48,823 − 20,000 + 97,920 ≈ 126,700,超過寫死的 90,000,舊版會 revert;提現給一個沒有 sBZZ 的 owner,同樣新建 slot,約 67,182 − 20,000 + 97,920 ≈ 145,100,超過寫死的 95,000。也就是說升級後預期不只部署會壞,兩筆轉帳也會壞,這比 issue 標題只提「部署」更廣。這是我的推論,真實結果是 10 月 6 日之後基準留言預告要補的「升級後同樣一輪」。
新的一條線:ePBS 下的假 builder 與 Sepolia 的 incident response
CoinDesk 09-18 報導,共識層開發者 Potuz 在 09-17 的核心開發者電話會議上警告:「I can just spin up a thousand builders, rotate them, offer very high bids, and not produce payloads. Any teenager can do this.」背景是 EIP-7732(ePBS)把區塊建構從鏈下 MEV-Boost 中繼搬進協定:builder 在信標狀態裡有自己的記錄,EIP 文字寫明質押「最低可低到 1 ETH」,以提款憑證前綴 0x03 的存款註冊;提案者拿到的付款是無條件的,於 builder 出價被採用、區塊提出時就從 builder 餘額扣掉,不論後來有沒有交出 payload;EIP 同時明說對 PTC(payload 及時性委員會,PTC_SIZE = 512)與 payload 雙簽「沒有懲罰」,也承認理性但惡意的 builder 可能在對自己有利時扣住 payload。時序上,ePBS 把證明委員會的期限從 4 秒收到 3 秒,並在 9 秒設 payload 委員會。
這個機制在 Sepolia 上的成本結構很特別。攻擊者每標中一個槽位就要付出標價,付款流向提案者;mainnet 上這是真金白銀,而且要壓過誠實 builder 的出價;Sepolia 的測試 ETH 免費,1,000 個 builder 只要 1,000 枚水龍頭 ETH,標價可以開到任意高。算幾個數字:每天 7,200 個槽位(24 × 3,600 ÷ 12);逐個 builder 被客戶端封鎖的防線,1,000 個身分輪流上場只能撐 1,000 個槽位,也就是 1,000 × 12 秒 = 12,000 秒 ≈ 3.3 小時,之後得靠「連續幾次缺 payload 就退回本地建塊」的整體斷路器。CoinDesk 轉述的緩解是這兩層並用,並說開發者接受縮短的時程,因為 Sepolia「相對中心化、出事較容易恢復」。若換成 mainnet,假設誠實 builder 的標價為 0.01、0.03、0.1 ETH(這是我設的假想值,不是量測),全天封殺要付 72、216、720 ETH,代價隨市場出價線性上升,和 Sepolia 的零成本是兩回事。
實況佐證:ACDC 第 188 次(10-01)的議程把「Sepolia upgrade → incident response」列為一項,當天 18:36 UTC,Lodestar 就開了 ethereum/pm 的 issue 2243,提名 Nico Flaig(主)與 Cayman Nava(備)擔任 Glamsterdam 事件應變聯絡人,內文寫明是「as requested on ACDC 188」。這個 issue 到查證時沒有任何留言,ACDC 第 188 次會議紀錄也尚未貼出,所以「每個客戶端團隊各派一主一備」是從這個 issue 推出來的,不是會議紀錄的內容。
客戶端準備度:兩個缺口
CoinDesk 寫的客戶端釋出期限是 09-29(Sepolia 前 7 天,而標準是 14 天);Hoodi 暫定 10 月 27 日。對照各客戶端 release(GitHub 發布時間):geth v1.17.6 於 09-23、v1.17.7 於 09-30(兩版都為 Sepolia 就緒);Besu 26.9.0 於 09-25;Reth v2.7.0 於 09-28;Prysm v7.2.0 與 Lodestar v1.49.0 於 09-28;Nethermind 2.1.0 於 10-01,release note 標示含「Final EIP-8037 state-gas rules」;Lighthouse 對 Sepolia 要用 v8.3.0-rc.0(10-01,預發布版,穩定版 v8.2.3 的說明頁明說 Sepolia 要改用 rc)。Teku 我沒有查。也就是說至少兩個客戶端在 09-29 期限之後才出 Sepolia 可用版本。
第二個缺口更具體:Prysm v7.2.0 的 release note 寫明,上游 09-24 發布的 Sepolia Gloas 設定用 EIP-8261 的 GAS_LIMIT_SCHEDULE 在升級時把 gas limit 拉到 200M,但這筆更動晚於 v7.2.0 切版,「not included in v7.2.0」,所以用這版的驗證者在 Gloas 的 proposer 偏好裡預設是 60M;要提 200M 就得自己在 proposer settings 檔設 "gas_limit": "200000000",或呼叫 keymanager 的 POST /eth/v1/validator/{pubkey}/gas_limit,且舊旗標 --suggested-gas-limit 升級後無效,官方說後續版本才會帶入排程。Lodestar v1.49.0 則已含「schedule 200M gas limit at Glamsterdam on Sepolia」。意義是:Sepolia 的 200M 不會在升級那一刻整齊地出現,而是看提案者用哪個客戶端、設了什麼,出塊的 gas 上限會參差不齊。這件事是公開文件,不是推測。
🧠 記
- ePBS 把「賄賂」變成協定內的付款,同時把「違約」變成沒有罰則的選項。 無條件付款保護提案者,卻沒有對 builder 扣住 payload 設任何懲罰;防線全靠客戶端的 builder 黑名單與整體斷路器,而這兩者是「主觀」機制,不寫在共識裡。
- 同一個攻擊在不同網路的成本差在水龍頭。 假 builder 在 Sepolia 免費、在 mainnet 要付每槽的標價;1,000 個身分只撐 3.3 小時這個算式,說明防線靠的不是封鎖,是輪替成本。
- 「所有客戶端 release 都好了」要拆成逐一核對。 兩個客戶端在期限後才出版本、一個 Sepolia 版仍是 rc、一個的 200M 預設沒帶進去;各自都是公開頁面可驗的事實,合起來才是真實準備度。
- 自己重算一次,會發現別人的數字有 5% 的縫。 issue 的 616,000 與我的 581,110 差 5.7%,兩者都證明寫死的上限會破,結論穩;但這種縫要靠實測才能閉合,所以 10 月 6 日之後的 Sepolia 實測比任何推算都值錢。
✍️ 實踐
用 30 分鐘做兩個可重現的驗算,把今天讀到的數字變成自己的東西:
- 貼進終端機驗證升級時間與常數:
python3 -c "print(1655733600 + 353024*384)"應該得到1791294816(與 geth v1.17.6 release note 的 Sepolia 時間戳一致);再算183600/1530與97920/1530是否為 120 與 64。 - 打開
github.com/crtahlin/wasp/issues/541,把表格的 CREATE 差額(我算 151,600、issue 用 163,600)與 3 個 slot 的差額(我算 233,760、issue 用約 257,000)逐項對一次,在紙上寫下你認為差額的來源,並標記成「待 10 月 6 日實測驗證」。 - 若你自己跑 Sepolia 驗證者:對照 Prysm v7.2.0 release note,檢查你的 proposer settings 是否有
gas_limit,沒有的話升級後會以 60M 出塊。
🔗 延伸學習
- CoinDesk — Ethereum developers warn ‘any teenager’ could disrupt upcoming Glamsterdam test — Potuz 的假 builder 警告、客戶端 7 天期限與 Hoodi 暫定日期的出處。
- EIP-7732 — Enshrined Proposer-Builder Separation — builder 註冊、無條件付款、PTC 與「無懲罰」設計的一手規格。
- Prysm v7.2.0 release — Sepolia 排程、builder 斷路器,以及 200M gas limit 預設仍是 60M 的說明。
- ACDC 第 188 次議程 issue(ethereum/pm 2227) — 議程含 Sepolia 升級的 incident response,與 Hegotá 範圍討論的各則留言。
💬 問 AI
我在追蹤 Ethereum Glamsterdam 於 Sepolia 的升級(2026-10-06 13:53:36 UTC)。以下是我自己查到、整理的事實,請你協助查證並嚴格區分來源:
1. CoinDesk 2026-09-18 引述 Potuz:在 Sepolia 上可以輪替大量假 builder、出高價標下槽位卻不交 payload;EIP-7732 的 builder 最低質押可低到 1 ETH、付款對提案者是無條件的。
2. ethereum/pm 的 issue 2243 顯示 ACDC 第 188 次要求各客戶端提名 Glamsterdam incident response 聯絡人。
3. Prysm v7.2.0 release note 稱 Sepolia 的 200M gas limit 排程未包含在該版,預設 60M。
4. crtahlin/wasp issue 541 估計部署支票簿交易升級後約需 616,000 gas,我自己依表格重算約 581,110。
請幫我:
(a) 查 ACDC 第 188 次與 ACDT 第 99 次(10 月 5 日)有沒有公開紀錄或逐字稿,incident response 具體決議了什麼、客戶端的 builder 黑名單與斷路器的門檻(連續幾次缺 payload 退回本地建塊)是多少;
(b) 查 Sepolia 升級後的實際結果:有沒有出現被扣住 payload 的槽位、gas limit 是否全面到 200M、wasp 的升級後基準實測用了多少 gas;
(c) 回答時請分成三類標示:「文章/來源明說的」、「你自己另外查證到的(附網址)」、「你的推論」,查不到就明說查不到,不要用舊記憶補。
這是技術研究,不需要任何投資建議,也請不要給。