5月11日和12日，连续两个晚上，以太坊的共识层暂时出现异常。根据imToken的分析，以太坊共识层部分客户端节点负载过高，直接导致验证器离线，共识层无法确认Epoch投票的终结性。然而，过了一会儿，以太坊网络自己恢复了正常。imToken认为这说明以太坊PoS的共识算法具有韧性和自我修复能力。
事件和背景在正常情况下，以太网PoS共识网络的状态将在两个时期内最终确定，但上周在最终确定时期方面出现了两次延迟。
第一次发生在5月11日，Epoch的敲定延迟了3个Epoch，大概20分钟。
第二次发生在5月12日，Epoch的敲定延迟了8个Epoch，大约51分钟。
活动期间，以太坊网络不断生成区块，处理交易。然而，由于验证器的投票率不足，Epoch无法最终确定(即Epoch由以太网PoS网络的共识级安全性保证)。未能完成Epoch意味着当大多数验证器是邪恶的和分叉的时，epcoh可能被回滚，这将导致事务被回滚。
事实上，在事件发生期间，以太坊网络并没有分叉，验证者也没有恶意投票。由于大量验证员离线，投票率不足，导致事发时Epoch无法最终确定。
经过观察，离线验证器出现了CPU过载的异常情况，认为这是导致离线验证器的直接原因。
第二个事件中，Epoch的终结延迟了8个Epoch，终结延迟大于min _ epochs _ to _ in activity _ penalty(= 4)，触发了以太坊共识算法不活动泄漏的处理机制。
惩罚下线验证者，削减其质押资金，没收约28 ETH。由于认证奖励的取消，大约有50个ETH没有颁发。该机制保证了在线验证者最终可以掌握以太坊的总质押资金，从而最终确定网络状态。imToken的节点服务也检测到了这一事件，通过实时监控以太坊共识层验证者的投票情况，可以在Epoch正常敲定之前提前预警以太坊共识网络的异常。下图显示了第一个事件发生时的节点状态。
在PoW机制下，交易成功与否是决定交易连续多少块不会回滚，而PoS以Safe Head返回的块高作为交易成功与否的判断。而目前的规范是以合理的检查点作为安全头的状态标识，所以从前一个Epoch的状态来看，可能会有6.4分钟的决策延迟，这对用户来说是非常糟糕的体验。
imToken开发的Safe Head服务，会根据以太坊共识层的实时数据计算安全块进行交易确认，在保证用户交易安全的前提下，缩短交易确认时间。一般情况下，imToken的安全头算法返回的块高(如上图黄色)会非常接近最新的块高(绿色)，从而提高用户体验。
有关安全头部装置的更多信息:
以太坊:安全头机制介绍(一)以太坊:安全头机制介绍(二)原因分析上述事件发生的直接原因是以太坊共识层部分客户端节点负载过高，导致验证器离线，所以经常没有共识投票。经过分析，这些节点高负载的原因有:
当接收到指向旧块的见证时，节点需要重新计算信标链状态来验证这些见证，这个过程需要消耗大量的CPU和内存资源。
当同时接收到大量指向旧块的见证时，会消耗节点的CPU和内存资源，导致这些验证器离线。
本来这种问题可以通过基于见证指向块的缓存来解决。然而，由于验证器规模的增长和大量此类证明的出现，问题客户端实现的缓存被破坏，节点不得不消耗大量资源重新计算信标链状态。
目前，共识层的客户库特和Pry已经发布了补丁版本来解决这个问题。具体来说，修补程序版本的客户端实现将过滤掉这些过时的见证，即，当满足以下条件时忽略见证:
见证指向旧插槽见证指向节点从未见过的检查点。但是，我们仍然需要继续观察以太网主网络的最终确定，以确认补丁的有效性。
共识层客户端库特和Pry的补丁版本:
撬:v4.0.3-Hotfix库特:v23.5.0以太坊设计的优势在这次事件中，以太坊保证了可用性继续生成块和处理事务，但推迟Epoch最终完成的关键有两点:
以太坊客户端的多样性Gasper算法的设计以太坊客户端的多样性在此次事件中，虽然库特和Pry的实现出现了问题，但并不影响其他共识客户端的正常运行。比如灯塔的客户端这次就不受影响。因为不同的客户端有不同的设计，所以仍然有一个验证器正常工作。
以太坊客户端的多样性保证了即使部分客户端出现问题(甚至导致Epoch无法最终完成)，也不会影响正常客户端生成区块和处理交易，从而维持以太坊的可用性。
以太坊Gasper consensus算法可用性的设计是以太坊Gasper consensus算法设计的出发点之一，它将以太坊区块的生产和定型分开。因此，即使块的终结被阻止，块的生成也不会终止。考虑到大多数情况下，块的终结最终会恢复(生成的块仍然会被终结)，对用户的影响其实会很低。与其他BFT共识算法相比，如果块终结失败，共识节点将停止产生下一个块。因此，整个区块链在此期间不可用，也就是俗称的“区块链挂机”
此外，第二个事件还触发了不活动泄漏的机制，这主要是为了保证以太坊在极端情况下(大量验证器长时间离线)仍能完成封块。
以太坊多客户端的体验与启示挑战目前以太坊客户端的多样性如下图所示:
来源:https://clientdiversity.org/#distribution可以看出以太坊客户的多样性仍然需要推广和宣传。可以想象，如果客户端实现足够多样，使得Pry和库特的比例小于，那么这个事件甚至不会发生(客户端的正常运行足以敲定Epoch)。另外，当前执行层的客户端集中在Geth，占比61%。其实有一个潜在的风险:如果Geth运营不正常，以太坊会受到很大影响。
除了以太坊客户端的多样性，还需要进一步的努力，以太坊客户端的切换也是此次事件暴露出的一个痛点:当一个客户端实现出现问题时，Validator如何切换到正常的客户端实现？这一过程包括:
将故障客户端的验证密钥安全地迁移到正常客户端。因为以太坊有斜杠的规则，所以需要保证新老客户端行为的一致性而不被斜杠。比如新老客户端分别投票给分叉两边的检查点，让Slash的新老客户端在同一个槽产生不同的块，由Slash以太坊的共识来监控。需要像Safe Head这样的服务持续监控以太坊PoS网络的实时状态，提前发现并预警此类事件，而不是像预期的那样等到Epoch无法最终确定才知道网络状态异常。最新的研究可以在这篇文章中找到。
以太坊共识算法的科普这次事件暴露了以太坊PoS共识机制的科普必要性。此次事件中，很多用户误以为“以太坊死了”，造成了不必要的恐慌。然而，在现实中，以太坊网络继续产生区块和处理交易。以太坊的共识层和执行层的结合，为以太坊的交易确认带来了双重保障。共识层历元无法终结时，执行层的分块处理不受影响，以太坊共识算法中也设计了历元终结的异常情况。面向用户的区块链知识普及仍然是从业者需要继续努力的方向。
对以太坊应用的启示虽然以太坊网络足够健壮，但是偶尔的不稳定也会对应用产生一定的影响。同时，应用程序应该正确处理这些不稳定的场景。
第1层->；第二层的存放时间会更长。当Layer2在mint中时，一个重要的前提是确保L1存款交易不会回滚。因此，当以太网时代的终结被推迟时，L1->；L2的存款时间会相应变长。同样，交易所也需要防止线上充值交易被回滚，因此其充值时间也会相应变长。Oracle链上的报价有回滚的风险，所以依赖它的高价值服务要适当暂停。在这次事件中，Uniswap没有显示余额，只能买不能卖，而dYdX则暂停了保证金。综上所述，在此次事件中，我们看到了以太坊PoS共识算法的应变能力和自我修复能力，也看到了客户端在事故发生后会立即做出反应并纠正错误。对于以太坊的整个生态，我们需要在以下几个方面继续投入:增加客户端的多样性，优化网络状态的实时监控和预警，深入的用户教育(不仅针对普通用户，也针对从业者)，为生态参与者准备网络异常时的应急预案。
参考链接
终局性问题2023年5月更新https://Twitter . com/robplust/status/1657044364382846978 https://Twitter . com/super phiz/status/1656780594326405121 https://Twitter.com/terencechain/status/1657021042110631936网站声明:网站内容来自互联网。如有侵权，请联系我们，我们会及时处理。
温馨提示：注：内容来源均采集于互联网，不要轻信任何，后果自负，本站不承担任何责任。若本站收录的信息无意侵犯了贵司版权，请给我们来信，我们会及时处理和回复。
原文地址"以太坊出什么问题了，以太坊崩盘了"：http://www.ljycsb.cn/qukuailian/220002.html。
微信扫描二维码投放广告
▲长按图片识别二维码
