Solana SWQoS:为什么同样的代码,你的端点上链率不一样

Q: 质押要多少 SWQoS 才有用?

没有公开的门槛值,而且它的效果是成比例的,不是断崖式的 —— 质押越多,拿到的验证节点容量份额越大。实际操作上该看的是拥堵时段的上链率对比,而不是去追某个具体的质押数字。

两个团队跑着一样的代码。重试逻辑一样,getRecentPrioritizationFees 的算法一样,getLatestBlockhash 的处理一样。其中一个在繁忙时段会明显丢交易,另一个不会。

第一反应通常是"代码里肯定有哪里不一样"。但很多时候真的一模一样。

差别在于交易走哪条路到达验证节点。而决定这件事的机制,大多数人在被它坑到之前根本不会想起来 —— 它叫 stake-weighted quality of service。

SWQoS 到底是什么

Solana 验证节点接收转发交易的能力是有限的。当涌进来的比它能处理的多,它必须做取舍。

它不随机选,也不先到先得。它按转发方的质押权重来分配容量:背后质押了大量 SOL 的节点,拿到的份额比质押很少或没有的节点更大。

机制就这么简单。重要的是它带来的后果。

为什么你多半从没注意过它

网络清闲时,验证节点有富余容量。转发过来的全都收,不管是谁转的。零质押的端点和重质押的端点表现完全一致 —— 你这时候跑任何基准测试,结论都是"两家一样"。

区块空间被抢的时候,这个分配才开始起约束作用。从低质押路径过来的交易被接受的比例更低。不是报错拒绝,只是接受得少了 —— 从你这边看,就是交易悄无声息地没上链。

所以 SWQoS 有个很别扭的性质:你测试的时候它是隐形的,而它起决定作用的时候恰好是你最在意的时候。

这也是为什么"我测过两家,表现一样"是个常见但具有误导性的结论。在一个风平浪静的下午跑基准,测的正是 SWQoS 什么都不做的那种情况。

如果费用和 blockhash 都排除了、想测另一条路径,免费领个 BoltTx key 改一行就行。

从你这边看是什么样子

你查不到服务商的质押权重,也不会有任何错误信息告诉你"你被降级了"。你能看到的只是一种模式:

大部分时候上链率正常。
一到新币上线、清算连锁这类拥堵事件,就往下掉。
你的代码没改。费用是实时算的,不是写死的。blockhash 也是新鲜的。
凌晨三点跑同样的代码,一切完美。

平时正常、高负载变差、代码没动 —— 这个特定形状就是它的特征。和其他失败模式对比一下:

原因	什么时候失败
blockhash 过期	任何时段,稳定失败
priority fee 太低	全网费率一涨就失败
没有重试循环	以一个稳定的低比例失败
提交路径 / SWQoS	只在拥堵时

前三种都能在你自己的代码里诊断和修复。所以应该先排除它们 —— 不是因为它们更可能,而是因为排除它们很便宜,而且排完之后剩下的诊断就没有歧义了。

拥堵拉开的是差距,不是整体

这里有个很容易搞错的地方:拥堵不是把所有交易按比例拖慢,它是把分布拉开。

关键的后果是:拥堵不会让每笔交易都同等变慢。大部分不受影响,少数会明显变慢 —— 而低质押路径的问题,恰好就暴露在这少数里。

如果你盯的是平均值,这看起来只是轻微退化。但如果你跑的策略机会窗口只有一两个 slot,你实际生活的正是这少数里。

这也是为什么服务商之间比"平均延迟"意义不大:平均值会趋同,差距不会。

怎么测,而不是猜

质押权重你测不了,但你真正在意的那个东西可以测。

把上链率按网络状况分桶。 按提交时网络有多忙给交易分组,然后对比各组的上链率:

// 拥堵程度的廉价代理指标:看近期 priority fee 什么水平。
const recent = await connection.getRecentPrioritizationFees();
const fees = recent.map((r) => r.prioritizationFee).sort((a, b) => a - b);
const medianFee = fees[Math.floor(fees.length / 2)] ?? 0;

metrics.record("submission", {
  landed: didItLand,
  congestionBucket: medianFee > 50_000 ? "busy" : "calm",
});

两个桶的上链率差不多,那 SWQoS 不是你的问题。如果 busy 桶明显掉下去,而你的费用是实时算的、blockhash 也是新鲜的,那剩下的就是提交路径。

两个端点并排跑,而且要在拥堵时跑。 交替往两边发交易,对比上链率。关键细节:一定要在网络繁忙时做这个对比。 在清闲时段测,测的是"所有路径表现一致"的那种场景 —— 而那根本不是你想评估的场景。

你能做什么

现实地讲有三个选择。

自己跑一个有质押的验证节点。 完全可控,但有实实在在的运维成本。如果你本来就因为别的原因在跑验证节点,这说得通;纯粹为了提升自己的上链率去搭,通常不划算。

用一个背后有足够质押的端点。 你继承它的分配份额。大多数团队走这条路,而且这是改配置,不是搞基础设施项目。

