以太坊Glamsterdam升級：最大規模底層重構，主網日期仍懸而未決

原創｜Odaily 星球日報（@OdailyChina）

作者｜jk

以太坊即將迎來的 Glamsterdam 升級，是繼 The Merge 之後核心開發者眼中改動幅度最大的一次協議級重構。這個名字來自兩部分的組合：執行層升級部分沿用「Amsterdam」，取自往屆 Devconnect 舉辦地阿姆斯特丹；共識層升級部分則命名為「Gloas」，以一顆恆星命名。繼此前的 Fusaka 升級之後，Glamsterdam 透過重組網路處理交易和管理其不斷增長資料庫的方式來推進 L1 擴容，從根本上更新了以太坊建立和驗證區塊的方式。

這次升級圍繞三個核心目標展開：

• 加速處理（平行化）：重組網路記錄資料依賴關係的方式，使其能夠安全地同時處理大量交易，而非緩慢的逐筆順序處理。
• 擴容：拆分區塊建立和驗證的繁重工作，讓網路有更多時間傳播更大量的資料而不減速。
• 永續性：調整網路費用以準確反映儲存新資料的長期硬體成本，為未來的 Gas 上限提升掃清障礙，同時避免硬體效能出現退化。

升級的兩項頭牌提案分別落在共識層和執行層：

有兩大 Headliner（頭牌）提案。來源：以太坊

頭牌提案一：ePBS，把「外包中間商」變成「內建規則」

先說共識層的頭牌提案，協議內提議者與建構者分離，英文簡稱 ePBS（EIP-7732）。

以太坊每次出塊，其實分兩步：一個人負責「選中哪個區塊」（提議者），另一個人負責「把區塊裡的交易實際組裝好」（建構者）。目前這個分工不是以太坊協議本身規定的，而是靠一批鏈下的「中介公司」（行話叫中繼）來撮合完成。這種鏈外關係還在區塊驗證期間造成了一條路徑，迫使驗證者在緊張的 2 秒視窗內匆忙完成交易廣播和執行，限制了網路能夠處理的資料量。打個比方，這就好比一家餐廳的點單和做菜環節，原本要靠一個獨立的外部對接人來協調傳菜，一旦這個對接人掉鏈子，廚房和前台就可能對不上帳。

ePBS 做的事情，就是把這套「點單-做菜」的分工規則，寫進餐廳自己的營運規範手冊裡，不再依賴外部對接人。這樣一來，鏈上可信的區塊交付和付款機制被直接建構進協議本身，從而不再需要依賴第三方中介軟體，不過如果雙方想用一些協議裡還沒規定的複雜功能，仍然可以選擇繼續用回外部對接人。同時，為了不再讓「傳菜」環節手忙腳亂，ePBS 還專門設立了一個「驗菜小組」，分別檢查「誰點的單」和「菜有沒有按時做好上桌」這兩件事，原來 2 秒的傳菜時間視窗也因此擴大到了約 9 秒，讓餐廳能一次性處理更多訂單，也就是讓以太坊能承載更多面向 Layer2 的資料。

頭牌提案二：BALs，出發前先把「購物清單」列好

再說執行層的頭牌提案，區塊級存取列表，英文簡稱 BALs（EIP-7928）。

現在以太坊處理交易的方式，有點像一個人矇著眼睛去超市買東西：必須先摸到一件商品、確認是什麼，才能決定下一步怎麼走，所以只能一件一件排隊來。因為不提前知道一筆交易會用到哪些資料，比如會涉及哪些帳戶，系統必須嚴格按順序逐筆處理交易，否則兩筆交易可能會意外地同時想要修改同一份資料（比如同一個地址的餘額），造成衝突出錯。

BALs 相當於讓這個人在出發前，先拿到一份寫清楚「要去哪幾個貨架、要拿哪幾樣東西」的購物清單。有了這份清單，系統提前就能看出哪些交易之間完全不會互相「打架」，於是可以把互不相關的交易分成幾組，同時平行處理，而不必再一件一件排隊。這份清單還有一個額外的好處：新節點加入網路時，可以直接照抄這份清單裡記錄的最終結果，而不必把所有複雜的歷史交易重新算一遍，這樣新節點同步進度會快很多。為了配合這份清單真正在網路裡流通起來，Glamsterdam 還打包了一項配套的傳輸協議升級，讓節點之間能夠實際共享這些存取列表，這項傳輸協議目前已成為所有執行層用戶端的強制要求。

配套提案：給「佔地方」的操作重新算帳

除了這兩項頭牌提案，Glamsterdam 還打包了兩項重新定價的配套提案，可以理解成給網路的「倉儲費」和「查詢費」分別做了一次價目表調整。

• 第一項是新建帳戶、部署合約這類會在網路裡「永久佔地方」的操作，以前的收費和它實際佔用的空間不太成正比，現在要按照「每佔用一份空間就收對應的錢」來重新計費，目標是把整個網路的資料成長速度控制在每年 120 GiB 這樣一個安全、可預測的水準上，確保用普通硬體也能持續跑得動這個網路。同時這筆倉儲費會單獨開一個帳戶來核算，不再和處理交易本身的計算費用混在一起，只要開發者願意多付一點倉儲費，依然可以部署規模更大、更複雜的應用，不會被總的 Gas 上限一下子卡死。
• 第二項是查詢、讀取網路裡已有資料這類操作，以前定價偏低，跟不上現在資料量變大之後實際的查詢成本，這次會把這類操作碼的收費標準提高，讓價格更貼近現代硬體真實的負載情況，同時也能防止有人鑽費用太便宜的空子，故意用大量查詢請求把網路堵住。

主網上線時間：目前還沒有定好

在時間表方面，Glamsterdam 目前正處在一個頗為微妙的階段。官方層面，最近一次可查證的全體核心開發者執行層會議（ACDE）是第 241 次，在 7 月 16 日，主要議程包括 Glamsterdam Devnet 階段的最新進展彙報，以及為下一次升級 Hegota 投票選出頭牌提案。此前業界廣泛引用的一份排期顯示，Devnet 階段共進行了從 0 到 7 的八輪迭代，時間跨度為 2026 年 3 月 28 日至 7 月 8 日，隨後 Sepolia 測試網分叉原定於 2026 年 8 月 3 日，Hoodi 測試網分叉原定於 2026 年 8 月 17 日，主網啟動的目標日期為 2026 年 9 月 16 日。

原本排期是 2026 年上半年，來源：以太坊

但從最新動向看，這份排期大概率已經推後。EthPandaOps 團隊近期推出了名為 Plataberget 的新測試網，這是專門為 Glamsterdam 設計的第一個短期公共測試網，正式的 Sepolia 與 Hoodi 部署預計要推遲到 9 月才會跟進，主網上線目標也相應後移至 2026 年第四季。這也是 Glamsterdam 繼此前從原定的 2026 年上半年推遲之後，第二次出現日期滑動。核心開發者此前已多次強調，升級的正確性優先於趕上任何特定日期，因此在正式的 ACD 會議鎖定具體區塊高度之前，我們可能要在第四季甚至年底才能看到這次升級了。