从开发者和用户的角度理解以太坊 1.0 向 2.0 转化。

原文标题：《引介 | eth1 -> eth2 转换》
撰文：Vitalik Buterin，以太坊联合创始人
翻译 & 校对：闵敏 & 阿剑，来自以太坊爱好者

本文为 Vitalik 于 2020 年 10 月 19 日在以太坊研究者论坛上发表的帖子，提议了他所设想的 Eth1 如何转换成分片化信标链的子系统的过程，并解释了开发者、用户对这个过程会有什么知觉。确切来说，这并不是一个针对 Eth1 的提案，因为提案的内容无涉于 Eth1 的链和生态如何形成广泛的社会共识来完成这种转换，相反，它仅仅涉及到了分片化信标链的一个子系统（「Eth1 EE」）要按什么样的程序选取 Eth1 上的哪个状态作为自己的起始状态。此外，读者还可借此一窥作者心中一个准备好完成转换的分片化信标链应具备哪些基础设施，例如，无状态性和 EE；借此可反推分片化信标链的开发方向和进度。

本文介绍的路线图被用来完成从 eth1 向 eth2 转换，如果你是应用开发者或用户，你所能感受到的变化乃至颠覆实际上非常有限。已有应用将继续运行，而不会发生任何改变。所有账户余额、合约代码和合约存储（包括 ERC20 余额、质押债仓等）都将继续存在。

你需要应对以下情况：

1. IO 访问操作码（SLOAD、BALANCE、EXT*、CALL*）的 gas 成本将增加。CALL （调用）的 gas 成本大概是每访问 1 字节的代码需要消耗 1 gas。
2. 你需要下载实现网络升级的代码。这在根本上与拜占庭和君士坦丁堡等其它升级没有区别。但是下载量更大一点，因为如果你还没有 eth2 客户端，那你需要下载一个。
3. 以太坊区块链可能会暂停大约 1 小时。1 小时后，「以太坊」 看似重新上线了，但是实际上 eth1 不再是一个独立的系统，而是成了在 eth2 内运行的子系统。

就是这样。如果你是开发者，只要你确保自己的应用所需的 witness 规模不会太高（可通过单笔事务所访问的全部 存储槽+合约+合约代码 的数量来衡量），你的应用因为 gas 消耗量改变而崩溃的可能性就很小。

转换将如何发生

假设 phase 0-2 已经完成，并且 eth2 链正在稳定运行。eth1 链也在稳定运行中。phase 0 规范已经安排了一个名为 eth1_data voting 的机制。在这个机制中，验证者会通过投票就 eth1 主链最新的区块哈希值达成共识；这个机制目前被用来处理押金。我们将重新改变该机制的用途，用它来将 eth1 的完整状态（根）传入 eth2。

目前，该机制有大约 6 小时的延迟（其中有 4 小时的延迟是因为 ETH1_FOLLOW_DISTANCE 「Eth1 主链跟随距离」，另外 2 小时是因为投票期） ，但是在转换完成前，这些参数会随着时间的推移而减小，将延迟降至 1 小时左右。

影响 eth1 向 eth2 转换的基本机制如下图所示：

1. 指定一个（eth1 链的） 高度 TRANSITION_HEIGHT。高度为 TRANSITION_HEIGHT 的 eth1 区块将被视为 eth1 链的 「最终」 区块。从该区块往后，（原本是 「正统链的」） eth1 将作为 eth2 的子系统运行。
2. eth2 的 「诚实验证者」 代码会根据（1）做出相应调整，不允许验证者投票给区块号 > TRANSITION_HEIGHT 的 eth1 区块。如果投票算法已经选出了某个区块编号 > TRANSITION_HEIGHT 的 eth1 区块，则改成为 TRANSITION_HEIGHT 的 eth1 区块投票。
3. 此外，在已触发（2）的情况下，验证者会将 deposit_count 设置为比实际值高 2**63 （就是将 deposit_count 的 top bit 作为 「eth1 已完成」 的标记）
4. 当 eth2 在 「eth1 已完成」 标记开启的情况下接受 eth1data 时，eth2 会执行一次 「非常规的状态变换」，将该 eth1 区块的状态根放到 「eth1 执行环境」（eth2 上的一类系统级智能合约）的状态中。与 eth1 链上的总 ETH 供应量等量的 ETH 会添加到这个 eth1 执行环境的余额中。

