Solana MEV 大战：读懂博弈，守住你的 Alpha

Mr.RC
发布于 7小时前
阅读 71

本文由Solana节点聚合器&数据供应商Astralane提供技术支持过去30天里，被提取的MEV超过12,000枚SOL，发生了145,000+次攻击，受害地址59,000+。三明治攻击在Solana上几乎无处不在，平均每小时至少100个受害者、全天不停。在A

*本文由Solana节点聚合器&数据供应商Astralane提供技术支持*

过去 30 天里，被提取的 MEV 超过 12,000 枚 SOL，发生了 145,000+ 次攻击，受害地址 59,000+。
三明治攻击在 Solana 上几乎无处不在，平均每小时至少 100 个受害者、全天不停。

![1_T5aVVJKAXn6L0rA4hK-VCQ.webp](https://img.learnblockchain.cn/attachments/2025/09/j5g6hkF668cd737a93e45.webp)

在 Astralane，我们正在研发新功能来保护你的交易免遭三明治和抢跑，同时也想把可操作的反制方法讲清楚，帮助交易者或机器人用户显著降低被 MEV“收割”的概率。
跟着我们一起，深挖 Solana 上的 MEV 全景。

![1_TctLtpYKI7tXHNrZEdvGtg.webp](https://img.learnblockchain.cn/attachments/2025/09/8AwWVUGl68cd73d98f86e.webp)

# 1. 三明治、交易排序与验证者行为
## 三明治攻击
三明治攻击通常包含三步：（1）捕捉到一个足够大的、足以推动 AMM 价格的待执行用户换汇；（2）在它之前插入买单（front-run，前置交易）把价格抬上去；（3）在它之后插入卖单（back-run，后置交易）吃掉价差。

![1_RszeCbrgsBDOYycxq8HRBw.webp](https://img.learnblockchain.cn/attachments/2025/09/rjIAwhBh68cd740094276.webp)

**紧凑三明治（Tight Sandwiching）**：通过私有订单流或区块引擎，把“前置-受害者-后置”三腿原子性地打包在同一个槽位里执行。常用私有中继或 Jito 的区块引擎做原子打包。

**宽松三明治（Wide Sandwiching）**：前置与后置不打包，彼此间隔 50–300ms 独立发送，赌的是时机与滑点，只要第一腿成功就能吃到受害者滑点空间。

![1_5OqtEcLhZW2_znssj4_2gQ.webp](https://img.learnblockchain.cn/attachments/2025/09/1MUyQxeI68cd7491d20e6.webp)

在区块里，交易的排序对三明治是否盈利至关重要。在 Solana 上，出块者对执行顺序拥有最终决定权；如果轮到的 leader（或能向 leader 输送私有交易的人）想要三明治某笔交易，他们拥有很强的控制力。

### a. 验证者如何做 MEV
验证者之所以能做三明治，是因为他们在自己担任 slot leader 时具备天然优势。不同于以太坊的公开 mempool，Solana 的散户对“有哪些交易被提交”并不透明。但 leader 能通过 QUIC/Turbine 在交易最终确认之前，直接收到来自中继/RPC 客户端的包。

这给了他们微秒级的视野，能看到用户交易的参数细节。验证者可以在受害者 swap 前插入自家的买单，因为其控制区块内排序，这笔一定会先执行；受害者 swap 完成后，再插入自家的卖单。通常这两腿会以原子方式被塞进同一个区块里，从而确保无风险地吃到差价。

### b. 如何识别恶意验证者
在 Solana 上识别恶意验证者尤其困难：没有意图证明（proof-of-intent），没有强制排序规则，你也无法知道验证者“收了哪些、丢了哪些、怎么重排的”。但可以用下面这份教科书式的核对清单，排查可疑对象：

i) 要求付费购买 bundle 优先级、或付费加入其私有订单流；
ii) 没有社媒存在、官网、运营者信息；
iii) 在 Stakewiz 或 Keybase 搜该公钥一无所获；
iv) 去 Jito Dashboard 比较其平均小费（tips）收入，如果异常之高，很可能在打包 MEV；
v) 在 Solflare 上，地址旁有警示符号；
vi) 其委托（stake）在短时间内突然暴增。到 Solana Compass 的 “Stake Over Time” 看看，如果在极短时间发生了可疑的大幅增长，需格外当心。

