概述
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 可能被回滚，从而导致交易被回滚。
MarketVector和Figment推出业界首个以太坊质押奖励指数:金色财经报道，MarketVector Indexes 正在与质押基础设施公司 Figment 合作，推出业界首个以太坊质押奖励指数，MarketVector 数字资产产品策略师 Martin Leinweber 在一份声明中表示，资产管理者和顾问能够以可定制的方式获得质押奖励，这在业界尚属首例。
该合作伙伴计划推出两款产品——MarketVector Figment 以太坊质押奖励参考率和 MarketVector Figment 以太坊总回报指数。这些指数将为向投资者提供数字资产投资机会的机构带来新的机会，并允许资产管理公司提供以新指数为基准的质押奖励产品。[2023/7/28 16:03:05]
实际上，在事件发生的期间，以太坊网络并未出现分叉，而 Validator 也未进行恶意投票，只因大量 Validator 离线导致投票率不足，从而使得 Epoch 在期间无法被敲定。
经过观察，离线的 Validator 出现 CPU 过载的异常情况，被认为是 Validator 离线的直接原因。
在第二次事件中，Epoch 敲定被延迟了 8 个 Epoch，由于敲定延迟大于MIN_EpochS_TO_INACTIVITY_PENALTY (=4) 从而触发了以太坊共识算法 Inactivity leak 的处理机制。
瑞士CMTA测试使用以太坊结算瑞士法郎:12月13日消息，近日，在瑞士资本市场技术协会（CMTA）的主持下进行的一项概念验证，展示了瑞士法郎现金方结算首次通过桥将以太坊与瑞士银行同业结算系统(SIC)连接起来。在这一过程中，瑞士信贷银行、百达银行和 Vontobel银行以代币形式在以太坊测试网上发行了结构化产品，并随后通过BX Swiss进行交易。（eqs-news）[2022/12/13 21:41:52]
· 惩罚离线的 Validator，削减其质押资金，罚没了约 28 个 ETH。
· 取消 Attestation 的奖励，导致约 50 个 ETH 未被发行。
· 该机制保证在线 Validator 最终能掌握以太坊总质押资金的 ?，从而使得网络状态最终能被敲定
imToken 的节点服务也侦测到了此次事件，通过实时监控以太坊共识层 Validator 投票的情况，从而在 Epoch 未能正常敲定前，提前预警以太坊共识网络的异常。下图是第一次事件发生时的节点状态。
PoW 机制下，交易的成功是认定交易在多少连续区块后大概率不会被回滚，PoS 则是以 Safe Head 返回的块高作为交易成功的判定。而目前的规范中则是以 Justified Checkpoint 作为 Safe Head 的状态认定，因此以前一 Epoch 的状态来看，可能存在有 6.4 分钟之久的判定延迟，这对用户而言是很糟糕的体验。
LedgerPrime已出售4950万美元证券以购买比特币和以太坊:金色财经报道，根据美国证券交易委员会（SEC）的一份文件，由前华尔街高管领导的数字资产投资公司LedgerPrime已经出售了价值4950万美元的证券，用于投资比特币和以太坊。[2021/3/12 18:37:26]
imToken 自研的 Safe Head 服务会基于实时的以太坊共识层数据，计算出安全的区块用于交易确认，在保证用户交易安全的前提下，缩短交易确认的时长。正常情况下，imToken 的 Safe Head 算法返回的块高（如上图黄色），会非常贴近最新的区块高度（绿色），从而提高用户体验。
原因分析
造成上述事件的直接原因是某几种以太坊共识层客户端节点负载过高，使得 Validator 宕机离线，从而无法正常进行共识投票。经过分析，这些节点负载过高的原因是：
当收到指向陈旧区块的见证（Attestation）时，节点需要重新计算信标链状态以验证这些见证，而该过程需要消耗大量的 CPU 以及内存资源。
当同时收到大量指向陈旧区块的见证时，节点的 CPU 以及内存资源被耗光，从而导致这些 Validator 宕机离线。
本来此类问题可以通过基于见证指向区块的缓存来解决，然而由于 Validator 的规模增长以及大量此类 attestation 的出现，导致出问题的客户端实现的缓存被击穿，节点不得不消耗大量资源重新计算信标链状态。
基于0.12规范的更正式以太坊2.0多客户端测试网有望在6月份发布:一个以太坊2.0开发人员的调用显示，Schlesi 测试网非常成功，有望在6月份发布一个基于0.12规范的更正式的多客户端测试网。现在，以太坊2.0的开发几乎完全是为了修复bug，团队试图将所有现有的客户端同步到区块链的一个版本中。5月14日举行的以太坊2.0实现者调用的后续报告显示，大部分工作致力于修复代码错误和改进检测方法。对于后者，Sigma Prime的开发人员Mehdi Zerouali报告了在设计“模糊”技术方面的重大进展，这种技术会向程序提供虚假数据，以找出程序的漏洞。Sigma Prime分析已经帮助发现了以太坊2.0客户端软件和它们所依赖的库中的一些低级错误。具体来说，分析人员在Teku客户端中发现了一个无限循环错误，在Nimbus中发现了一个内存分割错误。
由于客户端负责保存和验证区块链，因此它们之间的完全同步是非常重要的。对于以太坊2.0，有7个独立的客户机正在开发中。他们中的大多数人正在为Schlesi测试网进行优化，Schlesi测试网是第一个模拟主网环境的多客户端以太坊2.0测试网。Schlesi 测试网计划的负责人Afri Schoedon解释说，该网络有一个艰难的开始。bug阻止了第一次启动，一旦修复，由于客户端经常崩溃，事务最终结果“很糟糕”。 但是Schoedon赞扬了客户端开发人员在修复这些问题时的响应能力，这使得网络得以稳定。Schoedon补充道:“我将谨慎地将2020年6月作为发布日期。”不过他也指出，这在很大程度上取决于0.12客户端的发布。（Cointelegraph）[2020/5/15]
共识层客户端 Teku 以及 Prysm 目前推出了 patch 版本以解决该问题。具体而言，patch 版本的客户端实现会过滤掉这些陈旧的见证，即当满足下列条件，忽略该见证：
动态 | 微软把以太坊区块链纳入其产品组合:据Cryptodaily消息，微软正在探索和构建区块链技术。微软希望有一天能发展他们自己的改变游戏规则的区块链技术，但是现在，他们正在使用现成的项目来整合他们自己的技术。最近，以太坊区块链已经被纳入微软的产品组合。[2018/8/9]
· 见证指向一个陈旧的 Slot
· 见证指向一个节点从未见过的 Checkpoint
然而，我们仍需持续观察以太坊主网敲定的情况以确认 patch 的有效性。
共识层客户端 Teku 以及 Prysm 的 patch 版本：
· Prysm：v4.0.3-hotfix
· Teku：v23.5.0
以太坊设计优势
在此次事件中，以太坊保证可用性仍持续产生区块并处理交易，而仅推迟 Epoch 敲定的关键在于两点：
1. 以太坊客户端的多样性
2. Gasper 算法的设计
以太坊客户端的多样性
在此次事件中，虽然共识层客户端 Teku 以及 Prysm 的实现出现了问题，但不影响其他共识层客户端的正常运作。像是 Lighthouse 客户端本次并不受影响，由于不同客户端在实现的设计上并不相同，因此仍有 Validator 正常在运作。
以太坊客户端的多样性保证了：即使某些客户端出现问题（甚至导致 Epoch 不能敲定），也不会影响正常的客户端产生区块并处理交易，使得以太坊的可用性得到保持。
以太坊 Gasper 共识算法对可用性的设计
保证以太坊的可用性是以太坊共识算法 Gasper 的设计出发点之一，其把以太坊区块生产与敲定分离。因此，即使区块敲定受阻，区块的产生并不会随之终止。考虑到大部分情况下，区块敲定最终会恢复（产生的区块最终仍会被敲定），那么对用户影响其实会很低。对比其他 BFT 的共识算法：若区块敲定失败，共识节点会停止产出下个区块。从而，导致期间整个区块链不可用，即俗称的「区块链挂了」。
另外，第二次事件还触发到了 Inactivity Leak 的机制，其主要是为了保证以太坊在极端情况（大量 Validator 长时间离线）下仍能重新敲定区块。
经验与启示
以太坊多客户端的挑战
当前，以太坊客户端多样性现状如下图所示：
来源: https://clientdiversity.org/#distribution
可以看到，以太坊客户端多样性仍需继续推广和宣传。可以想象，如果客户端实现足够多样，使得 Prysm 以及 Teku 的占比小于 ?，那么这次事件甚至不会发生（? 客户端正常运作足以敲定 Epoch）。另外，当前执行层的客户端集中在 Geth，占比高达 61%。这实际上存在着潜在风险：如果 Geth 运作不当，以太坊会受到很大的影响。
除了以太坊客户端多样性需要进一步努力外，以太坊客户端切换也是此次事件暴露的一个痛点：当某个客户端实现出问题时，Validator 如何切换到正常的客户端实现之上。此过程涉及：
· 把出问题客户端的 Validation key 安全地迁移到正常的客户端之上
· 由于以太坊共识有 Slash 的规则，需要保证旧客户端与新客户端的行为的一致性而不被 Slash。例如：
o 新旧客户端分别对分叉两侧的 Checkpoint 进行投票，从而被 Slash
o 新旧客户端在同一个 Slot 产出不同的区块，从而被 Slash
以太坊共识的监控
需要类似 Safe Head 类似的服务持续监控以太坊 PoS 网络的实时状态，提前发现并预警该类事件，而非等到 Epoch 无法按预期敲定才得知网络状态异常。相关的最新研究可见此文章。
以太坊共识算法的科普
这次事件暴露了科普以太坊 PoS 共识机制的必要性。在此次事件中，很多用户误以为「以太坊挂了」，从而造成不必要的恐慌。然而，实际上，以太坊网络持续产生区块并处理交易。以太坊共识层和执行层的组合为以太坊交易交易确认带来双重保障，在共识层 Epoch 无法敲定的情况下，执行层的区块处理并不受影响，且 Epoch 敲定的异常状况也在以太坊共识算法中有相应处理设计。面向用户的区块链知识科普仍然是从业者们需要持续努力的方向。
对以太坊应用的启示
虽然以太坊网络足够健壮，但是偶尔的不稳定会对应用有着一定的影响。同时，应用要正确处理这些不稳定的场景。
· Layer1 -> Layer2 的存款时间会变长。Layer2 在 mint 的时候，一个重要前提是需要保证 L1 存款交易不会被回滚。因此，当以太坊网络 Epoch 敲定被推迟的情况下，L1->L2 的存款时间也会相应变长。
· 类似的，交易所也需要防止链上充值交易被回滚的情况，因此其充值时间也会相应变长。
· Oracle 链上报价存在被回滚的风险，因此依赖其的高价值服务要适当暂停。
· 在此次事件中，Uniswap 不显示余额、只能买入不可卖出，而 dYdX 暂停了存款。
总结
在这次事件中，我们可以看到以太坊 PoS 共识算法的韧性与自我修复的能力，也看到客户端很快在发生事故后，即时响应与修正错误。对以太坊整个生态而言，还需在以下方面持续投入：增加客户端多样性，优化对网络状态的实时监控与预警，深度用户教育（不仅面向普通用户，也需面向从业者），生态参与者在网络异常时的紧急预案准备。
参考链接
· Finality issue updates May 2023
· https://twitter.com/robplust/status/1657044364382846978
· https://twitter.com/superphiz/status/1656780594326405121
· https://twitter.com/terencechain/status/1657021042110631936
imToken
企业专栏
阅读更多
金色荐读
金色财经 善欧巴
迪新财讯
Chainlink预言机
区块律动BlockBeats
白话区块链
金色早8点
Odaily星球日报
MarsBit
Arcane Labs
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。