如何让 Solana 交易亚秒级上链

Solana 的 400ms 出块时间纸面上很快。但实际上,大多数 app 的端到端延迟都在 1.5–3 秒——因为请求要经过完整的网络链路。这篇文章讲清楚原因,以及你实际能做什么。

真实延迟链路

当你调用 sendTransaction,从代码到链上确认要经历这些环节:

1. 客户端 → RPC — HTTPS 请求穿越公网
2. RPC → 网络 — RPC 节点把交易提交进 Solana 网络
3. 块生产 — validator 把交易打包进块
4. 块 → 确认 — 集群投票确认

每一层都有延迟。前两层是 80% 时间消耗的地方,也是你实际能优化的地方。

为什么大多数项目都慢

三个常见问题。

1. RPC 距离过远

如果你的客户端和 RPC 节点在公网上隔得太远,每笔交易都要走一次很长的来回。光速是物理上限,软件无法解决。选一个基础设施离你的流量更近的 RPC,或者直接选一个内部帮你处理路由的 RPC,这样你完全不用操心。

2. TCP 连接复用错误

每个交易创建新 HTTPS 连接?每次都要付 ~100ms 的 TLS 握手成本。启用 HTTP keepalive,让一个连接复用几千次发送。

Node.js (web3.js v1) 写法——用 undici agent 复用连接:

import { Connection } from "@solana/web3.js";
import { Agent, fetch as undiciFetch } from "undici";

// 全局 keep-alive agent,跨调用复用 TCP/TLS 连接
const agent = new Agent({
  keepAliveTimeout: 30_000,
  keepAliveMaxTimeout: 600_000,
});

const connection = new Connection("https://bolttx.io/?api-key=YOUR_KEY", {
  commitment: "processed",
  fetch: (url, init) => undiciFetch(url, { ...init, dispatcher: agent }),
});

浏览器环境 keep-alive 由浏览器自己管,你不用配。HTTP 层完整调优看 Keep-Alive 和连接池指南。

3. skipPreflight 用错了

// 慢 — preflight 在发送前做完整模拟
await connection.sendTransaction(tx, signers);

// 快 — 跳过模拟,节省 ~100ms
await connection.sendTransaction(tx, signers, {
  skipPreflight: true,
  maxRetries: 0,
});

如果你信任自己的交易(自己构建、自己签名、知道会成功),跳过 preflight 能省 ~100ms。错误自己处理就行。完整权衡见 skipPreflight 详解。

怎么测延迟才靠谱

优化之前先把数字测准——不要用冷启动的营销延迟。

别只看平均值。 平均延迟会藏掉尾部表现;对交易类负载来说,尾部才是要命的地方。要分别跟踪 P50、P95、P99。一个机器人平均 400ms 但 P95 是 2.5 秒,大部分机会还是会错过。

别只测单次调用。 一次 ping 说明不了任何问题。要跑一个持续负载(比如一小时几百笔,理想情况是在拥堵期间),然后看分布。

端到端测,不要只测 HTTP round-trip。 你真正关心的是"从 sendTransaction 到上链",不是"RPC 多快收下我的请求"——这是两个数。

简单的测量代码:

const start = Date.now();
const sig = await connection.sendTransaction(tx, signers, {
  skipPreflight: true,
  maxRetries: 0,
});
const submittedMs = Date.now() - start;

const status = await connection.confirmTransaction(
  { signature: sig, blockhash, lastValidBlockHeight },
  "confirmed"
);
const totalMs = Date.now() - start;

logger.info({ sig, submittedMs, totalMs, slot: status.context.slot });

每笔交易记录时间,事后离线算百分位。完整方法论看 RPC benchmark 指南。

Tip 和 Priority fee:让交易真正上链的两个杠杆

延迟优化只解决了一半。另一半是拥堵下也能上链,这取决于两笔互相独立的费用:

Priority fee 是 Solana 协议层的链上 gas fee。 给得明显高于当前网络平均水平,你的交易会被推到打包队列前列;给 0 在繁忙网络下基本等于 blockhash 过期失败。

BoltTx tip 是你给 BoltTx 的小费——你给得越多,你的交易在 BoltTx 的提交侧优先级越高、上链越快。只在交易真上链时才扣;失败发送在 BoltTx 这边不收钱。

两个独立。一起调好,上链速度才最快:

• 高 priority fee + 没给 BoltTx tip = 链上队列前列,但提交是常规优先级
• 高 BoltTx tip + 没设 priority fee = 提交侧优先,但链上队列没占到先
• 两个都明显高于基线 = 两层都吃到红利

如何按预期利润动态调 priority fee(而不是每次都最大值)看 Priority fee 指南。

BoltTx 在生产环境的实际表现

对于跨境客户端的典型 Raydium swap,我们生产环境稳定看到的延迟画像:

实际数据受客户端地理位置、交易复杂度、链上拥堵程度影响。我们建议你在自己的真实交易场景下做基准测试——那才是对你最有意义的数据。

主要优化点:

• 单一全球入口 + 内部智能路由——你不用挑区域、不用做基础设施决策
• 专属 SWQoS + 优先级连接,所有套餐都包含——拥堵下也能优先获得上链能力
• 原生 Anti-MEV 防止交易被抢跑。为什么这件事对生产代码重要,看 Anti-MEV 三明治被夹保护完整指南。

这周该做什么

如果你在做 Solana 应用、关心延迟,按这个顺序优化:

1. 测你当前的 P95,不要只看平均值。平均值掩盖长尾。
2. 选一个基础设施离客户端更近的 RPC(或者一个内部帮你处理路由的 RPC)。评估标准看 交易机器人对 RPC 的要求。
3. 启用 HTTP keepalive。
4. 热路径上试 skipPreflight: true。
5. 设 maxRetries: 0 并自己处理重试。完整 sendTransaction 实战看 最佳实践。
6. Priority fee 和 tip 一起调好。 单独调任何一个都不够应对真实拥堵。

试用 BoltTx

如果你想要亚秒级确认但又不想自己操心这些细节,注册 BoltTx,把现有代码里的一个 URL 换掉:

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

就这么简单。你现有的 sendTransaction 调用立刻通过 BoltTx 投递——单一全球入口、内部智能路由、亚秒级确认、原生 Anti-MEV。无需选区域、无需运维基础设施。

延伸阅读

• Solana sendTransaction 最佳实践
• Solana Priority Fee 详解:什么时候付、付多少、为什么
• Anti-MEV 三明治被夹保护完整指南
• 交易机器人对 RPC 的要求
• 怎么 Benchmark Solana RPC 服务商
• BoltTx 文档