干货| 以太坊二期进展（2019-12）

以太坊 2.0 第 2 阶段的工作继续推进。 本文介绍了截至目前的最新进展。 第 2 阶段的大部分工作是 Ewasm 团队和以太坊基金会的 Quilt 团队合作完成的。 这篇文章不同部分的内容往往指向不同的领域，很少有交集。 因此，请选择你喜欢阅读的部分。在阅读本文之前，我强烈建议你先通过以下资料了解Phase2的背景知识和执行环境提案（EE）：影响Phase2的协议层变化

自今年 4 月以来，Vitalik Buterin 已经写了很多提案和准提案。 在这些概念上不断迭代之后，现在的方向应该说是非常确定了。 以太坊 2.0 执行环境 (EE) 的初始提案已在社区中讨论了一段时间。 Vitalik 的提案 2 完善了提案 1 和 Eth2 作为无状态协议的新概念（这篇博文有一个标题为“分片链不需要状态”的部分，简要解释了什么是无状态）。 当前的 Phase 2 设计与提案 2 的想法没有显着差异。 从历史上看，当引入信标链负载平衡的概念时，部分提案确实发生了变化。 这种负载均衡的思想提出把一条分片链理解为一个纯计算过程，那么EE就可以动态地运行在预先指定的分片链上。 本质上，这个思路是通过信标链上定义的负载均衡合约，将计算负载均衡到不同的分片链上。 值得强调的是，这种设计理念非常有趣，通过协作中继器可以实现多种不同模式的跨分片同步交易。 它值得我们的研究付出更多的努力。 如果可靠的话，我们可以在未来（可能上线之后）将这个工具添加到分片链中。 最后，Vitalik 在 Devcon 5 期间公开了一个简化 Phase 0 和 Phase 1 的提议。这个提议并没有改变 Phase 2 的基本方向，只是试图围绕 Phase 2 改善开发者的体验。在 Devcon 5 上，很多朋友抱怨道Eth2 不具备跨分片的产品可组合性（Vitalik 也给出了自己的回应）。 根据新提案，跨分片通信可以在一个区块内完成。 在之前的提案中，跨分片通信需要等待跨链数据确认后才能完成（6分钟）。 结果是，即使您的资金（或状态）分散在不同的分片中，也很容易将它们全部集中在一个分片中（等待 6 秒就足够了）。 这个提议也恢复了ETH的神圣性，因为在这个“操作系统”中，ETH可以在分片、执行环境、验证者账户和区块生产者之间自由传输，只需要一个区块延迟。 可以做到。 它还将产生一个更简单的费用市场（Gas 市场），消除旧费用市场提案的中心化问题（在另一章中详细介绍）。

环境提案的执行

我们在构建原型和执行环境的早期实施方面取得了重大进展。 首先，我们需要验证一个执行环境是否可以在无状态模式下运行。 这个执行环境需要的proof/witness数据量会不会太大？ 使用证明来执行状态转换会花费太长时间吗？ 为了回答这些问题，我们做了很多执行环境以太坊最新进展，用它们来研究这些问题。 然而，首先我们需要一个用于构建原型的引擎：Scout。

ScoutScout 是一个以太坊 2.0 Phase 2 执行过程原型引擎（最初由 Alex Beregszaszi 开发），它为 Ewasm API 开发了一个包装器，因此开发者可以使用它来构建执行环境的原型并进行基准测试（benchmarking）。 它还具有汇编脚本和 C++ 端口。

为了支持与Eth1相关的EE从Eth1到Eth2的切换，我们需要将Eth1的状态转换规则做成Eth2中的执行环境。 这个转换的主要挑战是将 Eth1 转换为无状态模型，然后将 EVM 和交易/账户模型转换为执行环境。 下面提到的 EE 是 Eth1 EE 的前身。 最近成立了一个工作组，重点关注围绕 Eth1 EE 的开发。 他们制定了初步工作计划，并在伦理研究论坛上亲切地介绍了自己。

