Mempool 扫描 101：过滤器、延迟和包含

简短回答 - 2026 年的内存池扫描有两个不同的问题：获取干净的信号（低延迟订阅+不会杀死召回的过滤器）和在可用窗口内对其进行操作（模拟+签名+足够快地发送以在下一个搜索者之前着陆）。大多数操作员过度调整过滤器并调整动作循环，这是错误的方向 - 缓慢处理的经过良好过滤的流只是另一种无用的。工作框架：订阅一个对等良好的节点（具有公共内存池的链上的 eth_subscribe('newPendingTransactions')、Arbitrum 上的定序器馈送 WSS、OP Stack 链上的操作节点八卦）；应用最小过滤器（池允许列表、值下限、路由器允许列表）；分析循环的每个阶段，直到您知道毫秒的去向。然后迭代最严重的阶段——它几乎从来不是过滤器集。

精通之路

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

“内存池扫描”在每条链上的含义并不相同

该术语借用自以太坊主网，其中有一个字面上的点对点广播层。在其他链上，机制不同，而且术语也很草率：

• 以太坊、BSC、Polygon、Avalanche 等 — 真正的公共内存池。针对任何对等节点的 eth_subscribe('newPendingTransactions') 为您提供实时流。
• Arbitrum——没有公共内存池。对应的信号来源是 sequencer feed WebSocket，它会在已接受的交易进入已确认区块之前先广播出来。
• Optimism、Base - 没有以太坊式的公共内存池，但排序器接受 JSON-RPC 提交并将其广播出去；连接良好的 op-node 可以通过标准订阅看到这些交易。
• Solana — 没有内存池概念；交易直接转发给验证器。 “扫描”工作更多的是关于 Geyser 插件流或块引擎订阅。

您订阅的内容以及什么算作“内存池中的机会”取决于您所在的链。延迟预算和滤波器形状也相应遵循。

过滤召回权衡

直觉陷阱：“过滤越严格 → 噪音越少 → 决策越快 → 包含率越高。”这个想法是错的，因为过滤器减少的不是"处理延迟"，而是"机会召回率"。

丢弃 90% 待处理交易的过滤器使您的决策循环只运行 10% 的数据。如果你的过滤器太紧，你就会错过避免噪音的真正机会，而噪音无论如何也不会让你变慢。正确的校准是：

1. **资金池许可名单：**您的策略实际交易的资金池。新的内容是明确添加的，而不是通过推理添加的。
2. **价值下限：**低于此触发交易大小，无论如何，数学都不适用于反向运行。 （以太坊上的名义价格低于 1000 美元，廉价链上的名义价格低于 200 美元。）
3. 路由器白名单： 您的策略实际上可以使用的路由器。附加令牌或不熟悉的路由器进入单独的“研究”流，而不是主要的热路径。

这就是热路径滤波器的内容。任何更激进的做法都是过度调整，会导致召回成本。

延迟预算

将从触发到发送的总时间分解为几个阶段并分析每个阶段：

如果其中任何一项处于“典型不良”范围内，那就是需要优化的地方，而不是您的过滤器组。状态获取阶段是最常见的隐藏罪犯；当许多机器人可以维护从同一 WSS 订阅更新的本地镜像时，它们会通过每次交易的往返 JSON-RPC 调用来获取状态。

包含与误报

两个独立的指标，经常被混淆：

• 收录率： 在我提交的捆绑包中，落地的比例是多少？对于预计 80% 以上的策略，低于 60% 是一个“基础设施”问题（延迟、费用模型、构建器覆盖范围）。
• 误报率： 通过我的过滤器的内存池事件中，有哪一部分被证明不是真正的机会？只要下游模拟器捕获到它们，高误报并不重要 - 这仅意味着您的过滤器松动。过滤器松动即可；下游成本高昂是问题所在。

操作员有时会收紧过滤器以追求错误的指标。如果您的纳入率较低，那么答案很少是更严格的过滤器。

测量什么

每个策略每日要保留的数字：

• 订阅过期警报（早于 500 毫秒阈值的事件）。
• 每阶段延迟百分位数（表阶段上方）。
• 过滤器通过率（每分钟通过的事件）。
• 有利可图的模拟后率（每分钟通过模拟）。
• 提交包含率。
• 通过中继包含（对于具有多个中继的链）。

每日仪表板上的这六个数字可以告诉您机器人在哪些方面表现良好，在哪些方面表现不佳。没有它们，调试就只是猜测。

常见扫描错误

• 单一订阅，无需交叉检查。 针对不同提供商的第二次订阅可验证您是否看到网络上实际存在的内容。如果没有它，无声的错过报道看起来就像“该策略没有找到机会”。
• WSS 重新连接风暴会擦除订阅状态。 一些提供商每 30-60 分钟重置一次连接以实现负载平衡。如果您的订阅者在重新连接时没有重播订阅，您将一次错过几秒钟。
• 热路径上的 JSON 解析。 完整待处理 tx 信封的简单 JSON.parse 会增加每个事件的毫秒数。仅提取您需要的字段（到/从/值/数据前缀）的流解析器可以以峰值速率实时保存。
• 跨区域订阅悄然将边缘减半。 从 us-east 故障转移到 ap-southeast 的“冗余”设置每个方向都会增加 100+ 毫秒。针对延迟发出警报，而不仅仅是针对硬故障发出警报。
• 未经验证就信任某个提供商的覆盖范围。 特别是在 BSC 上，一些商业提供商的弱对等节点会默默地滞后。定期交叉检查。

工作配置

最小可行内存池订阅者：

1. 两个并行的 WSS 订阅（提供商 A + 提供商 B），用于交叉覆盖验证。
2. 过滤器设置：池白名单+值楼层+路由器白名单。热路径上没有更深层次的过滤。
3. 状态作为本地镜像维护，从 WSS 流本身更新，而不是每次交易重新获取。
4. 每天持续对每个阶段进行百分位数的延迟分析。
5. 重新连接重播逻辑，在断开连接后 200 毫秒内重新订阅。

FRB Agent 默认实现所有这些；无论如何，对于自建系统重要的部分是相同的。

参考

• Reth WSS 订阅指南
• Arbitrum 排序器 Feed
• WSS 延迟测试工具