imToken Labs：以太坊网络Finalize延迟事件分析报告

原文作者：imToken Labs

概述

5 月 11 、12 日连续两天晚上，以太坊共识层短暂异常，imToken 分析该异常主要某几种以太坊共识层客户端节点负载过高，使得 Validator 宕机离线，直接导致 Epoch 投票无法达到 2/3 ，共识层无法确认最终性，但短时间过后以太坊网络自我恢复正常，imToken 认为这表明以太坊 PoS 共识算法具备韧性和自我修复的能力。

事件及背景

通常情况下，以太坊 PoS 共识网络状态会在 2 个 Epoch 被敲定（Finalized），而上周出现了两次 Epoch 敲定的延迟。

第一次发生在 5 月 11 日，Epoch 的敲定被延迟了 3 个 Epoch，约 20 分钟。

第二次发生在 5 月 12 日，Epoch 的敲定被延迟了 8 个 Epoch，约 51 分钟。

在事件发生期间，以太坊网络仍然持续产生区块并处理交易。然而，由于 Validator（验证节点）的投票率不足，Epoch 无法敲定（即 Epoch 得到以太坊 PoS 网络共识级别安全保证）。Epoch 未能敲定意味着在绝大多数 Validator 作恶并出现分叉的情况下，epcoh 可能被回滚，从而导致交易被回滚。

实际上，在事件发生的期间，以太坊网络并未出现分叉，而 Validator 也未进行恶意投票，只因大量 Validator 离线导致投票率不足，从而使得 Epoch 在期间无法被敲定。

经过观察，离线的 Validator 出现 CPU 过载的异常情况，被认为是 Validator 离线的直接原因。

在第二次事件中，Epoch 敲定被延迟了 8 个 Epoch，由于敲定延迟大于MIN_EpochS_TO_INACTIVITY_PENALTY (= 4) 从而触发了以太坊共识算法 Inactivity leak的处理机制。

惩罚离线的 Validator，削减其质押资金，罚没了约 28 个 ETH。

取消 Attestation 的奖励，导致约 50 个 ETH 未被发行。

该机制保证在线 Validator 最终能掌握以太坊总质押资金的  ⅔，从而使得网络状态最终能被敲定

imToken 的节点服务也侦测到了此次事件，通过实时监控以太坊共识层 Validator 投票的情况，从而在 Epoch 未能正常敲定前，提前预警以太坊共识网络的异常。下图是第一次事件发生时的节点状态。

PoW 机制下，交易的成功是认定交易在多少连续区块后大概率不会被回滚，PoS 则是以 Safe Head 返回的块高作为交易成功的判定。而目前的规范中则是以 Justified Checkpoint 作为 Safe Head 的状态认定，因此以前一 Epoch 的状态来看，可能存在有 6.4 分钟之久的判定延迟，这对用户而言是很糟糕的体验。

imToken 自研的 Safe Head 服务会基于实时的以太坊共识层数据，计算出安全的区块用于交易确认，在保证用户交易安全的前提下，缩短交易确认的时长。正常情况下，imToken 的 Safe Head 算法返回的块高（如上图黄色），会非常贴近最新的区块高度（绿色），从而提高用户体验。

更多关于 Safe Head 机制的资料：

以太坊：Safe Head 机制介绍（一）

以太坊：Safe Head 机制介绍（二）

原因分析

造成上述事件的直接原因是某几种以太坊共识层客户端节点负载过高，使得 Validator 宕机离线，从而无法正常进行共识投票。经过分析，这些节点负载过高的原因是：

当收到指向陈旧区块的见证（Attestation）时，节点需要重新计算信标链状态以验证这些见证，而该过程需要消耗大量的 CPU 以及内存资源。

当同时收到大量指向陈旧区块的见证时，节点的 CPU 以及内存资源被耗光，从而导致这些 Validator 宕机离线。

本来此类问题可以通过基于见证指向区块的缓存来解决，然而由于 Validator 的规模增长以及大量此类 attestation 的出现，导致出问题的客户端实现的缓存被击穿，节点不得不消耗大量资源重新计算信标链状态。

共识层客户端 Teku 以及 Prysm 目前推出了 patch 版本以解决该问题。具体而言，patch 版本的客户端实现会过滤掉这些陈旧的见证，即当满足下列条件，忽略该见证：

见证指向一个陈旧的 Slot

见证指向一个节点从未见过的 Checkpoint

然而，我们仍需持续观察以太坊主网敲定的情况以确认 patch 的有效性。

共识层客户端 Teku 以及 Prysm 的 patch 版本：

Prysm：v 4.0.3-hotfix

Teku：v2 3.5.0 

以太坊设计优势

在此次事件中，以太坊保证可用性仍持续产生区块并处理交易，而仅推迟 Epoch 敲定的关键在于两点：

1. 以太坊客户端的多样性

2. Gasper 算法的设计

以太坊客户端的多样性