投资有风险 入市需谨慎
APP
下载3点财经客户端

扫描关注

微信公众号
3点财经二维码 3点财经

3个阶段展示以太坊2.0最新进展

3点财经 ·

2019-07-15 15:17:40

热度: 0

我知道你们最近几天都被有关 Libra 的消息刷屏了,所以这里有一点精神慰藉:本文不会提及 Libra 的相关信息,在这里我们将回顾2019年6月以太坊 2.0最新的开发进展。 本文的内容



我知道你们最近几天都被有关 Libra 的消息刷屏了,所以这里有一点精神慰藉:本文不会提及 Libra 的相关信息,在这里我们将回顾2019年6月以太坊 2.0最新的开发进展。

 

本文的内容不是非常全面的,这些天发生的事情太多了。我将把过去几周积累的各种片段整理成一些连贯的东西。

 

让我们从开发更新开始。众所周知,以太坊 2.0的交付计划分为三个不同的阶段。最近最令人兴奋的是有关阶段0 (接近信标链客户端的互操作性) 和阶段2 (以太坊 2.0计算模型的开始) 的进展。

 

 

阶段0:信标链实现

 

信标链 (beacon chain) 是整个以太坊 2.0系统的协调层,可能也是最难交付的部分。有关信标链的背景知识,请参阅我之前发表的State of Ethereum Protocol #2: The Beacon Chain 这篇文章 [1]。

 

去年6月份,信标链被设想为以太坊2.0的未来。仅仅一年之后,阶段0的规范将在今年6月30日被冻结敲定。它是一个全新的区块链设计,其野心之大前所未有,包含了几十项重大的创新和见解,8个客户端实现已经准备就绪:这是惊人的以太坊社区一年以来的成就。坦率地说,这将使 Libra 相形见绌。任何对此不以为然的人,都生活在与我不同的宇宙中。

 

既然有关以太坊2.0规范的更新进展已经在 Github 上被很好地跟踪和记录了 [2],我就不像在以前那样详细介绍了。今天我们将从更广泛的角度来介绍相关的进展。

 

01. 互操作性

 

随着阶段0的规范趋于稳定,现在的重点转移到各个以太坊 2.0客户端实现之间的互操作性 (interoperability)。当前由8个活跃团队正在跟上最新的以太坊2.0规范。

 

一旦信标链网络启用,每个客户端都将需要相互进行通信,以便就信标链的状态达成共识。每个客户端都需要遵循相同的规则:即使是一个位 (bit) 不正确,也会导致无法达成共识。

 

考虑到这一点,我们在布鲁克林的 Bushwick Generator 举办了一个研讨会,名为“通往互操作之路”(The Road to Interop)。我拍了一些照片[3],感兴趣的人还可以观看现场录制的长达四个小时的视频 [4],还有研讨会的议程 [5]。这是一个让几个客户端实施团队聚在一起,计划如何让我们的客户端彼此连贯地通信的场合。Vitalik 在当天下午做了一个关于阶段2想法的演讲 (见下文)。Terence Tsao 也发布了关于 Prysm 客户端架构和设计的演讲幻灯片 [6]。

 

计划中的下一个重大事件是大约在9月初举办的主题为“Interop Lock-in”的研讨会。那时,客户端实现团队将在聚集在安大略省某个偏远的小屋,但只有在我们确认了所有客户端都能够很好地相处之后才会进行。

 

Jonny Rhea 在 Github 上整理发布了拟定通往互操作性之路的各阶段 [7],大家可进行参阅。

 

02. 网络 (Networking)

 

最终目标是使 Libp2p 成为以太坊2.0网络基础上的 P2P 通信协议 (备注:Libp2p 是一个便于使用者开发去中心化点对点应用程序的网络框架)。

 

然而,作为实现这一目标的一个简化步骤,各个客户端正在实现更简单的 Hobbits 协议,Trenton van Epps 发表的这篇文章 [8] 对 Hobbits 协议进行了很好地介绍。Jonny 也以推文风暴 [9] 的形式阐述了 Hobbits 协议的基本原理,且 ConsenSys 也提供了一些奖励金 [10] 来鼓励各团队在客户端中整合该协议。

 

