Eth2 进展速览

撰文：Danny Ryan

翻译：Unitimes_David

非常感谢 Sacha Saint-Leger、Joseph Schweitzer、Josh Stark 和 protolambda 提供的宝贵意见和反馈。

我花很多时间来对有关 eth2 的问题进行回答和解释，真的很多时间。其中一些是从深层次和技术层面来解答的，这是我在向技术贡献者们沟通研究和规范方面时的情况；但这些天我越来越多地回答社区有关 eth2 进展、方向、动机、设计决策、推迟等方面的问题。我真的非常喜欢这期间 (与社区成员) 的对话。当我在解释 eth2 时，突然想到全新的方式来描述不同的 (eth2) 组件，或者根据观众不同而找到正确的类比时，这宛如让齿轮转动，使灯泡亮起，都会让我兴奋不已。

但这种动态的/对话的方式，虽然很有价值，却依旧会让社区的很多人蒙在鼓里。我一次又一次地被问到同样的问题，且更令人担忧的是，我在6个月之后又会被问到同样的问题！显然其中存在信息传递的问题。这些信息都是存在的，但是分散在网络上——包括研究类帖子、规范、规范的解释性文章、公开电话会议、公共聊天室、reddit 帖子、博客文章等等。

在 devcon5 会议之后，我第一次尝试在那些深入了解 eth2 的人和社区的其他成员之间建立起一座信息的桥梁，以系列博客文章“eth2 quick update” (eth2 更新速览) 的形式呈现。这些都是可以帮助你理解 (eth2) 的小片段，但我意识到，这些系列文章并不能真正传递更大的图景信息。虽然通过博客、AMA (在线问答) 和会议确实能够 (向社区) 传递和讨论更大的图景信息，但即使这样，书面形式依然会所有帮助。

因此我写下了这篇文章。本文是面向社区的，向你们全面介绍今天的 eth2 是什么：它将走向何方，它可能成为什么，以及它对于以太坊社区意味着什么。我将试图提供适当的技术内容来说明 eth2 的动机、愿景、项目进展状态以及将要进行的工作，但不会涉及太多的数学或深奥的术语。

本文也可能对那些至今仍与 eth2 保持一定距离的以太坊技术专家有裨益。没关系，我能理解。这个项目很庞大，很复杂，而且看起来似乎在未来足够长的时间内你可以忽视它，专注于解决你更为紧迫的问题。希望这篇文章将帮助你更好地理解将要发生的事情。

至于 eth2 工作人员来说，你们可能也可以从本文中获得一些东西：一个关于我们现在的进展情况的更广阔的视角，以及我对未来事情的看法。

免责声明：本文是我 (Danny Ryan) 个人对当前情况的看法。还有很多的声音和观点推动着不断发展、不断演化的 eth2。本文只是我诠释的一部分内容。

什么是 eth2

“Eth2 是一个可扩展的 PoS 基础架构。”

如果你在过去 6 个月里听过我的演讲，那你一定听过我一次又一次地说过这句话。Eth2 是为以太坊而搭建的，最终会成为以太坊。它的目标是为当前的以太坊主网提供一个更安全和更加可扩展的环境，并对当前 (以太坊) 的运作方式带来很少的干扰。同时，它为我们的成长提供了一个升级的环境。

早在以太坊区块链推出之前，人们就知道单一的区块链模式无法提供足够的带宽来作为一个全新的去中心化互联网的支柱。以太坊相关的 PoS (权益证明) 和 sharding (分片) 的研究历史可以追溯到 2014 年。

PoS 和分片的目的都是为了回答这一问题：给定一定数量的资金支撑着一个加密经济系统，我们能否在提升安全性和吞吐量的同时，依旧允许消费级硬件设施参与到共识中并紧跟区块链？虽然我在这里不会详细地介绍相关研究历史，但这一探索花了数年时间，而且一开始就多次出师不利。最终，这个问题的答案是“能”，并以 eth2 项目的形式呈现了出来。

Eth2 是一个雄心勃勃、历时多年的项目，将分为多个阶段推出。这方面已经被广泛地记录和讨论过了，但我在本文将快速地、不那么技术性地介绍这些阶段所包含的事情。

阶段 0

阶段0，也称信标链阶段，是 eth2 全新的 PoS 共识机制的核心。这里是所有系统级活动和统筹发生的地方。阶段0是关于与成千上万的共识实体 (即验证者) 达成共识，这些实体是分布在世界各地的成千上万的节点。