什么都不做,接受这部分损失。 如果你对延迟不敏感,这完全合理。展示余额的钱包、回补历史的索引器、没有截止时间的批处理任务 —— 这些都不在乎。SWQoS 只在"交易时机跟钱挂钩"的时候才重要。

无论选哪个,重要的是先搞清楚自己处在哪种情况。有团队花几周去调滑点容忍度和重试间隔,而这些旋钮根本碰不到真正的问题。

BoltTx 在这里的位置

我们只做一件事:把签好名的交易送进区块。不做索引,不做解析历史,不做 NFT 元数据。就是投递。

提交走我们自建的四区域节点,带 SWQoS 路由,不暴露公共 mempool —— 交易在落块之前没有人能观察到。私钥始终在你手里,我们不托管资金、不代签、不修改交易内容。

定价也是同一套逻辑:你在交易里带一笔 tip,从自己的钱包链上支付;交易 revert 的话 tip 跟着一起 revert —— 这是 Solana 原子交易的机制决定的。只有到达链上的交易才计费。

免费领 API key,没有月费,没有订阅:

// 选离你机器人最近的区域
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");

别听我们说 —— 按上面那个方法,在拥堵时段做一次并排对比。在这件事上,只有那个对比有意义。

常见问题

Solana 的 SWQoS 是什么? stake-weighted quality of service(质押权重服务质量)。当验证节点收到的转发交易超过它的处理能力时,它按每个转发节点的质押权重来分配容量。从高质押路径过来的交易,被接受的比例高于从低质押路径过来的。

为什么我的交易平时都正常,一拥堵就失败? 因为 SWQoS 只在验证节点容量被抢时才起约束作用。容量富余时,转发过来的全都收,跟质押权重无关。区块空间紧张时分配才开始生效,而低质押的提交路径拿到的份额更小 —— 恰好在你最需要它变大的时候。

能查到 RPC 服务商的质押权重吗? 没有公开 API 可以直接查。你能测的是结果:把上链率按网络状况分桶对比。如果清闲时稳定、高负载时下滑,而费用是实时算的、blockhash 也新鲜,那就指向提交路径。

priority fee 给高一点能不能弥补低质押路径? 只能部分弥补。priority fee 影响的是"交易被验证节点接收之后"的排序;SWQoS 影响的是"它有没有被接收进来考虑"。两者作用在不同阶段,所以高费用没法完全替代路径质量。

SWQoS 和 bundle 提交是一回事吗? 不是。SWQoS 讲的是验证节点如何在各个转发节点之间分配接收容量;bundle 提交是另一套机制,用于把交易打包做原子执行、靠 tip 争取收录。一笔交易无论用不用 bundle,都会受 SWQoS 影响。

为什么我测出来两家服务商表现一模一样? 几乎可以肯定是在清闲时段测的。那测的是"所有路径都一样"的情况 —— 验证节点有富余容量,转发过来的全收。换到拥堵时段重测,差别在那里才存在。

SWQoS 会影响 getAccountInfo 这类读取吗? 不会。它管的是验证节点如何接收转发过来的交易,所以只作用于发送。索引、余额查询、历史查询这些读为主的负载完全不受影响 —— 这也是为什么很多团队读用一家、发用另一家。

质押要多少 SWQoS 才有用? 没有公开的门槛值,而且它的效果是成比例的,不是断崖式的 —— 质押越多,拿到的验证节点容量份额越大。实际操作上该看的是拥堵时段的上链率对比,而不是去追某个具体的质押数字。

是不是每个 Solana 项目都该关心 SWQoS? 不是。它只在"交易时机跟钱挂钩"时才重要:套利、狙击、清算、有时间点的 mint。展示余额的钱包、回补数据的索引器永远不会察觉到它。给一个没有截止时间的业务上交易级基础设施,是浪费。

如果我的交易在上新时总是不上链,是不是就一定是 SWQoS? 不一定。先排除三个更便宜的原因:blockhash 过期、费用太低或写死、以及缺少重试循环。这三种在高负载下也会变严重。只有当它们都干净、而失败仍然集中在拥堵时段,SWQoS 才是剩下的那个答案。

SWQoS 是我能配置的东西吗? 不是。它是验证节点侧的行为,取决于替你转发的那一方的质押权重。你只能通过"选择走哪条路提交"来影响它。

SWQoS 对每笔交易都起作用吗? 它规定的是验证节点总体上如何接收转发交易,但只在容量被抢时才起约束作用。容量富余时,转发过来的全都收,跟质押无关。

RPC 响应里能看到质押权重吗? 看不到,没有这个字段。要测的是结果:把上链率按网络状况分桶,在同一个拥堵窗口里对比不同端点。

SWQoS 会影响交易确认的快慢吗? 间接影响。它决定交易会不会被接收进来考虑,而那决定它到底上不上链。收录之后的确认时间是另一回事。

SWQoS 和 priority fee 是一回事吗? 不是,而且作用阶段不同。SWQoS 影响验证节点接不接收你转发过来的交易;priority fee 影响的是它已经接收的那些交易之间怎么排序。