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），链下聚合可以将性能提升约 10000 倍。
对于数据资源，短期通过 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），开发者需要自己想办法来优化。
这种策略相当有趣，颇有点开发者动动脑子降低成本，广大以太坊用户从中受益的意味。
