摘要
5月11日和12日晚，以太坊共识层暂时异常。根据imToken的分析，以太坊共识层部分客户端节点负载过高，导致验证器离线，直接导致纪元投票无法达到2/3，共识层无法确认终结。然而，过了一会儿，以太坊网络自己恢复了正常。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的补丁版本:
撬:4 . 0 . 3-修补程序
库特:v23.5.0
以太坊的设计优势
在这次事件中，以太坊保证了可用性会继续生成块和处理事务，但推迟Epoch最终完成的关键只在于两点:
1.以太坊客户的多样性
2.2的设计。Gasper算法。
以太坊客户的多样性
在此次事件中，虽然库特和Pry的执行存在问题，但并不影响其他共识客户的正常运作。比如灯塔的客户端这次就不受影响。因为不同的客户端有不同的设计，所以仍然有一个验证器正常工作。
以太坊客户端的多样性保证了即使部分客户端出现问题(甚至导致Epoch无法最终完成)，也不会影响正常客户端生成区块和处理交易，从而维持以太坊的可用性。
以太坊中Gasper一致性算法的可用性设计
保证以太坊的可用性是以太坊共识算法Gasper的设计出发点之一，它将以太坊区块的生产和定型分开。因此，即使块的终结被阻止，块的生成也不会终止。考虑到大多数情况下，块的终结最终会恢复(生成的块仍然会被终结)，对用户的影响其实会很低。与其他BFT共识算法相比，如果块终结失败，共识节点将停止产生下一个块。因此，整个区块链在此期间不可用，也就是俗称的“区块链挂机”
此外，第二个事件还触发了不活动泄漏的机制，这主要是为了保证以太坊在极端情况下(大量验证器长时间离线)仍能完成封块。
经验与启示
以太坊中多客户端的挑战
目前以太坊客户端的多样性如下图所示:
资料来源:https://clientdiversity.org/#distribution.
可见以太坊客户端的多样性还是需要推广和宣传的。可以想象，如果客户端实现足够多样，使得Pry和库特的比例小于，那么这个事件甚至不会发生(客户端的正常运行足以敲定Epoch)。另外，当前执行层的客户端集中在Geth，占比61%。其实有一个潜在的风险:如果Geth运营不正常，以太坊会受到很大影响。
除了以太坊客户端的多样性，还需要进一步的努力，以太坊客户端的切换也是此次事件暴露出的一个痛点:当一个客户端实现出现问题时，Validator如何切换到正常的客户端实现？这一过程包括:
将故障客户端的验证密钥安全地迁移到正常客户端。
因为以太坊共识有斜杠的规则，所以要保证新老客户端行为的一致性而不被斜杠。例如:
o新老客户投了岔路两边的关卡，被砸了。
o新老客户端在同一个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/superphiz/status/1656780594326405121
https://twitter.com/terencechain/status/1657021042110631936
温馨提示：注：内容来源均采集于互联网，不要轻信任何，后果自负，本站不承担任何责任。若本站收录的信息无意侵犯了贵司版权，请给我们来信，我们会及时处理和回复。
原文地址"以太坊eip1559推迟，以太坊网络拥堵解决方案"：http://www.ljycsb.cn/qukuailian/220011.html。
微信扫描二维码投放广告
▲长按图片识别二维码
