Vitalik：扩展 Rollups 的分步路线图

对于以太坊而言，Rollups 是短中期，也可能是长期的唯一无须信任的可扩展性解决方案。以太坊 L1 上的交易费在几个月以来一直很高，现在更迫切的是采取一切必要的行动，帮助推动整个生态系统转移到 Rollups。Rollups 已经大大降低了许多以太坊用户的费用：l2fees.info 网站时常显示 Optimism 和 Arbitrum 网络的费用要比以太坊基础层本身低了约 3-8 倍，而 zk-Rollups 有着更好的数据压缩，并且可以避免包含签名，因此其费用要比以太坊基础层低约 40-100 倍。

然而，对于许多用户来说，即便是这些 (Rollups中的) 费用也还是太过昂贵了。很长一段时间以来， 数据分片 (data sharding) 被认为是解决当前形式的 Rollups 的长期不足的解决方案，数据分片有望在以太坊链上为 Rollups 增加大约 1-2MB/s 的专用数据空间。本文描述了实现该解决方案的一条实用的路径，能够尽可能快地为 Rollups 解锁数据空间，并随着时间的推移增加更多额外的空间和安全性。

Step 1: 扩展交易 calldata

目前现有的 Rollups 使用了交易 calldata。因此，如果我们想要在无需让各个 Rollups 团队做出任何额外工作的情况下，在短期内提升 Rollups 的容量并降低成本，我们应该降低交易 calldata 的 Gas 成本。当前的平均区块大小还远没有达到威胁以太坊网络稳定性的大小，因此这样做是有可能安全的，尽管可能需要一些额外的逻辑来预防非常不安全的边缘情况。

参见 EIP-4488 提案，或者另一个 (更简单但效果更温和的) EIP-4490 提案。

EIP-4488：

https://github.com/ethereum/EIPs/pull/4488

EIP-4490：

https://github.com/ethereum/EIPs/pull/4490

EIP 4488 应该能将每个 slot 可用于 Rollups 的数据空间增加至理论上最大约 1 MB，并将 Rollups 上的成本降低约 5 倍。这可以比后面的步骤更快地实现。

Step 2: 几条分片

与此同时，我们可以开始做一些工作来推出“适当的”分片。想要以完整 (功能) 的形式实现分片还需要很长的时间，但我们能做的是可以一步步地实现它，并从每一步中获益。首先自然是要实现分片规范的“业务逻辑”，但需要使最先上线的分片数量非常低 (比如 4 条分片)，以此来避免围绕分片网络的大多数难点。每条分片将在其自己的子网络中广播。默认情况下，验证者将信任委员会，但如果他们愿意，他们可以选择在每个子网络中，但只有当他们看到了信标区块确认的任何分片区块的全部数据时，他们才会接收该信标区块。

分片规范本身并不是特别困难；它与最近发布的 Altair 硬分叉有着类似规模的样板代码更改 (Altair 的信标变更规范文件是 728 行，分片的信标变更规范文件是 888 行)，因此可以合理地预计它可以在与 Altair 的实现和部署类似的时间框架内实现。

为了使分片数据 (sharded data) 实际上可被 Rollups 使用，Rollups 将需要能够使其证明 (proofs) 进入到分片数据中。有两个选择：

增加 BEACONBLOCKROOT 操作码；Rollups 将增加代码来验证根植于历史信标链区块根的默克尔证明 (Merkle proofs)；

增加面向未来的状态和历史访问预编译，这样当承诺方案 (commitment scheme) 在未来发生改变时，Rollups 就不需要更改它们的代码。

这将使得每个 slot 的 Rollup 数据空间增加至约 2 MB (每个分片 250 kB * 4 个分片，再加上上文 Step 1 中扩大的 calldata)。

Step 3: N 条分片，由委员会保护

将活跃分片的数量从 4 条增加到 64 条。此时分片数据将进入子网络，因此届时的 P2P 层必须已经足够牢固，使得将其分割成更多数量的子网络变得可行。数据可用性的安全性将基于大多数 (验证者) 诚实假设，依赖于委员会的安全性。

这将使得每个 slot 的 Rollup 数据空间增加至约 16 MB (每条分片 250 kB * 64 条分片)；我们假设此时 Rollups 将已经从以太坊执行链中迁移出来。

Step 4: 数据可用性抽样 (DAS)

添加数据可用性抽样 (DAS) 以确保更高级别的安全性，使得即便是在大多数 (验证者) 不诚实的攻击情况下，用户也能够得到保护。数据可用性抽样可以分阶段来进行：首先，以非约束性的方式来允许网络对其进行测试，然后将其作为接收信标区块的必要条件，甚至可能先在某些客户端上进行。

一旦完全引入了数据可用性抽样，分片的铺展就完成了。

基于分片的 Optimistic Rollups 和 ZK Rollups

