链上交易中延迟的成本

延迟成本体现为产品观测到的链上状态与其操作实际执行时状态之间的差距。产品花在读取、决策、提交和等待确认上的每一毫秒，都会让这个差距变大。

对于长周期的持仓视图来说，这个差距可能只是个小麻烦。但对做市商、swap 路由器、清算引擎，或是想撤销过期订单的交易者而言，它可能会侵蚀策略收益中相当大的一部分。低延迟 RPC 之所以是交易体验成功的核心，是因为它能帮助这些产品基于更新的状态来行动。

报价可能在交易执行前就已过期

swap 报价捕获的是应用发起请求那一刻的资金池储备量、订单簿流动性、gas 状况和市场状态。而在用户确认交易期间，这些输入一直在变化。

基本流程很简单：

1. 应用读取链上和市场状态。
2. 计算出报价或交易决策。
3. 用户提交交易。
4. 网络传播、排序并执行该交易。
5. 应用收到回执并刷新其视图。

每一处延迟都会让最终的操作变得更加滞后。读取慢意味着使用了更旧的市场数据；提交慢给了市场更多变动的时间；确认慢则让用户看到的是过期的状态。

0x 为来自多个流动性来源的交易定价。其团队将响应速度和数据准确性与报价质量直接挂钩，因为在请求处理过程中价格可能发生变化，而他们生成报价的耗时不到一秒。

Jupiter 展示了这种时间差：其直接落地路径目标是 50–400 毫秒（即 0 到 1 个 Solana 区块），相比之下标准 RPC 提交需要 400 毫秒到 1.2 秒（即 1 到 3 个区块）。报价与执行之间间隔的区块数越少，状态发生变化的机会就越少。

延迟累积的四个阶段

每一笔交易都会经过以下这些阶段。任何一个阶段出现延迟，都会让最终结果变得更滞后或更不确定。

这些阶段之间会相互影响。即使写入路径很快，一次过时的市场读取仍然是过时的。在波动剧烈的时段，最慢的那些请求比平均值更重要。故障本身也会带来额外风险：重试、过期的界面、错过的操作。

对延迟敏感的产品应该同时评估 p95、p99 响应时间以及成功率。我们公开的基准测试方法测量的是预热后、方法级别的 EVM 读取，并将成功响应的延迟与失败请求分开统计。底层的 Node API 覆盖了产品与链交互所需的读写操作。它衡量的是某一特定提供商的路径，而交易团队需要测试自己的读写、地区和流量特征。

延迟在链上交易中如何变成经济成本？

当延迟改变了执行结果时，它就变成了经济成本，而具体如何变化则取决于工作负载。以下是链上交易系统中反复出现的一些典型模式。

Swap：过期的报价会变成滑点或回退

价格影响（price impact）和滑点（slippage）常被混为一谈，但它们描述的是不同的成本。我们的 DeFi 基础设施指南展示了这些成本在生产环境的报价流程中是如何体现的。价格影响是某一交易规模对资金池价格造成的可预测变化。滑点则是报价输出与实际执行时收到的输出之间的额外差距。它取决于延迟、并发交易以及区块的打包顺序。

这一区别在产品设计中很重要。价格影响在报价时就可以看到。而滑点则会在交易待处理期间不断累积。设置最小输出保护，可以把价格变动过大的风险转化为交易回退，从而保护用户。手续费较低的交易可以在价格环境变化时等待更久；最小输出、最大输入或截止时间则设定了用户能接受的最差执行结果。

面向用户的最终结果可能是更差的价格、错失的交易，或是一条更严格的执行路径，用以减少对市场变化的暴露。更快的读取和提交能够缩小这个暴露窗口的一部分。

做市与订单管理：过晚的撤单可能变成有毒流量

做市商会随着价格变动持续刷新报价。如果系统得知价格变动得太晚，或撤单发送得太晚，一笔挂单可能在已经变得无利可图之后才被成交。而下达市价单的交易者面临的是相反的风险：等交易到达市场时，可用的流动性可能已经消失。

清算与套利：时间本身就是机会的一部分

清算引擎和套利系统之间竞争的是：谁能先观察到状态变化并在机会窗口关闭前采取行动。相关的竞争对象可能是新的预言机价格、变化的健康因子、资金池失衡，或跨平台的价格差异。错过它可能意味着损失收益。反复失败的尝试同样会消耗手续费和区块空间。

链的设计决定了这场竞争的形态。在按到达顺序排序的系统中，更低的延迟路径可能直接影响排序结果。在使用优先费的系统中，费用和时间都很重要。在具有私密订单流或打包交易的系统中，可见性和原子执行会带来进一步的权衡取舍。基础设施在这些市场规则内运作，它的职责是避免在策略进入这些规则之前增加不必要的延迟。

钱包与交易界面：延迟会变成信任问题

延迟的影响不仅限于成交价格。一个钱包或交易应用在用户看到有用的界面之前，可能需要发出许多调用：余额、授权额度、路由报价、gas 估算、回执和交易历史。如果这些调用响应缓慢或间歇性失败，用户看到的就是变化中的价格、延迟的状态，或是看起来卡死的界面。

