以太坊共识层连续两晚短暂异常分析

近日，以太坊共识层出现短暂异常，引发业内广泛关注。本文将对该事件进行深入分析。

事件概述

5月11日和12日连续两个晚上，以太坊共识层出现短暂异常。分析显示，这主要是由于某些以太坊共识层客户端节点负载过高，导致验证节点(Validator)宕机离线。这直接影响了Epoch投票，使其无法达到所需的2/3阈值，导致共识层无法确认最终性。

值得注意的是，尽管出现异常，以太坊网络在短时间内就自我恢复正常。这体现了以太坊PoS共识算法的韧性和自我修复能力。

事件细节

通常情况下，以太坊PoS共识网络状态会在2个Epoch内被敲定(Finalized)。但在上周的两次事件中，Epoch敲定出现了延迟：

• 5月11日：Epoch敲定延迟了3个Epoch，约20分钟。
• 5月12日：Epoch敲定延迟了8个Epoch，约51分钟。

尽管Epoch未能按时敲定，以太坊网络仍然持续产生区块并处理交易。然而，由于验证节点的投票率不足，Epoch无法获得以太坊PoS网络的共识级别安全保证。

值得一提的是，在第二次事件中，由于敲定延迟超过了预设阈值，触发了以太坊共识算法的Inactivity leak机制。这导致了约28个ETH被罚没，约50个ETH未被发行。

原因分析

造成这两次事件的直接原因是某几种以太坊共识层客户端节点负载过高，导致验证节点宕机离线，无法正常进行共识投票。具体来说：

1. 当节点收到指向陈旧区块的见证(Attestation)时，需要重新计算信标链状态以验证这些见证，这个过程需要大量CPU和内存资源。

2. 当同时收到大量指向陈旧区块的见证时，节点的资源被耗尽，导致验证节点宕机离线。

3. 虽然这类问题可以通过基于见证指向区块的缓存来解决，但由于验证节点规模增长和大量此类attestation的出现，导致出问题的客户端实现的缓存被击穿。

目前，共识层客户端Teku和Prysm已推出补丁版本以解决该问题。补丁版本会过滤掉这些陈旧的见证，当见证指向一个陈旧的Slot或节点从未见过的Checkpoint时，会忽略该见证。

以太坊设计优势

在此次事件中，以太坊展现了其设计优势：

1. 客户端多样性：不同客户端的实现设计不同，即使某些客户端出现问题，也不会影响其他客户端的正常运作。

2. Gasper算法设计：将区块生产与敲定分离，即使区块敲定受阻，区块的产生也不会停止，保证了网络的可用性。

经验与启示

1. 客户端多样性仍需加强：目前以太坊客户端多样性仍有提升空间，特别是执行层客户端集中在Geth，占比高达61%，存在潜在风险。

2. 客户端切换机制需完善：当某个客户端实现出问题时，如何安全地切换到正常的客户端实现仍是一个挑战。

3. 共识监控需加强：需要类似Safe Head的服务持续监控以太坊PoS网络的实时状态，及时发现并预警异常。

4. 加强用户教育：科普以太坊PoS共识机制，避免用户产生不必要的恐慌。

5. 应用层需做好应对：Layer2、交易所、Oracle等应用需要正确处理网络不稳定的场景，如适当延长确认时间或暂停服务。

总结

这次事件展示了以太坊PoS共识算法的韧性和自我修复能力，同时也暴露了一些需要改进的方面。未来，以太坊生态需要在客户端多样性、网络监控、用户教育等方面持续投入，以提升整个网络的稳定性和可靠性。