![1_koNcZsE0JkFWiTdpol2IWg.webp](https://img.learnblockchain.cn/attachments/2025/09/hB8Pw5Bn68cd74f2b5e82.webp)

接着，借助 sandwiched.me 这类工具识别“三明治率”异常高的验证者。这通常意味着该验证者要么亲自下场，要么与第三方合谋做 MEV。

开源仓库 a-guard/malicious-validators 也提供了方法：如何判断某笔交易是否遭遇三明治、进而研判对应的验证者是否恶意。

![1_tUJvYzPdPqfP1Pds4TOF7Q.webp](https://img.learnblockchain.cn/attachments/2025/09/e8MUWrv568cd7579e69cf.webp)

另外，还可以查看这些恶意验证者主要从哪些质押池接收委托，以评估风险集中度。

![1_PM3_JVSw1Ztx6QfaS4GI-Q.webp](https://img.learnblockchain.cn/attachments/2025/09/Q6LNzgIX68cd7596ea9f3.webp)

### c. 验证者为什么要三明治？
因为这显著提高了他们的经济回报，远超基础的质押收益；同时这也“顺应了 Solana 的架构”，即 leader 对交易排序拥有更强的控制力。与 Jito 这样的工具结合，配合可预测的出块领导权与私有排序通道，MEV 的 ROl 非常可观，许多验证者已经在吃这块蛋糕。

![1_hNXEDEMiq1THYAY0eOkz6Q.webp](https://img.learnblockchain.cn/attachments/2025/09/tAtE9mlP68cd797480904.webp)

# 2. 三明治的后果
## a. 对散户的影响
- **价格更差、隐形亏损**：前后脚被插单，成交价更糟，长期反复亏损但很难把原因追溯到 MEV。
- **额外保护成本**：很多用户会付费（比如给 Jito）走私有打包以规避三明治机器人。有报告显示，每周用于此类保护的费用超过 50,000 枚 SOL。
- **错配的交易参数**：不少散户误以为“放宽甚至去掉滑点限制”能换来更快成交，结果反而成了机器人的“理想猎物”。

解决办法不是简单苛责用户或应用，而是：改进默认参数、教育交易者、以及在不同市场环境下提供更有引导性的设置。

## b. 对生态的影响
高比例的散户“被提取”，会把流动性赶向那些被认为“更公平”或“MEV 保护更强”的链；与此同时，MEV 利润集中在少数验证者、搜索者和私有流量区块引擎手里，放大了中心化风险。这种利润不对称还会扭曲验证者激励，促使 leader 优先处理私有 MEV bundle，而不是公平、自然的订单流。长期看，这会削弱去中心化程度、竞争力与网络健康。

# 3. MEV 保护
## a. jitodontfront
在你的 Solana 交易里，往任意一条指令里附加一个以“jitodontfront”开头的、合法的 Solana 公钥。
如果某个 bundle 里包含一笔带有 jitodontfront 账户的交易，那么区块引擎只会在该交易排在 bundle 的第一个位置（index 0）时才接受该 bundle。未包含该标记的交易或 bundle 不受影响。

![1_dnfh1pkmvn1SULLSntpfJA.webp](https://img.learnblockchain.cn/attachments/2025/09/QzSnhBmn68cd7c3637c65.webp)

```js
如何把它加进你的交易：
import { Transaction, SystemProgram, PublicKey } from "@solana/web3.js";
const sentinel = new PublicKey("jitodontfront111111111111111111111111111111");
// 构造你的正常指令（例如 DEX swap）
 const swapIx = /* your DEX swap instruction here */;
// 将 sentinel 作为额外的账户元数据附加到任意指令
 swapIx.keys.push({ pubkey: sentinel, isSigner: false, isWritable: false });
const tx = new Transaction().add(swapIx);
// 通过 Jito Block Engine 发送（bundleOnly 或 sendBundle）
```

- **对同一 bundle 内“紧凑三明治”的原子夹击有较好防护**：jitodontfront 阻止被塞在 bundle 中间。

- **无法阻止“宽松三明治”或 bundle 外的前置交易**：如果攻击者通过其他路径观测到你的交易（非 Jito 中继、声明泄露、公共 RPC），或提交一笔竞争交易在 Jito 之外的 leader 处先到达，仍可发动攻击。实务中，jitodontfront 普及后，观测到的攻击从“紧凑”明显转向“宽松”。

## b. Yellowstone Shield
Yellowstone Shield 是一个用于在链上维护地址白/黑名单的 Solana 程序。发送方或中间件可以在交易里声明：“只把我的交易转发给这份白名单里的验证者”，或相反“绝不转发给这份黑名单”。

借助 Shield，RPC 会结合 Solana 的 leader 排班（leader schedule），只有当当前 leader 符合策略时才发送；若当前 leader 未通过校验，就暂存，等到下一个可信的 leader 再发。这样可以避免你的交易暴露给“不信任”的验证者。

Yellowstone Shield 通过以下方式集成到 RPC：

- 在 sendTransaction RPC 新增 forwardingPolicies 参数，允许用户指定白/黑名单；

- 兼容旧客户端的可选 HTTP 头：Solana-ForwardingPolicies。

```js
use yellowstone_shield_store::{PolicyStoreConfig, PolicyStore};
let local = tokio::task::LocalSet::new();
// 策略存储配置
 let config = PolicyStoreConfig::default();
// 构建策略存储并订阅增量更新
 let policy_store = PolicyStore::build()
 .config(config)
 .run(&local)
 .await?;
// 模拟验证者与策略地址
 let validator = Pubkey::new_unique();
 let policy = Pubkey::new_unique();
// 获取最新快照
 let snapshot = policy_store.snapshot();
// 校验该验证者是否被策略允许
 match snapshot.is_allowed(&[policy], &validator) {
 Ok(true) => println!("Validator is allowed."),
 Ok(false) => println!("Validator is denied."),
 Err(e) => println!("Error checking policy: {:?}", e),
 }
```

## c. TPU 白名单化
TPU 是验证者负责出块的“交易处理单元”。leader 通过 QUIC 接收来自中继/RPC 客户端的交易包，校验签名，进入银行阶段（banking stage），产出 entries。谁能决定“哪些交易优先抵达 TPU”，谁就能掌控对抗抢跑的第一道防线。SWQoS（Stake-Weighted QoS，按质押权重的服务质量）允许 RPC 提供商和中继优先与 leader 的 TPU 端口建立对等连接，并按质押权重限制连接/流数量——高质量流量优先转发到 leader，而低质押、疑似垃圾的发送方被限流。这本质上就是“TPU 白名单化”（只有表现良好/有质押的对等方才能获得稳定的 QUIC 流）。

工程上通过对等连接配置（如 --rpc-send-transaction-tpu-peer 等）、QUIC 会话限额，以及 RPC/中继机器上的路由决策来实现。

现在不少企业级 RPC 会把“MEV 保护 + 质押加权 QoS”作为卖点能力。它们通过路由与分发混淆，降低 MEV 暴露。如果你是钱包/机器人用户，这是最简单的第一步：选择具备 SWQoS/MEV 保护的 RPC。

## d. Astralane 的 MEV Protect
我们正在开发一项功能，以保护你的交易免遭三明治与抢跑。启用非常简单：用现有的 sendTransaction 接口，加一个字段即可。

如何使用：调用 sendTransaction 时，加入名为 "mevProtect" 的布尔字段。

```js
{
 "id": 1,
 "jsonrpc": "2.0",
 "method": "sendTransaction",
 "params": [
 "base64_encoded_txn1",
 {
 "encoding": "base64",
 "skipPreflight": true
 },
 {
 "mevProtect": true
 }
 ]
 }
```
**可用端点：**

```js
<http\://fr.gateway.astralane.io/iris?api-key=xxxx>
 （也支持 HTTPS）
```

**工作原理：**

启用后，我们会将当前 Solana leader 与自定义的“风险验证者名单”进行比对（阈值可定制）；
如果当前 leader 判定为不安全，我们会暂缓发送，等到可信的 leader 接棒再发。

**更多信息请查阅文档：** https://astralane.gitbook.io/docs/low-latency/submit-transactions

# 结语
在快速演进的 Solana 生态里，MEV 保护已经从“可选项”变成“必需品”。这不仅是为了保护用户的每一笔交易，也是为了守住市场的公平性与完整性。

**答案很清楚：性能与保护，必须协同进化，Solana 的未来才会既安全又去中心化。**

如果你是机器人开发者，想要使用自定义的“风险标记”、灵活阈值、不同的黑名单策略，欢迎随时联系我们。

也欢迎加入我们的 Discord，与交易员、建设者、开发者一起讨论 Solana 上的“公平执行”未来（如果超链接失效，请使用此邀请链接加入： https://discord.gg/N4MvNqSARc ）。

# 参考资料
https://sandwiched.me/research/state-of-solana-mev-may-2025-analysis
https://www.helius.dev/blog/solana-mev-an-introduction
https://blog.triton.one/introducing-yellowstone-shield
https://www.quicknode.com/guides/solana-development/defi/mev-on-solana
https://docs.jito.wtf/lowlatencytxnsend/#sandwich-mitigation
https://anarcaze.medium.com/spotting-shady-validators-on-solana-a-friendly-guide-f39ef8b32a00

本文由Solana节点聚合器&数据供应商Astralane提供技术支持

过去 30 天里，被提取的 MEV 超过 12,000 枚 SOL，发生了 145,000+ 次攻击，受害地址 59,000+。三明治攻击在 Solana 上几乎无处不在，平均每小时至少 100 个受害者、全天不停。

在 Astralane，我们正在研发新功能来保护你的交易免遭三明治和抢跑，同时也想把可操作的反制方法讲清楚，帮助交易者或机器人用户显著降低被 MEV“收割”的概率。跟着我们一起，深挖 Solana 上的 MEV 全景。

1. 三明治、交易排序与验证者行为

三明治攻击

三明治攻击通常包含三步：（1）捕捉到一个足够大的、足以推动 AMM 价格的待执行用户换汇；（2）在它之前插入买单（front-run，前置交易）把价格抬上去；（3）在它之后插入卖单（back-run，后置交易）吃掉价差。

紧凑三明治（Tight Sandwiching）：通过私有订单流或区块引擎，把“前置-受害者-后置”三腿原子性地打包在同一个槽位里执行。常用私有中继或 Jito 的区块引擎做原子打包。

宽松三明治（Wide Sandwiching）：前置与后置不打包，彼此间隔 50–300ms 独立发送，赌的是时机与滑点，只要第一腿成功就能吃到受害者滑点空间。

a. 验证者如何做 MEV

验证者之所以能做三明治，是因为他们在自己担任 slot leader 时具备天然优势。不同于以太坊的公开 mempool，Solana 的散户对“有哪些交易被提交”并不透明。但 leader 能通过 QUIC/Turbine 在交易最终确认之前，直接收到来自中继/RPC 客户端的包。

b. 如何识别恶意验证者

在 Solana 上识别恶意验证者尤其困难：没有意图证明（proof-of-intent），没有强制排序规则，你也无法知道验证者“收了哪些、丢了哪些、怎么重排的”。但可以用下面这份教科书式的核对清单，排查可疑对象：

i) 要求付费购买 bundle 优先级、或付费加入其私有订单流； ii) 没有社媒存在、官网、运营者信息； iii) 在 Stakewiz 或 Keybase 搜该公钥一无所获； iv) 去 Jito Dashboard 比较其平均小费（tips）收入，如果异常之高，很可能在打包 MEV； v) 在 Solflare 上，地址旁有警示符号； vi) 其委托（stake）在短时间内突然暴增。到 Solana Compass 的 “Stake Over Time” 看看，如果在极短时间发生了可疑的大幅增长，需格外当心。

