主要标题

不知道大家有没有关注到，Vitalik Buterin在2月底干了件大事。就在2月27日那天，他在以太坊研究论坛（Ethereum Research）上扔出了一篇重磅长文，标题挺绕口的，叫《通过创建新形式的状态来超级扩展状态》。

说实话，读到这篇长文时，我的第一感觉是：V神这次谈扩展，格局打开了。他不再只是盯着某个具体的技术瓶颈敲敲打打，而是从整体架构的层面上，给我们勾勒出了一套分阶段实施的“扩展路线图”。这显然是在为未来几年以太坊网络容量的持续扩大，提前打下坚实的地基。

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

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

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

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

为了帮助大家理解，他随后还在X（就是原来的推特）上发了一条推文做补充说明。今天，我就想跟大家聊得透一点：Vitalik这次提出的新扩展方案，究竟葫芦里卖的什么药？而他之所以这么做，背后的深层考量又是什么？

执行资源与数据资源的短期与长期拓展

执行资源、数据资源与状态资源

文章一开头，Vitalik就提纲挈领地指出：“为了在未来五年内扩展以太坊，我们得搞定三种核心资源。” 在我来看，这个分类非常精辟：

首先是执行资源，就是EVM计算、签名验证这些“干活”的部分。其次是数据资源，主要指交易本身携带的信息，比如发送者、接收者、签名等。最后是状态资源，这也是最棘手的一个，它指的是那些需要被持久化记住的东西，比如账户余额、智能合约代码、存储数据。

有意思的是，前两种资源——执行和数据——在Vitalik的蓝图里，其实已经有了清晰的短期和长期拓展路径。

短期方案：让以太坊“跑”起来

先说执行资源。短期来看，依靠区块访问列表（BAL）、ePBS（以太坊提议者-构建者分离）和Gas费重定价这几招组合拳，大概能实现10到30倍的性能提升。而长期目标呢？那就要靠ZK-EVM了，理论上能带来约1000倍的惊人增长。对于一些特殊计算，比如签名验证和零知识证明，甚至能通过链下聚合实现万倍提升。

再看数据资源。短期内，通过对等网络（p2p）的改进和多维度Gas费设计，预计能提升10-20倍。长期则要依靠Blobs（数据块）加上PeerDAS（对等数据可用性抽样）技术，目标是500倍的扩容。

你可能会问，这些短期方案具体是怎么让以太坊“跑”得更快的？根据我的观察，现在以太坊慢，一个重要原因是验证交易的方式太“耿直”了——得像排队一样，一个接一个地顺序检查。只要有一个交易卡壳，后面全都得等着。

所以，今年计划中的“Glamsterdam”升级，核心就是引入区块访问列表（BAL）和ePBS。打个比方，BAL就像是区块打包者提前给验证者发了一份“物料清单”：“我这批交易，只会用到这些账户和存储位置。” 验证者拿到清单，就能提前把需要的数据从硬盘加载到内存里准备好。这样一来，验证者就能同时检查多个交易，就像把单线手工流水线改成了并行作业的现代化车间，效率自然就上去了。

而ePBS则是更彻底的“专业化分工”。它把区块的打包、提议和验证三个角色彻底分开，各司其职。区块构建者可以更放心大胆地打包更多交易，因为安全性检查的工作有专门的提议者和验证者来负责兜底。

核心招式：Gas费“分家”与“水库”机制

在我看来，Gas费重定价加上多维度Gas，可以说是这整套短期方案里的“核心招式”。现在的情况是，以太坊上啥操作都用一个统一的Gas费来计价，这其实不太合理。

Vitalik的想法是，不同类型的操作，成本天差地别，收费也应该区别对待。特别是创建新状态（比如开个新账户、部署个新合约），这应该被征收一笔特殊的“状态创建费”。为什么？因为这是整个系统里最“昂贵”的操作。它不光消耗计算资源，还永久性地占用了存储空间——这个成本一旦产生，就会一直跟着网络。

所以，他的思路很明确：让创建新状态变得更贵，但同时让那些不创建新状态的普通交易变得更便宜。这听起来有点矛盾，怎么实现呢？这里就不得不提一个巧妙的“水库机制”设计。

我们可以想象有两个“水桶”（或者说资金池），一个专收“状态创建费”，另一个收“普通Gas费”。当合约之间相互调用时，系统会自动从这两个池子里按需“借出”Gas，确保整个过程既清晰又不会乱套。

这么一改，效果就出来了：普通用户的转账等操作会明显便宜，因为他们不用分摊高昂的状态创建成本；而那些确实需要创建新状态的开发者，则必须支付相应的“高额入场费”。结果就是，网络整体的交易处理容量（TPS）能获得巨大提升，同时状态的增长速度又被有效控制住了，避免了全节点的硬盘被迅速“撑爆”。

长期愿景：主网“做大做强”

长期方案的思路更宏大，目标直指让以太坊主网自身变得更强，从而减少对Layer 2的绝对依赖。这主要围绕Blobs + PeerDAS和ZK-EVM的分阶段推出展开。

Blobs目前主要是给Layer 2用来存放数据的“临时大文件存储”。未来，以太坊主网自己也会用它来存数据。但问题来了：如果每个节点都得下载全部Blobs数据，网络马上就得被挤瘫痪。

