全面解读MEV-Boost工作原理及Ethereum分叉选择规则
原文标题：《Time,slots,andtheorderingofeventsinEthereumProof-of-Stake》原文作者：GeorgiosKonstantopoulos,MikeNeuder原文编译：Kxp，BlockBeats引言
4月2日，恶意的?Ethereum?网络参与者利用MEV-Boost中继中的漏洞从一个MEV搜索者那里窃取了2000万美元。接下来几天，开发者通过发布五个补丁来解决这个漏洞。这些补丁，加上网络延迟和验证器策略，导致?Ethereum?网络在4月6日出现了短暂的波动。重组区块对网络健康会产生不利影响，因为它们减缓了区块的生产速率并降低了结算保障。在这篇文章中，由于搜索者受到攻击且网络暂时不稳定，我们探讨了MEV-Boost与共识之间的相互作用，分析了?Ethereum?的权益证明机制的微妙之处，并列举了一些可能的前进路径。MEV-Boost及其重要性
MEV-Boost是由Flashbots和社区设计的一个协议，旨在减轻最大可提取价值对?Ethereum?网络的负面影响。MEV-Boost中有3个参与者：1.中继——相互信任的拍卖者，连接出块者和区块构建者2.构建者——构建区块的复杂实体，以最大化自己和出块者的MEV3.出块者——Ethereum?的权益证明验证者每个区块的大致事件序列是：1.构建者通过从用户、搜索者或其他订单流接收交易创建一个区块2.构建者将该区块提交给中继3.中继验证块的有效性并计算它向出块者支付的金额4.中继向当前slot的出块者发送空白标题和支付值5.出块者评估他们收到的所有出价，并签署与最高付款相关联的空白标题6.出块者将此已签名标题发送回中继7.中继使用它们的原生信标节点发布区块，并将其返回给出块者。奖励通过区块内的交易和区块奖励分配给建设者和提议者。中继是一个受信任的第三方，促进出块者公平交换区块空间和构建者用于MEV提取的交易排序。中继通过保护构建者免受MEV偷窃，避免出块者复制构建者交易以取走MEV而不分配给发现它的搜索者/构建者来保护构建者。中继通过确认构建者区块的有效性、代表出块者处理每个slot上的数百个区块以及确保出块者支付的准确性来保护出块者。MEV-Boost是关键的协议基础设施，因为它使所有出块者都能够民主地访问MEV，而无需与构建者或搜索者建立信任关系，这有助于?Ethereum?的长期去中心化。Ethereum?的分叉选择规则与MEV-Boost
在探讨攻击和响应之前，我们先来看看?Ethereum?的权益证明机制和相关的分叉选择规则。分叉选择规则允许网络就链头达成共识，《Ethereum?合并后的重组》这篇文章中对其做出了定义：「分叉选择规则是一个由客户端评估的函数，它用已看到的区块和其他消息作为输入，并向客户端输出「规范链」。分叉选择规则十分重要，因为可能有多个有效的链可供选择。」分叉选择规则也与时间相关，这对出块有重大影响。slot和sub-slot周期
在?Ethereum?的权益证明机制中，时间被分割为每12秒为一组的slot。权益证明算法随机分配验证者在该slot内提出块的许可证；这个验证者被称为出块者。在同一slot内，其他验证者被分配为根据其本地视图应用分叉选择规则来为链头进行验证的任务。这12秒的slot被细分为三个阶段，每个阶段消耗4秒。在slot中发生的事件如下所示，其中t=?0表示slot的开始。在slot期间，最关键的时刻是在t=?4时的认证截止时间。如果认证验证者在认证截止时间前没有看到区块，他们将会投票给链上先前被接受的头部。一个区块被提出的时间越早，它就有更多的时间传播，从而积累更多的认证。从网络健康的角度来看，区块发布的最佳时间是t=?0?。然而，由于区块价值随着时间单调递增，出块者有动机推迟其区块的发布，以便更多的MEV积累。有关详细信息，请参见??TiminggamesinProof-of-Stake??和本讨论?。以前，出块者可以在认证截止时间后发布区块，只要下一个验证者在建立其后续slot的区块之前观察到该区块即可。这是由于子区块继承父区块的权重，分叉选择规则在叶节点终止。因此，推迟区块发布没有任何副作用。为了帮助将理性行为转向诚实行为，实施了「诚实重组」。出块者奖励机制和诚实重组
两个新的概念被引入到共识客户端中，对认证截止时间有关键的影响。1.出块者奖励机制——旨在通过授予出块者等同于40%全部认证权重的分叉选择「奖励」来尽量减少重组平衡攻击。重要的是，这个奖励仅持续整个slot。2.诚实重组——利用出块者加速，允许诚实的出块者强制重组认证权重低于20%的区块。这已经在Lighthouse和Prysm中实现。这个改变是可选的，因为它是出块者作出的决策，不影响认证验证者的行为。因此，我们不用将其同时应用于所有客户端，它也没有与任何特定的硬分叉相关联。需要注意的是，在一些特殊情况下会避免使用诚实重组：1.在epoch边界区块期间?2.如果链没有最终确定?3.如果链头不是重组前slot的头部情况3确保诚实重组只会从链中删除一个区块，这起到了断路器的作用，使得链能够在极端网络延迟期间继续生成块。这也反映了提案者对网络的看法的信心降低了，因为他们无法确定其提议增强的块是否将被视为规范。下图展示了如何改变诚实行为以实施重组策略。在这种情况下，让b?1代表一个迟到的块。由于延迟，b?1只有第n个slot的19%的证明权重。剩余的81%的证明权重分配给父块HEAD，因为许多证明者没有在证明截止期之前看到b?1?。如果没有诚实的重组，第n?1个slot的提案者会将b?1视为链的头并构建子块b?2?。提案者没有努力重组b?1?，尽管它只有19%的证明权重。在第n?1个slot，b?2具有提案者的增强，假设它按时交付，b?2将通过积累该slot的大多数证明成为规范。有了诚实的重组，情况大不相同。现在，第n?1个slot的提案者看到b?1的19%证明权重低于重组阈值，因此他们建立一个以HEAD为父块的块，并强制重组b?1?。当我们到达第n?1个slot的证明截止期时，诚实的证明者将比较b?1?与b?2?的相对权重。所有客户端都实现提案者增强，因此b?2将被视为链的头，并将积累第n?1个slot的证明。针对解绑攻击的中继和信标节点修复?
在4月2日的unbundling攻击中，提案者利用中继漏洞向中继发送了一个无效的签名头。在接下来的几天里，中继和核心开发团队发布了许多软件补丁，以减轻重复攻击的风险。五个主要更改如下：中继更改：检查数据库中已知的恶意提案者。检查中继是否已将完整块传递到P2P网络中的某个slot。在块发布之前引入0-500?ms范围内的均匀随机延迟。信标节点更改：在广播之前验证信标块。在发布区块之前检查网络是否存在错误确认。这些更改的结合导致了共识不稳定性，这一问题加剧了由于大部分验证者现在使用上述诚实重组策略而产生的影响。意外的后果?
上述的五项更改都在中继块发布的热路径中引入了延迟，这增加了中继块在确认截止时间之后广播的概率。下图显示了这五项检查的顺序以及引入的延迟如何导致区块发布超过确认截止时间。在实施这些检查之前，大量滞后于t=0?的已签名头部通常不会产生问题。由于中继的开销非常低，因此它将在t=4之前发布区块，而无需等待确认截止时间。然而，由于这五个修补程序的延迟引入，中继现在可能部分负责迟延广播。让我们看看下面的假设性区块发布过程。中继在t=3时从出块者处接收到已签名头部。到了t=4?，中继仍在执行检查，因此广播将在确认截止时间之后进行。在这种情况下，出块者发送的延迟已签名头部和中继引入的一些额外延迟的结合导致了未能在确认截止时间之前广播。如果没有诚实的重组，这些区块很可能已经进入链上。如图2所示，接下来slot的诚实出块者不会因为这些区块迟到而故意进行重组。然而，如果错过了确认截止时间，则这些区块将被下一个出块者重组。因此，在攻击后的几天中，分叉块的数量急剧增加。Metrika的两周数据显示，在最坏的情况下，一小时内可能会有13个区块被重新组织，这是正常情况的约5倍。随着中继器推出各种更改，分叉块的数量急剧增加变得明显。感谢中继操作员和核心开发人员的伟大社区努力，一旦了解到影响，许多更改被撤回，网络恢复到了健康状态。截至今天，最有用的更改是信标节点块验证和发出之前的抵赖检查。恶意的出块者不能再通过向中继发送无效头部并确保中继信标节点在发布之前不看到抵赖块来执行攻击。尽管如此，中继仍然面临着MEV-Boost和ePBS中提出的更一般的抵赖攻击。下一步行动
在这篇文章中，我们强调了MEV-Boost的工作原理以及它对?Ethereum?共识的关键性。我们还对与时间有关的?Ethereum?分叉选择规则中的一些较少知道的方面进行了详细分析。通过使用「解绑」攻击和开发人员的反应作为案例研究，我们强调了分叉选择规则与时间有关的方面的潜在脆弱性以及其对网络稳定性的影响。考虑到这一点，研究界应该评估什么是「可接受」的重新组织次数，并考虑抵赖攻击的更一般曝光情况，以确定是否应该实施缓解措施。此外，目前正在积极探索多个未来方向：1.实施头锁机制，以保护MEV-boost免受等价错误攻击。这还需要更改共识客户端软件并可能需要规范更改以扩展证明提交期限。2.增加MEV-Boost软件的漏洞赏金计划的数量和传播力度。3.扩展模拟软件以探索sub-slot定时如何影响网络稳定性，这可以用于评估如何调整证明提交期限以减少重组。4.优化中继上的区块发布路径以减少不必要的延迟——这已经在探索当中。5.承认MEV-boost是核心协议功能，并将其纳入共识客户端，即「enshrined-PBS(ePBS)」。两个slot的ePBS容易受到明显的攻击，因此实施「头锁机制」仍然是一种选择。6.通过围绕延迟和认证截止时间的问题加入更多的hive和/或spec测试。7.通过构建中继规范的其他实现，鼓励中继客户端的多样性。8.考虑调整对于明显攻击的惩罚，但要记住即使进行完整的32个ETH的惩罚，也可能无法阻止在极大的MEV机会存在时的恶意行为。9.重新审视sub-slot计时，并考虑调整区块传播阶段。总的来说，我们对MEV和mev-boost生态的再次兴起感到兴奋。通过解绑攻击和缓解措施，我们已经了解了延迟，MEV-boost和共识机制之间的关键关系；我们希望协议能够继续加强以应对这种情况。原文链接
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。