未來5年，Vitalik將這樣擴展以太坊

2026年2月27日，Vitalik Buterin在Ethereum Research上發表了一篇標題為「Hyper-scaling state by creating new forms of state（通過創建新形式的狀態來實現超高擴展性）」的長文。

在本文中，Vitalik Buterin進一步梳理了以太坊的擴展路徑。這篇文章不僅僅是從技術角度來談論以太坊的擴展，更是從一個整體的架構角度，提供了一套分階段推進的擴展方案，旨在為以太坊在未來幾年持續擴大網路容量提供基礎。

同時，他也在X上發表了一篇推文，進一步對這篇文章進行了解釋。我們嘗試深入淺出地來理解，Vitalik此次新提出的擴展方案究竟是什麼，又到底為什麼要這麼做。

執行資源與數據資源的短期與長期擴展

Vitalik在長文的開頭指出，「為了在未來五年內擴展以太坊，需要擴展三種資源」：

- 執行資源：EVM 計算、簽名驗證等

- 數據資源：交易的發送者、接收者、簽名等

- 狀態資源：帳戶餘額、程式碼、存儲

前兩者有著短期和長期的擴展方案。

對於執行資源，短期通過區塊訪問列表（BAL）、ePBS和Gas費重定價來實現約10-30倍的增長，長期通過ZK-EVM來實現約1000倍的增長，並且對於某些特定類型的計算（簽名、SNARK/STARK），鏈下聚合可以將性能提升約10000倍。

對於數據資源，短期通過p2p改進和多維度Gas來實現約10-20倍的增長，長期通過Blobs + PeerDAS來實現約500倍的增長。

短期的擴展著眼於讓以太坊跑得更快。現在以太坊的慢，是因為現在的驗證方式是串行的——一個接一個地檢查交易。如果某個交易卡住了，整個驗證過程就卡住了。

所以接下來今年的Glamsterdam升級，會推出區塊訪問列表（BAL）與ePBS。

区塊訪問列表使區塊打包者提前告訴驗證器：「這個區塊裡的交易，會訪問這些帳戶和存儲位置」。有了這個資訊，驗證器就可以提前準備，把這些數據從硬碟加載到內存。然後，驗證器可以並行檢查多個交易，而不是一個一個地檢查。就像工廠的流水線：以前是一個工人負責整個產品，現在是多個工人同時處理不同的部分。

ePBS 則是把區塊的打包和驗證過程分開——區塊構建者負責打包交易，提議者負責提議區塊，驗證器負責驗證區塊。每個角色各司其職，都做好自己的這部分工作，那麼區塊構建者就可以更激進地打包更多交易，因為提議者和驗證器會幫他檢查，不必擔心安全性問題。

Gas 費重定價 + 多維度 Gas 可能可以說是「核心招式」。現在，以太坊所有的操作都用同一種 Gas 費。但 Vitalik 的想法是，不同的操作應該有不同的價格。

特別是，創建新狀態（比如創建新帳戶、部署新合約）應該有特殊的「狀態創建費」。因為創建新狀態是最昂貴的操作。它不僅佔用計算資源，還佔用存儲資源。而且，這個成本是永久的——一旦創建，這個狀態就會一直存在。

所以，Vitalik 的想法是：讓創建新狀態變得更貴，但讓普通交易變得更便宜。

實現的方法是「水庫機制」。想象有兩個桶，一個庫裝「狀態創建費」，另一個庫裝「普通 Gas 費」。合約互相調用時，Gas 會自動從兩個庫裡借，保證不會亂。

普通用戶的交易將變得更便宜，因為這些交易不用交「狀態創建費」。而想要創建新狀態的開發者，則需要支付更高的費用。這樣，網路的整體容量暴增，但狀態增長被控制住了，不會讓全節點的硬碟爆炸。

長期的拓展是讓主網自身做大做強，減少對 Layer 2 的依賴。這包括 Blobs + PeerDAS 與 ZK-EVM 的分階段 Rollout。

Blobs，一種臨時的大文件存儲，現在主要給 Layer 2 用。以後，以太坊主網自己也會用 Blobs 來存儲數據。但問題也隨之而來——如果每個節點都要下載所有的 Blobs，那網路會被撐爆。