这时候PeerDAS就派上用场了。它的核心理念是“抽样检测”：每个节点不需要下载全部数据，只需要下载并验证一小部分。这就像做人口普查，不用问遍全国每一个人，只需要科学地抽样调查一部分，就能可靠地推断整体情况。再结合ZK证明技术，即使一个节点只保存了全部数据的1/16，它也能确信所有数据的完整性和可用性。这个设计非常巧妙。

另一个重头戏是ZK-EVM的分阶段落地。一旦实现，验证一个区块的有效性就不再需要傻傻地重新执行里面的每一笔交易，节点只需要相信并验证一个附带的ZK证明就行了。验证成本就从“执行N笔交易”直接降为“验证1个证明”。

根据Vitalik的规划，这个过程是循序渐进的：2026年，先让一部分节点试用ZK验证；2027年，鼓励更多节点加入；最终，一个区块想要被确认有效，必须包含来自不同证明系统的至少3种证明。他预计，未来除了少数索引节点，所有节点最终都将依赖ZK-EVM证明来工作。

没有“灵丹妙药”的状态拓展

聊完了前两者，现在让我们把目光转向那个在短期和长期方案里都语焉不详的“硬骨头”——状态资源。

短期内，通过和区块访问列表同步、优化p2p网络、改进数据库引擎这些手段，状态访问效率提升个5到30倍是有可能的。但长期呢？Vitalik给出的答案非常直接：没有像前两者那样清晰的“银弹”方案。

为什么扩展状态资源这么难？你可以把以太坊的状态想象成一个超级庞大的、不断生长的数据库，里面记录着每一个账户的余额、每一段合约代码、每一个存储位置的数据。目前这个数据库大概100GB，如果扩展20倍就是2TB。那再过几年呢？8TB？甚至更多？

问题关键不在于硬盘存不下（现在硬盘便宜），而在于两个更深层的挑战：

1. 数据库效率问题： 现代数据库多用Merkle树这类树形结构组织数据。每次写入新数据，都需要更新从叶子节点到根节点的整条路径。这意味着，应用层面做X次更新，在数据库底层可能引发远多于X次的操作。随着写入越来越频繁，操作会指数级增加，最终让写入速度慢到无法忍受。

2. 新节点同步难题： 一个新节点加入网络，必须下载并验证从创世区块到最新的完整状态，才能开始正常工作。如果状态膨胀到8TB，以大多数人目前的家庭宽带，光同步数据就得下到“天荒地老”，这严重损害了网络的去中心化。

现有方案的局限与Vitalik的新思路

当然，社区也不是没提出过解决方案，但Vitalik觉得它们各自都有明显的“阿喀琉斯之踵”：

强状态无状态性： 简单说，就是节点不用存完整状态，交易时需要用户自己提供Merkle证明。但Vitalik指出了几个痛点：可能导致“状态存储”这件事变得中心化（只有少数专业节点存）；动态访问存储时容易因证明不全导致交易失败；而且频繁生成和传输证明的带宽成本也不低。

状态过期： 让不经常访问的“冷状态”自动从活跃内存中清除。节点只保留最近用过的“热状态”，能极大节省存储空间。但这个方案有个根本性的哲学难题，我称之为“不存在证明”困境。比如，你要创建一个全新的账户地址，你必须向网络证明“这个地址在以太坊的整个历史中都从未被创建过”。这意味着，每创建一个新账户，理论上都得把过去十年的历史数据翻查一遍，这会让创建账户变得极其复杂和昂贵。

破局之道：创造“新形式”的状态

既然旧的思路走不通，Vitalik的破局方法就显得很有创意了：他提议不完全抛弃现有方案，而是结合它们的长处，创造几种“新形式的状态”。这本质上是对以太坊状态资源架构的一次整体升级：

1. 临时存储： 一种会“自动清零”的存储。比如，可以新建一棵Merkle树，设定其生命周期为一个月。到期后，树里的数据自动失效。这特别适合那些天然具有时效性的数据，比如订单簿的挂单、临时性的流动性池、或者一些计数器。这些数据通常没必要永久留存，一个月后，旧的订单失效，新的池子又会建起来。

2. 周期性存储： 和临时存储类似，但周期更长，比如一年。适合一些中长期但非永久的数据。

3. 受限存储： 给某些存储加上“访问限制”。例如，一个ERC20代币的余额存储，可能规定只能通过标准代币接口来读写。系统就可以针对这种 predictable（可预测）的访问模式进行深度优化。

最重要的是，现有的、完全永久且无限制的状态形式依然会被保留。这样一来，未来可能会出现一种有趣的局面：通过ZK-EVM，执行可能便宜了1000倍，但创建全新的永久状态，可能只便宜了20倍。 这个价差会形成一种强大的经济激励。

Vitalik认为，一旦引入了这些新的状态形式，开发者就面临选择了：要么继续沿用老式的、永久的状态，但支付高昂的费用；要么主动重新设计你的应用逻辑，去适配临时性或周期性的新状态，从而享受低廉的成本。对于ERC20、NFT这些标准用例，社区肯定会总结出最佳实践；而对于更复杂的DeFi协议，就需要开发者们各显神通，自己动手做优化了。

在我看来，这个策略相当高明，颇有点“让开发者多动脑筋来优化设计，从而让广大以太坊用户最终受益”的意味。它没有强行推行一个一刀切的方案，而是通过架构创新和经济调节，引导整个生态朝着更可持续的方向演化。这很Vitalik，不是吗？