与此同时,Whiteblock 在 Libp2p 上做了一些性能测试,Daniel Choi 在 Scaling Ethereum 探讨会上进行了介绍  [11] 。他们的发现对 Libp2p 在某些情况下的性能提出了一些问题 [12]。但是,通过与 Prtcocol Labs 进行合作,我们还将对 Libp2p 进行一些进一步的测试,以探索与以太坊 2.0相关的更真实的参数范围。

 

另一个有趣的进展是,PegaSys 研发团队发表的拜占庭容错聚合协议 Handel:Practical Multi-signature Aggregation for Large Byzantine Committees (《Handel:实现更大规模的拜占庭委员会的实用多重签名聚合》) [13]。

 

该协议可以显著地加快以太坊2.0中验证者搜集区块证明 (attestations) 的速度,允许更大的委员会规模 (committee sizes),因此可能更快地实现交易的最终性 (finality)。

 

03. Testing  测试 (Testing)

 

在当前对阶段0进行开发的期间,大量的测试工作正在进行。值得注意的是 Antoine Toulme 关于测试运行器 (runner) 的工作,这项测试工作由 Moloch DAO 资助,可以通过这个视频来了解最近的进展更新 [14],该视频非常值得客户端开发人员查看。

 

该规范是可执行的,并且所有跨客户端测试向量都可以直接从编写好的规范生成 [15],这一点是非常棒的。

 

还需要进行大量的工作来对该规范进行模糊测试 (fuzz-test),并提供一个用于对客户端进行模糊测试的框架,正如在最新版的以太坊2.0规范中所体现出来的那样[16]。

 

04.形式化验证 (Formal Verification)

 

Runtime Verification 已经编写了有关以太坊2.0存款合约增量 Merkle 树实现的审计报告,该报告使用 Vyper 语言  (而不是 Solidity) 进行编写。

 

这是一个重要的里程碑,为将存款合约部署到当前的以太坊 1.0链铺平道路。为了便于阅读,我们团队 (备注:即 PegaSys 团队) 的 Joe Delong 撰写了一篇解释性的有关以太坊 2.0 存款 Merkle 树的实现的文章 [17]。稀疏的 Merkle 树是非常棒的!

 

Runtime Verification 还将在 K 语言中生成信标链的正式可执行规范 [18]。

 

05. 信标链上线

 

在上周以太坊2.0实施者的电话会议上,Justin Drake 提出了信标链部署阶段的两个目标日期:

 

  • 在 DevCon 5 会议期间:将存款合约部署到当前的以太坊1.0链上。这一公开仪式将有助于避免骗子发布虚假地址来窃取人们的存款。

 

  • 2020年1月3日:信标链创世区块可能诞生。那时信标链将正式启用。

 

信标链创世区块的诞生将取决于两个先决条件。首先,存款合约中必须质押有足够多的 ETH。之前的一个硬性目标是质押的数量超过200万 ETH,但这个要求已经被移除 [19]。但质押数量的目标将是一个保证信标链安全启动的指令。

 

第二个先决条件是目标为3个 (或至少两个) “生产就绪”的信标链客户端和网络验证者。在此之前,所有客户端都要完成大量的兼容性、优化、测试、审计、改进、工具化、文档化和打包工作,所以我认为1月3日的目标有些雄心壮志。

 

 

阶段1:分片数据

 

最近,阶段1的规范 [20] 已经成了 Serenity 的一片绿洲。

 

 

阶段2:状态执行

 

