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），開發者需要自己想辦法來優化。

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