原文作者：@VitalikButerin
翻譯：Peggy，BlockBeats

編者按：隨著以太坊生態系規模不斷擴大，如何在不牺牲安全性與去中心化的前提下實現網路擴展，成為核心議題。本文中，Vitalik Buterin 進一步梳理了以太坊的擴展路徑：短期通過 Gas 機制優化、區塊驗證並行化等技術改進提升執行效率，長期則依靠 ZK-EVM 與 blobs 資料架構推動網路規模提升。

整體來看，這一路線提供了一套分階段推進的擴展方案，旨在為以太坊在未來幾年持續擴大網路容量提供基礎。

以下為原文：

現在談談擴展（scaling）。這裡主要分為兩部分：短期擴展和長期擴展。

短期擴展

關於短期擴展，我在其他地方已經寫過一些。核心思路大致如下：

·區塊級訪問列表（block-level access lists）（將在 Glamsterdam 升級中推出）可以讓區塊驗證實現並行化。

·ePBS（同樣將在 Glamsterdam 推出）具有多項特性，其中之一是：它讓我們能夠安全地使用每個 slot 中更大比例的時間來驗證區塊，而不是像現在這樣只用幾百毫秒。

·Gas 重新定價（gas repricing）會確保各類操作的 gas 成本與其實際執行時間（以及它們帶來的其他成本）保持一致。我們也在早期探索多維 gas（multidimensional gas）機制，使不同資源能夠分別設定上限。這兩者結合起來，可以讓我們在驗證區塊時使用更大比例的 slot 時間，而不必擔心極端情況的出現。

關於多維 gas，我們制定了一條分階段的路線圖。第一階段是在 Glamsterdam 升級中，將「狀態創建成本」與「執行和 calldata 成本」分離。

例如，目前：一個 SSTORE 操作，如果把存儲槽從 非零 → 非零，費用是 5000 gas；如果從 零 → 非零，費用是 20000 gas。

在 Glamsterdam 的一次 gas 重定價中，這個額外成本會被顯著提高（例如提高到 60000）。這樣做的目標是，在提高 gas 上限的同時，讓執行能力的擴展速度遠高於狀態規模的擴展速度。

關於原因，我之前已經寫過：https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

因此，在 Glamsterdam 中：這個 SSTORE 操作將消耗5000 的「普通 gas」，例如 55000 的「狀態創建 gas」

需要注意的是：狀態創建 gas 不會計入約 1600 萬的交易 gas 上限。

這意味著：創建比現在更大的合約將成為可能。

多維 Gas 在 EVM 中如何實現？

這裡會出現一個問題：EVM 的設計預設 gas 只有一個維度，例如 GAS、CALL 等 opcode 都基於這個假設。

我們的解決方法是保持兩個不變量：

如果你用 X gas 發起一個 call，那麼這個 call 將擁有 X gas，可以用於「普通操作」、或「狀態創建」、或未來可能新增的其他維度。

如果 GAS opcode 告訴你當前有 Y gas，然後你發起一個消耗 X gas 的 call，那麼在 call 返回之後，你仍然至少有 Y − X gas，可以用於後續操作。

具體實現方式是：我們引入 N+1 個 gas 維度。預設情況下 N = 1（狀態創建），額外的一個維度稱為 reservoir（儲備池）。

EVM 的執行邏輯是：

如果可能，優先消耗專用維度的 gas

如果不夠，再從 reservoir 中消耗。

例如，如果你擁有：(100,000 狀態創建 gas, 100,000 reservoir)

如果你用 SSTORE 創建三次新狀態，gas 的變化過程是：(100,000, 100,000)→ (45,000, 95,000)→ (0, 80,000)→ (0, 20,000)

在這種設計下：

GAS opcode 返回的是 reservoir

CALL 會從 reservoir 中傳遞指定數量的 gas，並同時傳遞所有非 reservoir gas

多維 Gas 定價

之後我們會進一步引入多維定價（multi-dimensional pricing），讓不同資源維度擁有不同的浮動 gas 價格。

這將帶來：

更好的長期經濟可持續性

更優的資源配置效率

詳見：https://vitalik.eth.limo/general/2024/05/09/multidim.html

而 reservoir 機制正好解決了那篇文章最後提到的 子調用（sub-call）問題。

長期擴展

長期擴展主要包括兩個方向：ZK-EVM 和 Blobs。

Blobs

對於 blobs，我們計劃持續迭代 PeerDAS，最終希望達到大約 8 MB/秒的數據吞吐能力。

這個規模：

足夠滿足以太坊自身需求

並不打算成為一個「全球數據層」。

目前，blobs 主要用於 L2。未來計劃是讓 以太坊區塊數據本身直接寫入 blobs。

這樣做的目的，是讓人們能夠在不下載並重新執行整條鏈的情況下驗證一個高度擴展的以太坊網絡：

ZK-SNARKs 消除了重新執行的需求

PeerDAS + blobs 允許在不下載全部數據的情況下驗證數據可用性

ZK-EVM

對於 ZK-EVM，我們的目標是逐步提高網絡對它的依賴程度。

2026 年：將出現支持 ZK-EVM 的用戶端，使節點可以用 ZK-EVM 參與 attestation。但它們還不足夠安全，不能讓整個網絡依賴它運行。不過，如果約 5% 的網絡使用它們是可以接受的。（如果 ZK-EVM 出現問題，你不會被罰沒質押，但可能會構建在無效區塊上，從而損失收益。）

2027 年：我們會開始建議更大比例的節點運行 ZK-EVM，同時把重點放在形式化驗證和安全性提升上。即使只有 20% 的網絡使用 ZK-EVM，也可以讓我們顯著提高 gas limit，因為這為 solo staker 提供了一條低成本驗證路徑，而 solo staker 的比例本身也不到 20%。

技術成熟後：我們將引入 3-of-5 強制證明機制。也就是說，一個區塊必須包含 5 種不同證明系統中的至少 3 個證明，才能被視為有效。到那時，我們預計除了需要做索引的節點之外，大多數節點都會依賴 ZK-EVM 證明。

長期：繼續改進 ZK-EVM，使其更加穩健，並進行更嚴格的形式化驗證。這一階段也可能涉及虛擬機層面的改變，例如 RISC-V 等方向。

詳見：https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia