Solana Anti-MEV 三明治被夹保护:完整指南

Q: MEV-blocker 跟私有 RPC 有什么区别?

MEV-blocker 用经济问责层(MEV 被抽取了就退款);私有 RPC 是首先就不暴露交易。两者都有效;后者协调成本更低。

如果你在 Solana 上交易或做开发,而你的交易在被打包前还在公共 mempool 里看得见,你就在被定价。整个 DeFi 因为 MEV(Maximal Extractable Value,最大可提取价值)损失的金额按 10 亿美金计。Solana 上,主要的攻击向量是三明治:机器人前置你的交易,等你执行,然后后置回收价格冲击——这就是俗称的"被夹"。

这篇我们讲 Solana 上 MEV 是什么样的、真正有效的保护模式、以及 MEV-blocker / 批量拍卖 / 原生 RPC 几种方案在实战中的差别。目的是让你心里有底,能根据自己在做的事挑对保护方式。

MEV 是什么,具体到 Solana 上

MEV 是拥有交易排序权的角色能在标准手续费之外抽取的价值。在有公共 mempool 的链(以太坊、BSC)上,这发生在 mempool 这一层——机器人看到 pending 交易并重排。

Solana 不一样。Solana 没有传统意义上的公共 mempool——交易直接发给排定要出下一块的 validator。但这不代表 Solana 没有 MEV。暴露点只是位置变了:

Validator 端排序:出块的 validator 可以在自己的 slot 内重排交易
RPC 端观察:RPC 服务商在转发前看到交易。恶意或被攻陷的 RPC 可能泄露
打包前可见性:通过某些路径广播的交易在落块前对机器人可见,允许前置

对交易者来说,实际影响跟以太坊一样:你的交易被夹、你付的滑点比应该的多、差额进了机器人钱包。

三明治攻击:实际是怎么发生的

Solana 上一次三明治攻击长这样:

你通过 DEX 提交一笔 100 SOL 换某 memecoin 的 swap
三明治机器人侦测到这笔 pending swap
机器人前置你:先买同样的 memecoin、把价格推高
你的 swap 在被推高的价格上执行
机器人后置你:立刻卖出,吃掉你刚刚创造的价格冲击

你拿到的代币比提交时 AMM 数学应该给你的少。机器人拿走差额,扣掉它自己的手续费。

成交量很大。任何没有保护的 DEX 应用都在给这数据贡献。

MEV 保护的几种模式

有几种主流模式,各有取舍。

1. 私有 mempool / 私有 RPC 路由

交易完全不进公共路径。从你的客户端到一个私有端点,端点在没有中间可见性的情况下完成上链投递。这是最直接的缓解方式:机器人看不到的,前置不了。

这就是 BoltTx 用的模式。每一笔通过我们端点路由的交易,在投递时都不暴露在打包前的观察面上。不是独立产品、不需要 opt-in、不需要额外集成——就是默认路径。

2. MEV-blocker 模式

MEV-blocker 是一种文档化的模式(最早在以太坊上),RPC 通过同意不前置的搜索者路由交易,并在搜索者抽取了 MEV 时退款给用户。Solana 版本没那么标准化,但底层思路——RPC 这一层带经济问责的反前置——正在被采纳。

如果你在搜 mev-blocker rpc docs 或更广义的 MEV-blocker 生态,看到的主要是以太坊上的引用。底层原则(带经济问责的 RPC 层保护)是 BoltTx 在 Solana 上原生提供的——你不需要去评估单独的搜索者经济。

3. 批量拍卖

批量拍卖是另一种 MEV 保护思路:订单在一个时间窗口内收集、在一次结算里统一匹配,三明治的尝试就被中和了——因为根本没有单笔交易可以拿来前置。

这种模式以太坊上有些 DEX 在用,Solana 上目前没有同等规模的直接对应,但也有几个 Solana DEX 在探索类似机制。对交易者的实际意义是:链不一样,以太坊上有效的方案不一定能直接搬过来。

4. 前端层 Anti-MEV(交易终端自带)

一些 Solana 交易终端会在自己的交易流里捆绑一层 MEV 保护。这种保护只在你完全通过那个终端交易时有效。一旦你通过其他路径提交交易,保护就被绕过了。

对 dApp 开发者来说,这其实是对用户的一个硬约束——你没法强制每个用户都通过你指定的前端来交易。所以保护必须做在 RPC 这一层。

哪种模式适合谁

模式	最适合	取舍
私有 RPC 路由(BoltTx 这种)	dApp、机器人、AI agent——任何程序化提交	需要使用特定 RPC
MEV-blocker	有成熟搜索者经济的生态	Solana 上的实现不如以太坊成熟
批量拍卖	从零搭的 DEX	实现成本高;不可移植
前端层(交易终端自带)	被锁在某个交易 UI 里的终端用户	用户跑去别处就没保护了

对今天大多数发布 Solana 应用的开发者来说,现实选择是:通过原生 Anti-MEV 的 RPC 路由交易。这是集成成本最低、杠杆最高的选项。

"原生 Anti-MEV"在实战中的含义

我们说 BoltTx 用原生 Anti-MEV 路由,具体意味着:

提交到 https://bolttx.io/?api-key=... 的交易不暴露在机器人扫描的公共观察面上
默认路径就是受保护的路径。没有"MEV 模式"开关让你忘记打开
这适用于每一笔交易——DEX swap、NFT mint、代币转账、自定义程序调用

这跟你发任何交易用的是同一份代码路径。你完全不用想 MEV——保护是路由的一部分。

import { Connection } from "@solana/web3.js";

const connection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

// 这次 sendTransaction 自动以 Anti-MEV 保护路由
const signature = await connection.sendTransaction(tx, signers, {
  skipPreflight: true,
  maxRetries: 0,
});

整个集成就这样。没有"启用 MEV 保护"这个参数,因为没有不带保护的版本。

什么时候 MEV 保护最重要

对自己的负载诚实点。不是每笔交易都需要 MEV 保护。

绝对需要保护:

DEX swap(任何 token 到 token 的交易)
AMM 流动性提供与移除
套利路径
竞争性 mint 中的 NFT mint
任何交易机器人或做市策略
代币发行和预售

可能不需要保护:

钱包间的简单 SOL 转账
链上状态读取(没有交易)
账户创建
给 validator stake / unstake(很少能被夹)

如果你的应用在第一类里,RPC 这一层的 Anti-MEV 就是你成本结构的一部分,不管你记不记账。不如把它显式化、选一个能把这件事做对的服务商。

这周可以做什么

不论你最后用不用 BoltTx,我们建议的实战顺序:

审计当前交易流。 识别哪些交易有 MEV 敞口(尤其是 DEX swap)
量化成本。 看历史交易,估算可归因于被夹的滑点。Solana 上有工具帮你做这个
选一层保护。 对大多数开发者来说,RPC 层的原生 Anti-MEV 是杠杆最高的选项
用真实流量测试。 免费档够用来验证集成是否生效
持续监测。 切完之后继续量滑点和被夹发生率

试一下 BoltTx 做三明治被夹保护

不想去评估搜索者经济或批量拍卖实现、又想要原生 Anti-MEV——BoltTx 就是改一个 URL 的事:

const connection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

免费档注册,跟你现在用的任何路径并行做基准对比。如果你的被夹敞口明显下降,答案就有了。

常见问题

Solana 有公共 mempool 吗? 传统意义上没有。交易直接发给下一个排定的 validator。但暴露面仍然存在——通过 RPC 端观察和打包前可见性——这就是 Anti-MEV 解决方案处理的事。

Anti-MEV 等同于前置保护吗? 前置是 MEV 的一种形式。Anti-MEV 保护涵盖前置、三明治、后置。

MEV-blocker 跟私有 RPC 有什么区别? MEV-blocker 用经济问责层(MEV 被抽取了就退款);私有 RPC 是首先就不暴露交易。两者都有效;后者协调成本更低。

能在现有 Helius / QuickNode 集成上加 Anti-MEV 保护吗? Helius 和 QuickNode 都有各自的 MEV 保护实现,但通常作为独立产品、要主动配置。BoltTx 默认就用 Anti-MEV 路由所有交易,不需要单独路径。

Anti-MEV 额外收费吗? 看服务商。BoltTx 把它内置在默认 tip-based 计费里——没有单独的"Anti-MEV 费"。