编者按:随着以太坊生态规模不断扩大,如何在不牺牲安全性与去中心化的前提下实现网络扩展,成为核心议题。本文中,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 中消耗。
例如,如果你拥有:(100000 状态创建 gas, 100000 reservoir)
如果你用 SSTORE 创建三次新状态,gas 的变化过程是:(100000, 100000)→ (45000, 95000)→ (0, 80000)→ (0, 20000)
在这种设计下:
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
