跳至内容
0%

交易团队为什么选择 Alchemy 的低延迟 RPC

作者:Alchemy

最后更新:2026年10月6日2 分钟阅读
低延迟交易构建在 Alchemy 之上

一笔链上交易,从必须在价格变动之前送达的市场数据开始。随后订单必须成交,即使交易量突然放大;资金也必须在事后与链上记录核对一致。

预测市场、交易所、DEX 基础设施、交易应用和市场数据提供方,都在 Alchemy 上完成这项工作。他们选择我们,是因为峰值负载下的低延迟、所交易链上的可靠基础设施,以及帮助调优技术栈的工程师。

交易团队为什么选择 Alchemy?

交易团队选择 Alchemy,是因为我们覆盖这项工作的两端:市场变动时的低延迟读写,以及资金结算时完整、可靠的记录,即使在交易量峰值也是如此。

可以把它看成交易公司的两张桌子:前台需要速度,后台需要确定性。两边都通过 RPC 节点到达链上。RPC 节点是响应应用请求的服务器,用来读取区块链数据并提交交易。

使用场景
团队
选择 Alchemy 的原因
结果
预测市场交易
压力下的性能
超过 12.5 万并发用户;摄取延迟从约 250ms 降至约 100ms
DEX 聚合与订单路由
测试过的平台中,唯一可以依靠的一家
亚秒级报价,99.9% 正常运行时间
Hyperliquid 上的交易产品
标准节点行为,以及响应迅速的工程支持
迁移后 RPC 请求成功率 100%
交易所充值与提现核对
归档与 trace 数据、链覆盖、可靠性
30 天内跨 9 个网络超过 2500 万次请求,零错误
面向终端和代理的市场数据
一条链到多条链都用同一家提供方,外加亲手支持
平台上追踪超过 19 亿笔交易(Struct 报告)

Alchemy 如何在真实负载下保持低延迟?

我们在规模上路由每一个请求,从而稳定地服务各个团队;对峰值极高的团队,我们会围绕他们的流量调整路由和容量。平台底层的引擎 Cortex 会在交易者察觉之前,把流量从已经变差的路径上移开。

Polymarket 在测试了多家 RPC 提供方之后选择了我们。2024 年美国总统辩论期间,它服务了超过 12.5 万并发用户;整个选举期间,有 33 亿美元的投注经过该平台。我们按 p99 延迟(最慢的 1% 请求)重新路由它的请求,并增加了两支专用节点集群。Cortex 把它关键数据摄取的延迟从约 250ms 降到了约 100ms。

"与 Alchemy 合作至关重要。亲自支持、对我们功能需求的快速响应,以及对我们规模的关注——Alchemy 始终做得更多。他们不只是基础设施提供方。他们是我们团队的一部分。"

— Rodrigo,Polymarket 平台负责人 · 阅读 Polymarket 案例研究

0x 为去中心化交易所以及自己的交易应用 Matcha 路由流动性。在测试了可用的平台之后,它认定我们是唯一可以依靠的一家。在 Alchemy 上,它在一秒内生成报价,正常运行时间为 99.9%。

Alchemy 如何让交易基础设施保持可靠?

我们运行交易团队宁可不自己运维的那一层:Hyperliquid 上的 HyperEVM 节点、Solana gRPC 流,以及交易所用于结算的归档数据和 trace 数据。

Valantis 在 Hyperliquid 上构建交易产品。它自托管的 HyperEVM 节点一周会宕机好几次,每次故障都可能让交易者无法开仓或平掉定投(DCA)仓位。迁到我们的 HyperEVM Node 之后,Valantis 报告 RPC 请求成功率为 100%。

"我们需要基础设施正常工作,这样才能继续专注于打造出色的交易体验。Alchemy 给了我们更可靠的基础,以及一个在我们需要时能迅速帮忙的团队。"

— Deven Matthews,Valantis CEO · 阅读 Valantis 案例研究

服务超过 1.25 亿用户的 Bitget,只有在独立来源一致时才记入一笔充值,而我们是 9 个网络上的来源之一。它自己的全节点只保留大约最近 128 个区块,因此依赖我们的归档数据(完整链历史)和 trace 方法(逐步重放交易)。30 天里,Bitget 向我们发送了超过 2500 万次请求,错误为零。

Alchemy 的团队如何帮助交易团队调优基础设施?

本文中的大多数团队都把支持列为选择我们的原因。我们的工程师直接处理问题,和每个团队自己的工程师一起工作。

向交易终端和代理推送市场数据的 Struct,在选择我们之前对多家提供方做了基准测试。它运行在我们的 Node API 和 WebSockets 上,并在增加网络时依靠我们的支持。

"与 Alchemy 合作,为 Struct 提供了我们的数据管道所需要的稳定性。再加上亲手的开发者支持,我们就能把精力放在尽全力服务客户上。"

— Elliot,Struct CEO · 阅读 Struct 案例研究

在 Alchemy 上开始构建交易使用场景

我们为峰值负载下的低延迟读写而构建,外加后台所依赖的归档、trace 和流式数据,覆盖你交易的每一条链。

开始使用,或与我们的团队交流。

常见问题

哪家 RPC 提供方最适合 Hyperliquid?

Alchemy 运行遵循标准 Ethereum 节点规范的 HyperEVM Node,因此现有服务可以迁过来,而不必换一套运维模式。Valantis 把它的 Hyperliquid 交易后端从自托管节点一次迁移一个服务到 Alchemy,并报告此后 RPC 请求成功率为 100%。先用你自己的方法测试任何提供方。

Solana 交易应用在 RPC 提供方上应该看什么?

在请求-响应式 RPC 之外,还要看 gRPC 流式传输。Alchemy 的 Solana gRPC 兼容 Yellowstone,因此现有客户端换一个 URL 就能迁过来。每个订阅会扇出到多个上游节点,重连后会回补丢失的数据,端点运行在 US East、US West、EU Central 和 Asia-Pacific。

加密货币交易所为什么会使用不止一家 RPC 提供方?

单一提供方就是用户资金的单点故障。Bitget 运行自己的节点,只有在独立来源一致时才记入充值,Alchemy 是这些来源之一。30 天里,Bitget 向 Alchemy 发送了跨 9 个网络的超过 2500 万次请求,错误为零。

哪些 RPC 提供方支持归档和 trace 数据?

Alchemy 提供归档数据,以及 trace_block 和 debug_traceBlockByNumber 等 trace 与 debug 方法。Trace API 可在按量付费和 Enterprise 方案中使用。标准全节点只保留最近的区块,大约是最后 128 个,因此无法重建更早的交易。Bitget 用这些数据核对充值。

Alchemy 新闻通讯

第一时间获取发布信息

订阅我们的新闻通讯

获取 Alchemy 的最新产品更新和资源

A
O
D
+
超过 80,000 名订阅者

填写您的电子邮箱地址即表示您同意接收我们的营销通讯和产品更新。您确认 Alchemy 按照我们的隐私声明处理我们收到的信息。您可以随时取消订阅。