未來 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），鏈下聚合可以將效能約 1000 倍。

對於資料資源，短期透過 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），開發者需要自己想辦法優化。

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