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

以下为方案译文:

用户体验

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

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

IO访问操作码(SLOAD, BALANCE, EXT*, CALL*)的Gas成本将会增加。CALL(调用)的Gas成本可能会每访问一字节代码就需要增加1 Gas;

在某个时候,你必须下载实现网络升级的代码。这与任何其它升级(如拜占庭、君士坦丁堡升级)没有本质上的区别,但这次的下载量要大一些,这是因为你还需要下载一个以太坊2.0客户端。

区块链可能会暂停大约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小时。

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

指定一个(eth1)过渡区块高度 TRANSITION_HEIGHT:TRANSITION_HEIGHT指定的eth1区块将被视为eth1侧的“最终”区块,从那时起,这条eth1链将作为eth2的子系统运行;

与(1)相同时间点,添加对eth2“诚实验证者”代码的更改,该代码不允许对number > TRANSITION_HEIGHT的eth1区块进行投票。如果投票算法先前选择了一些 number > TRANSITION_HEIGHT的区块,则投票TRANSITION_HEIGHT高度的祖先(ancestor)区块;

此外,在触发(2)的情况下,验证者应将deposit_count(存款计数)设置为比其真实值高2**63(这基本上是使用deposit_count的top bit作为信号,表示“eth1已经完成”);

当“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状态进行一些预处理。比如我们可以:

将十六进制Patricia树替换为二进制稀疏Merkle树,以及一个专用哈希函数,以确保分支的哈希开销保持为O(log(n)),这使Merkle分支的大小减少了约4倍;

用SSZ哈希树替换RLP;

向帐户添加与状态租赁相关的数据字段;

清除“粉尘”账户;

根据“抽象化”提议修改账户结构;

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

来源:巴比特

原创文章,作者:高天,如若转载,请注明出处:http://www.doubi.com/?p=2869

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

在线咨询:点击这里给我发消息

QR code