一文图解以太坊发展路线(2)

说到 rollups，这是众多可用的扩容解决方案之一，但从协议设计的角度来看，这种解决方案可能提供了最优的折衷方案。这种方案的想法很简单：通过将数据存储在链上 (这些数据用于重建状态转移的执行) 来综合地处理状态转换，并且将状态的执行放到链下。如果有人不同意执行的结果，或者有人一开始就忘记执行，融易新媒体，数据就在链上供所有人使用 (可以重新计算)，这是完全无需许可的！

更准确地说，执行所需的数据 (交易输入) 与其载体 (交易) 分离，并以节省空间的方式 “捆绑”起来。同时，rollups 在执行链 (eth1) 之外运行，提交并执行数据。

图：已有几个 rollups 方案部署，还要更多正在研发中

用户需要往执行链 ("eth1") 上的 rollup 合约质押一笔资产，才能够进入到 rollup 里，用户可以在里面进行交易。完成之后，用户可以将资产从 rollup 中转回到执行链中。

Rollups 的替代方案是什么？大家看一下上图，让我们来假设一下，如果我们用一串串平行的红色来代替那些垂直的黄色链会怎样？比如说，如果我们复制了几条 eth1 链，然后它们之间并排运行会怎么样？

这里的问题是如何处理并行运行的多个执行链。如果某条链上发生了什么事情，而其他人需要知道怎么办呢？这是分片面临的一个非常棘手的问题，或者说对于在多个链中执行的方案来说都需要克服的问题。

"Rollups 之间并没什么不同"，读者可能这么认为，本质上来说这没什么错。但是当你想要从一个 rollup 转到另一个 rollup 上进行交易时，同样棘手的问题又出现了。然而，关键在于，现在已经存在几种 rollup 设计了，并且这些解决方案的可探索空间仍非常广泛。既然如此，为什么不让 rollups 先进行试验，然后再引入一种协议级别的方法呢？

这让我们来到了...

图：使用分片来存储 rollup 发布的数据

读者应该听说过区块空间不足的事吧？Rollups 确实需要发布它们的数据，但是 eth1 区块空间十分稀缺！而且，就像我们所讨论过的，跨分片是非常难的。那为了解决这个问题，我们可以用分片来保存 rollup 需要发布的数据。届时很可能会有 64 个分片，即现在可用带宽的 64 倍。而且一个分片区块可能会比 eth1 链区块当前能够容纳更多的数据量。

我需要强调一下，这并不意味着我们将永远排除执行分片这个方案。以 rollup 为中心的以太坊路线图是我们中短期的发展目标，直到我们找到更好的加密基元，以保证能够实现跨多条链的执行分片。这个方案很吸引人，需要团队很多人花费很长的时间去研究。与此同时，我们可以使用 rollups。

图：每个 rollup 都有自己的执行环境

这方面还有很多工作要做！首先我们不要忘记，“合并”和“数据分片”都是非常复杂的工作，需要多个团队同时从事其中一项或两项工作。但在 rollup 方面，也仍有一些有趣的问题有待探索，我仅列出了一部分：

实现用户和 rollups 之间的大规模迁移是一个很酷的概念。如果用户有足够多的公共交通工具令其往返 Layer1  (eth1) 和 Layer2 (rollups)，那么为什么还要自己开车往返呢？这非常不经济。

如果用户觉得可以在另外一个 rollup 上做一些更酷的东西 (ta 所在的 rollup 是没有的)，难道 ta 一定得先提现至 L1，然后再从 L1 中存款进这个 rollup 中吗？这未免太浪费了。

对于当前的链上操作来说，rollups 极大地提高了网络带宽，这是毫无疑问的。但是 rollups 仍不是用户所期望的无限高速公路那样。仍有很多人想要在 rollups 上做很多事情，有时甚至是同时做的！因此 rollups 将不可避免地面临拥堵问题，但与 L1 这个尤其拥堵的市场不同 (很快就会上线 1559 了)，rollups 的可探索空间更加广泛。

说到拥堵问题，虽然这更特定于协议层面，但是我们还将看到 EIP-1559 扮演交通警察的角色，来规定每个数据分片上发布多少数据，确保验证者可以处理这个数据量。如果读者觉得 eth1 上运行 EIP-1559 很酷，那么请期待届时会在 64 条分片链上同时运行 1559。那么，rollups 应该在哪里发布它们的数据呢？是仅发布在单个分片上，使数据仅在该分片上可获取？还是说发布在多个分片上，这样就可以受益于计划推出的“错开分片区块生产” (shard staggering) 方案？这个方案由 Vitalik 提出，即分片轮流出块，这样发布数据时，距离新区块的生成时间为几百毫秒以内，这对于需要“快速敲定”的应用来说是理想选择。

特此感谢 Danny Ryan 和 Sacha Saint-Leger 的建议。

[1] 我听说 PoW 不是一种共识算法，但我认为如果使其定义超载了，将其描述为共识机制是没有问题的。