当前的以太坊与实施分片之后的以太坊的一个主要区别就是，在分片的世界里，Rollup 数据实际上不可能成为向智能合约提交 Rollup 区块的交易的一部分。相反，Rollup 数据的发布与 Rollup 区块的提交将必须是分开的：首先，数据发布将把数据放到链上 (也就是放到分片链中)，然后区块提交将会提交区块头以及一个指向底层数据的证明。

Optimism 和 Arbitrum 已经为 Rollup 区块的提交使用了一种两步式设计，因此这对二者来说都将是一个很小的代码更改。

对于 ZK Rollups，事情有点棘手，因为提交交易需要提供一个直接对数据进行操作的证明。它们可以通过 ZK-SNARK 来证明分片中的数据与信标链上的承诺相匹配，但这一操作是非常昂贵的。幸运的是，还有更便宜的替代方案。

如果该 ZK-SNARK 是一个基于 BLS12-381 的 PLONK 证明，那么它们可以简单地直接将分片数据承诺作为输入来进行打包。BLS12-381 分片数据承诺是一个 KZG 承诺，与 PLONK 中的承诺类型相同，因此可以作为公共输入直接传递到证明中。

如果 ZK-SNARK 使用了一些不同的机制 (或者即便是 BLS12-381 PLONK 但有着一个更大的可信设置)，那么它可以包含自己的数据承诺，并使用一个等效性证明 (proof of equivalence) 来验证该证明中的承诺与信标链中的承诺是对相同数据的承诺。

分片世界中，谁将存储历史数据？

增加数据空间的一个必要条件是移除以太坊核心协议负责永久性维护达成共识的所有数据的属性。因为这些数据量太大了。例如：

EIP-4488 理论上带来的最大链大小是每 12 秒的 slot 为大约 1,262,861 字节，也即每年大约 3.0 TB，但实际上每年更有可能是约 250-1000 GB，尤其是在开始阶段。

4 条分片 (每个 slot 为 1 MB) 每年会增加额外的约 2.5 TB。

64 条分片 (每个 slot 为 16 MB) 每年将带来总计为约 40 TB 的存储。

大多数用户的硬盘驱动器的大小在 256 GB 和 2 TB 之间，1 TB 似乎是中间值。下图是一项针对计算机硬盘空间有多大而在一组区块链研究员中开展的内部调查的结果：

这意味着用户当前可以运行一个节点，但如果此路线图的任何一部分如果不进行修改就实施，那么用户将无法运行节点。当然还有更大的驱动器可用，但用户将必须竭力去购买它们，这大大增加了运行节点的复杂性。当前主要的解决方案是 EIP-4444，此提案消除了节点运营者存储超过 1 年的区块或收据的这一责任。在分片的情况下，这个 1 年的时长将很可能进一步缩短，而且节点将只需要负责他们积极参与的子网络上的分片。

这就提出了一个问题：如果以太坊核心协议不存储这些数据，谁来存储？

首先，重要的是要记住，即使有了分片，数据量也不会那么大。是的，每年 40 TB 确实超出了运行“默认”消费硬件的个人的能力 (事实上，即便每年 1 TB 也还是如此)。然而，对于一个愿意投入一些资源并想办法来存储这些数据的人来说，这是在其可接受的范围内的。当前一台 48 TB 的 HDD (硬盘驱动器) 的售价是 1729 美元，一台 14 TB 的是约 420 美元。出于可以获得质押奖励，某个运行了 1 个 32 ETH 验证者插槽的人可能会愿意支付并存储分片实施之后的整条链。因此，实际上，「没有人会存储某个分片的一些历史数据以至于这些数据完全丢失」的这种情况似乎是不可能出现的。

那么谁将存储这些数据？我的一些想法：

个人和机构志愿者；

区块浏览器 (etherchain.org、etherscan.io、amberdata.io 等等) 将肯定会存储所有数据，因为向用户提供数据是它们的业务模式。

Rollup DAOs 指定并付费给参与者来存储并提供与他们的 Rollup 相关的历史数据。

历史数据可以通过种子 (torrents) 进行上传和共享。

客户端可以自愿选择随机存储区块链的 0.05% 的历史数据 (使用纠删码，这样只有当许多客户端在同一时间离线时才会丢失一小块数据)。

Portal Network 中的客户端可以随机存储一部分区块链历史数据，且 Portal Network 会自动将数据请求导向存储了该数据的节点。

可以在协议中激励历史数据的存储。

像 The Graph 这样的协议可以创建激励市场，其中的客户端向服务器支付费用，从而获取历史数据和证明其正确性的默克尔证明。这就激励了人们和机构来运行存储历史数据的服务器，并按需提供这些数据。

这些解决方案中的一些方案 (个人和机构志愿者、区块浏览器) 已经是可用的了。而当前的 P2P 种子场景更是一个主要由志愿者驱动和存储大量内容的生态系统的绝佳例子。其他基于协议的方案要更加强大，因为它们提供了激励机制，但它们可能需要更长的时间来进行开发。从长期来看，通过这些 L2 协议来访问历史数据，可能要比通过当前的以太坊协议更加有效。