---
title: "格蘭斯特丹"
description: "了解格蘭斯特丹 (Glamsterdam) 協定升級"
lang: zh-tw
template: upgrade
---
格蘭斯特丹 (Glamsterdam) 是計畫於 2026 年第四季進行的以太坊升級
格蘭斯特丹升級只是以太坊長期發展目標中的一步。了解更多關於[協定路線圖](/roadmap/)與[先前的升級](/ethereum-forks/)。
[以太坊](/)即將到來的格蘭斯特丹 (Glamsterdam) 升級旨在為下一代擴容鋪平道路。格蘭斯特丹的命名結合了「Amsterdam」（執行層升級，以先前的 Devconnect 舉辦地點命名）與「Gloas」（共識層升級，以一顆恆星命名）。
繼[富薩卡 (Fusaka)](/roadmap/fusaka/)升級取得進展後，格蘭斯特丹專注於透過重組網路處理交易與管理其不斷增長的資料庫的方式來擴展第一層 (L1)，從根本上更新以太坊建立與驗證區塊的方式。
富薩卡專注於基礎改良，而格蘭斯特丹則透過將不同網路參與者之間的職責分離寫入協定中，並引入更有效率的資料處理方式，為高吞吐量平行化準備[狀態](/glossary/#state)，從而推進「擴展 L1」與「擴展 Blob」的目標。
這些改進確保以太坊在處理更多活動時保持快速、經濟實惠且去中心化的特性，同時讓在家運行[節點](/glossary/#node)的人能夠負擔得起硬體要求。
## 考慮納入格蘭斯特丹的改進 {#improvements-in-glamsterdam}
注意：本文重點介紹了預計包含在格蘭斯特丹升級中的部分 EIP。正在開發網中測試的其他預定提案包括 EIP-7610、EIP-7688、EIP-7778、EIP-7843、EIP-7976、EIP-7981、EIP-8024、EIP-8246 與 EIP-8282。如需最新狀態更新，請查看 [Forkcast 上的格蘭斯特丹升級](https://forkcast.org/upgrade/glamsterdam)。
如果您想新增一個正在考慮納入格蘭斯特丹但尚未新增至此頁面的 EIP，請[在此了解如何為 ethereum.org 做出貢獻](/contributing/)。
格蘭斯特丹升級以三個主要目標為中心：
- 加速處理（平行化）：重組網路記錄資料依賴關係的方式，使其能夠安全地同時處理許多交易，而不是緩慢地逐一循序處理。
- 擴展容量：分散建立與驗證區塊的繁重工作，讓網路有更多時間傳播大量資料而不會減慢速度。
- 防止資料庫膨脹（永續性）：調整網路費用以準確反映儲存新資料的長期硬體成本，為未來的 Gas 限制增加掃除障礙，同時防止硬體效能下降。
簡而言之，格蘭斯特丹將引入結構性變更，以確保網路在增加容量的同時，保持永續性並維持高效能。
## 擴展 L1 與平行處理 {#scale-l1}
有意義的 L1 擴容需要擺脫協定外的信任假設與循序執行的限制。格蘭斯特丹透過將某些區塊建構職責的分離寫入協定中，並引入新的資料結構，讓網路為平行處理做好準備，從而解決了這個問題。
### 焦點提案：寫入協定的提案者與建構者分離 (ePBS) {#epbs}
- 消除協定外的信任假設與對第三方中繼 (relays) 的依賴
- 透過延長傳播時間窗口允許更大的負載，從而支援 L1 擴容
- 將無須信任的建構者付款直接引入協定中
- 要求質押池進行架構更新以實現無須信任的監控，儘管整體質押使用者體驗透過改良的建構者選擇過程得到了提升
目前，提案與建構區塊的過程包含區塊提案者與區塊建構者之間的交接。提案者與建構者之間的關係並非以太坊核心協定的一部分，因此它依賴受信任的第三方中介軟體、軟體（中繼）以及實體之間的協定外信任。
提案者與建構者之間的協定外關係也在區塊驗證期間建立了一條「熱路徑 (hot path)」，迫使[驗證者](/glossary/#validator)在緊湊的 2 秒窗口內匆忙完成交易廣播與執行，限制了網路可以處理的資料量。
**寫入協定的提案者與建構者分離 (Enshrined Proposer-Builder Separation, ePBS，或 EIP-7732)** 正式將提案者（選擇共識區塊）與建構者（組裝執行負載）的工作分開，將這種交接直接寫入協定中。
將區塊負載與付款的無須信任交換直接建構到協定中，消除了對第三方中介軟體（如 MEV-Boost）的需求。然而，對於尚未成為核心協定一部分的複雜功能，建構者與提案者可能仍會選擇使用協定外的中繼或中介軟體。
為了解決「熱路徑」瓶頸，ePBS 還引入了負載及時性委員會 (Payload Timeliness Committee, PTC) 與雙重截止期限邏輯，允許驗證者分別對共識區塊與執行負載的及時性進行證明，以最大化吞吐量。
在協定層面分離提案者與建構者角色，將傳播窗口（或在網路上傳播資料的可用時間）從 2 秒擴展到約 9 秒。
透過以協定內機制取代協定外的中介軟體與中繼，ePBS 減少了信任依賴，並允許以太坊安全地處理更大量的資料（例如為[第二層 (L2)](/glossary/#layer-2) 提供更多 Blob），而不會對網路造成壓力。
**資源**：[EIP-7732 技術規範](https://eips.ethereum.org/EIPS/eip-7732)
### 焦點提案：區塊級存取清單 (BALs) {#bals}
- 透過提供所有交易依賴關係的預先映射，消除循序處理的瓶頸，為驗證者平行處理許多交易（而非逐一處理）奠定基礎
- 允許節點透過讀取最終結果來更新其記錄，而無需重播每筆交易（無執行同步），從而大幅加快節點與網路同步的速度
- 消除猜測，允許驗證者一次預先載入所有必要的資料，而不是逐步發現，這使得驗證速度快得多
今天的以太坊就像一條單行道；因為網路在交易運行之前不知道交易將需要或更改哪些資料（例如交易將觸及哪些帳戶），所以驗證者必須在嚴格的循序隊列中逐一處理交易。如果他們試圖在不知道這些依賴關係的情況下同時處理所有交易，兩筆交易可能會意外地嘗試同時更改完全相同的資料，從而導致錯誤。
**區塊級存取清單 (Block-Level Access Lists, BALs，或 EIP-7928)** 的作用就像網路的地圖，詳細說明在工作開始之前將存取資料庫的哪些部分。執行層儲存完整的區塊存取清單，包括交易將觸及的每個帳戶變更，以及這些變更的最終結果（所有狀態存取與執行後的值）。為了保持區塊輕量化，區塊頭包含一個新欄位，其中帶有此清單的唯一數位指紋（雜湊記錄）。
因為 BALs 提供了哪些交易不重疊的即時可見性，它們允許節點執行平行磁碟讀取，同時獲取許多交易的資訊。網路可以安全地將不相關的交易分組並平行處理它們。
由於 BAL 包含交易的最終結果（執行後的值），當網路的節點需要同步到網路的當前狀態時，它們可以複製這些最終結果來更新其記錄。驗證者不再需要從頭開始重播所有複雜的交易才能知道發生了什麼，這使得新節點加入網路變得更快、更容易。
由 BALs 實現的平行磁碟讀取將是邁向以太坊未來能夠同時處理許多交易的重要一步，從而顯著提高網路速度。
#### eth/71 區塊存取清單交換 {#bale}
區塊存取清單交換 (Block Access List Exchange, eth/71 或 EIP-8159) 是區塊級存取清單的直接網路配套功能。雖然 BALs 解鎖了平行執行，但 eth/71 升級了點對點協定，允許節點實際在網路上共享這些清單。現在所有執行層客戶端都必須具備區塊存取清單交換功能，這將實現更快的同步，並允許節點執行無執行的狀態更新。
**資源**：
- [EIP-7928 技術規範](https://eips.ethereum.org/EIPS/eip-7928)
- [EIP-8159 技術規範](https://eips.ethereum.org/EIPS/eip-8159)
## 網路永續性 {#network-sustainability}
隨著以太坊網路發展得越來越快，確保使用它的成本與運行以太坊的硬體損耗相符非常重要。網路需要增加其整體容量限制，以便安全地擴展並處理更多交易。
### 狀態建立 Gas 成本增加 {#state-creation-gas-cost-increase}
- 確保建立新帳戶或智能合約的費用準確反映它們對以太坊資料庫造成的長期負擔
- 設定固定的**每狀態位元組成本 (cost per state byte, CPSB)**，目標是實現每年 120 GiB 的安全且可預測的增長率，確保標準實體硬體可以繼續運行網路
- 將這些特定費用的記帳分離到一個新的儲備池 (reservoir) 中，消除舊的交易限制，並允許開發人員部署更大、更複雜的應用程式
新增帳戶、代幣與[智能合約](/glossary/#smart-contract)會建立永久資料（稱為「狀態」），運行網路的每台電腦都必須無限期地儲存這些資料。目前新增或讀取這些資料的費用並不一致，且不一定反映它們對網路硬體造成的實際長期儲存負擔。
在以太坊上建立狀態的某些操作（例如建立新帳戶或部署大型智能合約），與它們在網路節點上佔用的永久儲存空間相比，成本相對較低。例如，合約部署的每位元組成本明顯低於建立儲存槽的成本。
如果不進行調整，隨著網路朝著格蘭斯特丹實現的 2 億 Gas 限制底線擴展（開發人員目前正在 1.5 億參考區塊 Gas 限制下進行測試，以得出準確的狀態定價），以太坊的狀態增長將變得無法永續。
**狀態建立 Gas 成本增加 (State creation gas cost increase，或 EIP-8037)** 透過將成本與正在建立的資料實際大小掛鉤來協調成本，更新費用使其與操作建立或存取的永久資料量成正比。
EIP-8037 還引入了儲備池模型來更可預測地管理這些成本；狀態 Gas 費用首先從 `state_gas_reservoir` 中扣除，而 `GAS` 操作碼僅返回 `gas_left`，防止執行框架錯誤計算可用 Gas。為了支援這一點，基本的背景任務會獲得額外的燃料授權額度，直接進入這個專用儲備池，確保關鍵的網路操作不會僅僅因為儲存永久資料需要更多資源而失敗。
在 EIP-8037 之前，計算工作（主動處理）與永久資料儲存（將智能合約儲存到網路資料庫）共享相同的 Gas 限制。儲備池模型將記帳分開：交易實際計算工作（處理）的 Gas 限制與長期資料儲存（狀態 Gas）的 Gas 限制。將兩者分開有助於防止應用程式資料的龐大體積達到 Gas 限制的上限；只要開發人員提供足夠的資金來填滿資料儲存的儲備池，他們就可以部署更大、更複雜的智能合約。
更準確、更可預測地為資料儲存定價，將有助於以太坊安全地提高其速度與容量，而不會導致資料庫膨脹。這種永續性將允許節點營運者在未來幾年繼續使用（相對）負擔得起的硬體，保持家庭質押的可及性，以維持網路的去中心化。
**資源**：[EIP-8037 技術規範](https://eips.ethereum.org/EIPS/eip-8037)
### 狀態存取 Gas 成本更新 {#state-access-gas-cost-update}
- 增加應用程式讀取或更新永久儲存在以太坊上的資訊（狀態存取操作碼）時的 Gas 成本，以準確匹配這些命令所需的計算工作
- 透過防止利用人為低廉的資料讀取操作進行阻斷服務攻擊，增強網路韌性
隨著以太坊狀態的增長，搜尋與讀取舊資料（「狀態存取」）的行為對節點來說變得更加繁重且緩慢。儘管現在尋找資訊（在計算能力方面）稍微昂貴了一些，但這些操作的費用卻保持不變。
因此，相對於它們迫使節點執行的工作，某些特定命令目前的定價過低。例如，`EXTCODESIZE` 與 `EXTCODECOPY` 的定價過低，因為它們需要兩次獨立的資料庫讀取——一次用於帳戶物件，第二次用於實際的程式碼大小或位元組碼。
**狀態存取 Gas 成本更新 (State-access gas cost update，或 EIP-8038)** 增加了狀態存取操作碼（如尋找帳戶與合約資料）的 Gas 常數，以符合現代硬體效能與狀態大小。
調整狀態存取的成本也有助於使以太坊更具韌性。因為這些繁重的資料讀取操作人為地便宜，惡意攻擊者可能會在達到網路費用限制之前，在單個區塊中向網路發送數千個複雜的資料請求，從而可能導致網路停滯或崩潰（阻斷服務攻擊）。即使沒有惡意意圖，如果讀取網路資料太便宜，開發人員在經濟上也不會受到鼓勵去建構有效率的應用程式。
透過更準確地為狀態存取操作定價，以太坊可以更具韌性地抵禦意外或故意的速度減緩，同時將網路成本與硬體負載保持一致，為未來 Gas 限制的增加提供了更永續的基礎。
**資源**：[EIP-8038 技術規範](https://eips.ethereum.org/EIPS/eip-8038)
## 網路韌性 {#network-resilience}
對驗證者職責與退出流程的改良確保了在大規模罰沒事件期間的網路穩定性，並加快了質押者移動其質押的速度。這些改進使網路更加穩定，並確保所有參與者（無論大小）都受到公平對待。
### 排除被罰沒的驗證者進行提案 {#exclude-slashed-validators}
- 阻止受罰（被罰沒）的驗證者被選中提案未來的區塊，消除必然錯過的時段 (slots)
- 保持以太坊平穩可靠地運行，防止在大規模罰沒事件中出現嚴重的停滯
目前，即使驗證者被罰沒（因違反規則或未按預期運行而受罰），系統在產生未來的提案者預視 (lookaheads) 時，仍可能在不久的將來選擇他們來領導一個區塊。
因為來自被罰沒提案者的區塊會自動被拒絕為無效，這會導致網路錯過時段，並在大規模罰沒事件期間延遲網路恢復。
**排除被罰沒的驗證者進行提案 (Exclude slashed validators from proposing，或 EIP-8045)** 只是過濾掉被罰沒的驗證者，使其不被選中執行未來的職責。這透過確保只選擇健康的驗證者來提案區塊，從而提高了鏈的韌性，在網路中斷期間維持服務品質。
**資源**：[EIP-8045 技術規範](https://eips.ethereum.org/EIPS/eip-8045)
### 讓退出使用合併佇列 {#increase-exit-and-consolidation-churn}
- 透過讓退出容量隨質押的 ETH 總量擴展，而不是限制在固定速率，顯著減少質押提款時間
- 為驗證者合併 (consolidations) 提供專屬的隊列容量，加速向更大、更有效率的驗證者過渡
- 透過仔細分析的安全參數維持網路安全
以太坊的流動限制 (churn limit) 是對驗證者進入、退出或合併其質押 ETH 速率的安全限制，以確保網路的安全性永遠不會被破壞。如今，退出與啟用共享一個單一的上限限制，因此在需求高峰期，質押者可能面臨漫長的等待才能提取他們的 ETH。合併（驗證者合併成擁有高達 2,048 ETH 的更大驗證者，由[佩克特拉升級](/roadmap/pectra)啟用）也競爭這個有限的容量，這意味著以目前的速率，合併整個驗證者集將需要數年時間。
**增加退出與合併流動 (Increase exit and consolidation churn，或 EIP-8061)** 將這些限制重組為獨立的通道：
- 驗證者啟用保持其現有的上限限制，維持不變
- 退出不再設有上限，而是隨質押的 ETH 總量擴展
- 合併獲得其專屬的容量，大約是啟用與退出組合限制的一半大小
在目前的質押水平下，這將退出容量增加了大約 4 倍，合併容量增加了大約 2 倍，這意味著質押者可以在高需求期間更快地提取他們的 ETH，並且網路可以更快地過渡到更小、更有效率的驗證者集。
因為質押可以更快地進出網路，這項變更將節點在需要最近的受信任檢查點才能安全重新加入網路之前可以保持離線的時間大約減半（弱主觀性時期，從大約 15.7 天減少到大約 7 天）。這種權衡經過了仔細分析，以確保維持網路安全。
**資源**：[EIP-8061 技術規範](https://eips.ethereum.org/EIPS/eip-8061)
## 改善使用者與開發人員體驗 {#improve-user-developer-experience}
以太坊的格蘭斯特丹升級旨在改善使用者體驗、增強資料可發現性，並處理不斷增加的訊息大小以防止同步失敗。這使得追蹤鏈上發生的事情變得更加容易，同時防止網路擴展時出現技術故障。
### 降低內在交易 Gas 成本 {#reduce-intrinsic-transaction-gas-costs}
- 降低交易的基礎費用，減少簡單原生 ETH 支付的整體成本
- 使小額轉帳更實惠，提升以太坊作為日常交換媒介的可行性
今天，所有以太坊交易都有一個固定的基礎 Gas 費，無論處理起來多麼簡單或複雜。**降低內在交易 Gas (Reduce intrinsic transaction gas，或 EIP-2780)** 提議降低該基礎費用，使現有帳戶之間的標準 ETH 轉帳便宜高達 **71%**。
降低內在交易 Gas 的運作方式是分解交易手續費，使其僅反映運行網路的電腦實際執行的基本、必要工作，例如驗證數位簽章與更新餘額。因為基本的 ETH 支付不執行複雜的程式碼或攜帶額外資料，此提案將降低其費用以匹配其輕量級的足跡。
該提案為建立全新帳戶引入了例外情況，以防止較低的費用壓垮網路的狀態。如果轉帳將 ETH 發送到一個空的、不存在的地址，網路必須為其建立一個永久的新記錄。為該帳戶建立增加 Gas 附加費，以幫助支付其長期儲存負擔。
總體而言，EIP-2780 旨在使現有帳戶之間的日常轉帳更實惠，同時透過準確為真實狀態增長定價，確保網路仍然受到保護，免受資料庫膨脹的影響。
**資源**：[EIP-2780 技術規範](https://eips.ethereum.org/EIPS/eip-2780)
### 確定性工廠預先部署 {#deterministic-factory-predeploy}
- 為開發人員提供一種原生的方式，將應用程式與智能合約錢包部署到跨多個鏈的完全相同地址
- 允許使用者在多個第二層 (L2) 網路上擁有相同的智能錢包地址，減少認知負荷、減少混淆，並降低意外損失資金的風險
- 取代開發人員目前用來實現這種一致性的變通方法，使建構多鏈錢包與應用程式變得更容易、更安全
如果使用者今天擁有一個智能合約錢包，其帳戶跨越多個相容以太坊虛擬機 (EVM) 的鏈，他們通常會在不同的網路上得到完全不同的地址。這不僅令人困惑，還可能導致意外損失資金。
**確定性工廠預先部署 (Deterministic Factory Predeploy，或 EIP-7997)** 為開發人員提供了一種原生的、內建的方式，將他們的去中心化應用程式與智能合約錢包部署到跨多個 EVM 鏈（包括以太坊主網、第二層 (L2) 網路等）的完全相同地址。如果被採用，它將允許使用者在每個參與的鏈上擁有完全相同的地址，從而顯著減少認知負荷與使用者出錯的可能性。
確定性工廠預先部署的運作方式是將一個最小的、專門的工廠程式永久放置在每個參與的 EVM 相容鏈上的相同位置（具體來說，地址 0x12）。其目標是提供一個通用的、標準的工廠合約，可供任何 EVM 相容網路採用；只要 EVM 鏈參與並採用此標準，開發人員就能夠使用它將他們的智能合約部署到該網路上完全相同的地址。
這種標準化簡化了開發人員與更廣泛生態系統建構和管理跨鏈應用程式的過程。開發人員不再需要建構自訂的、特定於鏈的程式碼來將他們的軟體跨不同網路連結在一起，而是使用這個通用工廠在任何地方為他們的應用程式產生完全相同的地址。此外，區塊瀏覽器、追蹤服務與錢包可以更輕鬆地識別並連結跨各種鏈的這些應用程式與帳戶，為所有基於以太坊的參與者建立一個更統一、無縫的多鏈環境。
**資源**：[EIP-7997 技術規範](https://eips.ethereum.org/EIPS/eip-7997)
### ETH 轉帳與銷毀發出日誌 {#eth-transfers-and-burns-emit-a-log}
- 每次轉帳或銷毀 ETH 時自動產生永久記錄（日誌）
- 修復了一個歷史盲點，允許應用程式、交易所與跨鏈橋在沒有臨時追蹤工具的情況下可靠地檢測使用者存款
與代幣 (ERC-20) 不同，智能合約之間的常規 ETH 轉帳不會發出清晰的收據（標準日誌），這使得交易所與應用程式難以追蹤它們。
ETH 轉帳與銷毀發出日誌 (ETH transfers and burns emit a log，或 EIP-7708) 強制網路在每次移動或銷毀非零數量的 ETH 時發出標準日誌事件。
這將使錢包、交易所與跨鏈橋營運者在沒有自訂工具的情況下，更輕鬆、更可靠地準確追蹤存款與資金移動。
**資源**：[EIP-7708 技術規範](https://eips.ethereum.org/EIPS/eip-7708)
### eth/70 部分區塊收據清單 {#eth-70-partial-block-receipt-lists}
隨著我們增加以太坊可以執行的工作量，這些操作的收據清單（這些交易的資料記錄）變得如此之大，以至於它們可能會導致網路節點在嘗試相互同步資料時失敗。
現在作為所有執行層客戶端的要求，eth/70 部分區塊收據清單 (eth/70 partial block receipt lists，或 EIP-7975) 引入了一種節點相互通訊的新方式 (eth/70)，允許將這些大型清單分解成更小、更易於管理的部分。eth/70 為網路的通訊協定引入了分頁系統，允許節點分解區塊收據清單，並安全地以更小、更易於管理的區塊請求資料。
這項變更將防止在活動頻繁期間發生網路同步失敗。最終，它為以太坊增加其區塊容量並在未來每個區塊處理更多交易鋪平了道路，而不會壓垮同步鏈的實體硬體。
**資源**：[EIP-7975 技術規範](https://eips.ethereum.org/EIPS/eip-7975)
## 進一步閱讀 {#further-reading}
- [以太坊路線圖](/roadmap/)
- [Forkcast：格蘭斯特丹](https://forkcast.org/upgrade/glamsterdam)
- [格蘭斯特丹 Meta EIP](https://eips.ethereum.org/EIPS/eip-7773)
- [2026 年協定優先事項更新部落格公告](https://blog.ethereum.org/2026/02/18/protocol-priorities-update-2026)
- [The Daily Gwei Refuel podcast - 後量子以太坊，格蘭斯特丹即將到來](https://www.youtube.com/watch?v=qx9sd50uQjQ)
## 常見問題 {#faq}
### 在格蘭斯特丹硬分叉之後，如何轉換 ETH？ {#how-can-eth-be-converted-after-the-hardfork}
- **您的 ETH 無需採取任何行動**：在格蘭斯特丹升級之後，無需轉換或升級您的 ETH。您的帳戶餘額將保持不變，並且您目前持有的 ETH 在硬分叉後仍將以其現有形式可供存取。
- **當心詐騙！** **任何指示您「升級」ETH 的人都是試圖詐騙您。** 關於這次升級，您不需要做任何事情。您的資產將完全不受影響。請記住，保持消息靈通是防範詐騙的最佳防線。
[更多關於識別與避免詐騙的資訊](/security/)
### 格蘭斯特丹升級會影響所有以太坊節點與驗證者嗎？ {#does-the-glamsterdam-upgrade-affect-all-ethereum-nodes-and-validators}
是的，格蘭斯特丹升級需要更新[執行客戶端與共識客戶端](/developers/docs/nodes-and-clients/)。因為這次升級引入了寫入協定的提案者與建構者分離 (ePBS)，節點營運者將需要確保他們的客戶端已更新，以處理網路建構、驗證與證明區塊的新方式。
所有主要的以太坊客戶端都將發布支援硬分叉的版本，並標記為高優先級。您可以透過客戶端的 GitHub 儲存庫、他們的 [Discord 頻道](https://ethstaker.org/support)、[EthStaker Discord](https://dsc.gg/ethstaker)，或訂閱以太坊部落格以獲取協定更新，來掌握這些版本何時可用。
為了在升級後維持與以太坊網路的同步，節點營運者必須確保他們運行的是受支援的客戶端版本。請注意，有關客戶端發布的資訊具有時效性，使用者應參考最新更新以獲取最新詳細資訊。
### 身為質押者，我需要為格蘭斯特丹升級做些什麼？ {#as-a-staker-what-do-i-need-to-do-for-the-glamsterdam-upgrade}
與每次網路升級一樣，請確保將您的客戶端更新到標有支援格蘭斯特丹的最新版本。關注郵件清單與[以太坊基金會部落格上的協定公告](https://blog.ethereum.org/category/protocol)中的更新，以獲取有關發布的資訊。
為了在格蘭斯特丹於主網上啟動之前驗證您的設定，您可以在測試網上運行驗證者。測試網分叉也會在郵件清單與部落格中宣布。
### 格蘭斯特丹將包含哪些 L1 擴容的改進？ {#what-improvements-will-glamsterdam-include-for-l1-scaling}
焦點功能是 ePBS (EIP-7732)，它將驗證網路交易的繁重任務與達成共識的任務分開。這將資料傳播窗口從 2 秒擴展到大約 9 秒，解除了以太坊安全處理更高交易吞吐量並為第二層 (L2) 網路容納更多資料 Blob 的能力限制。
### 格蘭斯特丹會降低以太坊（第一層）的費用嗎？ {#will-glamsterdam-lower-fees-on-ethereum-layer-1}
是的，格蘭斯特丹極有可能會降低日常使用者的費用！降低內在交易 Gas (Reduce intrinsic transaction gas，或 EIP-2780) 降低了發送 ETH 的基礎費用，使得使用 ETH 進行日常支付變得便宜得多。
此外，為了長期永續性，格蘭斯特丹引入了區塊級存取清單 (BALs)。這實現了平行處理，並為 L1 在未來安全處理更高的整體 Gas 限制做好了準備，隨著容量的增長，這可能會降低每筆交易的 Gas 成本。
### 在格蘭斯特丹升級之後，我現有的智能合約會有任何改變嗎？ {#will-my-smart-contracts-change}
現有的合約在格蘭斯特丹升級後將繼續正常運作。開發人員可能會獲得幾個新工具，並且應該審查他們的 Gas 使用量：
- 增加最大合約大小 (Increase maximum contract size，或 EIP-7954) 允許開發人員部署更大的應用程式，將最大合約大小限制從大約 24KiB 提高到 64KiB。
- 確定性工廠預先部署 (Deterministic factory predeploy，或 EIP-7997) 引入了一個通用的、內建的工廠合約。它允許開發人員將他們的應用程式與智能合約錢包部署到所有參與的 EVM 鏈上完全相同的地址。
- 如果您的應用程式依賴複雜的追蹤來尋找 ETH 轉帳，ETH 轉帳與銷毀發出日誌 (ETH transfers and burns emit a log，或 EIP-7708) 將允許您改用日誌來進行更簡單、更可靠的記帳。
- 狀態建立 Gas 成本增加 (State creation gas cost increase，或 EIP-8037) 與狀態存取 Gas 成本更新 (state-access gas cost update，或 EIP-8038) 引入了新的永續性模型，這將改變某些合約部署成本，因為建立新帳戶或永久儲存將根據建立的資料大小收取新的標準化固定費用。
### 格蘭斯特丹將如何影響節點儲存與硬體要求？ {#how-will-glamsterdam-affect-node-storage-and-hardware-requirements}
考慮納入格蘭斯特丹的多個 EIP 解決了狀態增長的效能懸崖問題：
- 狀態建立 Gas 成本增加 (State creation gas cost increase，或 EIP-8037) 引入了固定成本框架 (CPSB)，目標是實現每年 120 GiB 的狀態資料庫增長率，確保標準實體硬體可以繼續有效率地運行網路。
- eth/70 部分區塊收據清單 (eth/70 partial block receipt lists，或 EIP-7975) 允許節點請求分頁的區塊收據，這將資料繁重的區塊收據清單分解成更小的區塊，以防止在以太坊擴展時發生崩潰與同步問題。