由于在阶段1及以后，有着将验证者子集分配到各个分片中的技术需求，我们需要能够处理大量的验证者。阶段0 (信标链) 设计的复杂性在很大程度上都是源于这个需求。其他不实现分片的 PoS 机制往往有着数百或者数千的验证者数量，但 eth2 的设计目标是至少承载大约 1.6 万验证者，并期望这个数字在几年内达到数十万。

阶段 1

阶段0是关于达成共识，而阶段1是关于要在很多事情上达成共识。这些“事情”以许多个分片 (shards) 的形式呈现。你可以将每个分片都想象成一条与当前的以太坊链有着相同复杂性的区块链，但分片链是存在于 eth2 共识之下 (也就是说，分片链存在于信标链之下，并由信标链构建/控制)。信标链的验证者被随机分配短期任务来构建和验证分片链，他们对每条分片链的状态、可用性和有效性向核心系统 (信标链) 做出经济承诺。

当前，我们预计起初将存在 64 条分片链，系统可用的总数据为每秒 1~4 MB (是的，这是庞大的数据量)。

阶段 1.5

阶段1.5 是关于将当前的以太坊主网作为一个分片并入到全新的 eth2 共识机制中 (将作为在阶段1期间创建的许多个分片中的一个而存在)。我们知道，当前的以太坊链是通过 PoW (工作量证明) 挖矿算法的方式来搭建的，但并入到 eth2 中后，这条链将由 eth2 验证者来搭建。

对于当前以太坊链上的应用程序和用户，这种共识机制的转变 (从 PoW 转变为 PoS) 将在很大程度上是不被察觉的。这些应用程序将继续运行，但届时开发者们将拥有一个更加强大的系统 (更高的安全性、严格意义上的经济确定性、更多用于 rollups 和其他有趣的应用程序的 Layer 1 数据)。

阶段 2

阶段2 将会对更多的分片链增加状态和执行功能，而不仅仅是 (在阶段1.5期间并入其中的) 初始以太坊分片链。这可以采取多种形式来实现。具体通过哪种形式以及之后的细节，这是当前的研究和原型设计的一个热点。我将在下面的章节对此进一步讨论。

随着时间的推移，eth2给社区带来的益处

好了，我们介绍了所有这些阶段，且阶段0实际上就要到来了。但这个发展路线图听起来还是有点长。那么在这些升级的阶段中，我应该对 eth2 有什么实际的期待呢？

这是个好问题！总的来说，预计每个阶段都会有一波不断触及更多的以太坊和社区相关的升级浪潮。作为用户，你可以尽早地参与到阶段0 Staking 中来，或者你也可以等到阶段 1.5 以太坊链完全迁移至 eth2 中 (不管是从 dapp 开发者还是用户的角度来说，这一迁移都是无缝进行的) 之后再参与进来。不管你选择的参与程度如何，在哪个阶段参与进来，随着每个阶段的推出，都有重要的里程碑和益处值得你注意。

首先，我知道你们很多人都是坚定的 ETH 持有者，渴望参与到 staking 中来。对于所有潜在的验证者，特别是爱好者，阶段0是为你们准备的。阶段0有着自身的风险和投资回报期，这使其对于一些参与者没有吸引力，因此我个人希望这个阶段对于爱好者和长期的以太坊信徒来说都是一种福音。此阶段是一个让你进入这个领域的独特时机，对 (eth2的) 愿景贡献力量，且作为早期参与者将获得更高的 ETH 奖励。

那阶段1期间呢？在将以太坊链迁移进 eth2 中之前，我们能对这些数据做些什么有用的事情吗？答案是肯定的，很高兴你这么问！

即使没有本地计算，Layer 1 的数据也是非常有用的。事实上，在过去12个月的时间里，最有前景的 Layer 2 扩展性解决方案是这些所谓的“rollup” 链 (optimistic rollp 和 ZK rollup)，这些方案会随着 Layer 1 数据可用性的增加而得以扩展。预计 eth2 数据层将会为以太坊提供大约每秒 1~4 MB 的数据可用性，如果与 rollup 技术相结合，这些数据可用性将可以转化为巨大的可扩展性提升。

但由于一开始以太坊 (旧链) 与全新的 eth2 分片系统是脱节的，因此要获取 eth2 分片数据是很困难的。这就是为何 EIP 2537 提案对于以太坊主网来说如此重要的原因之一。通过一个本地的 BLS (即全新的 eth2 签名算法) 预编译，我们可以编写一个高效的 eth2 轻客户端作为一个 solidity 合约，从而使当前以太坊上的应用程序能够在 阶段1.5 迁移之前获取 eth2 中的数据。