Stateless Merkel Patricia Tree (SMPT) token 主要信息：Github，Sina Mahmoodi 在 Devcon 5 上的演讲 stateless token EE 的第一个原型旨在模仿 Eth 1.0 的架构。 它使用 parity 的代码库来实现 Eth1 状态树（Hexary Merkle-Patricia Trie）和 RLP 编码规则。 它还包含一个基本的中继器实现，让中继器为一组交易生成多个证明。 基准：70 笔交易和 5000 个账户/叶节点耗时：5 秒证明大小：235 kb 执行执行和证明大小仍需要重大改进，但从这些早期结果中可以明显看出进展。 其中一个问题涉及将 Parity 的 rust 库编译成 wasm 代码，这导致了大量的 memcopy（内存复制）操作和其他低效率。 一般来说，将 rust 编译为 web assembly 已被证明是相当困难的。 此外，签名验证项目花费了 4 秒（总共 5 秒）。

Turbo Token主要信息：Turboproof概述（编者注：中文翻译见文末超链接）、Turboproof Rust Github、Turbo Token Github、Guillaume Ballet的Devcon 5演讲、Sina Mahmoodi的Devcon 5演讲中使用的Turboproofs技术Turbo Token 模型一开始是Alexey Akhunov 为实现Eth1 无状态轻客户端所做的研究。 它可以高效地生成、合并和序列化 Eth1 数据树的 multiproof，同时也支持单次操作（single pass）高效更新数据树。 Casey Detrio 和 Sina 使用汇编脚本和 Rust 开发了一个初始的单分支原型，以验证 turboproof 是否足够高效。 在单分支原型上初步获得满意的结果后，Casey 用汇编脚本实现了一个简单且最基本可用的 turbo proof token EE。 Sina Mahmoodi 复制了这个实现，然后将 Guillaume 的 turbo proof full rust 代码库和生成器移植到 typescript。 基准测试：70 笔交易和 5000 个账户/叶节点运行时间：140 毫秒证明大小：50 kb 与 SMPT 原型相比，执行时间和证明大小都有很大改进。 此外，签名验证在整个基准测试中花费了 105 毫秒。 Casey Detrio 的基准测试表明，进一步优化还可以将签名验证时间缩短 1/3。 当然，5000 远远少于 Eth1 数据树上的实际账户数量，新浪正在拓宽基准测试 turboproof 在实际负载下的表现。

EVM 解释器 EE 主要信息：Github，Devcon 5 演讲 我们需要在执行引擎中开发一个 EVM 解释器（可用于 web assembly）以支持 Eth1 EE。 Hugo 制作了一个原型并围绕 add 和 mul256 合约对其进行了测试。 未来需要引入更多的合约和基准来完善这个原型。

总结 以上所有的实验工作都是为了实现Eth1的执行环境。 我们已经开始原型构建，但是还有很多性能问题需要考虑。 如上所述，一个工作组最近开始专注于开发 Eth1 EE 和创建 Eth1 无状态模型。

这部分以 Eth2 为中心的 EE 将介绍那些没有完全开发用于 Eth1 -> Eth2 迁移的 EE。 Eth2 将使用一个新的基于账户的执行环境，这与 Eth1 的账户和交易模型不同，因为 Eth1 使用的交易、账户和累加器模型并不是最优的。 此外，optimistic rollups、ZK rollups等模型也应该研究一下。 Eth2 EE 的设计空间非常开放，以下是早期的想法和原型。

