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

• 惩罚离线的 Validator，削减其质押资金，罚没了约 28 个 ETH。
• 取消 Attestation 的奖励，导致约 50 个 ETH 未被发行。
• 该机制保证在线 Validator 最终能掌握以太坊总质押资金的 ⅔，从而使得网络状态最终能被敲定。

• 见证指向一个陈旧的 Slot
• 见证指向一个节点从未见过的 Checkpoint

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

• 以太坊客户端的多样性

• Gasper 算法的设计

在此次事件中，虽然共识层客户端 Teku 以及 Prysm 的实现出现了问题，但不影响其他共识层客户端的正常运作。像是 Lighthouse 客户端本次并不受影响，由于不同客户端在实现的设计上并不相同，因此仍有 Validator 正常在运作。

以太坊客户端的多样性保证了：即使某些客户端出现问题（甚至导致 Epoch 不能敲定），也不会影响正常的客户端产生区块并处理交易，使得以太坊的可用性得到保持。

保证以太坊的可用性是以太坊共识算法 Gasper 的设计出发点之一，其把以太坊区块生产与敲定分离。因此，即使区块敲定受阻，区块的产生并不会随之终止。考虑到大部分情况下，区块敲定最终会恢复（产生的区块最终仍会被敲定），那么对用户影响其实会很低。对比其他 BFT 的共识算法：若区块敲定失败，共识节点会停止产出下个区块。从而，导致期间整个区块链不可用，即俗称的「区块链挂了」。

另外，第二次事件还触发到了 Inactivity Leak 的机制，其主要是为了保证以太坊在极端情况（大量 Validator 长时间离线）下仍能重新敲定区块。

当前，以太坊客户端多样性现状如下图所示：

△ 来源: https://clientdiversity.org/#distribution

• 把出问题客户端的 Validation key 安全地迁移到正常的客户端之上。
• 由于以太坊共识有 Slash 的规则，需要保证旧客户端与新客户端的行为的一致性而不被 Slash。
  例如：
• 新旧客户端分别对分叉两侧的 Checkpoint 进行投票，从而被 Slash。
• 新旧客户端在同一个 Slot 产出不同的区块，从而被 Slash。

• Layer1 -> Layer2 的存款时间会变长。Layer2 在 mint 的时候，一个重要前提是需要保证 L1 存款交易不会被回滚。因此，当以太坊网络 Epoch 敲定被推迟的情况下，L1->L2 的存款时间也会相应变长。
• 类似的，交易所也需要防止链上充值交易被回滚的情况，因此其充值时间也会相应变长。
• Oracle 链上报价存在被回滚的风险，因此依赖其的高价值服务要适当暂停。
• 在此次事件中，Uniswap 不显示余额、只能买入不可卖出，而 dYdX 暂停了存款。