正如上文中所讨论的，阶段1.5 的影响是巨大的。Eth2 是为以太坊搭建的，在这个阶段，eth2 将成为以太坊。所有我们熟悉和喜爱的应用程序都将整合进升级的 eth2 共识机制中，在保留我们所习惯的特性的同时，开启了由安全的 PoS 共识带来的广阔新前景，并在本地获取高度可扩展的数据层。在我看来，这是整个过程的关键，这是取得伟大成功的时刻，因为我们将以太坊 (旧链) 完全地锚定在全新的系统中。

除此之外，随着时间的推移，在之后的阶段，通过在其他分片链上实现状态/执行，还可以获得更多的可扩展性提升。这可以以 EVM (以太坊虚拟机) 或者一个称为 eWASM 的全新虚拟机的形式来呈现。不管选择什么 VM (虚拟机)，现有的以太坊 EVM 分片 (即在阶段1.5期间迁移进来的以太坊旧链) 和其他全新的分片链将可以通过信标链来进行交互和通信，从而实现 eth2 分片的愿景。

明白了吗？这是一个过程，但在这个过程中会收获满满。

这种升级方式带来的难题，以及为何值得采用这种方式

如此多的验证者

分片技术 (sharding) 依赖的一个关键组件就是将共识参与者 (即验证者) 随机分配到委员会中对 eth2 协议的一部分 (比如一条分片链) 进行验证。

如果协议中有足够数量的验证者，并且假设某个攻击者控制了最大数量的验证者节点 (比如控制了 1/3 的验证者节点)，那么从数学的角度来说，该攻击者控制任何一个委员会和腐蚀整个系统都是不可能的 [1] (概率为 1/2^40，趋于零)。

这允许我们将系统设计为允许任何人使用消费级设备 (比如笔记本电脑或者一步旧手机) 就可以成为一名验证者 (因为验证者会被分配到系统中的某个部分，而验证任何部分都可以使用单台机器的计算资源来完成)。

这就是 sharding 的不可思议之处，同时也是其困难之处。

首先，我们必须要有足够多的验证者来使这种随机分配的方式足够安全：这意味着，eth2 比大多数其他 PoS 协议都拥有更多的验证者。

这给整个过程的每个层面——从技术研究到共识机制的规范，再到网络、客户端的资源消耗和优化等——都带来了挑战。每个新增的验证者都会给系统增加负载，这必须在每个阶段都考虑进去。各个 Eth2 客户端团队已经完成了管理成千上万个验证者达成共识的艰巨任务，这样我们就可以安全、有效地在阶段1集成许多的分片链。

如此多的分片链

另一个使我们正在构建的 eth2 如此困难的基本设计决策就是，在以太坊中，我们选择在不牺牲去中心化的情况下提升可扩展性。

如果我们不关心用户是否能够自己验证区块链，或者不关心如何确保数据对网络有用，那么将区块链扩展到每秒数万笔交易并不困难。分片共识机制的复杂性是很有必要的，这样系统就可以被分成可验证的小块。制定这样的共识机制的规范并加以实现是一项非常艰巨的任务。

如此多的客户端

以太坊的一个核心原则是，协议第一。以太坊是组成协议的抽象规则集，而不是这些规则集的任何具体实现。为此，以太坊社区从一开始就鼓励实现许多的客户端。

在当前的以太坊主网上，有 besu、ethereumJS、geth、nethermind、nimbus、open-ethereum、trinity 和 turbo-geth 等客户端实现。

而在 eth2 系统中，我们将有 cortex、lighthouse、lodestar、nimbus、prysm、teku 和 trinity 等客户端实现。

多客户端的模式有着许多显著的好处：

• 拥有许多客户端允许社区对更广泛的创意、算法和架构进行探索 (每个客户端都有自己的方法和理念)。随着我们构建更为强大的系统，这个过程营造了一个各客户端相互沟通的健康氛围，

• 各客户端通常有着不同的设计目标。随着时间的推移，这将带来用户和应用程序的多样化。客户端可能或多或少地专注于这些方面中的任何一项：性能、安全性、水平扩展、UI/UX、轻客户端、浏览器、资源受限的设备等等。