這裡就要靠 PeerDAS——不用下載全部數據，只需要下載一小部分。就像抽樣調查，不需要問每一個人，只需要問一小部分人，就能推斷出整個群體的情況。結合 ZK 證明，即使只下載了全部數據的 1/16，你也能確認數據完整性。

然後是 ZK-EVM 的分階段 Rollout，這使得驗證一個區塊不再需要重新執行區塊裡的所有交易，節點直接去相信 ZK 證明就好，驗證的成本就從「執行所有交易」降低到「驗證一個 ZK 證明」。

Vitalik 的計劃是，2026 年，部分節點試用 ZK 驗證。到 2027 年，鼓勵更多節點使用。最後，一個區塊要有效，必須包含來自不同證明系統的 5 種證明類型中的 3 種。他預計，所有節點（索引節點除外）最後都將依賴於 ZK-EVM 證明。

沒有「靈丹妙藥」的狀態擴展

現在讓我們看看短期與長期擴展中還沒有談到的「狀態資源」。儘管在短期，仍然能夠通過與區塊訪問列表同步、p2p 改進以及數據庫優化等方式提升約 5-30 倍，但長期呢？

Vitalik 的答案是，沒有。

為什麼狀態資源這麼難擴展？以太坊的狀態就像一個巨大的數據庫。這個數據庫裡存著所有帳戶的餘額、所有合約的代碼、所有存儲位置的數據。

現在這個數據庫還不大，只有大約 100 GB，但如果把狀態擴展 20 倍，就是 2 TB。那時間再長一些呢？8 TB？

問題不在於硬碟裝不下，而是：

- 數據庫效率受到影響：現代數據庫使用樹結構（比如 Merkle 樹）來組織數據。當寫入一個新數據時，需要更新整棵樹。這意味著，如果你要做 X 次更新，在數據庫層面就又是 X 次操作，而不是更新一次，數據庫操作一次就行了。更新越多，操作越多，寫入會慢到爆炸。

- 同步困難：一個新加入以太坊網路的節點，需要下載整個狀態，才能驗證新的區塊。如果數據規模到 8 TB，大多數人當前的網速又要下很久。

解決方案是有的，但 Vitalik 認為都有問題：

- 「強狀態無狀態性」：節點不需要存儲完整的狀態，只需要用戶提供 Merkle 證明。Vitalik 認為，這個方案存在狀態存儲的中心化、動態存儲訪問導致交易失敗以及帶寬成本問題。

- 「狀態過期」：不經常訪問的狀態，自動從活躍狀態中刪除。節點只需要存儲最近訪問過的狀態，就能大大減少存儲空間。Vitalik 認為存在一個根本性的「存在問題」，即創建一個新狀態時，如何證明某狀態「從未存在」。假設創建一個新帳戶，那麼就需要證明，新帳戶地址在以太坊上從未被創建過。這意味著，每個新帳戶的創建，都需要檢查 10 年的歷史數據，創建新帳戶將變得複雜且昂貴。

Vitalik 最終的方法是，結合這兩種方案，提出幾種新的狀態形式，這是對以太坊狀態資源架構的整體變更：

- 臨時存儲：一種會自動過期的存儲。比如，可以創建一個新的樹，每個月自動清零。這種存儲可以用於臨時數據，訂單簿、流動性池、臨時計數器等這些數據通常不需要永久存儲，一個月後，舊的訂單過期了，新的流動性池又創建了。

- 週期性存儲：與臨時存儲類似，但周期更長，比如 1 年。

- 受限存儲：某些存儲只能以特定方式訪問。比如，一個 ERC20 代幣的餘額存儲，可能只能通過特定的接口訪問。這樣，系統就可以對這種存儲進行優化。

同時，保留現有的狀態形式。這樣，執行可能便宜 1000 倍（通過 ZK-EVM），但新狀態創建可能只便宜 20 倍。

Vitalik 認為，有了新的狀態形式，開發者就有了選擇。繼續使用現有的狀態形式，但支付更高的費用，或是重新設計應用，使用新的狀態形式，獲得更低的費用。對於常見的用例（比如 ERC20 餘額、NFT），會有標準化的工作流，而對於更複雜的用例（比如 DeFi），開發者需要自己想辦法來優化。

這種策略相當有趣，頗有點開發者動動腦子降低成本，廣大以太坊用戶從中受益的意味。