以太坊扩展之路：从短期优化到长期演进

最近我一直在思考以太坊面临的核心挑战：随着生态规模指数级增长，我们如何在保持安全性和去中心化这两个根本原则的同时，让网络真正实现大规模扩展？这个问题其实困扰着整个社区很久了。Vitalik Buterin最近的一篇技术梳理给了我不少启发，他把扩展路径清晰地分成了短期和长期两个阶段。简单来说，短期内我们主要通过Gas机制优化和区块验证并行化来提升执行效率，而长期则要依靠ZK-EVM和blobs数据架构这些更根本的技术革新。

说实话，这种分阶段推进的思路很务实。就像盖房子，你不能一下子把所有新技术都用上，得先打好地基，再一层层往上建。以太坊的扩展方案也是同样的道理。

欧意官网地址：点击进入〉〉〉

欧意app下载地址：点击下载〉〉〉

币安官网地址：点击进入〉〉〉〉

币安app下载地址：点击下载〉〉〉

短期扩展：从Gas优化入手

说到短期扩展，我在研究这些方案时发现，核心思路其实很直观——就是让区块验证变得更高效。让我来具体解释一下。

首先，区块级访问列表（block-level access lists）是个很巧妙的设计，它能让区块验证实现并行化。这就像超市结账时开了多个收银台，而不是所有人都排一个队。ePBS（enshrined proposer-builder separation）也将在Glamsterdam升级中推出，它有个特别实用的特性：允许我们安全地使用每个slot中更大比例的时间来验证区块。说实话，现在只用几百毫秒确实太紧张了。

Gas重新定价（gas repricing）则确保各类操作的gas成本与其实际执行时间相匹配。这让我想起了餐厅按实际消费收费，而不是固定套餐价。我们还在探索多维gas机制，让不同资源能够分别设置上限。根据我的经验，这两者结合后，我们就能在验证区块时使用更大比例的slot时间，而不用太担心极端情况的出现。

关于多维gas，我们制定了一条很务实的分阶段路线图。第一阶段是在Glamsterdam升级中，将“状态创建成本”与“执行和calldata成本”分离。举个例子，目前SSTORE操作的费用结构是：如果存储槽从非零→非零，费用是5000 gas；从零→非零，费用是20000 gas。在Glamsterdam的gas重定价中，这个额外成本会被显著提高到60000左右。这样做的目标很明确：在提高gas上限的同时，让执行能力的扩展速度远高于状态规模的扩展速度。

所以在Glamsterdam中，这个SSTORE操作将消耗5000的“普通gas”和大约55000的“状态创建gas”。这里值得一提的是，状态创建gas不会计入约1600万的交易gas上限。这意味着创建比现在更大的合约将成为可能，这对开发者来说应该是个好消息。

多维Gas在EVM中如何实现

实现多维gas时我们遇到了一个技术难题：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定价

之后我们会进一步引入多维定价，让不同资源维度拥有不同的浮动gas价格。这让我联想到机票价格会根据季节和需求浮动，确实能带来更好的资源配置效率。

从长远来看，这种设计能带来更好的经济可持续性。而reservoir机制正好解决了之前那篇文章最后提到的子调用问题，这是个很巧妙的解决方案。

长期扩展：面向未来的架构革新

长期扩展主要围绕两个方向：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等方向。这让我想到技术演进就像河流，总会在阻力最小的地方开辟新的航道。