C Merkle Token 主要资料：Github, Devcon 5 PresentationPaul Dworzanski 的无状态Merkle token 的C 语言实现，他使用二叉Merkle 树（而不是稀疏Merkle 树）。 数据树的验证和更新采用最优内存分布，并安排了独特的多重证明格式。 该模型的验证和更新数据树操作在一次pass（单通道）中完成（从而避免了内存复制操作（memcopy and duplication）），很有可能可以用在Eth1的16进制数据树上。 但是，数据树更新算法是否可以用在Eth1数据树上还不清楚（因为基于Eth1的模型一般都是采用multiple pass）。 基准测试：222个账户中有40个涉及证明时间：20ms（不包括签名验证）证明大小：25kb目前，测试中使用的实现已经是最高效的。 签名验证不包括在基准测试中，但我们估计它只需要额外的 30 毫秒。 并且还有许多进一步的优化解决方案，例如缓存哈希和证明以减少计算时间和大小。 自适应哈希长度方案（哈希的长度随着网络的增长而增加）也可以进一步减少证明大小。 最后，更好的散列函数实现可以缩短计算时间。

ZK Rollup主要信息：General ZK Rollup Overview（编者注：中文翻译见文末超链接“ZK rolup vs. Optimistic rollup”）、Devcon 5演讲、EE stark verifier example、WASM proof verifier、 web snarks ZK rollups 是一种 Layer-2 扩展解决方案，因为它没有使用复杂的退出挑战机制和锁定机制，可以避免现有 Layer-2 解决方案常见的用户体验问题。 与这里列出的其他代币转移方案相比，ZK Rollup 大大降低了对数据可用性的要求。 此处列出的实现使用 web snark——一种在 wasm 中实现的生成器，可用于 snark 验证或其他配对功能。 为了开发 EE，Jared 采用了 websnark，开发了一个单独的 wasm 库来验证 Groth16 证明。 该 EE 仍是早期原型，需要继续开发。

Shard Ether (Sheth) 主要来源：Github，Matt Garnett's Devcon 5 talk，Internal Quilt talk（更详细），SSZ 概述 Sheth 是 Eth2 合约 EE 的前身（基于 Eth1，但经过迭代使其更适合）wasm/Eth2 ). Sheth 基于 Eth2 中使用的简单序列化编码规范 (SSZ)，它使用稀疏 Merkle 树方案，借用 turboproof 操作码，但使用不同的形式来管理读取、写入和更新要求。 Diederik Loerakker 的设计思想是通过存储一个偏移列表来决定如何遍历整个数据树。 稀疏 Merkle 树证明的优势在于，您可以在编译时静态定义所引用数据的整体索引。 它还大大简化了更新状态所需的逻辑，因为节点永远不会被删除或插入到数据树中； 然而，为此有一些牺牲（高强度哈希计算）。 Sheth 还包括一个命令行客户端，可以充当中继器或状态提供程序。 基准测试：50 个账户和 50 个交易证明大小：517 kb 当前的实现产生的证明太大（517 kb 不是一个小数字）并且比我们想要的要慢。 通过去掉padding 0或者去掉0哈希值的个数，可以大大减少证据； 运算速度可以通过引入host函数管理256位运算（下节详述）和必要的代码优化来提升。 Diederik Loerakker 提交了一个讨论如何有效提交此设计的问题。 一般来说，使用稀疏 Merkle 树会更多地依赖哈希计算，这种效果已经从最初的基准测试中得到体现。

SimpleUmbrella — Eth2 智能合约 EE 主要资料：Eth Research 论坛中的提案，执行代码宿主函数 PR以 wasm 的形式。 此外，将来它可能会切换到累加器，而不是 eth1 使用的十六进制 Merkle 树。 稀疏 Merkle 树看起来不错，但需要进一步的基准测试才能做出可靠的决策。 Matt Garnett 制定了 Eth2 EE spawn runtimes 和在子合约中共享调用者/被调用者数据的早期规范。 由于最近的一些争议，我们开发了一个主机函数原型，可用于在 Eht2 EE 中生成或运行子合约。 一个新的代码库已经开放，很快我们就可以运行基本的智能合约。

Ewasm - 解释器、编译器和计算指标

本节涵盖了 Ewasm 团队在过去几年中所做的大量工作。 在 Devcon 5 期间，Ewasm 团队对 Ewasm 相关工作的状态和进展进行了清晰翔实的描述。 如果这部分引起了您的兴趣，我强烈建议您观看完整视频。 下面我做一个简单的总结。 此外，Maksym 还非常全面地概述了 Ewasm 团队在 Wasm in the Blockchain 会议上分享的内容。