公平地说,就在几个月前,以太坊 2.0要交付的阶段2还是一片迷雾。阶段2是所谓的“执行层”,这使得以太坊2.0区块链实际可用。该阶段将提供资金转移、实现智能合约和让所有 dapp 得以搭建等功能。但是,就在最近的4月初,我们还不清楚该阶段将会是什么样子。Casey Detrio 在 Scaling Ethereum 会议期间上做了一个关于阶段2的历史和现状的精彩演讲 [21],非常值得你花五分钟的时间进行观看……当时针对此阶段的所有问题都是开放的,设计空间仍然是巨大的,可能性也是无限的,那时我们不知道从哪里开始。

 

为了打破这一僵局,Casey 在 Ethresear.ch 上发布了一项令人兴奋的提议:Phase One and Done: eth2 as a data availability engine [22]。在不深入所有细节的情况下,这引发了一股创新浪潮,阶段2迅速而令人兴奋地开始成为关注的焦点。

 

之后 Vitalik 默默地公开了有关阶段2的首个提案 [23] 及其后续跟进 [24],以回应 Casey 的提议。新成立不久的 Quilt 团队的 Will Villaneuva 在 Medium 上发表了一篇对此进行解释的文章 [25]。在纽约的 Interop day 期间,Vitalik 讲述了有关阶段2的最新想法 (相关视频见[26]),最后在多伦多的 Scaling Ethereum 会议期间阐述了更多的背景信息 (视频见 [27] )。

 

Vitalik 提议的主旨是将以太坊区块链在执行交易中的作用降至最低。在以太坊1.0链中,只有一种执行交易的方式,即通过 EVM。在执行了某个区块中的交易之后,交易状态的 Merkle 根将被写入该区块中。为了在该区块中的交易上运行 EVM,所有的节点都需要存储整条链的状态 (包含账户余额、合约存储情况等)。

 

目前的阶段2建议采用这个模型并加以推广。现在可以有几种 (甚至很多) EVM 类型 (我们称之为执行环境,execution environments (EEs))。

 

执行环境 (EE) 就是在 eWASM 中编写的、(几乎) 作为纯函数运行的代码。这意味着执行环境本身并不会存储任何状态:执行环境所需要知道的任何信息都必须伴随着交易一并被提供。因此,假如我想要发送一枚代币给你,那伴随这笔交易,我需要提供一个证明 (比如一个 Merkle branch) ,从而证明我的余额中有这枚代币;该执行环境不知道我的余额有多少,因为它并不存储任何信息。实际上,这并不完全正确:每个执行环境都将存储一个32字节的值,该值是其当前全局状态的某种概要或累加器 (也许是一个 Merkle 根,但这并不是规定性的,它可以是任何足够安全的东西)。

 

以这种方式将执行层提取出来,这能够提供最大程度的灵活性。可能会出现针对 zk-Rollups、ERC20 之类的代币或者企业友好型环境、Plasam, 亦或者使用 Haskell 编写 [28] 的智能合约的 EE (执行环境) 等等。

 

其理念是,只要支付相当高的费用 (大约100 ETH?),任何人都可以部署自己的 EE 来支持自己的专业区块链环境。以太坊2.0分片链只关注基本方面:交易排序和数据可用性。

 

当前,一些问题仍在积极讨论中:是否支持 EE 之间的同步调用、如何组装区块的细节以及收取 gas 费用 [29]、EE 是永久性的还是需要支付一些存储费用 (storage fee)、 EE 最初将在以太坊2.0中部署什么等等。但在我看来,这无疑是正确的方向。

 

如果你想了解更多关于这一切的细节,你可以查看 Casey 和 Alex 的 Scout 库 [30],他们正在做一些可能的原型 [31],以及他们在 Ethersear.ch 上发表的文章:Phase 2 execution prototyping engine [32]。

 

对于我们这些更熟悉当前 EVM 执行的具体情况的人来说,所有这些听起来可能相当抽象和陌生。不用担心,适应以太坊1.0和以太坊2.0之间的平稳过渡路径已经成为一项优先事项,现在有一些有趣的想法 [33] 可以有效地实现这一点。虽然还存在一些挑战 [34],但相关的讨论 [35] 一直在 Ethresear.ch 行进行展开。

关键字:

推广
id_3广告位-758*200