包含概率 101：思考失败

简短回答 - 包含概率是您提交的实际落在链上的捆绑包的份额。到 2026 年，这是经过衡量的，而不是假设的：以太坊主网上具有多构建器扇出和有竞争力的优先费用的工作捆绑路径通常会获得绝大多数捆绑，但绝对数量取决于您的策略的竞争水平、扇出所达到的构建器覆盖范围以及费用模型的新鲜度 - 所有这些都因链和一天中的时间而异。预期值公式为 EV = (Reward − Cost) × P_inc − (Failure_Penalty × (1 − P_inc))，并且在私有中继路径上，失败惩罚大致为零（未包含的捆绑包没有链上Gas），这使得提高 P_inc 成为您拥有的最高杠杆旋钮。陷阱操作员陷入的​​困境是将 P_inc 视为单个全局数字 - 它是每个策略、每个中继、每个时间的分布，这就是它应该如何测量。

精通之路

• 什么是 MEV？
• 私有内存池与公共内存池
• Backrun vs 三明治策略
• 包含概率（当前）
• 修复失败的捆绑包指南
• Mempool 扫描 101

期望值框架

每个 MEV 机会都是对您的捆绑包是否落地以及在落地时是否有利可图的赌注：

EV = (Reward − Cost) × P_inc − (Failure_Penalty × (1 − P_inc))
Copy

在哪里：

• 奖励 = 如果捆绑包成功并且策略有效的话利润。
• 成本 = 支付的Gas + 优先费 + 中继费（如果有） + 建设者回扣。
• P_inc = 包含在目标块中的概率。
• 失败_惩罚 = 如果捆绑包已提交但未实现盈利，则支付链上Gas。

对于私有中继路径 (eth_sendBundle)，Failure_Penalty ≈ 0 — 未包含的捆绑包不会燃烧 Gas。这将公式压缩为大约 EV ≈ (Reward − Cost) × P_inc，这使得提高 P_inc 成为最高杠杆旋钮。

对于公共内存池发送，Failure_Penalty 是每次恢复尝试的全部 Gas。这就是为什么即使个别成功的交易是有利可图的，公共内存池 MEV 运营商也会流血——被拒绝的尝试会加剧。

是什么驱动 P_inc

三个主要因素，按典型影响排序：

1. 构建者对中继扇出的覆盖范围。 单中继提交只能覆盖该中继的构建者所赢得的那部分下一区块。在以太坊上，这一比例通常为 30-60%。 Flashbots + Titan + beaverbuild + rsync-builder 的扇出将覆盖率推向接近 95% 以上。大多数运营商只需在扇出中增加中继，就能获得最大的 P_inc 改进。
2. 优先费用竞争力。 优先费用低于该块的清算价格的捆绑包不会被包含在内，无论哪个中继转发它。构建者按每燃气价值对捆绑包进行排序；没有竞争力的出价每次都会失败。
3. 中继延迟。 构建者会在时段之前的某个时刻关闭其包含列表。在该截止日期之后到达的捆绑包即使支付良好，也不能包含在内。在 12 秒主网时隙上，低于 150 毫秒的 RTT 就足够了；低于 50 毫秒并没有进一步的帮助。

次要因素：

• 提示正确性。 缺少 revertingTxHashes 会使可能应该落地的捆绑包无效。
• 与现实不同的捆绑包模拟。 模拟绿色但在生产中恢复的捆绑包实际上并不可包含 - 模拟漂移隐藏了包含问题。
• 策略方竞争。 当其他搜索者看到同样的机会时，拍卖清算出价就会上升；有些捆绑包本来能落在冷清的区块上，却落不到争夺激烈的区块上。

如何衡量您的真实包容率

每个策略的每日数字，保存在仪表板上：

• 已提交捆绑包。
• 包含捆绑包。 对照捆绑包所针对的实际块进行交叉检查，而不是对照“我的任何交易是否落在某处”。
• 按中继的包含率。 每个中继归因 — 哪个中继的路径传送了每个成功的捆绑包。
• **按一天中不同时间段划分的包含率。**不同的时间、不同的拥堵情况、不同的 P_inc。
• 每个包含的捆绑包的实际利润与模拟利润。 持续的差距意味着模拟在撒谎。

“通过中继”故障是最具可操作性的。在几百个捆绑包之后，您可以看到哪些中继始终为您的特定策略提供服务，哪些是自重；重新调整扇出对获胜者的权重。

当 P_inc 滑倒时该采取什么行动

如果您测得的 P_inc 较基线下降 20% 以上：

1. 首先查看逐个中继站。 如果一个中继站的贡献已经崩溃，则该中继站的构建者覆盖范围已发生变化（失去了主要构建者等） - 删除或减轻其权重。
2. 然后是延迟。 p95 延迟到中继的回归通常与 P_inc 崩溃相关。云提供商的怪异、区域路由变化、ISP 问题。
3. 然后是费用模型的新鲜度。 在费用制度转变期间（分叉后，blob-fee 时代开始），过时的模型会在数周内低于出价，直到您注意到为止。
4. 最后，策略。 通常看起来“策略停止工作”实际上是上述之一；按此顺序进行调查可以节省时间。

改善 P_inc

• 跨至少四个中继的扇出。 单中继提交会留下 30-50% 的包含量。
• **在签署前立即刷新费用状态。**陈旧的费用会失去有争议的区块。
• 如果您当前位置到中继的延迟超过 150 毫秒，就将您的发送节点部署到中继所在区域。
• 使用正确的提示。 revertingTxHashes 对于任何可能恢复的交易； targetBlockNumber 和 maxBlockNumber 来限制包含窗口。
• 跟踪每个中继的性能并重新加权。 FRB Agent 自动执行此操作。

链特定包含特征

P_inc 机制在各个链之间存在很大差异——用于提高以太坊包容性的相同策略并不总是直接转化。

以太坊（12 秒时段）： 多构建者 PBS 生态系统意味着构建者覆盖范围是主导因素。通过 Flashbots + Titan + Beaverbuild 扇出，覆盖率达到 90% 以上。第二个因素是有竞争力的出价水平——以太坊拥有最活跃的搜索者市场，因此费用竞争力在这里比任何其他链都更重要。

Solana（亚秒时段）： Jito 区块引擎捆绑包通过基于提示的订购直接发送给验证者领导者。 Solana 上的 P_inc 在很大程度上取决于您是否提交到足够的区域 Jito 端点（纽约、法兰克福、东京、阿姆斯特丹）以及您的小费是否等于或高于当前 80% 的已结算小费。"构建者覆盖率"这个概念在这里并不适用——因为不存在构建者中介。

Arbitrum 和 L2： 基于排序器（sequencer）的打包方式意味着您的 P_inc 窗口更窄。排序器按到达顺序在队列中处理交易（约 100–250 毫秒批处理延迟）。由于只有一个排序器，扇出在这里起不到像以太坊那样的作用。排序器的延迟才是主要杠杆。

BNB 链： 没有成熟的私有中继等效项。 P_inc 的改进几乎完全来自直接向验证者提交和有竞争力的优先费。多中继扇出的好处有限——大多数包含都是通过标准内存池路径发生的。

关键要点：不要跨链实施包含优化策略。在以太坊上提升 P_inc 的因素（更多中继）不会直接转化为 Solana（更多区域端点），也不会转化为 Arbitrum（更低的排序器延迟）。

参考

• Flashbots：了解捆绑包
• 最佳以太坊私有 RPC
• 修复失败的捆绑包指南
• 盈利能力与风险：Gas和预算上限
• Mempool 扫描、过滤器和延迟