接着，借助 sandwiched.me 这类工具识别“三明治率”异常高的验证者。这通常意味着该验证者要么亲自下场，要么与第三方合谋做 MEV。

开源仓库 a-guard/malicious-validators 也提供了方法：如何判断某笔交易是否遭遇三明治、进而研判对应的验证者是否恶意。

另外，还可以查看这些恶意验证者主要从哪些质押池接收委托，以评估风险集中度。

c. 验证者为什么要三明治？

因为这显著提高了他们的经济回报，远超基础的质押收益；同时这也“顺应了 Solana 的架构”，即 leader 对交易排序拥有更强的控制力。与 Jito 这样的工具结合，配合可预测的出块领导权与私有排序通道，MEV 的 ROl 非常可观，许多验证者已经在吃这块蛋糕。

2. 三明治的后果

a. 对散户的影响

价格更差、隐形亏损：前后脚被插单，成交价更糟，长期反复亏损但很难把原因追溯到 MEV。
额外保护成本：很多用户会付费（比如给 Jito）走私有打包以规避三明治机器人。有报告显示，每周用于此类保护的费用超过 50,000 枚 SOL。
错配的交易参数：不少散户误以为“放宽甚至去掉滑点限制”能换来更快成交，结果反而成了机器人的“理想猎物”。