编译器 如果我们希望 Eth2 尽快发布，继续编译器路线可能风险更大。 很难或难以弄清楚的事情之一是管理 JIT 炸弹（通过模糊测试方法发现）。 single-pass 编译器也可能避免 JIT 炸弹，但现在大家更担心的是当前 single-pass 编译器实现的稳定性和安全性。 将来将编译器作为 Eth2 的一部分可能是有意义的，但如果我们想尽快开始，解释器可能是更安全的选择。

口译员 Casey Detrio 和 Alex Beregszaszi 在 Devcon 5 的演讲中对口译员的表现进行了非常全面的分析。 更有趣的是，优化的解释器和编写良好的代码已被证明可以实现接近本机的编译器性能。 在一项测试中，Casey 将 wasm 解释器和主机函数（Bignum 库）结合起来进行 256 位数学运算，以评估各种配对函数和哈希函数的性能。 结果令人印象深刻，性能接近本机和优化编译器。 在他的一系列基准测试中，他还发现最快的解释器是 wabt。

计算指标 Paul Dworzanski 在他的 Devcon 5 演讲中深入探讨了这个领域。 为了测量计算，在部署和验证 wasm 合约时，use_gas 调用会注入 wasm 字节码（无论它是在 EE 还是 umbrella EE 中运行）。 注入和验证的复杂性无疑会影响合约部署的成本。 当前的基准测试表明，wasm 代码在注入计算指标后运行速度慢了 1.04-2.4 倍。 对注入过程和注册表组装的更好模式进行基准测试将指向进一步的优化。

Lighthouse 客户端或第 2 阶段模拟中的第 1 阶段和第 2 阶段原型

我们想要模拟第 1 阶段和第 2 阶段客户端最终将如何构建以及如何支持开发实施的团队。 我们也希望利用这项工作来模拟和测试 EE 在真实环境中跨多个分片运行。 在 Devcon 5 期间，我谈到了我们构建的模拟。 我们在 Lighthouse 客户端中开发/引入了一个非常简单的第 1 阶段原型（未添加网络组件），并在客户端中包含第 2 阶段 Ewasm 运行时。 我们与 Sheth 交互（Sheth 充当中继器和状态提供者）并且能够在 Lighthouse 中模拟基本的 EE 或令牌传输。 由于 Lighthouse 客户端仍在积极开发中，我们意识到维护 Lighthouse 客户端的分支并在其上进行开发可能比我们最初想象的要难。 因此，我们决定从最初的原型中吸取营养，在 Scout 中开发一个抽象的存根版本。 我们将继续模拟信标链和分片链的运行，但是我们可以大大简化逻辑，因为我们的重点是执行环境和跨分片基准测试的研究。 这部分工作由 Quilt 团队的两名新成员负责。

中继器、状态提供者和费用市场

John Adler 就此主题撰写了非常全面的概述。 他的文章还讲述了 Eth2 提案的有趣演变。 总而言之，Vitalik 最新的分片简化提案首先消除了我们在中继模型中遇到的许多问题。 然而，关于状态提供者如何将交易发送给区块生产者，以及区块生产者如何将交易包整合到合适的多重证明中，仍然存在许多悬而未决的问题。 其中一项提议是部署一个带有证明合并脚本的新执行环境。 接下来，还应确定围绕状态提供者的激励机制。 Zsolt 在第一次 Light Client Squad 视频会议（记录在这里）中分享了他对激励的研究。 Eth1 EE 工作组还在评估一个状态提供者网络，使用之前关于 Beam Sync 的工作作为模型。 最终，中继器或状态提供者将继承 web3.js 或 ethers.js 连接到的 RPC 端点。 为跨多个 EE 的这些操作提出一套标准至关重要。

跨分片交易

