Glamsterdam vs Dencun vs Fusaka：以太坊升級路徑有哪些差異？

Glamsterdam、Dencun、Fusaka 的核心差異在於各自聚焦的問題領域不同：Dencun 著重於階段性的容量與使用體驗，Fusaka 著眼於中程的協同過渡，而 Glamsterdam 則專注於出塊協作與執行約束的結構重塑。如果將這三者視為同類型的替代方案，容易誤判升級的實際價值與實施難度。

Glamsterdam 升級全景將 Glamsterdam 放在 Lean Ethereum 路線中解讀；以下以對比角度說明：三次升級各自解決哪些痛點？為何 Glamsterdam 在路線圖推進階段會被視為關鍵承接點？

Dencun 是什麼？主要解決哪些問題？

Dencun 是以太坊連續升級路徑中針對容量與可用性的重要節點，核心目標為優化階段性使用體驗，主要機制包含 proto-danksharding（EIP-4844）等，旨在降低 L2 資料可用性成本，並改善擴容過程中的費用結構。對一般用戶及 L2 生態來說，Dencun 的效果較為直觀，常體現在 L2 交易成本及資料提交效率的變化。

Dencun 並未解決出塊協作邊界或並行執行的前置約束問題。其價值在於為後續升級累積容量經驗，同時驗證生態對協議變更的適應能力。若將 Dencun 的成功標準直接套用於 Glamsterdam，評價會出現維度錯置。

Fusaka 是什麼？在升級路徑中扮演什麼角色？

Fusaka 可視為承上啟下的協同優化階段，關注多元組件於中程週期內如何順利過渡。它更偏向「系統聯動調優」階段，而非獨立定義長期架構方向。Fusaka 的價值在於減少升級之間的斷層，為客戶端、基礎設施及應用團隊提供更連續的適配窗口。

Fusaka 與 Glamsterdam 並非競爭關係，而是接力關係。Fusaka 降低後續結構變更的協同摩擦，Glamsterdam 則進一步重塑協議邊界。理解 Fusaka 的過渡屬性，有助於說明為何 Glamsterdam 的討論更專注於工程機制，而非單一費率指標。

Glamsterdam 是什麼？與 Dencun、Fusaka 有何不同？

Glamsterdam 觸及更深層次的結構議題：包括出塊協作邊界（ePBS（EIP-7732）機制）及執行前約束（BAL（EIP-7928）與並行執行）。根據 Ethereum.org 路線圖記載，該升級已列入主網推進重點，但相關機制討論並不依賴單一時程，而是根據測試網驗證及客戶端成熟度數據推進。

從上表可見，Glamsterdam 的討論天生更偏向「機制化」。不僅關心「是否更快」，更進一步追問「為何更穩、誰負責、如何驗證」。

圖 1. Dencun、Fusaka 與 Glamsterdam 的目標與機制差異對照圖。

三次升級對一般用戶的體感有何不同？

一般用戶在 Dencun 階段較容易感受到交易成本及 L2 可用性的變化。Fusaka 階段的影響則較為間接，主要體現在系統穩定度及過渡順暢度。Glamsterdam 的體感可能表現在高負載時系統行為更可預測，但改善幅度與節奏會因生態適應狀況而異。

因此，升級帶來的用戶體驗不會每次都以相同方式展現。若將所有升級都套用「立刻降費」的模型，會忽略不同升級目標所產生的差異。用戶更穩妥的預期，是關注交易穩定性及高峰時段體驗的可解釋性，而非單一費率的承諾。

三次升級對開發者與基礎設施方的影響有何不同？

Dencun 階段，開發者重點在於成本及可用性策略。Fusaka 階段則著重於兼容性及遷移協同。進入 Glamsterdam，重點轉為執行假設審核、監控體系升級及上線策略分層。

基礎設施方在 Glamsterdam 階段需投入更多「機制理解成本」。結構邊界的調整會影響告警設計、故障定位及回滾策略。節點升級準備清單提供分層灰度、指標監控及回滾閉環的操作架構；Glamsterdam 對 DApp 的影響則補充應用指標重設及發布節奏，是基礎設施與應用團隊協同適配的實用參考。

此表有助於團隊依據角色分配適配資源，避免將 Dencun 經驗直接套用於 Glamsterdam 準備流程。

為什麼 Glamsterdam 是 Lean Ethereum 的關鍵承接點？

Lean Ethereum 指向長期發展方向，而 Glamsterdam 提供階段性工程施力點。它將長期路線拆解為可驗證的任務：協作邊界是否清晰、狀態約束是否前置、執行行為是否可預測。只要這些問題持續得到驗證，長期路線就有落地基礎。

Glamsterdam 熱度上升的主因，是討論焦點從抽象願景轉向具體可執行的工程任務。團隊可圍繞 ePBS、BAL 建立測試清單、監控指標與檢討模板，使升級討論具備可操作的評估標準。

三次升級各自的風險與不確定性為何？

三次升級皆有實施節奏、實現品質及生態同步的風險，但權重各異。Dencun 主要風險在於容量預期與實際落差，Fusaka 則在於協同鏈路中斷，Glamsterdam 則更擔憂結構變更帶來的實現不一致。

風險評估應著重「風險類型差異」而非「風險絕對多寡」。不同升級對應不同失敗模式，監控與應對策略亦須分別設計。若路線圖時程因測試反饋調整，屬於工程治理常態，並不必然代表機制方向變更。

總結

Dencun、Fusaka、Glamsterdam 是同一路線上的連續分工，不是彼此替代的版本競爭。理解這一路徑的核心，是將每次升級放回其專屬問題域：容量體驗、協同過渡、結構治理。Glamsterdam 的獨特之處在於，將以太坊升級討論推向機制邊界及工程可驗證層級。

FAQ

Glamsterdam 和 Dencun 最大的差異是什麼？

兩者重點不同。Dencun 著重於階段性可用性與擴容體驗，Glamsterdam 則聚焦於出塊協作與執行約束的結構重塑。

Fusaka 在三者中扮演什麼角色？

Fusaka 屬於中程過渡階段，重點在多組件協同與順暢遷移，為後續結構升級創造更穩健的實施條件。

為什麼 Glamsterdam 會被單獨討論？

因為它聚焦於具體機制問題及執行清單，討論對象從抽象願景轉向可執行工程任務，搜尋意圖也更明確。

開發團隊應優先關注哪些資訊？

應優先追蹤機制級更新、客戶端實現進度與測試網回饋，再依應用自身路線進行兼容性驗證與上線節奏調整。

Dencun 成功是否代表 Glamsterdam 必然順利？

不可直接類推。Dencun 驗證的是容量路徑與生態適應性，Glamsterdam 面臨的是不同層級的結構變更，風險類型與準備重點並不相同。

一般用戶需要為 Glamsterdam 進行特別操作嗎？

多數情況下無需額外鏈上遷移。關鍵是核對錢包、交易所及 Ethereum.org 等公開升級說明，並與客戶端發布資訊保持一致。