编者按：本文来自以太坊爱好者，作者：WillVillanueva，翻译&校对:阿剑&曾汨，Odaily星球日报经授权转载。以太坊2.0Phase2的工作在不断推进。本文所讲的是截至当前的最新进展。Phase2的大部分工作都是以太坊基金会的Ewasm团队和Quilt团队合作完成。本文不同部分所讲的内容往往指向不同领域，交集甚少，因此，就请挑自己喜欢的部分阅读吧。在阅读本文之前，我非常推荐大家通过下列材料先了解一下Phase2以及执行环境提议的背景知识：通往Eth2Phase2以及Phase2测试网之路以太坊2.0Phase1&2开发者体验EthHub深入解读Ethereum2.0Phase2环游Eth2Phase2Ewasm2.0：Eth2.0中的状态执行影响Phase2的协议层变更
VitalikButerin自今年4月以来已经写出了不少提案以及准提案。在这些观念上不断迭代之后，当前的方向应该说非常确定了。最先提出以太坊2.0执行环境的初始提案已经在社区中探讨多时了。Vitalik的2号提案精炼了1号提案以及Eth2作为无状态协议的新理念。当前Phase2的设计没有大幅偏离2号提案的思想。从历史上来看，引入信标链负载均衡的概念之后，提案的一部分确实有所改变。这种负载均衡的思想提议将一条分片链理解为一个纯粹的计算进程，那么EE就可以在预先指定的分片链上动态运行。本质上，这种理念是通过在信标链上定义的负载均衡合约，将计算负载平衡到不同的分片链上。值得强调的是，这一设计理念非常有趣，可以通过相互协作的中继者实现多种不同模式的跨分片同步交易。它值得我们投入更多精力去研究，如果可靠的话，我们可以在未来把这一工具加到分片链上。最后，Vitalik在Devcon5期间公开了一份提案来简化Phase0以及Phase1。这份提案没有改变Phase2的根本方向，只是尝试改善围绕Phase2的开发者体验。在Devcon5上，有不少朋友都投诉Eth2没有跨分片的产品可组合性。在新提案下，跨分片通信可以在一个区块内完成。而在以前的提案中，跨分片通信要等待交联数据得到确认才能完成。结果就是，即使你的资金分散在不同的分片中，也可以很容易地把它们都汇集到一个分片中。该提议也恢复了ETH的神圣性，因为在这个“操作系统”中，分片、执行环境、验证者账户、区块生产者之间都可以自由传输ETH，只需一个区块的时延即可完成。它也会生成一个更简单的手续费市场，消除大家对旧的手续费市场提案的中心化担忧。执行环境提案
我们已经在搭建执行环境的原型和早期实现上取得了重大进展。首先，我们需要验证一种执行环境是否能在无状态模式下运作。这种执行环境所要求的证明/见证的数据量会太大吗？使用证据来执行状态转换的时间会太长吗？为了回答这些问题，我们做了很多种执行环境、用它们来研究这些问题，不过，首先我们需要一个搭建原型的引擎：Scout。Scout
Scout是一款以太坊2.0Phase2执行过程原型搭建引擎，它开发了一个对EwasmAPI的封装器，所以开发者可以用它搭建出执行环境的原型并开展基准测试。而且它还有assemblyscript和C++端口。与Eth1相关的诸EE
为了支持Eth1能切换到Eth2中，我们要把Eth1的状态转换规则做成Eth2中的一个执行环境。这一切换的主要挑战在于，将Eth1转换成无状态模型，然后将EVM和交易/账户模式转成一个执行环境。下面要谈到的EE都是Eth1EE的前身。最近有一个工作组成立，专门围绕Eth1EE大力开发。他们汇总出了一份初始工作计划，并且很友善地在ethresearch论坛介绍自己。无状态默克尔帕特里夏树token主要资料：Github、SinaMahmoodi在Devcon5上的演讲无状态tokenEE的第一个原型旨在模仿Eth1.0的架构。它使用parity的代码库来实现Eth1状态树以及RLP编码规则。它也纳入了一个基本的中继者实现，让中继者为一组交易生成多种证明。基准测试：70笔交易以及5000个账户/叶子节点用时：5秒证据大小：235kb执行执行和证据大小仍需要重大改进，但进展也从这些早期结果中展现了出来。其中一个问题涉及到将Parity的rust库编译成wasm代码，结果出现了很多memcopy操作以及其它效率低下的操作。总的来说，把rust编译到webassembly已经被证明会遇到很多困难。此外，签名验证一项用去了4秒。TurboToken主要资料：Turboproof概览、TurboproofRustGithub、TurboTokenGithub、GuillaumeBallet的Devcon5演讲、SinaMahmoodi的Devcon5演讲TurboToken模型用到的turboproofs技术一开始是AlexeyAkhunov为实现Eth1无状态轻客户端所做的研究，它能够高效地生成、合并及序列化Eth1数据树的multiproof，也支持单次操作高效更新数据树。CaseyDetrio和Sina用assemblyscript和rust语言开发出了一个初始的单分支原型，以验证turboproof的效率是否够高。在单分支原型上初步得出了令人满意的结果后，Casey用assembly脚本实现了一个简单、最基本可用的turboprooftokenEE。SinaMahmoodi复制了这一实现，然后将Guillaume的turboproof完整rust代码库和生成器移植到了typescript中。基准测试：70笔交易以及5000个账户/叶子节点用时：140毫秒证据大小：50kb执行时间和证据大小相比起SMPT原型都有了很大的提升。此外，在整个基准测试中，签名验证花去了105毫秒。来自CaseyDetrio的基准测试证明还可借助进一步的优化将签名验证的时间削减1/3。当然，5000远远小于Eth1数据树上的实际账户数量，Sina正在拓宽基准测试，以测试turboproof在实际负载下的表现。EVM解释器EE主要资料：Github、Devcon5演讲我们需要在一个执行引擎中开发出一个EVM解释器，好支持Eth1EE。Hugo做了一个原型，而且围绕一个addandmul256合约做了测试。未来还需要引入更多合约和基准测试来改进这个原型。总结上述所有的实验性工作都是为了做出Eth1执行环境的一种实现。我们已经开始制作构造原型了，但还是有很多性能问题需要审议。如上文所述，近期有一个工作组开始一门心思开发Eth1EE并打造Eth1无状态模式。以Eth2为中心的诸EE
这一部分要向大家介绍那些不完全是为实现Eth1->Eth2迁徙而开发的EE。Eth2要使用一种新的基于账户的执行环境，不同于Eth1的账户和交易模型，因为Eth1所用的交易、账户和累加器模型都不是最优的。此外，诸如optimisticrollups、ZKrollups之类的模型也要研究。Eth2EE的设计空间是完全开放的，而下列就是早期的想法和原型。CMerkleToken主要资料：Github、Devcon5PresentationPaulDworzanski对无状态Merkletoken的C语言实现，他使用了二叉默克尔树。数据树的验证和更新都用到了最优内存分布，而且安排了独特的multiproof格式。该模型的验证、更新数据树操作都是一次完成的），而且很有可能可以用在Eth1的十六叉数据树上。但是，尚不清楚数据树更新算法能不能用在Eth1的数据树上）。基准测试：证明中涉及到了222个账户中的40个用时：20毫秒证据大小：25kb当前，测试用到的这个实现已经是最高效率的了。基准测试中没有包括验签的部分，但我们估计只需多花30毫秒即可。而且还有很多进一步优化的方案，比如通过缓存哈希和证据来减低运算时间和大小。适应性哈希长度方案也可以进一步降低证据的大小。最后，更好的哈希函数实现就能带来更短的运算时间。ZKRollup主要资料：GeneralZKRollupOverview、Devcon5演讲、EEstark验证者示例、WASMproof验证者、websnarksZKrollups是一种Layer-2扩展方案，因为不会用到复杂的退出挑战机制和锁定机制，所以能够避免现有的Layer-2方案常见的用户体验问题。与这里列出的其它token转移方案相比，ZKRollup大幅降级了对数据可用性的要求。这里列出的实现使用了websnark——一个用wasm实现的生成器，可用于snark验证或其它配对函数。为了开发该EE，Jared改编websnark、开发了一个验证Groth16证据的独立wasm库。这个EE还是个早期原型，还得继续开发。ShardEther(Sheth)主要资料：Github、MattGarnett的Devcon5演讲、InternalQuilt演讲、SSZ概览Sheth是Eth2合约EE的一个先驱。Sheth基于Eth2中用到的简单序列化编码规范，它用到了稀疏默克尔树方案、借用turboproof的操作码但使用了不同的形式来管理读取、写入和更新需求。DiederikLoerakker的设计思路是，通过存储一个offset的列表来决定如何遍历整棵数据树。稀疏默克尔树证明的长处在于，你可以在编译时静态地定义你正在引用的数据的总体索引。它也极大地简化了更新状态所需的逻辑，因为数据树永不删除或者插入节点；不过，为此也付出了一些牺牲。Sheth还包括了一个命令行客户端，可以作为中继者或者状态提供者。基准测试：50个账户以及50笔交易证据大小：517kb当前的实现产生的证明大小实在是太大了，而且也比我们期望的要慢。证据可以通过移除补位的0或者消除0哈希值的数量而大幅减小；运算速度则可以通过引入host函数来管理256比特的操作还有必要的代码优化来提升。DiederikLoerakker已经提交了一个issue，论述了如何提交这个设计的效率。总的来说，使用稀疏默克尔树就会比较依赖哈希计算，而这个效果已经从初始的基准测试表现出来了。SimpleUmbrella—Eth2智能合约EE主要材料：EthResearch论坛中的提案、executecodehostfunctionPR该Eth2EE是一个无状态的智能合约执行环境，运行合约的方式与Eth1执行环境相似，但合约是wasm形式的。此外，它未来有可能会转用累加器，而不是使用eth1所用的十六叉默克尔树。稀疏默克尔树看起来不错，不过也还需要进一步的基准测试来作出可靠的决策。MattGarnett汇总了一个Eth2EEspawnruntimes以及在子合约中分享调用者/被调用者数据的早期规范。因为近期的一些争议，我们开发了一个host函数的原型，可用于在Eht2EE中spawn或者运行子合约。一个新的代码库已经开放，很快我们就能运行基本的智能合约了。Ewasm——解释器、编译器以及计算量度量
这部分内容涵盖了Ewasm团队在过去几年中的大量工作。在Devcon5期间，Ewasm团队给出了一个清楚的、数据翔实的Ewasm相关工作现状和进展说明。如果这部分内容勾起了你的兴趣，我非常推荐你看看完整的视频。下面我会给出一个简单的总结。此外，Maksym也为Ewasm团队在WasmintheBlockchain大会上的分享内容做了一份非常全面的概览。编译器
如果我们想让Eth2能尽快发布，那么继续编译器路线可能会有更高的风险。其中一个困难或者说难以弄清楚的事项是管理JITbombs。单操作的编译器也许也可以避免JITbombs，但现在大家都比较担心当前的单操作编译器实现的稳定性和安全性。在未来将编译器作为Eth2的一部分也许不无道理，但如果我们想尽快启动，解释器可能是个更安全的选择。解释器
CaseyDetrio以及AlexBeregszaszi的Devcon5演讲给出了对解释器性能的非常全面的分析。更有意思的是，优化后的解释器以及精心编写的代码被证明可以实现接近原生编译器的性能。在一次测试中，Casey将一个wasm解释器和用于256位数学操作的host函数相结合，评估了多种配对函数和哈希函数的性能。结果令人印象深刻，性能很接近原生且优化后的编译器。在他的一系列基准测试中，他还发现最快的解释器是wabt。计算量度量
PaulDworzanski在他的Devcon5演讲中深入探讨了这个领域。为了度量计算量，use_gas调用会在wasm合约部署及验证之时注入wasm字节码。注入及验证的复杂性无疑会影响合约部署的费用。当前的基准测试显示，注入计算量度量组件后，wasm代码运行的速度会变慢1.04～2.4倍。对注入流程及注册器assembly的更优模式基准测试将指明进一步优化的方向。在Lighthouse客户端或者Phase2模拟中的Phase1和2原型
我们希望模拟Phase1和2的客户端最终是如何构建的，以及如何支持开发实现的团队。我们也希望使用这些工作来模拟及测试EE在实际环境中跨多个分片运行时的情形。在Devcon5期间，我做了一场关于我们所构建的模拟程序的演讲。我们在Lighthouse客户端中开发/加入了一个非常简单的Phase1原型并在该客户端中加入了phase2Ewasmruntime。我们与Sheth交互，而且能够在Lighthouse中模拟基本的EE或者代币转移。因为Lighthouse客户端还在踊跃开发中，我们意识到维护Lighthouse客户端的一个分支并在上面开发很可能会比我们一开始设想的要难。所以，我们决定吸取初始原型的养分，在Scout里面开发一个抽象的存根版本。我们将继续模拟信标链和分片链的运行，不过我们可以大幅简化其中的逻辑，因为我们的重心在执行环境的研究以及跨分片基准测试上。这部分工作正由Quilt团队的两位新成员管理着。中继者、状态提供者以及手续费市场
JohnAdler针对这一主题写了一份非常全面的概览。他的文章也讲述了Eth2提案的有趣演化历程。总结一下，Vitalik最新的分片简化提案消除了一开始我们在中继者模型中遇到的许多问题。不过，关于状态提供者如何向区块生产者发送交易，以及区块生产者如何将交易包合并到一个合适的multiproof中，仍有不少问题悬而未决。其中一种建议是部署一个带有证明合并脚本的新执行环境。接下来，围绕着状态提供者的激励机制也要确定下来。Zsolt在第一次轻客户端小分队视频会议中分享了他对激励机制的研究。Eth1EE工作组也正在评估一个状态提供者网络，他们拿BeamSync上先前的工作作为模型。最终，中继者或者状态提供者将继承web3.js或者ethers.js所连接的RPC端点。为这些跨多个EE的操作提出一系列标准是至关重要的。跨分片交易
异步跨分片交易
Vitalik的最新Phase0&1提案对于跨分片交易和可组合性来说都是好消息。在新提案中，一次跨分片调用只需1个时隙的时延就能完成，而在过去的提案中，一次调用要等待12~18分钟的时延才能确定下来。因此，在分片间转移你的状态会变得很快。此前，我们想用optimisticroots来加快调用速度，但发现这些方案都非常复杂。从一个dApp开发者的角度来看，跨分片调用只需遵循多线程编程中的异步范式和方法。在编写智能合约时，HLL和DSL需要提供必要的工具将跨分片行为抽象成异步范式。整个模式很有可能就像下面这样：简单的异步调用消息驱动型方法两阶段确认锁——读/写如何在EE或者在合约的底层中支持这些模式还需要进一步的研究。上文提到的模拟应该能为我们对这些模型的实验提供基础，不过，我们真的要说，这是一个重要的研究领域，如果人们愿意参与进来，我们会非常高兴。像在此贴中描述的那样，在更底层规定进程前和进程后的行为分别，可能会为在合约内暂停执行及后续继续执行提供一个合理的框架。同步跨分片交易
之前，Vitalik发表了一篇论述状态方案的帖子。这些方案实质就是链上Layer-2模式，而分片仅作为数据可用性层。这些模型其实都是现在所谓的optimisticrollups的前身。将多分片用作一个optimisticrollup方案的数据可用性层使同步跨分片交易成为可能。我们可能在不远的将来根据这个概念开发出一款原型。此外，如果信标链引入负载均衡机制，我们可以通过相互合作的中继市场实现同步跨分片交易。请看上文“影响Phase2的协议层变更”部分了解更多细节。我们真的需要跨分片调用吗？
另一种值得进一步研究的观点是，Eth2的主体应该要向状态通道、optimisticrollups以及zkrollups倾斜。在这种思路下，Eth2本身就是一个数据可用性层，而跨分片调用只有在桥接这些方案或者在退出挑战/错误性证明过程中才会用到。Rollups仍要在Eth1或者Eth2执行环境的边界内定义好，不过，只有需要提交错误性证明的时候，才需要在链上执行计算。Phase2工具链
为推进我们的研究，我们提议了一套开发者需要用到的工具链。正如上文“Lighthouse中的Phase1和Phase2原型”章节中说的那样，我们正在积极开发一套模拟来测试及运行跨分片的执行环境。不过，为使智能合约运行模式最优化，我们还得添加很多编排工具。这个帖子对这些工具做了更深入的说明。Phase1&2模拟类似于Truffle这样的测试工具，用于在一个EE中运行wasm合约插入Phase1客户端的运行时环境可靠的muilti-proof后端中继者、状态提供者工具，用于与web3.js交互Vitalik对Phase2的其他贡献
Vitalik最近还在其它帖子中讨论了与Phase2相关的主题，但我在上文中没有直接引用，特此指出：Eth1->Eth2迁移实现跨分片交易通过加入储存价值的EE来消除执行环境风险形式化并提升Eth2应对无效分片区块确定性的方法在信标链上保存的合约跨分片DeFi可组合性行动起来！
如果你有兴趣帮助我们，请联系我们并参与进来。请加入这个telegram频道来获取新知或提问。我们已经有了进步，但仍有很多工作做。最后，我们将开始每月一次的视频会议。第一次会议计划在美国东部时间的12月3号，周二，上午10点举行。结论
在Phase2上我们已经取得了很多进展，但毫无疑问需要做更多工作。这些早期的数据显出前景不错，而近期的大力投入也是非常有用的。我们需要围绕跨分片搭建原型并加以测试，我们也要开始构思如何在Eth2EE里面开发合约。无状态系统的累加器方案需要更多关注，因为它将让当前的EE原型性能更高、更适应生产环境。我们还需要为EE开发打造更好的工具。最后，不能漏掉，我们还需要中继者、状态提供者的经济激励机制。感谢DannyRyan和JosephC。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。