加密机器人背后的爆炸性真相：它们在抢先盗贼以“拯救”资金——但由谁获得偿还由它们决定

来源：CryptoNewsNet 原文标题：加密机器人背后的爆炸性真相：它们在“救援”资金时会优先抢跑盗贼——但由谁决定偿还谁 原文链接：

Makina Finance 事件

Makina Finance 在一次闪电贷和预言机操控漏洞中损失了 1,299 ETH，约合 413 万美元。

攻击者耗尽了协议的资金，并将交易广播到以太坊的公共内存池，本应由验证者捕获并包含在下一个区块中。

然而，一个由地址 0xa6c2 识别的 MEV 构建者抢跑了这笔耗尽资金的交易，将大部分资金在黑客将其链下转移之前，转入了由构建者控制的保管账户。

黑客的交易失败了。资金流入了与该 MEV 构建者相关的两个地址。

立即的结论是，Makina 的用户避免了全部损失。更深层的信号是，最终谁持有了这笔钱，以及这对加密货币新兴的应急响应架构意味着什么。

这个故事中最重要的角色不是攻击者或协议本身，而是拦截漏洞的区块构建供应链，它现在掌控着用户是否能拿回资金、在什么条件下以及多快。

MEV 机器人和构建者正成为加密货币的最后一道防线，这不是出于设计，而是结构性位置造成的。这是个问题，因为救援能力集中在追求最大利润的中介手中，且责任不明。

MEV 作为后备机制已成为一种模式

Makina 事件并非孤例。Chainalysis 在 2023 年 Curve 和 Vyper 漏洞中也记录了类似的动态，指出白帽黑客和 MEV 机器人操作者帮助追回资金，减少了实际损失，低于最初估算。

这种模式是机械的：只要漏洞或救援尝试在公共交易渠道中可见，复杂的搜索者和构建者就可以竞争重排交易。

有时他们会挽救资金，有时会夺取资金。无论哪种方式，他们都在充当事实上的应急响应层。

当漏洞交易进入公共内存池时，MEV 搜索者会监控是否存在盈利机会。如果黑客耗尽协议并公开广播交易，搜索者可以构建一笔竞争交易，优先执行，将资金重定向到不同的地址。

搜索者将交易打包后提交给区块构建者，如果利润超过竞争出价，构建者会将其包含在区块中。如果验证者选择了构建者的区块，搜索者的交易就会执行，黑客的交易则会失败。

这是一种带有副作用的利润提取，而非纯粹的利他行为。但它也是加密货币在实时拦截漏洞方面最可靠的机制，因为它在交易排序层面操作，而不是依赖协议层的断路器或治理干预。

为什么依赖 MEV 构建者令人不安

基于 MEV 的救援问题在于，它将应急响应能力集中在一个高度中介化的流程中。

在以太坊上，MEV-Boost 主导区块生产。Rated 的中继格局显示，最近大约 93.5% 的区块通过 MEV-Boost 路由，而仅有大约 6% 使用普通区块生产。

在 MEV-Boost 内，中继市场份额进一步集中：Ultra Sound Money 占据大约 29.84% 的中继流量，Titan 占大约 24.24%，意味着两个最大中继共同处理超过 54% 的区块生产。

如果大部分区块通过 MEV-Boost 流动，而大部分流量都经过两个中继，救援层在结构上依赖少数中介。这会很快引发治理问题。

如果构建者最终持有了救援资金，谁来授权保管？谁来设定赏金？什么能防止勒索或赎金要求？如果构建者在海外、匿名或在执法力度薄弱的司法管辖区运营怎么办？

Makina 案例正好说明了这个问题。资金由构建者保管，但没有公开的服务水平协议（SLA）、预设的赏金，也没有明确的机制将资金返还给 Makina 或其用户。

构建者可以自愿返还资金、协商赏金、要求高于行业标准的费用，或完全拒绝返还。

私有路由让问题更糟

一篇 2025 年的学术论文《Sandwiched and Silent》记录了交易的广泛私有路由，发现许多受害者在被 MEV 机器人夹击后迁移到私有通道。

然而，私有路由并未消除 MEV，只是将其从公共内存池转移到由构建者和中继控制的私有订单流通道。

对协议而言，这意味着公共内存池的救援变得不那么可靠，因为漏洞交易越来越多地通过仅对部分构建者开放的私有通道进行路由。

试图规范混乱

Safe Harbor 是由 SEAL 开发的一个框架，旨在用授权响应者、明确的 SLA 和有限的激励机制取代“MEV 构建者意外成为托管人”的模式。

SEAL 将 Safe Harbor 描述为一个法律和技术框架，允许协议预先授权白帽在主动漏洞期间进行干预。

其核心操作规则是：救援资金必须在 72 小时内转入官方的恢复地址，并设定预定义、可强制执行的赏金。

SEAL 表示，Safe Harbor 的灵感来自 Nomad 被盗事件，当时白帽愿意帮助，但受到法律模糊的限制，不清楚返还资金是否会被视为未授权的计算机访问。

Safe Harbor 通过赋予协议预先授权干预和设定明确条款的方式，消除了这种模糊。SEAL 声称，Safe Harbor 已在多个主要协议中提供保护，总价值超过 $16 十亿美元，包括某些去中心化交易所（DEXs）、Pendle、某些 Layer-2 解决方案和 zkSync。

Immunefi 这个漏洞赏金平台也已将 Safe Harbor 付诸实践，采用更严格的条款。

Immunefi 将 Safe Harbor 描述为由 SEAL 开发的框架，将资金重定向到 Immunefi 平台上的协议控制仓库。其 Safe Harbor 计划页面的条款规定：“你有 6 小时的时间将资金转回。”

未在六小时内完成转账即视为重大违约。这比 SEAL 72 小时的基础要求快了四倍。

Safe Harbor 并未消除对 MEV 基础设施的依赖，而只是试图将其制度化。

如果构建者抢跑漏洞，且协议已采用 Safe Harbor，预期构建者会将干预视为授权，并在 SLA 内将资金路由到协议指定的恢复地址。

但这假设构建者会监控 Safe Harbor 注册表、尊重条款，并优先考虑合规而非利润。

场景范围

在漏洞中，用户的预期救援率可以用以下模型表示：预期救援等于干预概率乘以（1 - 赏金百分比）乘以（1 - 失败或泄露百分比）。

Safe Harbor 旨在通过减少法律模糊和提前设定赏金百分比，增加干预的可能性。

在基本情况下，未来 12 个月内，Safe Harbor 的采用会逐步增加。更多协议在其治理框架中加入 Safe Harbor 条款，更多白帽注册为授权响应者。

由于响应者拥有法律明确性和固定的赏金条款，干预概率上升。救援率也会提高，尤其是在采用更严格 SLA（如 Immunefi 的六小时窗口）的协议中。

在牛市场景中，救援层变得专业化。协议建立紧凑的仓库地址，将 SLA 压缩到单数字小时，并与已知白帽团队预先协商赏金计划。

构建者将 Safe Harbor 注册表集成到交易排序算法中，自动将救援资金路由到指定地址，无需人工干预。

在熊市场景中，依赖构建者的程度加深。私有订单流和中继集中使救援变得不那么透明，更具寡头垄断性。未采用 Safe Harbor 的协议最终不得不在事后与构建者协商，没有明确的杠杆或 SLA。

治理变得依赖于持有资金并单方面设定条款的中介。