ETH2:ETH:客户端多样性为何如此重要_AIR

免责声明:本文没有贬低任何一个客户端。每个客户端,甚至是规范,可能都存在不足和漏洞。ETH2.0是一个复杂的协议,实现这个协议的人也都是肉体凡胎。本文旨在强调如何以及为何要降低风险。

随着Medalla测试网上线,官方团队鼓励人们对不同的客户端进行实验。从创世的那一刻起,这么做的重要性便凸显出来:Nimbus和Lodestar节点因无法处理测试网的负载量而卡住??。结果,Medalla在上线半个小时内无法敲定区块。

在北京时间8月15日,由于Prysm客户端用来作为参照的时钟服务器突然出现偏差,Prysm节点的时钟提前了4小时。因此,这些节点一直在为超前的slot创建区块和见证消息。等这些节点的时钟恢复正常后,那些禁用了默认罚没保护机制的验证者发现自己遭到了罚没。

若想了解更详细的情况,我强烈推荐你阅读RaulJordan的《ETH2Medalla测试网事故》一文。

时钟故障——情况恶化

出现时钟偏差时,Prysm节点占全网节点的62%左右。这就意味着,网络无法达到敲定区块所需的最低参与率。更糟糕的是,这些节点找不到它们所预期的区块链顶端,因此这些节点都在猜测“缺失”数据,创建了很多短的分叉链,造成网络拥堵。

-目前,在Medalla测试网的所有节点中,Prysm节点占比高达82%?!(ethernodes.org)-

这时,网络上充斥着成千上万个关于区块链顶端的猜测,而且还在不断增加之中,为了辨别哪个分叉是正确的,所有客户端都开始不堪重负。这就导致节点出现停滞不前、无法同步和内存不足等问题,以至于情况进一步恶化。

塞翁失马,焉知非福。经过这次事故,我们不仅可以修复时钟的根本问题,还能在大规模节点故障和网络负载过重的情况下对客户端进行压力测试。尽管如此,这次事故本来不会造成这么极端的后果,根本原因在于Prysm节点占比过大。

去中心化有利于ETH2.0

正如我此前所讨论的那样,就异步拜占庭容错算法而言,1/3是安全阈值。如果超过1/3的验证者离线,网络就无法实现终局性。虽然ETH2.0区块链在不断增长,但是验证者却不敢保证哪个区块、哪个状态一定不会被颠覆。

去中心化有利于验证者

从根本上来说,我们希望经济激励机制足以让验证者做对整个网络都好的事,而不用我们相信他们是好人。

如果有超过1/3的验证者节点离线,离线节点所遭受的惩罚就会加重。这就是所谓的不作为惩罚。

也就是说,作为一名验证者,你会希望自己在因为某种原因被迫离线的同时,不会有很多其它节点因为同样的原因离线。

罚没也是如此。?虽然你的验证者节点有可能因为规范或软件故障/漏洞而遭到罚没,但是个体罚没只会损失1ETH。

然而,如果有许多验证者和你同时遭到罚没,罚金就会高达32ETH。

上述两种情况分别称为活性反相关机制和安全性反相关机制,是ETH2.0中精心设计的部分。反相关机制将个体惩罚与每个验证者对网络的影响联系在一起,以此激励验证者做出对网络最有利的决策。

一些数据

ETH2.0由多个独立团队实现。每个团队都根据ETH2.0研究团队编写的规范开发独立的客户端。这样可以确保有多个信标链节点和验证者客户端实现。在构建ETH2.0客户端时,每个客户端团队在技术、语言、优化和权衡关系方面会做出不同的决定。这样一来,即使ETH2.0系统的任意一层出现漏洞,只会影响运行特定客户端的节点,不会波及全网节点。

以Medalla测试网上Prysm节点的时钟偏移为例。如果只有20%的ETH2.0节点运行Prysm客户端,且85%的验证者在线,则Prysm节点就不会遭受不作为惩罚。开发团队只需熬几个通宵就可以解决这个问题,惩罚力度也能控制在最小范围内。

事实上,由于太多验证者都集中在同一个客户端上,短时间内遭到罚没的验证者人数在3500至5000之间。*如此高的相关性意味着,这些验证者的损失约为16ETH,就因为他们运行的是热门客户端。

至本文截稿时,罚没金额还在大幅增加,尚未得到最终数据。

不妨来试试其它客户端

现在正是尝试不同客户端的时候。不妨来体验一下小众客户端。目前,Lighthouse、Teku、Nimbus和Prysm都比较稳定,Lodestar正在迎头赶上。

最重要的是,一定要尝试新的客户端!我们可以在Medalla上让不同客户端的验证者分布合理化,以便迎接ETH2.0主网上线。

原文链接:

https://blog.ethereum.org/2020/08/21/validated-why-client-diversity-matters/

作者:?CarlBeekhuizen

翻译&校对:?闵敏?&?阿剑

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

大币网

[0:15ms0-3:958ms