异步跨分片交易 Vitalik 最新的第 0 阶段和第 1 阶段提案对于跨分片交易和可组合性来说都是个好消息。 在新提案中，跨分片调用只需延迟一个时隙（6 秒）即可完成，而在过去的提案中，调用必须等待 12 到 18 分钟的延迟才能完成。 因此，在分片之间转移你的状态（或 eth）变得非常快。 之前我们想用optimistic roots来加速调用，但是发现这些方案都非常复杂。 从dApp开发者的角度来看，跨分片调用只需要遵循多线程编程中的异步范式和方法即可。 在编写智能合约时，HLL (Slodity) 和 DSL (Vyper) 需要提供必要的工具，将跨分片行为抽象为异步范式。 整个模式很可能是这样的：如何在EE或合约底层支持这些模式需要进一步研究。 上面提到的模拟（以及下面提到的编排工具）应该为我们使用这些模型进行实验提供基础，但实际上，我们会说这是一个重要的研究领域，如果人们愿意参与，我们会很开心。 如本文所述，在较低级别指定预处理和后处理行为可能会为在合约中暂停和随后继续执行提供合理的框架。

在同步跨分片交易之前，Vitalik 发表了一篇讨论状态方案的帖子。 这些解决方案的本质是链上的 Layer-2 模式，分片只是作为数据可用性层。 这些模型（也就是之前传说中的“delayed state execution”模型、“lazy execution”模型或者“shadow chain”）其实就是所谓optimistic rollups的前身。 使用多个分片作为 optimistic rollup 方案的数据可用性层使得跨分片同步事务成为可能。 我们可能会在不久的将来开发基于此概念的原型。 另外，如果信标链引入负载均衡机制，我们可以通过相互协作的中继市场实现同步跨分片交易。 有关详细信息，请参阅上面的“影响第 2 阶段的协议层更改”部分。

我们真的需要跨分片调用吗？ 另一个值得进一步研究的观点是，Eth2 的主体应该倾向于 state channels、optimistic rollups 和 zk rollups（在这些方案成熟之后）。 按照这个思路，Eth2 本身就是一个数据可用性层以太坊最新进展，跨分片调用只有在桥接这些方案或退出挑战/虚假证明时才会使用。 Rollup 仍然需要在 Eth1 或 Eth2 执行环境的边界内定义，但是，只有在需要提交错误证明时才需要在链上进行计算。

第二阶段工具链

为了推进我们的研究，我们提出了开发人员需要使用的工具链。 正如上面“Lighthouse 中的第 1 阶段和第 2 阶段原型”部分所述，我们正在积极开发一组模拟来测试和运行跨分片的执行环境。 但是，为了优化智能合约的运行方式，我们不得不加入很多编排工具。 这篇文章更深入地解释了这些工具。

Vitalik 对 Phase2 的其他贡献

Vitalik 最近在其他帖子也讨论过 Phase 2 相关的话题，不过我上面没有直接引用，特此指出：

让我们继续前进！

如果您有兴趣帮助我们，请与我们联系并参与其中。 请加入此电报频道以获取更新或问题。 我们取得了进展，但仍有许多工作要做。 最后，我们将开始每月一次的视频会议。 第一次会议定于美国东部时间 12 月 3 日星期二上午 10:00 举行。

综上所述

我们在第二阶段取得了很大进展，但毫无疑问还有更多工作要做。 这些早期数字很有希望，但最近的投资（尤其是无国籍客户）也非常有用。 我们需要围绕跨分片构建原型并进行测试，我们还需要开始思考如何在 Eth2 EE 中开发合约。 无状态系统的累加器方案需要更多关注，因为它将使当前的 EE 原型具有更高的性能和生产准备。 我们还需要为 EE 开发构建更好的工具。 最后，不能错过，我们还需要一个对中继者和状态提供者的经济激励机制。

感谢 Danny Ryan 和 Joseph C.

（结束）

（文中提供了很多超链接，请点击阅读原文在EthFans网站获取）

原文链接：

@william.j.villanueva/ethereum-2-0-phase-2-progress-7673b57eabff