编者注:本文为 Vitalik 于 2020 年 10 月 19 日在以太坊研究者论坛上发表的帖子,提议了他所设想的 Eth1 如何转换成分片化信标链的子系统的过程,并解释了开发者、用户对这个过程会有什么知觉。确切来说,这并不是一个针对 Eth1 的提案,因为提案的内容无涉于 Eth1 的链和生态如何形成广泛的社会共识来完成这种转换,相反,它仅仅涉及到了分片化信标链的一个子系统(“Eth1 EE”)要按什么样的程序选取 Eth1 上的哪个状态作为自己的起始状态。此外,读者还可借此一窥作者心中一个准备好完成转换的分片化信标链应具备哪些基础设施,例如,无状态性和 EE;借此可反推分片化信标链的开发方向和进度。
本文介绍的路线图被用来完成从eth1 向 eth2 转换,如果你是应用开发者或用户,你所能感受到的变化乃至颠覆实际上非常有限。已有应用将继续运行,而不会发生任何改变。所有账户余额、合约代码和合约存储(包括 ERC20 余额、质押债仓等)都将继续存在。
你需要应对以下情况:
- IO 访问操作码(SLOAD、BALANCE、EXT*、CALL*)的 gas 成本将增加。CALL(调用)的 gas 成本大概是每访问 1 字节的代码需要消耗 1 gas。
- 你需要下载实现网络升级的代码。这在根本上与拜占庭和君士坦丁堡等其它升级没有区别。但是下载量更大一点,因为如果你还没有 eth2客户端,那你需要下载一个。
- 以太坊区块链可能会暂停大约 1 小时。1 小时后,“以太坊” 看似重新上线了,但是实际上 eth1 不再是一个独立的系统,而是成了在 eth2 内运行的子系统。
转换将如何发生
eth1_data
voting 的机制。在这个机制中,验证者会通过投票就 eth1主链最新的区块哈希值达成共识;这个机制目前被用来处理押金。我们将重新改变该机制的用途,用它来将 eth1 的完整状态(根)传入 eth2。目前,该机制有大约 6 小时的延迟(其中有 4 小时的延迟是因为 ETH1_FOLLOW_DISTANCE “Eth1 主链跟随距离”,另外 2 小时是因为投票期) ,但是在转换完成前,这些参数会随着时间的推移而减小,将延迟降至 1 小时左右。影响 eth1 向 eth2 转换的基本机制如下图所示:- 指定一个(eth1 链的) 高度
TRANSITION_HEIGHT
。高度为TRANSITION_HEIGHT
的 eth1 区块将被视为 eth1 链的 “最终” 区块。从该区块往后,(原本是 “正统链的”)eth1 将作为 eth2 的子系统运行。 - eth2 的 “诚实验证者” 代码会根据(1)做出相应调整,不允许验证者投票给区块号 >
TRANSITION_HEIGHT
的 eth1 区块。如果投票算法已经选出了某个区块编号 >TRANSITION_HEIGHT
的 eth1 区块,则改成为TRANSITION_HEIGHT
的 eth1 区块投票。 - 此外,在已触发(2)的情况下,验证者会将
deposit_count
设置为比实际值高 2**63(就是将deposit_count
的 top bit 作为 “eth1 已完成” 的标记) - 当 eth2 在 “eth1 已完成” 标记开启的情况下接受
eth1data
时,eth2 会执行一次 “非常规的状态变换”,将该 eth1 区块的状态根放到 “eth1 执行环境”(eth2 上的一类系统级智能合约)的状态中。与 eth1 链上的总 ETH 供应量等量的 ETH 会添加到这个 eth1 执行环境的余额中。
update(state_root, transaction, witness) -> new_state_root
功能,可以按照 eth1 链的规则,以交易和见证消息(状态部分的默克尔证明)作为输入处理该交易,并决定更新后的 eth1 状态根。关于见证消息和状态根的运作原理,请阅读《无状态客户端概念》。eth1 执行环境代码可以添加额外的功能,即,将 ETH 和消息从 eth1 执行环境提取到 eth2 的其它部分,以及其它分片上的 eth1 执行环境副本中。在默认情况下,所有 eth1 账户/合约都会放在同一个分片上,因此为了利用 eth2 更大的容量,你需要主动使用这个功能将你的 ETH 或其它应用转移到其它分片上,不过难度不大。我们需要通过扩展 ERC20 标准来支持跨分片代币转账。用户客户端如何运作
TRANSITION_HEIGHT
的 eth1 区块都不存在。如果转换已经发生,客户端就会在 eth2 上查看 eth1 执行环境。完整的客户端将按顺序处理 eth2 上所有针对 eth1 执行环境的交易,以便继续更新完整的 eth1 状态树。这使得完整的客户端可以为它们想要发送的交易生成见证消息,并使用 eth2 格式对其进行 “打包”。轻客户端(以及钱包,如 metamask)会将它们的交易广播给完整的客户端,由后者为其添加见证数据。从用户的角度来看,以太坊能够 “感受到” 转换前和转换后(由于 PoS 和 EIP 1559,以太坊在感受后者时更加顺畅)。虽然打包和广播交易所使用的代码路径区别很大,但是它们所提供的功能都是一样的。我们甚至可以对这种转换进行设计,以便钱包无需经过任何修改,即可通过 RPC 与客户端通信。用户案例
潜在优化
TRANSITION_HEIGHT
至 eth2 上的 eth1 执行环境获取该状态的这段时间内,我们会对 eth1 状态进行一些预处理。特别是,我们可以:- 将十六叉帕特里夏树替换成二叉稀疏默克尔树和一个专门的哈希函数,以确保分支的哈希开销保持在O(log(n))。这可以将默克尔树分支的大小减少 4 倍左右。
- 将 RLP 替换成 SSZ 哈希树
- 将状态租金相关的数据字段添加到账户上
- 清除 “粉尘” 账户
- 根据抽象提案修改账户结构
(完)
(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)
原文链接:
https://ethresear.ch/t/the-eth1-eth2-transition/6265
作者: Vitalik
翻译&校对: 闵敏 & 阿剑你可能还喜欢:
干货 | 以太坊无状态客户端初探引介 | 无状态客户端中的见证数据观点 | 无状态以太坊:二进制状态树实验