可视化以太坊的未来之路

本文是关于通往未来以太坊的道路。今天的以太坊就是 eth2 开发者所称的“eth1”，也即当前我们熟知和喜爱的 PoW 链；明天的以太坊既不是 eth1，也不是 eth2，而就是...以太坊：综合了在今天的执行层 (eth1) 之上部署 PoS 和分片的一系列 eth2 工作。

我们先来回顾一下今天的以太坊 (eth1)：

今天的 eth1 链的运作方式

在今天的以太坊上，当用户想要做一些事情 (即“事务”)，他们会把事务 (transactions) 发送给矿工，然后矿工把事务打包进区块，并将这些区块添加到一条不断增长的区块链 (eth1) 中。矿工运行 PoW 共识机制，以此来决定由谁来添加下一个区块，矿工也执行区块中包含的事务，以确保这些事务是有效的。

PoS 替代 PoW：验证者替代矿工，小型服务器替代大量挖矿设备

PoW 需要大量的硬件设备来运行密集运算，进而造成了过高的能耗。在此，我们不会像大多数加密货币批评者那样讨论能源浪费问题 (比如“为什么我们要使用一个消耗<某个国家的>能源的支付系统？”)，但如果我们可以消耗绝对更少的 kWh (千瓦时) 来做一些事情，那么这 (PoW) 就确实是存在能源浪费，我们应该减少能耗。

因此，这将我们带入 PoS，使用小型的服务器来取代大量挖矿设备，并使用验证者 (validator) 取代矿工。

在 PoS 中，如果验证者不执行验证工作 (图中第2步)，则将会适当地损失质押金

那么，上图中的第2步 (即验证) 是什么呢？验证者到底要验证什么？

我们可以将以太坊的活动分为两部分：共识层→“哪个是正确的数据？”；执行层→“数据的含义是什么？”

共识层 (consensus layer) 确保所有人都对正确的数据达成共识。执行层 (execution layer) 实际上是“解释”这些数据，使数据有意义。“数据”是指与区块链进行的任何交互，比如部署一个智能合约，在交易所进行交易，发送一笔付款等等...

区块链的核心是在链中引入新的区块。当新区块被添加进来时，新区块进来之前的状态和进来之后的状态之间，会发生一次状态转换 (state transition)。区块链的当下状态汇总了之前所有区块的数据。

例如，如果当前状态维持着一个记录了 Alice 和 Bob 的账户余额的账本，而新区块中包含了一笔 Bob 向 Alice 支付了 10 枚币的交易，那么这个新区块被添加进区块链中之后，状态将会记录新的余额信息。一个新区块添加进来之后，要么会更改当前的状态 (比如，更新 Alice 和 Bob 的余额)，要么会创建一个新的状态 (比如部署一个智能合约，或者将 Carol 新添加进账本中...)。

根据以太坊计划，第1步是将共识与执行解耦；第2步是把PoW共识换成PoS共识

根据我们的计划，Rollups 和 eth2 工作的总体要点就是处理上图中的第1步，也即将共识与执行解耦 (decorrelate consensus and execution)。那么，这方面进展如何了呢？

第1步已经完成了！

自 2020 年 12 月以来，我们已经有了两条并行运行的区块链 (见上图)：

上方的是 PoS 共识链 (即信标链)

下方的是可靠的 PoW 共识+执行链 (即 eth1 链)

这两条链并行运行，但它们会相互“交流”，当然目前是单向的...

如何成为一名验证者？

要成为 PoS 共识链 (即信标链) 的验证者，用户需要在部署于 PoW 共识+执行链 (即eth1) 上的存款合约中锁定 32 ETH，该质押金会自动转移到 PoS 共识链中。一旦验证者被激活，就可以开始 (对 PoS 共识链) 进行验证并获取奖励。

合并之后，信标链 (紫色) 是共识链，切换为 PoS 共识的 eth1 链 (红色) 将作为执行链。什么时候实现合并？可能在2021年实现...

预计这种单向的“交流”将不会持续很长时间。合并这两条链将永久地连接 PoS 共识链 (信标链) 和 PoW 共识+执行链 (eth1) 之间的鸿沟，从而允许验证者为执行层 (即合并之后切换为 PoS 共识的 eth1 链) 生成区块。因此，合并之后，我们将有两条链：

同一条 PoS 识链 (即信标链)

基于 PoS 的执行链 (即切换为 PoS 共识的 eth1 链)

合并之后，PoS 共识链 (信标链) 的验证者们将终于能够赎回和提取他们的收益和存款，并将收益和存款发回至 PoS 执行链 (eth1) 中。

所有这些使我们从 PoW 环境转移到了一个完全合格的 PoS 环境中！但需要注意的是，此时并没有增加这条链的带宽——这是分片 (sharding) 要实现的目标。在这之前，在我们尚且只有一条执行链 (即 eth1 链) 之际，我们来讨论一下如何通过其它方式来对执行进行扩展。

扩展计划：1. 将执行转移至链下；2. 将数据提交至链上。

Rollups 是众多可用的扩展解决方案之一，但从协议设计的角度来看，它可能提供了最优折衷的方案。Rollups 的理念很简单：通过在链上提交重建状态转换执行所需的数据，来综合地处理状态转换，并将执行转移至链下进行。如果有人对执行结果有异议，或者有人忘记了在第一时间执行，那么数据就在那里等着所有人处理。Rollups 是无需许可的！