• 由于存在许多生产级客户端，当某个重大的攻击 (比如 DOS 攻击) 击垮任何一个客户端时，其他客户端都能够顽强抵抗。在以太坊的早期历史中，从“上海DoS攻击”中就可以看到这一点，当时的一系列 DOS 攻击使很多 geth 和 parity 客户端瘫痪，但它们并不是同时被击垮的。

• 每个客户端都是通向某个编程语言社区的门户。使用某种特定语言编写的客户端打开并迎接对这种语言的试验和创新。该客户端的基本工具通常都会如滚雪球般形成一个由该语言的工具和贡献者组成的强大生态系统。多客户端的模式增强了以太坊的吸引力。

拥有上述这些明显的优势是需要攻破一些难点的：

• (eth2的) 规范和测试必须是无懈可击的，从而避免主网发生任何意外的分叉。如果协议只有一个客户端实现，那么这个实现就成了协议本身。在只存在单个客户端的情况中，如果客户端的任何一个共识方面的“bug”影响到了主网，那么这个bug将成为该协议的现实。要解决这一难题，如果主网上健康地分布着许多不同的客户端 (比如，没有哪种客户端拥有超过1/3的节点/验证者数量)，那么区块链网络就可以在面临单个客户端存在共识问题的情况下继续保持运行了。

• 在最佳情况下，N 个客户端的协作能够比只有单个客户端带来线性开销 (liner overhead)，但在某些情况下可能会导致二次开销 (N^2)。我们会使用一些技术来减少这种开销，比如共识 (以及即将到来的网络) 测试，但这总会在某种程度上存在。

eth2客户端和测试网的进展

在过去两年中，eth2 阶段0 已经成为了相当复杂的软件，能够处理数千个节点中成千上万的验证者的分布式共识。当前我们正处于测试网阶段，每天都更加接近 (信标链的) 发布。我原本预计最后一英里会很长，事实证明的确如此。

在 (信标链) 发布之前的这段时间，我希望你们可以走出舒适圈去尝试不同的客户端。这些客户端之间有许多的权衡取舍，你需要亲自使用才能找到哪个客户端最适合你。如上所述，以太坊以多客户端的模式运行，为了获得这种方式的益处，我们需要用户运行各种不同的客户端 (从而使各种不同类型的客户端健康地分布在网络中)。

除此之外，eth2 协议中还内置了反相关性激励机制。在一些极端的情况下，比如某个大客户端不小心导致大量验证者离线了，或导致大量验证者执行了可被罚没的行为，此时如果你的验证者节点的行为与该客户端有关联，那么此时你受到的惩罚将会比当你犯错但与他人无关时受到的惩罚严重得多。换句话说，在这些情况下，运行某个不那么受欢迎的客户端要比运行某个占据网络很大一部分的客户端要好得多。

需要明确的是，如果存在不止一个可行且安全的客户端，那么你应该运行那个不那么受欢迎的客户端软件，从而促进各客户端软件在网络上健康地分布，这是你的义务。

还有，不要害羞。如果你遇到了文档方面的问题，请让其他人知道。如果你看到了一个打字错误，请提交一个 PR。如果什么东西崩溃了，或者出现 bug，请务必在 github 或客户端的 discord 聊天室中进行上报。你们是测试阶段的用户，在你们的帮助下，我们可以让一些变得更好。

测试网

我们目前正在运行小型公共开发网络 (devnets)，大约每一到两周重启一次。我之所以将这些测试网称为“开发网络”，是因为这些测试网络首先是为各客户端团队开发人员解决 bug、优化等问题的工具。

这些测试网络是公开的，欢迎你加入，但需要知道的是，这些测试网络还会不像 Goerli 或 Rinkeby 那样长期存在。最新发布的测试网是由 Afri Schoedon 领导的、运行 v0.11 版本规范的 Witti 测试网 [2](如果你想运行一些节点，请查看这里的 README [3])。

各客户端团队都正在积极地升级到最新的 v0.12 版本规范[4]，此规范集成了最新版本的 IETF BLS 签名标准。在此基础上，我们将会把这些测试网络过渡到 v0.12 规范，我们将继续增加这些测试网的规模，在客户端上包含越来越多的负载。

当我们通过 2-3 个客户端成功地启动 v0.12 测试网并高负载运行之后，我们将推出一个更公共的测试网，该测试网将允许你运行大多数的节点和验证者。其目标是创建一个长期存在的多客户端测试网，尽可能模拟主网 (用户将可以在该测试网中可靠地运行节点和进行任何测试)。理想情况是仅搭建一次这样的测试网，在维护这个测试网的同时解决所有故障。但是，根据故障的存在和严重程度，我们可能需要运行多次才能达到这一目的。

