Solana 链上如何做到最快速度的狙击交易
内容提要
文章记录了Solana新池狙击的优化过程：通过预解锁、预取blockhash、跳过模拟和异步落库，将发送耗时从十几秒降至毫秒级；改用Processed信号后，发现主要等待发生在信号抵达前。主网测试达到8 slots约3秒，但暴露出约1秒执行等待、近200ms后处理及授权过期问题。结论是Preprocessed、Raw Shreds等更早信号无法自动消除既有延迟，需分段计时并兼顾成功率。
延伸解读
测量陷阱：毫秒级发送不等于毫秒级成交
文章指出，将发送耗时从十几秒压缩到几毫秒，并不代表交易能在几毫秒内成交。页面上的“检测到开始广播”只计算机器人具备执行条件后多久开始发送，未包含信号抵达前的等待和交易发出后的落块时间。旧版“检测到提交”与新版“检测到开始广播”边界不同，不能直接相除宣称整体快了几千倍。评估狙击速度必须回到买单实际进入哪个 slot，并用分段计时解释延迟来源。
Processed 信号：更早触发不等于稳定更早成交
改用 Processed 信号后，一次同池对照中，Processed 的执行账号更新比 Confirmed 早到 259ms，最终买入领先 2 个 slot，回执早 208ms。但后续测试出现两单同块、Confirmed 更靠前，甚至双 Processed 建池到买入耗时 54 slots 的情况。文章强调，Processed 只提供更早执行的机会，实际成交还取决于信号抵达、应用处理和落块过程，单次最好成绩不能代表稳定表现。
主网验证暴露的延迟与授权竞态
主网一轮成功测试中，两笔买单进入建池后 8 slots，约 3 秒。但分段数据显示，从账号更新到满足执行条件花了 1005ms，触发后处理又用了约 198ms，RPC 请求接近 1.2 秒。随后连续两轮因授权过期在广播前失败：触发时授权租约仅剩约 494ms，而构造和签名用了约 792ms。文章指出，续租逻辑需独立覆盖构造签名阶段，但修复尚未在主网复测验证。
更早信号源的成本与适用条件
Preprocessed 和 Raw Shreds 能提供更早的交易数据，但代价是数据形态变化和额外成本。Helius Preprocessed WebSocket 处于 Public Beta，Developer 套餐 49 美元/月起，按每条消息 0.1 credits 计费；Raw Shreds 通常 1000 美元/月/IP。Shyft RabbitStream Build 套餐 199 美元/月，QuickNode Blazar 价格未确认。文章提醒，这些只是数据订阅费用，且更早信号无法自动消除已有的约
Q&A
Solana 新池狙击最初为什么需要十几秒才能发出买单？
最初的 Standard 模式把太多工作留到机会出现后才做，包括准备信息、完成检查、构造交易和提交，导致检测到提交耗时 13.230 秒、14.098 秒和 9.629 秒。
Fast 模式做了哪些优化来缩短发送时间？
Fast 模式在监听前完成解锁授权、检查余额预算、准备代币与账户参数，监听期间后台刷新 blockhash 和优先费，触发后只做交易构造、签名和广播，并跳过发送前模拟（skipPreflight: true），数据库异步落库。
为什么页面显示 5ms 发送，但链上买入仍然要等 5 秒？
页面上的 5ms 只计算机器人具备执行条件后到开始发送的时间，不包含信号抵达前的等待和交易发出后的落块时间，所以链上买入仍可能在建池后 29 slots（约 5 秒）才进入区块。
改用 Processed 信号后，为什么交易反而可能更晚？
因为监测模块看到池子的时刻与执行模块收到账号订阅更新的时刻可能相差数秒（如 4.72 秒），Processed 只是给了更早执行的机会，最终成交还取决于信号实际抵达、应用处理和落块过程，单次结果不稳定。
主网测试中 Fast + Processed 遇到了哪些新问题？
主网一轮成功达到 8 slots（约 3 秒），但暴露出约 1 秒的执行条件等待、近 200ms 的触发后处理，以及授权过期问题：触发时授权租约仅剩约 494ms，而构造签名用了约 792ms，导致广播前授权已过期。
Preprocessed 和 Raw Shreds 信号能自动消除现有延迟吗？
不能。Preprocessed 和 Raw Shreds 虽然能更早看到建池交易，但无法自动修复主网中约 1 秒的执行条件等待和近 200ms 的触发后处理，需要分段计时并兼顾成功率，否则提前的几毫秒很容易消失在后续流程中。