更准确地说，在 Rollups 中，执行所需的数据 (事务输入) 与它的载体 (事务) 是分开的，且这些数据是以节省空间的方式“捆绑”起来。同时，Rollups 在执行链 (即eth1链) 之外运行，提交数据并加以执行。见下图：

如今 eth1 链的扩展正在发生，Rollups 已经部署，其它扩展方案也在开发中。

想要“使用某条 Rollup 链”的用户，需要在该 Rollup 位于执行链 (eth1) 上的合约中存储一些资产，之后用户就可以在该 Rollup 上做一些事情了，比如使用自己的资产与该 Rollup 链上的其它资产进行交易。一旦用户完成了想要做的事情，就可以将资产从 Rollup 撤回至执行链中。就是这样！

Rollups 有什么其它替代性方案？如果我们没有这些并行运行的 Rollps 链(上图中的黄色链)，而是拥有很多条并行运行的执行链(上图中的红色链)，那会如何？比如，如果 eth1 链被“复制”，并与其它几条复制链并行运行，那会怎样？

其中的问题在于我们如何处理几条平行运行的执行链。如果其中某条执行链想要知道另一条执行链中发生的事情，那该如何做到？这正是分片 (sharding) 遇到的棘手问题 (注：也即所谓的跨分片通信问题)。

你可能会说，“Rollups 差不多也有这样的问题！”，实际上确实如此。当你在某条 Rollup 链上想要与另一条 Rollup 链进行交互时，同样的棘手问题也会出现 (即跨Rollup通信问题)。但重点是，当前存在几种 Rollup 设计，这一问题的解决方案空间很广阔，且在很大程度上尚未被探索。因此，在将某种方案纳入协议层之前，为何不通过 Rollups 先启动试验呢？

这将我们带向了以 Rollup 为中心的以太坊路线图[1]。

以 Rollup 为中心的 eth2：使用分片来保存 Rollups 发布的数据

你听说过区块空间的稀缺性吧？Rollups 需要发布数据，而 eth1 的区块空间是稀缺的！且如上所述，跨分片很难。因此，为什么不使用分片来保存 Rollups 需要发布的数据呢？借助于 64 条分片链，就能带来比当前可用的多出 64 倍的带宽，而且可能更多，因为一个分片区块将可能保存比当前的 eth1 区块更多的数据量。

应该强调的是，这并不意味着在分片层的执行功能会永远被排除在外。当前以 Rollup 为中心的以太坊路线图是一种短期到中期的前进方式，直到 (例如) 找到更好的加密原语来保证正确地将执行划分到多条链中 (注：即实现可执行分片)。这一切都非常迷人，应该会让很多人忙上很长一段时间。在此期间，Rollups 是解决之道。

每条 Rollup 链都是其自身的“执行环境”：如何轻松地迁往/迁出 Rollup？我们可以进行跨Rollup操作吗？Rollups 应该如何处理拥堵问题？

这方面还有很多工作要做！首先，我们不要忘记，合并和数据分片是非常复杂的工作，目前有多个团队在致力于其中一项或兼顾这两项工作。而即便是在 Rollup 方面，仍然有一些非常有趣的问题有待探讨，以下仅是其中一些：

如何大规模地实现用户向 Rollups 的迁移或者从 Rollups 迁回至链上[2]，这是一个很酷的概念。如果你有足够多的公共交通工具让你往返于 Layer1 (eth1) 和 Layer2 (Rollps) 之间，为何你还要自己开车往返呢？其中的经济机制是什么呢？

如果你想在临近的一条 Rollup 链做一些事情，因为该 Rollup 中有着一些你所在的 Rollup 中没有的酷东西，那你该怎么办？你是否必须从当前的 Rollup 撤回至 Layer1 上，然后再从 Layer1 转移至该临近的 Rollup 中？这似乎相当的不经济。

对于当前的链上操作来说，Rollups 是一个巨大的带宽提升，这是毫无疑问的。但是，Rollups 并不是用户所期望的无限高速公路。在 Rollups 中，仍然会有很多人想要做很多事情，且有时候是同时发生的！因此，Rollups 将与生俱来地要应对拥堵问题，但与 Layer1 协议保护的拥堵市场 (EIP-1559 很快就会实施) 不同，Rollups 有着更大的设计空间可供探索。

说到拥堵问题，这是更特定于协议的，但我们还将看到 EIP-1559 扮演交通警察的角色，来规范每个数据分片上发布的数据量，以确保验证者能够处理这个数据量。如果你认为 EIP-1559 机制在一条链 (eth1) 上很酷，那么等到有 64 条分片链同时运行该机制时会更酷。那么，Rollups 应该在哪里发布它们的数据呢？是将数据仅发布在单个分片上，使数据仅在该条分片上可获取？还是发布在多个分片上，从而受益于计划中的分片交错出块？其中，分片交错出块 (shard staggering) 是 Vitalik 最近提出的想法，即所有分片轮流出块，这样 Layer2 项目 (如 Rollups) 在发布数据时，距离一个新区块的时间间隔不会超过几百毫秒，这对于需要快速敲定的应用来说是理想选择，详见?[3]。

原文链接：

https://barnabe.substack.com/p/eth2

正文中涉及的链接：

[1]:https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698

[2]:https://ethresear.ch/t/mass-migration-to-prevent-user-lockin-in-rollup/7701

[3]:https://ethresear.ch/t/simple-approach-to-incentivizing-shard-staggering/9149