解决办法不是简单苛责用户或应用，而是：改进默认参数、教育交易者、以及在不同市场环境下提供更有引导性的设置。

b. 对生态的影响

高比例的散户“被提取”，会把流动性赶向那些被认为“更公平”或“MEV 保护更强”的链；与此同时，MEV 利润集中在少数验证者、搜索者和私有流量区块引擎手里，放大了中心化风险。这种利润不对称还会扭曲验证者激励，促使 leader 优先处理私有 MEV bundle，而不是公平、自然的订单流。长期看，这会削弱去中心化程度、竞争力与网络健康。

3. MEV 保护

a. jitodontfront

在你的 Solana 交易里，往任意一条指令里附加一个以“jitodontfront”开头的、合法的 Solana 公钥。如果某个 bundle 里包含一笔带有 jitodontfront 账户的交易，那么区块引擎只会在该交易排在 bundle 的第一个位置（index 0）时才接受该 bundle。未包含该标记的交易或 bundle 不受影响。

如何把它加进你的交易：
import { Transaction, SystemProgram, PublicKey } from "@solana/web3.js";
const sentinel = new PublicKey("jitodontfront111111111111111111111111111111");
// 构造你的正常指令（例如 DEX swap）
 const swapIx = /* your DEX swap instruction here */;
