Glamsterdam 升级，以太坊的 L1 擴容答案

原創 | Odaily 星球日報 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 會議鎖定具體區塊高度之前，我們可能要在第四季度甚至年底才能看到這次升級了。