Flashbots 捆绑包解释：私有 MEV 执行

简短回答 — Flashbots 捆绑包是通过 eth_sendBundle 提交到构建器中继（Flashbots、Titan、beaverbuild、rsync-builder）的有序交易组，以便原子包含在目标块中。整个包裹要么落在一起，要么什么都没有——没有部分填充。提交是密封的（其他搜索者无法在任何公共内存池中看到您的捆绑包），并且可以包含诸如 revertingTxHashes （允许在不使捆绑包无效的情况下恢复的交易）、targetBlockNumber / maxBlockNumber （包含窗口）、replacementUuid （重新提交同一逻辑捆绑包）和 refundRecipient （其中 MEV-Share 回扣）之类的提示去）。最常见的错误是将用户保护 RPC（Flashbots Protect，针对普通钱包用户）与搜索中继（relay.flashbots.net，针对 eth_sendBundle）混为一谈 — 它们是不同的产品，具有不同的端点、不同的身份验证和不同的语义。两者的名字中都有“Flashbots”；只有一个接受捆绑。

精通之路

• 高级 ETH 套利策略
• 机构 MEV 反向运行 (2026)
• Flashbots 捆绑包说明（当前）
• 最佳以太坊私有 RPC
• 私有 RPC 指南
• MEV 盈利能力 (2026)

捆绑包实际包含什么

捆绑包是通过 HTTPS 发送到中继的 JSON 信封。最小有效负载：

• txs — 已签名的 RLP 编码交易数组，按执行顺序排列。
• blockNumber — 目标块（十六进制）。这是捆绑包目标包含的块。

可选但常用的：

• minTimestamp / maxTimestamp — 将包含窗口收紧至实时范围。
• revertingTxHashes — 允许恢复的交易哈希值列表。如果没有这个，任何 tx 中的任何 恢复都会使整个包失效。
• replacementUuid — 使用相同的 UUID 替换之前提交的包（并非所有中继都支持）。
• refundRecipient — 用于 MEV 共享感知捆绑包；向何处发送任何回扣。
• refundPercent — 将 MEV 的哪一部分分享回触发器用户。

txs 中的每笔交易只是一个普通的签名以太坊交易。捆绑包本身“不是”交易——它是一个包装器，指示构建器如何集中处理交易。

捆绑包生命周期

1. 搜索者构建捆绑包 — 通常：签名的触发器参考 + 签名的策略交易。
2. 搜索器使用 eth_callBundle 针对下一个块目标进行模拟。如果无利可图，就放弃。
3. 搜索者使用 eth_sendBundle 向一个或多个中继提交。中继层密封。
4. 中继验证架构 + 运行模拟 + 转发给参与的构建者。
5. 构建者评估包含该捆绑包是否可以提高其块价值超过次佳替代方案。如果是，请包括。
6. 提议者（验证者）选择要发布哪个构建器的区块——他们选择支付最高的那个。
7. 捆绑包成功落地——如果被选中的构建者区块包含了它。否则：未被纳入。

没有落在目标块中的包就消失了——默认情况下不会重试。搜索者要么接受失败，要么重新提交（使用相同或更新的参数）以获取稍后的目标块。

为什么“私人”并不像大多数人想象的那样

捆绑包在 public-mempool 层是私有的。它仍然可见：

• 您提交给的中继（Flashbots、Titan 等）。
• 中继转发到的构建器（每个中继转发到不同的集合）。
• 一旦构建器包含该捆绑包，验证器就会提议该块。

所以“私有”意味着“不在 eth_subscribe('newPendingTransactions') 中”。其他搜索者看不到它；中继的建造者集确实如此。这很重要：如果您使用单个构建器提交到单个中继，那么您就以公共内存池不需要的方式信任该构建器和该中继的策略。

中继与 RPC 的区别

令人困惑的是，Flashbots 生态系统有两个具有相似品牌的端点：

到用户 RPC 的 eth_sendBundle 失败。发送到中继的钱包交换也会失败。这两种产品服务于不同的受众，并且不能互换。完整的讨论位于最佳以太坊私有 RPC。

多构建器扇出现在是默认设置

Flashbots 不再是唯一的区块生成器。截至 2026 年，主要构建者包括：

• Flashbots——历史上占据主导地位，目前仍然占据重要份额。
• Titan — 按当前区块份额计算是最大的之一。
• beaverbuild — 高优先级块的高份额。
• rsync-builder — 可靠的辅助。
• bloXroute — 具有全球基础设施的商业中继。

单接力提交意味着您打赌您的接力的建造者赢得下一个位置。根据当天的情况，存在 30-60% 的盲点。现代严肃的搜索者扇出：同一包同时提交给四个以上的构建者，第一个包含者获胜。 FRB 代理 自动执行此扇出，并根据每个中继包含成功情况调整权重。

MEV-Share：OFA 层

MEV-Share 是一个单独的 Flashbots 构建的订单流拍卖协议。它公开了有关待处理交易的预执行“提示”（正在发生交换，这里是粗略的大小和池，但不是确切的细节），因此搜索者可以构建 OFA 感知的捆绑包，以退款奖励原始用户。

MEV-Share 的关键概念：

• 提示 — 有关发布到提示流的待处理交易的部分信息。搜索者订阅的是提示，而不是完整的交易。
• 捆绑包引用提示 — 您的捆绑包包含触发器用户的散列交易 ID 作为后台引用；中继在包含方面与它相匹配。
• 退款 — 当捆绑包落地时，一小部分 MEV 通过 refundRecipient / refundPercent 返回给触发用户。

MEV-Share 是它自己的订阅端点，具有自己的架构。将 MEV 共享式捆绑包提交到常规 Flashbots 中继（反之亦然）会默默失败。不同的产品，不同的规则，但概念上相邻。

常见的捆绑错误

• 忘记 revertingTxHashes. 如果一个多交易捆绑包中的一个交易预计可能恢复（例如，探测并重试），则整个捆绑包将失效，除非这些交易被标记。
• 错误的 targetBlockNumber。 相差一或十六进制与十进制混淆。中继拒绝。
• 向中继提交交易费用没有竞争力。 构建者按价值优先。无论哪个中继转发它，都不会包含在打包块之上具有 1 gwei 优先费的捆绑包。
• 单中继提交。 使 30-60% 的区块共享无法访问。
• 在没有 replacementUuid 的情况下在同一块重新提交。 某些中继将重新提交视为新捆绑包；有些人将其视为重复。如果中继支持，则使用 replacementUuid ；否则手动跟踪哪些捆绑包正在等待哪个目标块。
• **令人困惑的 eth_sendBundle 和 eth_sendRawTransaction。**不同的方法，不同的端点，不同的意图。

工作配置

现代搜索者的捆绑路径：

1. 使用适当的提示构建捆绑包（如果 MEV 共享，则为 revertingTxHashes、refundRecipient、目标块、最大块）。
2. 通过 eth_callBundle 针对目标块进行模拟。如果无利可图就放弃。
3. 通过 eth_sendBundle 同时扇出到 Flashbots + Titan + beaverbuild + rsync-builder。
4. 等待一个街区。如果不包含，则重新评估（状态可能已发生变化）：删除或重新提交。
5. 记录每个包的包含源。

FRB Agent 通过每个中继包含跟踪来实现此端到端，随着时间的推移自动调整扇出权重。

参考

• Flashbots：了解捆绑包
• Flashbots eth_sendBundle 参考
• MEV-Share 文档