除了正常的测试网之外，我们还将提供一个具有激励作用的“攻击网络” (attack net)，客户端团队可以在其中运行一个稳定的测试网，我们将邀请你尝试使用不同的方法来攻击这个网络。如果攻击成功，以太坊基金会将提供 ETH 奖励。更多这方面的信息敬请期待！

eth2工具的进展

虽然 eth2 的工具还处于起步阶段，但这是一项令人兴奋且不断发展的工作。如上所述，工具通常源自客户端代码库以及客户端团队的努力，但每天越来越多的人参与了进来。

为了更好地理解、保护和增强 eth2 并与之进行交互，我们作为一个社区需要构建基本的 eth2 工具。

我在此想要对已经为其 eth2 工具提供巨大价值的团队和个人表示欢呼，并欢迎更多人搭建新的工具和对已有工具进行扩展和增强。

Eth2 工具是一个新领域机遇。这是一个研究、提供真正价值和获得认可的绝佳机遇。

下方是其中一些正在制作中的工具，但还有很多其他的工具！

• 浏览器: Beaconcha.in、Etherscan、Eth2stats

• 网络工具: Prrkl[5]、Rumor[6]、Pyrum[7]、Stethoscope[8]

• 密钥库和钱包: ethdo[9]、deposit cli[10]、EIP 2335[11] 以及其他新的标准

• API[12]设计和原型绑定[13]

• 罚没监测: Prysm “hash slinging slasher”[14]

以下是其中一些公开的工具创意：

• Eth2 验证者警告：当验证者没有以最优的方式执行任务时，提供一种向节点运营者发出警告的服务；

• 验证者抵押追踪：通过追踪验证者的抵押过程，协助在当前的以太坊链和 eth2 浏览器之间架起桥梁；

• 通过代理服务保护验证者：使用一个代理服务来追踪验证者的消息，从而确保你的客户端不会发送不安全的消息。

还有更多——这种类型的贡献并不局限于一个规范。创造力是很重要的。如果你想要有所贡献，请与 eth2 客户团队讨论。

eth1+eth2 合并的进展

在当前的以太坊客户端 (比如 geth 客户端) 中，几乎所有的复杂性都在于处理用户层面的活动：交易池、区块创建、虚拟机计算以及状态存储/检索。实际的核心共识——工作量证明 (PoW)——在协议中是非常简单的。大部分的复杂性是由协议之外的复杂硬件来处理的。

而另一方面，eth2 客户端是完全就是共识。在 PoS 和分片中，协议引入了许多复杂性，以实现可扩展性共识的目标。

这些关注点的区别使得 eth1 和 eth2 完美地相结合。

eth1 和 eth2 合并的最初工作正在由 Geth (以太坊基金会) 和 TXRX (ConsenSys) 团队进行。这项工作涉及到：

1. 在 eth1 和 eth2 之间定义一个通信协议；    

2. 向 eth1 客户端增加一个共识引擎，该引擎可以通过该通信协议进行控制； 

3. 原型化和模拟 eth2 阶段1 的行为来测试耦合。

我们预计将在今年夏天看到一些具体的结果。

你可以在这里[15]阅读更多关于高层次 eth1+eth2 客户端关系的信息，以及在这里[16]了解关于合并的技术范围的信息。

状态执行和跨分片通信的进展

如上所述，跨多个分片链实现状态执行的确切路径式一个经过激烈研究和争论的领域。这方面有很多问题需要回答，比如：

• 多少条分片链应该实现状态执行功能？

• 对于新增的分片，我们是使用 EVM 还是 eWASM 来作为其虚拟机？

• 我们如何组织和处理跨分片交易？

• 我们要对当前的 EVM 做出哪些改变来支持跨分片交易？

• 通常状态执行和账户结构是否可以/应该扩展？

在过去的12个月里，eWASM (以太坊基金会) 和 Quilt (ConsenSys) 团队都在这些领域进行了大量的研究。事实证明，解决方案的领域是巨大的，尽管我们现在已经很好地掌握了该领域的广度，但最近的重点一直是深入研究简单、切实的解决方案，以便能够测试、创建原型并真正地奠定通信的基础。由此诞生了 eWASM 的 Eth1x64 计划 (通过这里[17]了解这个项目的高级概况，并查看一些正在被讨论的最新规范[18])。

