Vitalik：以太坊1.0将成为以太坊2.0的子系统，PoW将失去意义

译者注：据以太坊联合创始人Vitalik Buterin刚提出的 eth1->eth2过渡方案 显示，以太坊转换前和转换后，它们会使用非常不同的代码路径来打包和广播交易，而在完成过渡后，以太坊1.0将成为以太坊2.0的子系统，而用户经历的更改将是非常有限的。

以下为方案译文：

用户体验

如果你是一名app开发者或app用户，并且本文中描述的路线图被用于完成以太坊1.0 -> 以太坊2.0 的过渡，那么你所经历的更改和困扰将是非常有限的。现有的应用将继续运行，而不会有变化。所有账户余额、合约代码和合约存储（包括ERC20余额、有效CDP等）将延续存在。

而你需要面对及处理的是以下这些：

1. IO访问操作码（ SLOAD , BALANCE , EXT* , CALL* ）的Gas成本将会增加。CALL（调用）的Gas成本可能会每访问一字节代码就需要增加1 Gas；
2. 在某个时候，你必须下载实现网络升级的代码。这与任何其它升级（如拜占庭、君士坦丁堡升级）没有本质上的区别，但这次的下载量要大一些，这是因为你还需要下载一个以太坊2.0客户端。
3. 区块链可能会暂停大约1个小时。1小时后，“以太坊”就会重新上线了，但此时以太坊1.0将作为以太坊2.0的一个子系统，而不是一个独立的系统运行。

就是这些了，如果你是一名开发人员，你可通过主动编写验证内容（witness）较小的应用程序（即测量一笔交易中访问的总存储槽+合约+合约代码），来消除gas成本变化带来的最大干扰。

（ 译者注：以下eth1代表以太坊1.0链，eth2代表以太坊2.0链 ）

如何实现平稳过渡？

假设阶段0-阶段2已经实现，并且eth2链稳定运行了，我们的目标是让eth1区块链也会继续稳定运行。在阶段0的规范中，已经存在一种名为 eth1_data voting 的机制，其中验证者投票同意最近的规范eth1哈希，这种机制被用于处理存款。我们只需要对它稍作修改，然后用于将eth1的完整状态（根）馈送到eth2。

目前，该机制会存在大约6小时的延迟（ ETH1_FOLLOW_DISTANCE 有4小时，投票周期有2小时），但这些参数可在过渡前随时间的推移而减小，最终使延迟变成大约1小时。

影响过渡的基本机制如下：

1. 指定一个（eth1）过渡区块高度 TRANSITION_HEIGHT ： TRANSITION_HEIGHT 指定的eth1区块将被视为eth1侧的“最终”区块，从那时起，这条eth1链将作为eth2的子系统运行；
2. 与（1）相同时间点，添加对eth2“诚实验证者”代码的更改，该代码不允许对 number > TRANSITION_HEIGHT的eth1区块 进行投票。如果投票算法先前选择了一些 number > TRANSITION_HEIGHT 的区块，则投票 TRANSITION_HEIGHT高度的祖先 （ancestor）区块；
3. 此外，在触发（2）的情况下，验证者应将 deposit_count （存款计数）设置为比其真实值高2**63（这基本上是使用 deposit_count 的top bit作为信号，表示“eth1已经完成”）；
4. 当“eth1已经完成”信号被发出，eth2链 接收eth1数据时，其执行一次性的“不规则状态转换”，将eth1区块的后状态（post-state）根放入“eth1执行环境”的状态（eth2上的一种系统级智能合约）。这等于eth1链的ETH总供给量被加到这个eth1 EE（执行环境）的余额中；

在这一点之后，过渡就完成了。 eth1链在技术上仍继续存在，但它是没有价值 的 （ valueless ），当难度冰河期来临时，它最终会消亡（ 译者注：Vitalik指的是PoW会失去意义，而不是指 eth1 的币没有价值 ） 。

此时， eth1系统就位于eth2的内部了，因此，通过在eth2上提交以eth1 EE（执行环境）为目标的交易（如上所述，它是eth2的一个子系统），可进一步转移至eth1系统。eth1 EE（执行环境）有实现整个eth1 EVM（虚拟机）和交易处理逻辑的代码，其具有一个函数升级（ state_root, transaction, witness) -> new_state_root ），它会接受一笔交易和验证内容（部分状态的merkle证明），根据eth1链上的相同规则处理交易并确定更新的eth1状态根。请参阅 无状态客户端概念 来了解验证内容和状态根的工作方式。

附加的功能将添加到eth1 EE（执行环境）代码中，该代码允许ETH和消息从eth1 EE（执行环境）撤回到eth2的其他部分，以及撤回到其他分片eth1 EE的副本中。默认情况下，所有eth1帐户/合约都将被放置在同一分片上，因此想要利用eth2增加的容量，你需要主动使用此功能将ETH或其他应用移动到其他分片中，但这并不困难。另外，我们还需要对ERC20代币标准进行扩展，以支持代币的跨分片传输。

用户客户端将如何工作

在过渡之前，面向客户的客户端将被修改成具有两种代码路径。客户端将检查eth2，以查看是否已发生了转换。如果它还没有发生，那么它就会像以前一样使用eth1链发送交易、检查余额等，除非其认为所有 number > TRANSITION_HEIGHT 的eth1区块都不存在。而如果发生了转换，它将检查eth2上的eth1 EE。完整客户端将按顺序处理eth2上以eth1 EE为目标的所有交易，以便继续更新完整的eth1状态树。这将允许客户端为它们要发送的任何交易生成验证内容，并以eth2格式“打包”它。而轻客户端（以及metamask等钱包）会将它们的交易广播至一个完整客户端，该客户端可以为它们添加验证内容。

从用户的角度来看，以太坊转换前和转换后，没有发生大的变化（除了转换后因为PoS和 EIP 1559的原因，体验上会更平滑）。实际上，转换前后会使用非常不同的代码路径来打包和广播交易，但提供的功能将是相同的。

可能的话，这种转换还可以进行改造，以至钱包通过RPC与客户端通信而不需要改变任何东西。

举个app用户的例子

比如你是在MakerDAO上有CDP（债务抵押头寸），那么在eth1到eth2的转换过程中，你可以好好睡上一觉，当你醒来时，过渡就已经完成了。你可以像以前一样通过发送交易来与CDP交互以及清算CDP，但实际上你的客户端代码将认为你是在转换后的，并将验证数据添加到你的交易中，然后将其发送到eth2网络，而不是eth1网络。

可能的优化

在eth1链到达TRANSITION_HEIGHT（转换高度），以及eth2上的eth1 EE接受到状态之间的期间，我们可以对eth1状态进行一些预处理。比如我们可以：

1. 将十六进制Patricia树替换为 二进制稀疏Merkle树 ，以及一个 专用哈希函数 ，以确保分支的哈希开销保持为O(log(n))，这使Merkle分支的大小减少了约4倍；
2. 用SSZ哈希树替换RLP；
3. 向帐户添加与状态租赁相关的数据字段；
4. 清除“粉尘”账户；
5. 根据“抽象化”提议修改账户结构；

相比将实际的eth1状态根包含到EE（执行环境）中，我们可选择包含通过执行所有这些修改生成的状态树根。这是一种确定性计算，因此所有验证者都可并行完成。这种一次性计算能够节省开销，可大大提高eth1转换后的效率和可用性。