// 将 sentinel 作为额外的账户元数据附加到任意指令
 swapIx.keys.push({ pubkey: sentinel, isSigner: false, isWritable: false });
const tx = new Transaction().add(swapIx);
// 通过 Jito Block Engine 发送（bundleOnly 或 sendBundle）

对同一 bundle 内“紧凑三明治”的原子夹击有较好防护：jitodontfront 阻止被塞在 bundle 中间。
无法阻止“宽松三明治”或 bundle 外的前置交易：如果攻击者通过其他路径观测到你的交易（非 Jito 中继、声明泄露、公共 RPC），或提交一笔竞争交易在 Jito 之外的 leader 处先到达，仍可发动攻击。实务中，jitodontfront 普及后，观测到的攻击从“紧凑”明显转向“宽松”。

b. Yellowstone Shield

Yellowstone Shield 是一个用于在链上维护地址白/黑名单的 Solana 程序。发送方或中间件可以在交易里声明：“只把我的交易转发给这份白名单里的验证者”，或相反“绝不转发给这份黑名单”。

Yellowstone Shield 通过以下方式集成到 RPC：

在 sendTransaction RPC 新增 forwardingPolicies 参数，允许用户指定白/黑名单；
兼容旧客户端的可选 HTTP 头：Solana-ForwardingPolicies。

use yellowstone_shield_store::{PolicyStoreConfig, PolicyStore};
let local = tokio::task::LocalSet::new();
// 策略存储配置
 let config = PolicyStoreConfig::default();
// 构建策略存储并订阅增量更新
 let policy_store = PolicyStore::build()
 .config(config)
 .run(&local)
 .await?;
// 模拟验证者与策略地址
 let validator = Pubkey::new_unique();
 let policy = Pubkey::new_unique();
// 获取最新快照
 let snapshot = policy_store.snapshot();
// 校验该验证者是否被策略允许
 match snapshot.is_allowed(&[policy], &validator) {
 Ok(true) => println!("Validator is allowed."),
 Ok(false) => println!("Validator is denied."),
 Err(e) => println!("Error checking policy: {:?}", e),
 }

c. TPU 白名单化

TPU 是验证者负责出块的“交易处理单元”。leader 通过 QUIC 接收来自中继/RPC 客户端的交易包，校验签名，进入银行阶段（banking stage），产出 entries。谁能决定“哪些交易优先抵达 TPU”，谁就能掌控对抗抢跑的第一道防线。SWQoS（Stake-Weighted QoS，按质押权重的服务质量）允许 RPC 提供商和中继优先与 leader 的 TPU 端口建立对等连接，并按质押权重限制连接/流数量——高质量流量优先转发到 leader，而低质押、疑似垃圾的发送方被限流。这本质上就是“TPU 白名单化”（只有表现良好/有质押的对等方才能获得稳定的 QUIC 流）。

工程上通过对等连接配置（如 --rpc-send-transaction-tpu-peer 等）、QUIC 会话限额，以及 RPC/中继机器上的路由决策来实现。

d. Astralane 的 MEV Protect

我们正在开发一项功能，以保护你的交易免遭三明治与抢跑。启用非常简单：用现有的 sendTransaction 接口，加一个字段即可。

如何使用：调用 sendTransaction 时，加入名为 "mevProtect" 的布尔字段。

{
 "id": 1,
 "jsonrpc": "2.0",
 "method": "sendTransaction",
 "params": [
 "base64_encoded_txn1",
 {
 "encoding": "base64",
 "skipPreflight": true
 },
 {
 "mevProtect": true
 }
 ]
 }

可用端点：

&lt;http\://fr.gateway.astralane.io/iris?api-key=xxxx>
 （也支持 HTTPS）

工作原理：

启用后，我们会将当前 Solana leader 与自定义的“风险验证者名单”进行比对（阈值可定制）；如果当前 leader 判定为不安全，我们会暂缓发送，等到可信的 leader 接棒再发。

更多信息请查阅文档： https://astralane.gitbook.io/docs/low-latency/submit-transactions

结语

在快速演进的 Solana 生态里，MEV 保护已经从“可选项”变成“必需品”。这不仅是为了保护用户的每一笔交易，也是为了守住市场的公平性与完整性。

答案很清楚：性能与保护，必须协同进化，Solana 的未来才会既安全又去中心化。