ETH2更新速览#15

区块链技术 4 4 月 22, 2024 0 区块链315

ETH2更新速览#15

来源 | [Ethereum Blog](https://blog.ethereum.org/2020/09/01/eth2-quick-update-no-15/) 作者 | Danny Ryan ![](https://img.learnblockchain.cn/2020/09/17/16003051896821.jpg) *耕农们看好庄稼啦* *时和年丰* *硕果累累* 要点速览 * 平稳地运行着 * 客户端多样性是必须的 * Eth1+Eth2 (阶段5，即合并阶段) [端对端demo](https://twitter.com/mkalinin2/status/1299038199591862274) * 在逐渐接近阶段0这个过程中，测试和审计仍继续着 ## Medalla运行良好 (经过一些小波折后) 无波折的测试网是充满不确定性的、可疑的。如果读者在过去几周里有关注Medalla的进展，那么大家对8月14日发生的为期5天的事故肯定不陌生了。大家可以阅读Prysm对该事故的[回顾文章](https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a)，以了解该次事故的技术因素和时间线细节。还可以读Ben最近的博客文章([[1](https://hackmd.io/@benjaminion/eth2_news/https:/hackmd.io/@benjaminion/wnie2_200817)][[*2*](https://hackmd.io/@benjaminion/eth2_news/https:/hackmd.io/@benjaminion/wnie2_200822)])，他对此事件进行了高水平的分析。事件发生后，客户端团队忙活了整个周末，部署同步操作和修复漏洞来解决网络的高度碎片化问题。尽管该事件为测试网带来了巨大的压力，但同时给了所有的客户端一个机会，增强客户端的抗压能力，以应对一些难以想象的失控场面。我相信经历了这次事件，客户端软件会更加稳健。在Eth2主网上线之前，我会稍微睡得安稳一些。事故过后，Medalla平稳地运行着：现在测试网上有3.9万个活跃验证者，还有1.2万在启动队列中等候着 (要等12天呢)！ ## 客户端多样性是必须的尽管有许多Eth2客户端正积极开发着*[**卓越的、可行的、强健的、可用的等等**]**，但是现在网络主要还是由单一的客户端**Prysm**主导。* 这是有历史原因的——过去一年多以来，Prysm都将重心放在早期的测试网、社区参与以及其可用性上。给了Prysmatic团队良好的声誉。对于我们整个行业和开源来说，社区建设是非常困难的，也是非常重要的。也就是说，网络由Prysm主导的这个隐患，在此次Medalla的事件中放大了，而我们在为Eth2.0主网发布做努力时，作为社区，我们必须有意识地补救这个问题。我自己在Medalla上测试过了所有Eth2客户端，我可以直接告诉你，绝大多数客户端都十分强健且有完善的说明文档，所有客户端团队都会积极参与discord和github，帮助你解决任何可能遇到的问题。 ### 保护自己客户端多样化不仅使Eth2共识更加强健，还会在用户面临极端情况时提供一定的保护性。由于Eth2的反相关激励机制，用户的消极行为与其他人的消极行为关联性越强，用户的损失就越大。比如，假设由于客户端A出现故障，网络中60%的节点连续掉线几天，但是客户端B和客户端C保持平稳运行。尽管客户端B和C上的节点持续构建区块链，但是由于>33%离线率，链将不能进行最终确定工作。而如果用户使用客户端A运行节点，由于最终确定性故障仍然存在 (可以称之为“不活跃漏洞”)，用户的损失将越来越多。然而如果你使用客户端B或C运行节点，由于你保持在线，你的余额会受到保护。[注意：不活跃漏洞比普通的离线要面临更严重的惩罚。] 相反，假设一小部分的客户端B节点 (占网络的20%)遭遇严重故障，导致其客户端用户面临大量掉线故障。在这种情况下，该链仍然能够继续最终确定工作，因为网络上80%的节点仍在运行。这些离线验证者并不会导致“不活跃漏洞”，他们只会遭受普通的惩罚。所以与上述情景相比，这些运行客户端B节点的验证者只会受到比较小的惩罚。 ### **易于切换的客户端** 除了努力尝试开发新客户端，客户端团队也在努力确保切换客户端变得更加简单、安全。随着一些[跨客户端标准](https://hackmd.io/@sproul/Bk0Y0qdGD)的添加，用户很快就可以从一个客户端切换到另一个客户端，而且停机时间很短，没有意外罚没的风险。这些防止客户端锁定的标准，是强健的Eth2网络的关键组件。易于切换的客户端将使社区在单个客户端出现故障时，能够更快地解决问题 (如Medalla事件)。 ## **eth1+eth2** **端到端****demo** Eth2的主要目标之一是阶段1.5 (即合并阶段)，届时现有的以太坊区块链共识将整合到eth2中。从那时起，我们所熟知和热爱的区块链将有PoS验证者来构建，取代当前的资源密集型工作量证明共识。到阶段1.5的过渡旨在尽可能与现有用户和应用程序无缝衔接。Eth1客户端仍然是状态、事务和执行的载体。通过最大程度上保持用户层的不变，以太坊将能够像现在一样利用现有的工具和API来进行交易并支持dapp。为此，Mikhail (TXRX团队) 和Guillaume (geth团队) 最近发布了多分片信标链 (其中eth1链作为分片之一) 的[端到端演示](https://twitter.com/mkalinin2/status/1299038199591862274)。在发布的演示视频中，Mikhail使用未修改的MetaMask钱包将大量交易发送到eth1分片链。读者可以查看并且试用[docker化](https://github.com/txrx-research/eth1-shard-demo)的eth1+eth2 demo，如果想更深入的话，可以[从来源](https://github.com/txrx-research/teku/tree/phase1/phase1/src/main/kotlin/tech/pegasys/teku/phase1#eth1-shard-simulation)进行搭建并运行。 ## **测试和审计仍在进行中，聚焦阶段****0****主网** 在这方面我们并未松懈。客户端团队正在努力工作，审计人员正在深入研究每个细节，并正在准备启动主网。声明：ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系ethereumcn@gmail.com进行授权。

来源 | Ethereum Blog

作者 | Danny Ryan

耕农们看好庄稼啦 时和年丰 硕果累累

要点速览

平稳地运行着
客户端多样性是必须的
Eth1+Eth2 (阶段5，即合并阶段) 端对端demo
在逐渐接近阶段0这个过程中，测试和审计仍继续着

Medalla运行良好 (经过一些小波折后)

无波折的测试网是充满不确定性的、可疑的。

如果读者在过去几周里有关注Medalla的进展，那么大家对8月14日发生的为期5天的事故肯定不陌生了。大家可以阅读Prysm对该事故的回顾文章，以了解该次事故的技术因素和时间线细节。还可以读Ben最近的博客文章([1][2])，他对此事件进行了高水平的分析。事件发生后，客户端团队忙活了整个周末，部署同步操作和修复漏洞来解决网络的高度碎片化问题。

尽管该事件为测试网带来了巨大的压力，但同时给了所有的客户端一个机会，增强客户端的抗压能力，以应对一些难以想象的失控场面。我相信经历了这次事件，客户端软件会更加稳健。在Eth2主网上线之前，我会稍微睡得安稳一些。

事故过后，Medalla平稳地运行着：现在测试网上有3.9万个活跃验证者，还有1.2万在启动队列中等候着 (要等12天呢)！

客户端多样性是必须的

尽管有许多Eth2客户端正积极开发着*[卓越的、可行的、强健的、可用的等等]，但是现在网络主要还是由单一的客户端Prysm*主导。

这是有历史原因的——过去一年多以来，Prysm都将重心放在早期的测试网、社区参与以及其可用性上。给了Prysmatic团队良好的声誉。对于我们整个行业和开源来说，社区建设是非常困难的，也是非常重要的。

也就是说，网络由Prysm主导的这个隐患，在此次Medalla的事件中放大了，而我们在为Eth2.0主网发布做努力时，作为社区，我们必须有意识地补救这个问题。我自己在Medalla上测试过了所有Eth2客户端，我可以直接告诉你，绝大多数客户端都十分强健且有完善的说明文档，所有客户端团队都会积极参与discord和github，帮助你解决任何可能遇到的问题。

保护自己

客户端多样化不仅使Eth2共识更加强健，还会在用户面临极端情况时提供一定的保护性。由于Eth2的反相关激励机制，用户的消极行为与其他人的消极行为关联性越强，用户的损失就越大。

比如，假设由于客户端A出现故障，网络中60%的节点连续掉线几天，但是客户端B和客户端C保持平稳运行。尽管客户端B和C上的节点持续构建区块链，但是由于>33%离线率，链将不能进行最终确定工作。而如果用户使用客户端A运行节点，由于最终确定性故障仍然存在 (可以称之为“不活跃漏洞”)，用户的损失将越来越多。然而如果你使用客户端B或C运行节点，由于你保持在线，你的余额会受到保护。[注意：不活跃漏洞比普通的离线要面临更严重的惩罚。]

相反，假设一小部分的客户端B节点 (占网络的20%)遭遇严重故障，导致其客户端用户面临大量掉线故障。在这种情况下，该链仍然能够继续最终确定工作，因为网络上80%的节点仍在运行。这些离线验证者并不会导致“不活跃漏洞”，他们只会遭受普通的惩罚。所以与上述情景相比，这些运行客户端B节点的验证者只会受到比较小的惩罚。