為甚麼 Glamsterdam 可能是以太坊 Merge 後最重要的升級之一？
撰文：KarenZ，Foresight News
本文最早發佈於 2026 年 6 月 23 日
2026 年 9 月 30 日更新：
以太坊基金會於 9 月 28 日公佈 Glamsterdam 測試網升級安排，將在 epoch 353,024（大約在北京時間 2026 年 10 月 6 日 21:53）在 Sepolia 測試網激活 Glamsterdam 網絡升級，Hoodi 測試網及主網的激活時間尚未確定。
升級範圍也進一步明確。原文列出的 10 項計劃納入提案均獲保留，最新清單增至 18 項，ePBS（EIP-7732）和區塊級訪問列表 BAL（EIP-7928）仍是核心。此前處於「考慮納入」階段的 8 項提案現已進入計劃納入清單，分別為：按資源拆分交易基礎 Gas 成本的 EIP-2780、面向未來兼容的共識層數據結構 EIP-7688、確定性工廠合約 EIP-7997、狀態訪問 Gas 成本更新 EIP-8038、排除已被罰沒驗證者提議區塊的 EIP-8045、提高退出和合併處理額度的 EIP-8061，以及移除 SELFDESTRUCT 銷毀餘額行為的 EIP-8246 和構建者執行請求 EIP-8282。
原文：
以太坊的 Glamsterdam 升級，最容易被誤讀成又一次單純提高吞吐量的技術迭代。更準確的說法是：它在重排以太坊的出塊流程、驗證流程和資源定價方式等內容，為更高 Gas 上限、更大 blob 容量和未來並行執行鋪底。
截至 2026 年 6 月 23 日，ethereum.org 將 Glamsterdam 標注為計劃於 2026 年下半年進行的升級。Glamsterdam 的名字來自執行層升級 Amsterdam 與共識層升級 Gloas 的組合。官方路線圖把它放在 2025 年 12 月 Fusaka 之後、Hegotá 之前，並明確列出兩項主要功能：協議內提議者 - 構建者分離，即 ePBS，以及區塊級訪問列表，即 BAL。
誰提議，誰構建：ePBS 把出塊分工寫進協議
今天的以太坊出塊像一個時間很緊的交接班：有人負責提議區塊，有人負責構建交易內容，中間還依賴 MEV-Boost、第三方中繼（relay）等協議外基礎設施。
這個體系已經運行多年，但它把一部分信任關係放在協議外，也讓驗證者在很短時間窗口裡同時處理共識、執行、數據可用性等任務。
Glamsterdam 的頭號變化之一 EIP-7732，即 ePBS（Enshrined Proposer-Builder Separation），就是把提議者和構建者的分工寫進協議。
簡單說，提議者負責選擇共識區塊，構建者負責準備裡面的交易內容。構建者不能只口頭承諾，它要先在協議里「交保證書」：寫清楚自己會交出哪個執行區塊、願意付給提議者多少錢；隨後，Payload Timeliness Committee（負載及時性委員會，PTC ）會檢查它是否按時交付。
這項改動的關鍵不只是減少對第三方中繼的依賴，還在於給區塊傳播和驗證爭取時間。
今天，驗證者需要在很短的關鍵窗口內同時處理共識和執行；ePBS 把這兩件事拆開，讓執行負載可以稍後揭示和驗證。按 EIP-7732 的設計，執行負載的傳播窗口，也就是數據在網絡里傳播並被節點接收的可用時間，可以從約 2 秒擴展到約 9 秒。窗口變長後，以太坊在提高區塊容量時，更不容易因為節點來不及下載、驗證和投票而增加掉票或重組風險。
這件事對普通用戶的直接感知可能不強，但對以太坊擴容很關鍵。更長的傳播和驗證窗口，意味著網絡可以更安全地處理更大負載。CoinDesk 在 2026 年 6 月 16 日報道中援引以太坊基金會 DevOps 工程師 Parithosh Jayanthi 的說法，Glamsterdam 可能是 Merge 以來最大的分叉之一，將改變很多關於以太坊的假設，並為未來更大規模擴容做準備。
BAL 和重定價：擴容不能只踩油門，還要管數據庫
Glamsterdam 的另一項核心改動是 EIP-7928，Block-Level Access Lists，區塊級訪問列表。
它可以理解成給每個區塊配一份「訪問記錄」：這個區塊執行時碰過哪些賬戶、哪些存儲位置，執行後相關狀態變成了甚麼，都要被記錄下來。這樣，節點在處理區塊時就不再完全像拆盲盒，可以更早知道哪些數據需要讀取，哪些計算可以並行推進。
過去的 EIP-2930 已經引入過交易級訪問列表，但它是可選的，實際使用有限。EIP-7928 的變化在於，它把訪問列表提高到區塊層面：區塊頭裡留下這份清單的「指紋」（哈希記錄），執行負載存儲完整清單。節點執行區塊時會核對，清單里寫的訪問記錄是否真的和區塊執行過程一致；如果對不上，區塊就無效。
這件事為甚麼重要？今天以太坊執行交易時，很多數據訪問只有真正跑到那一步才知道。節點不知道一批交易會不會同時讀寫同一個賬戶或存儲槽，就很難放心地並行處理。BAL 相當於把區塊執行中的訪問軌跡顯式寫出來，讓客戶端可以做並行磁盤讀取、並行交易驗證、並行狀態根計算，也能在某些場景下不完整重放交易就更新狀態。它不是直接讓用戶手續費下降的按鈕，而是給客戶端工程打開並行化空間。
但 Glamsterdam 的擴容邏輯不只有「把路修寬」。它還要管住以太坊數據庫的長期膨脹。EIP-8037 提高狀態創建成本，並引入每狀態字節成本 CPSB。狀態可以理解為以太坊必須長期保存的數據庫內容，比如新賬戶、新合約、新存儲槽。交易執行完就結束，狀態卻會留在所有節點要維護的賬本里；如果狀態增長太快，運行節點會越來越貴，去中心化也會被慢慢擠壓。
EIP-8037 給出的背景數字很直觀：截至 2026 年 1 月，一個專用於狀態的 Geth 節點數據庫約為 390 GiB；主網 Gas 上限從 3000 萬提高到 6000 萬後，每日新增狀態從約 105 MiB 上升到約 326 MiB，折算成年增長約 116 GiB。若在 2 億 Gas 上限下按比例外推，狀態年增長可能達到約 387 GiB，並在不到一年內突破 650 GiB 這一性能退化閾值。
所以，EIP-8037 想做的是把「臨時計算」和「永久佔數據庫」分開定價。創建新狀態會更貴，因為它給網絡帶來的不是一次性計算成本，而是長期存儲負擔。
Vitalik Buterin 也在解釋 Glamsterdam 擴容路線時提到，Glamsterdam 會把狀態創建成本從執行與 calldata 成本中分出來：目標是讓執行容量可以擴大得更多，而狀態規模不要按同樣速度膨脹。
放在一起看，BAL 讓節點更容易並行處理區塊，解決的是「跑得更快」；狀態創建重定價讓長期佔用數據庫的操作付出更高成本，解決的是「別把賬本越撐越胖」。Glamsterdam 的擴容不是簡單提高 Gas limit，而是在問一個更現實的問題：以太坊能否裝下更多交易，同時避免區塊傳播、交易驗證和狀態存儲壓力失控。
Glamsterdam EIP 清單成形：哪些已定，哪些還在等？
截至 2026 年 6 月 23 日，根據 Forkcast 上有關以太坊升級的跟蹤內容，當前以太坊開發者正在對 Glamsterdam 升級進行 devnets 環境測試，8 月 3 日將在 Sepolia 上線，9 月 16 日將在主網上線（具體上線時間可能有變動）。
當前計劃納入 Glamsterdam 清單的有 10 個 EIP：
EIP-7708（ETH 轉賬也會觸發日誌，方便索引和追蹤原生 ETH 轉賬）
EIP-7732（ePBS，把提議者和構建者分工寫進協議，減少對協議外 relay 的依賴）
EIP-7778（取消 Gas refund 相關的區塊 Gas 記賬，讓區塊 Gas 計算更簡單）
EIP-7843（新增 SLOTNUM 操作碼，讓合約能讀取當前 slot 編號）
EIP-7928（區塊級訪問列表 BAL，記錄區塊執行訪問過的賬戶和存儲位置，為並行驗證鋪路）
EIP-7954（提高最大合約大小上限，允許更大的合約字節碼）
EIP-7976（提高 calldata floor cost，調整 calldata 的最低成本）
EIP-7981（提高訪問列表成本，重新校准 access list 的 Gas 定價）
EIP-8024（向後兼容的 SWAPN、DUPN、EXCHANGE 操作碼，增強 EVM 棧操作能力）
EIP-8037（提高狀態創建 Gas 成本，抑制狀態數據庫過快膨脹）
這些 EIP 大致可以分成幾類：第一類是出塊和驗證流程重構，以 EIP-7732 和 EIP-7928 為核心；第二類是資源定價調整，包括 EIP-7778、EIP-7976、EIP-7981 和 EIP-8037；第三類是 EVM 和開發者體驗改動，包括 EIP-7708、EIP-7843、EIP-7954、EIP-8024。
換句話說，Glamsterdam 不是只改一個功能點，而是在同時升級出塊分工、並行驗證、Gas 定價和 EVM 可用性。
另有一批 EIP 仍在 「考慮納入」清單：
EIP-2780（按資源拆分交易 intrinsic Gas）
EIP-7610（非空存儲賬戶創建合約時回滾）
EIP-7688（面向未來兼容的共識層數據結構）
EIP-7904（計算 Gas 成本分析，可能會被從 Glamsterdam 中剔除）
EIP-7975（eth/70，部分區塊收據列表）
EIP-7997（確定性工廠合約）
EIP-8038（狀態訪問 Gas 成本更新）
EIP-8045（排除已被罰沒驗證者繼續提議區塊）
EIP-8061（提高退出和合併 churn）
EIP-8070（eth/72，Sparse Blobpool）
EIP-8080（讓退出使用 consolidation queue）
EIP-8136（數據列廣播的 cell-level deltas）
EIP-8159（eth/71，區塊訪問列表交換）
EIP-8246（移除 SELFDESTRUCT burn）
EIP-8282（Builder Execution Requests，給 ePBS 構建者提供專門的註冊和退出請求）
此外，Forkcast 目前還把 EIP-8254（限制每個執行層區塊里的 deposit requests 數量為 8192 個）列為「建議納入」清單。
從質押者角度看，考慮納入清單中的 EIP-8061 和 EIP-8080 尤其值得關注。對質押者來說，這意味著退出流動性可能改善。Figment 在 2026 年 5 月 5 日文章中稱，機構質押者最需要關注 ePBS、EIP-8061 和 EIP-8080，並估算截至 2026 年 4 月約 3890 萬枚 ETH 質押規模下，EIP-8061 可把退出 churn limit 從 256 ETH/epoch 提高到約 1187 ETH/epoch，EIP-8080 則讓普通退出可以利用合併隊列的空余能力。Figment 同時提醒，所有主網上線前的數字都應視為推測。
來源：Figment
協議在升級，基金會成員也在變動
Glamsterdam 的技術準備，和以太坊基金會協議集群（Protocol cluster）的人事調整幾乎同時發生。以太坊基金會 2026 年 5 月 11 日博客稱，Glamsterdam 已達到幾個里程碑：2 億 Gas limit floor 被建立為可信的 post-Glamsterdam 目標，ePBS 在多客戶端 Glamsterdam devnet 中穩定運行，EIP-8037 完成定稿。
同一篇文章宣佈 Protocol cluster 的領導交接：Will Corcoran、Kev Wedderburn、Fredrik 將成為新的協議集群協調者。原協調者 Barnabé Monnot、Tim Beiko 離開以太坊基金會，Alex Stokes 休假。
基金會對三位新協調者的分工描述是：Will Corcoran 具備跨團隊協調經驗；Kev Wedderburn 領導 zkEVM 團隊；Fredrik 領導 Protocol Security 和 Trillion Dollar Security 項目。
這輪變化沒有停留在協議團隊。2026 年 6 月 18 日，Hsiao-Wei Wang 發文稱，在休假後決定辭去以太坊基金會聯合執行董事和董事會成員職務
以太坊基金會前研究員 Dankrad Feist 在 2026 年 6 月 19 日表示，離開 EF 的人是 CROPS（抗審查與抗捕獲、開源、隱私、安全）信仰者，問題不在戰略，而在管理，並稱這波人才外流對以太坊偏利空。Miden 聯合創始人 Azeem 則從相反方向解讀，認為 EF 難以自我改變，人才流出後可能成立更能執行以太坊路線圖的新組織，對生態長期反而是淨利好。
以太坊基金會內部人士的口徑更像一次定邊界。以太坊基金會臨時聯席執行董事 Bastian Aue（Aerugo）回應稱，以太坊基金會成員離職原因包括戰略分歧、崗位適配、機構正常變動或個人選擇，EF 不會在社交媒體上討論個人人事問題，但表示離職者應有體面的離場方式。
以太坊基金會隨後用官方推特 thread 給出更明確的組織敘事：實現以太坊潛力需要多個組織組成聯盟，過去一年已有若干組織共同增強生態韌性和能力。EF 列出的例子包括：6 月 23 日宣佈的 ethlabs（一個聚焦以太坊與 ETH 下一階段採用的非營利研發實驗室）、2026 年 4 月啓動的 Eth Apps Guild（面向以太坊原生應用真實採用，尤其關注新興市場）（2026 年啓動的 Ethereum Economic Zone（目標是通過同步可組合性和零知識實時證明降低生態碎片化）以及 2025 年成立的 Argot（一個維護 Solidity 與開源編譯器工具的工程師和研究員自治集體）。
這條官方 thread 讓以太坊基金會的近期變化更容易理解：基金會不是單純把人和項目往外推，也不是放棄中心協調，而是可能在把以太坊路線圖拆給更多組織共同承擔。
小結
所以，Glamsterdam 不該只被看成一組 EIP。它是以太坊在更高吞吐量之前做的一次工程重排：誰建塊、誰提議、誰驗證、哪些數據必須長期保存、哪些資源該更貴，都被重新放上桌面。
技術路線的關鍵詞是 ePBS、BAL 和多維 Gas 的開端；組織路線的關鍵詞則更現實：以太坊基金會能否保持協調力，以及基金會之外的新組織能否把這份協調力變成持續交付。
參考：
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122