在这之后，转换完成。从技术层面来说，eth1 链会继续运行，但它已经变成了一条毫无价值的链；等到冰河期到来时，这条 eth1 链将彻底消失。

eth1 系统现在位于 eth2 系统内部。因此，通过在 eth2 上提交针对 eth1 执行环境（即上文所述的 eth2 子系统）的交易，eth1 进一步转换成 eth2 的子系统。eth1 执行环境拥有可以实现整个 eth1 EVM 和交易处理逻辑的代码；它有一个 update(state_root, transaction, witness) -> new_state_root 功能，可以按照 eth1 链的规则，以交易和见证消息（状态部分的默克尔证明）作为输入处理该交易，并决定更新后的 eth1 状态根。关于见证消息和状态根的运作原理，请阅读《无状态客户端概念》。

eth1 执行环境代码可以添加额外的功能，即，将 ETH 和消息从 eth1 执行环境提取到 eth2 的其它部分，以及其它分片上的 eth1 执行环境副本中。在默认情况下，所有 eth1 账户 / 合约都会放在同一个分片上，因此为了利用 eth2 更大的容量，你需要主动使用这个功能将你的 ETH 或其它应用转移到其它分片上，不过难度不大。我们需要通过扩展 ERC20 标准来支持跨分片代币转账。

用户客户端如何运作

在转换至两种代码路径之前，我们需要对客户端面向用户的部分进行修改。客户端会检查 eth2，来查看转换是否已经发生。如果转换尚未发生，客户端就会像之前那样使用 eth1 来发送交易，查看余额等，不同之处在于客户端会假装所有区块编号 > TRANSITION_HEIGHT 的 eth1 区块都不存在。如果转换已经发生，客户端就会在 eth2 上查看 eth1 执行环境。完整的客户端将按顺序处理 eth2 上所有针对 eth1 执行环境的交易，以便继续更新完整的 eth1 状态树。这使得完整的客户端可以为它们想要发送的交易生成见证消息，并使用 eth2 格式对其进行 「打包」。轻客户端（以及钱包，如 metamask）会将它们的交易广播给完整的客户端，由后者为其添加见证数据。

从用户的角度来看，以太坊能够 「感受到」 转换前和转换后（由于 PoS 和 EIP 1559，以太坊在感受后者时更加顺畅）。虽然打包和广播交易所使用的代码路径区别很大，但是它们所提供的功能都是一样的。

我们甚至可以对这种转换进行设计，以便钱包无需经过任何修改，即可通过 RPC 与客户端通信。

用户案例

假设你在 MakerDAO 上创建了一个质押债仓，然后就去睡觉了。等你醒来时，你发现转换已经发生了。你可以像以前那样发送交易来与你的质押债仓交互并将其清算，但是你的客户端会看到转换已经发送，于是会将见证数据添加到你的交易上，将其发送至 eth2 网络而非 eth1 网络上。

潜在优化

在 eth1 链达到 TRANSITION_HEIGHT 至 eth2 上的 eth1 执行环境获取该状态的这段时间内，我们会对 eth1 状态进行一些预处理。特别是，我们可以：

• 将十六叉帕特里夏树替换成二叉稀疏默克尔树和一个专门的哈希函数，以确保分支的哈希开销保持在 O(log(n))。这可以将默克尔树分支的大小减少 4 倍左右。
• 将 RLP 替换成 SSZ 哈希树
• 将状态租金相关的数据字段添加到账户上
• 清除 「粉尘」 账户
• 根据抽象提案修改账户结构

我们不会在 EE 中照搬沿用 Eth1 的状态根生成方法，而是以适用上述修改后的方法来计算状态根（Instead of including the actual eth1 state root into the EE, we would include the root of the state tree generated by performing all of these modifications）。这是确定性计算，因此所有验证者都可以同时进行计算。这种一次性的计算支出可以大大提高 eth1 转换后的效率和可用性。