这在波动剧烈时尤其有害。在平静的市场中只是略显不便的余额刷新延迟，在用户试图管理风险、需要对冲、决定撤单或确认充值时，可能会带来更严重的后果。

为什么尾部延迟比平均值更重要

延迟分布存在长尾。当某个端点在负载下变慢时，产品恰恰会在流量上升、波动加剧或链上拥堵的时候经历这种慢路径。

这就是为什么评估一个提供商时应该回答以下四个问题：

• 哪些方法处于关键路径上？分别评估最新区块读取、eth_call、eth_getLogs、回执查询和交易广播；它们各自的行为都不相同。
• 用户和服务从哪些地区连接？地理位置会改变网络路径。
• 成功请求的 p95 和 p99 有多慢？这些数值揭示了被平均值掩盖的那些请求。
• 请求失败或超时的频率如何？超时是一种可靠性事件，可能触发重试、界面过期或操作错失。

基准测试应当明确列出这些条件，并测量买方实际会运行的产品路径。我们的基准测试方法针对每个方法级别的对比，固定了请求来源、方法、payload、超时时间、成功判定规则和连接状态，以帮助开发者做出基础设施决策。

低延迟 RPC 能解决什么，不能解决什么

更快的 RPC 层能够更早返回当前状态、更早提交已签名的交易，并让交易界面保持响应。但成交质量仍然取决于市场变动、流动性、手续费、路由选择、交易保护机制以及链的排序策略。提供商的读取基准测试衡量的是读取性能；端到端的 swap 表现、交易打包、WebSocket 行为以及策略 PnL 需要单独测试。

明确这一范围有助于保持基础设施相关说法的准确性，也帮助团队选择与自身工作负载相匹配的测量方式。我们的目标是从那些产品经济效益对时间最敏感的路径中，消除可避免的延迟。

我们围绕这一目标开展了低延迟 RPC 相关工作。Alchemy Edge Proxy 在接入层消除了固定的请求路径开销，在其迁移测量中将 APAC 地区的 p99 从 150 毫秒降至 20 毫秒。Cortex 路由会为每个请求选择一个健康的节点，而不是仅仅把邻近性当作全部答案。Cortex 同时也支撑着容量和节点集群运营，使请求路径在高负载下依然保持响应。我们的低延迟基础设施工作涵盖边缘、路由、容量、节点运维和测量等多个层面。每一层都经过精细调优，以为你提供可靠的低延迟服务。

如何评估你自己的执行路径

从延迟会造成最大用户或经济成本的流程开始。

1. 绘制从状态读取到用户可见结果的整条路径，包括路由计算、签名、提交、打包和状态刷新。
2. 从你的服务和用户所在的地区，测试产品实际使用的方法和 payload。从你的产品所依赖的 RPC API 和支持的链开始。在正常时段和高波动或高流量时段分别运行相同的测试。
3. 记录 p50、p95、p99、成功率、超时率以及从报价到结果的耗时。将读取、提交和打包延迟分开记录。
4. 将这些测量结果与实际结果关联起来：报价与成交之间的偏差、回退、错失的成交、撤单成功率、客服联系量以及用户流失。

这样就能为你的策略、资产和用户建立起一套成本模型——并显示出更快的路径会在哪些地方改变执行结果。

常见问题

RPC 延迟如何影响交易表现？

延迟会拉大交易应用观测到的状态与其交易实际执行时状态之间的差距。读取慢会让报价在签名前就已过期，提交慢给了市场更多变动时间，确认慢则让用户基于过期的界面采取行动。结果就是更差的成交、错失的交易，或是交易回退。

更低的 RPC 延迟能保证更好的成交结果吗？

更低的 RPC 延迟能减少提交前后可避免的延迟。但成交质量还取决于市场变动、流动性、手续费、私密订单流、路由选择、链的排序方式以及交易保护机制。

为什么 p95 对交易应用来说比平均 RPC 延迟更有用？

平均值可能掩盖了在高负载或波动期间集中出现的慢请求。p95 说明在测量条件下，95% 的成功响应至少达到了这个速度。应结合成功率一起看，因为失败和超时需要单独的可靠性度量。

如何为交易应用对 RPC 提供商进行基准测试？

从你的用户和服务所在的地区，测试产品实际使用的方法和 payload。可以用我们的基准测试方法作为可复现的起点。记录 p50、p95、p99、成功率和超时率，并将读取、提交和打包延迟分开记录。在波动剧烈、流量高峰的时段以及平静的市场条件下都重复测试。

价格影响和滑点是一回事吗？

不是。价格影响是交易规模对当前资金池造成的可预测影响。滑点是报价输出与用户实际收到结果之间在执行时产生的差异。Raydium 的文档对两者都给出了清晰的技术定义。

交易团队应该分别对读取、写入和完整工作流进行基准测试吗？

是的。方法级别的读取测试可以比较不同提供商在特定请求上的表现。而要理解报价新鲜度、决策、提交、打包和确认这些环节如何共同作用，则需要完整的交易流程测试。两者的结论应分开看待。