在将抽象的跨分片通信的想法引入具体的规范中进行讨论并最终形成原型方面，已经取得了快速的进展。请密切关注这方面的进展，尤其是如果你是 dapp 开发人员。我们打算在接下来的几个月里提供一些你可以理解、试用和提供反馈的东西。

无状态以太坊与 eth2

与 eth2 并行进行的另一项主要研发工作是“无状态以太坊” (Stateless Ethereum)。无状态以太坊旨在解决状态大小增长问题。这将允许参与者无需在本地存储整个状态的情况下验证区块。

当前的以太坊状态转换函数中有一个隐式输入：整个状态。通过无状态以太坊，将在区块内提供所需状态的证明 (即 witnesses, 见证数据)。这允许将区块作为纯函数进行转换/验证。

对于用户来说，这种转变意味着用户可以在无需存储所有状态的情况下跟随这条链，甚至可以关注自己关心的那部分状态。一些网络参与者 (比如区块生产者、区块浏览器、收费的状态提供者等) 很可能会存储所有的状态，但绝大多数参与者将只存储一小部分状态。

对于 eth2 而言，这是一种重要的技术机制，可以确保节点和验证者能够在无需存储每个分片的完整用户状态的情况下验证和保护协议。验证者可能会选择成为某些分片的区块生产者，而基线验证者 (baseline validator) 可能只验证无状态区块。

无状态以太坊是对 eth2 愿景的一个非常有价值的补充，它使分片协议的基础非常“瘦”。虽然我们计划以无状态的方式运行 eth2，但我们有几个选择，以防止无状态的方式最终被证明不可行 (但我自己对无状态非常有信心????)。

在这篇文章，我不会深入探讨无状态以太坊。你只要知道这是一个令人兴奋的并行研发路径，以确保以太坊的长期可持续性。如果你想了解更多，可以查看 Griffin 发表的 Eth1.x 系列博客文章[19]。

写在最后

Eth2 是一项宏伟的工程，它将为以太坊提供一个升级的、下一代高度可扩展的、安全的、去中心化的共识。每天都有数十个团队和数百个人在努力实现这一目标。我们选择的道路是艰难的，但已经并将继续取得巨大进展。

这种全新机制的核心部分 (信标链) 即将推出。

如果你是一名有抱负的验证者，现在就可以开始加入进来了。通过尝试多个不同的客户端来支持 eth2 的这种多客户端模式，并为 eth2 的创世奠定一个强大的客户端多样性基础贡献力量。

如果你是一名用户或者 dapp 开发者，请继续推进当前的以太坊链。同时我们将继续为你准备一个更加安全和可扩展的环境。当时机成熟时，eth1 向 eth2 的转换将尽可能无缝地实现。

感谢那些非常棒的团队和个人，让以太坊一直保持良好的生命力；感谢所有为 eth2 的未来做准备的人；也感谢所有的用户和开发者让以太坊变得如此有魅力????

参考链接：

[1]https://blog.ethereum.org/2020/03/27/sharding-consensus/

[2]https://witti.beaconcha.in/

[3]https://github.com/goerli/witti

[4]https://github.com/ethereum/eth2.0-specs/releases/tag/v0.12.0

[5]https://github.com/prrkl 

[6]https://github.com/protolambda/rumor

[7]https://github.com/protolambda/pyrum

[8]https://github.com/lsankar4033/stethoscope 

[9]https://github.com/wealdtech/ethdo

[10]https://github.com/ethereum/eth2.0-deposit-cli 

[11]https://github.com/ethereum/EIPs/pull/2335 

[12]https://github.com/ethereum/eth2.0-apis 

[13]https://github.com/protolambda/eth2.py/

[14]https://github.com/prysmaticlabs/prysm/blob/master/slasher/README.md 

[15]https://ethresear.ch/t/eth1-eth2-client-relationship/7248 

[16]https://ethresear.ch/t/the-scope-of-eth1-eth2-merger/7362

[17]https://ethresear.ch/t/the-eth1x64-experiment/7195

[18]https://ethresear.ch/t/eth1x64-variant-1-apostille/7365

[19]https://blog.ethereum.org/2020/04/02/eth1x-stateless-tech-tree/

【文章版权归原作者所有，其内容与观点不代表Unitimes立 场。转载文章仅为传播更有价值的信息，合作或授权联系请发邮件至 [email protected]或添加微信unitimes2017】