Alchemy 如何为链上金融服务提供支持

金融应用以毫秒为单位被评判。

当用户查看储蓄余额、提交交易、等待存款到账，或在市场剧烈波动时关注借贷仓位时，过时的答案和错误的答案代价相同。底层的链是去中心化的，但上层的产品仍要接受客户从其他金融应用中习得的同一套标准的检验。

金融正在迁移上链，基础设施的问题也随之而来。从借贷、交易所、稳定币账户、汇款、投资组合工具到市场数据，我们提供金融产品与链之间的连接：低延迟读取、可靠的交易执行、实时事件推送、用于历史查询的归档数据，以及面向有独立需求的团队的单租户专属容量。我们还发布了一份实时延迟基准测试，将我们的 EVM 端点与 QuickNode、dRPC 和 Infura 进行对比，其测试方法和原始数据均公开，因此性能方面的说法是可以被验证的，而不是只能被接受的。

为什么基础设施决定金融产品是否可用？

每一个链上金融产品都在用户操作和链响应之间运行一个循环，而这个循环有截止时间。

借贷协议必须先知道抵押品的当前价值，才能计算借款人的健康因子。交易所需要独立确认存款已经结算才能为客户入账。支付应用必须提交一笔稳定币转账、追踪它，并展示新的余额，同时不需要客户理解什么是 gas。市场数据提供方必须以足够快的速度发布价格，供读取它的协议使用。

这个循环中任何一环出问题，暴露出来的都是产品层面的故障，而不是基础设施层面的。一笔错过的交易。一笔卡住的存款。一个悄无声息出错的余额。客户不会把这些归类为"RPC 降级"。

这正是为什么像 Aave、Bitget、Pana、Polymarket、RedStone、Symphony、Solflare、0x、Zapper 和 Zerion 这样的团队，把延迟和可靠性当作产品需求，而不是供应商账单上的一行字。

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

RPC 延迟决定了金融产品读取状态和提交交易的速度下限，因此它会直接体现在报价的新鲜度、存款入账时间，以及交易能否以用户所见的价格成交上。RPC 端点是应用用来读取区块链状态和提交交易所调用的接口。它增加的每一毫秒都是用户等待的一毫秒，而在波动行情下，这种延迟正是滑点和过时报价的来源。

最快的请求，不一定是发送给最近那台机器的请求。节点健康状况每分钟都在变化，流量模式也在变化。一个繁重的历史查询和一次简单的余额查询，对基础设施的需求不同，不应争用同一份容量。

Cortex 是支撑我们平台处理这一问题的引擎。它把每个请求路由到当前健康且适合该特定方法的容量上，并随条件变化而调整，而不是遵循固定的路径。相较于我们此前的架构，官方公布的提升为速度快 2.5 倍、可靠性提高 5 倍、吞吐量提高 500 倍。

对金融产品来说，这项工作在用户感知之前就已完成。报价界面在交易高峰中保持响应。团队的历史数据重建任务运行时不会拖慢客户依赖的实时查询。当某条路径出现降级时，请求会在客户察觉之前转移走。

Aave 在 20 多个网络上运行着 DeFi 中规模最大的借贷协议，借贷业务从不暂停，状态过时意味着用户会误判自己的仓位。迁移到 Cortex 后，Aave 的索引和回填工作负载运行速度提升了 3 到 5 倍。当 Aave 的 API 请求峰值达到约每秒 7 万次时，我们无故障地承接了这一负载。

什么样的区块链基础设施才能满足金融服务对可靠性的要求？

对金融工作负载而言，可靠性意味着两件事同时成立：请求成功，且返回的答案完整且正确。一个快速但错误的答案，比一个慢的答案更糟。

我们通过多链 RPC 提供读写能力，通过归档数据支持历史查询，并通过实时事件系统在活动结算时推送信息。团队还可以观察和排查自己的区块链流量，这正是大多数问题在客户报告之前就被发现的方式。

Bitget 服务超过 1.25 亿用户，并将我们作为存款和取款的独立确认层。其自有节点承担了大部分工作负载，我们与其并行，作为涉及客户资金的任何事项的第二个、无关联的真相来源，这样一来，某个系统中的 bug 或延迟就不会在不知不觉中导致账户被错误入账或扣款。在最近的 30 天窗口期内，Bitget 通过我们在 9 个网络上路由了超过 2500 万次请求，零错误。

这种设计值得借鉴。任何单一的提供方，包括我们在内，对于一个涉及资金流动的产品来说都是单点故障。Bitget 的做法是运行自己的节点，并为那些出错代价高昂的工作流保留第二条独立路径。

对 RedStone 而言，可靠性就是市场的完整性。RedStone 为借贷市场、永续合约、稳定币、外汇交易对和代币化现实世界资产提供价格馈送，并在 2025 年 2 月将我们选定为新链上线的首选 RPC 提供方。自那以后，我们已处理超过 120 亿次请求,目前有 51 条链在我们的节点上实际运行 RedStone 的流量。其历史累计的价格推送记录为 2680 万笔链上交易，成功率达 99.999%。对于清算引擎读取的价格馈送来说，这个成功率决定了市场能否正确出清。

如何让产品与链实时保持同步？

保持同步的可靠方式，是让链主动向你推送事件，而不是轮询它——这正是 webhook 的作用：在匹配的链上事件发生时，向你的服务发出 HTTP 回调。按固定时间间隔轮询多条链，要么意味着持续付费查询,要么意味着接受延迟，而且还意味着你要自己搭建并维护这套轮询基础设施。

Alchemy Webhooks 解决了这个问题。团队可以订阅自己关心的事件，并在活动发生时保持自己的账本、通知和界面同步更新。投递方式是至少一次送达，因此你这一侧的临时故障不会导致事件丢失。

Slingshot 此前为跨链存款追踪搭建了 40 个独立的 Google Cloud 服务，其中一套用于 EVM 链，另一套用于 Solana。改用 Webhooks 后，只用了约 20 行代码和一周时间。结果是一套统一的实时存款系统，零漏检存款。

如何在不让用户等待的情况下加载历史活动？

实时事件让账本保持最新，而历史记录则是客户打开应用时看到的内容：过往转账、投资组合分析、多年的活动记录。这些内容加载速度必须和实时余额一样快。

Solflare 使用我们的 Solana Archive Method,为超过 400 万活跃用户提供历史活动和投资组合分析服务。归档查询的速度比 Solflare 测试过的其他提供方快多达 20 倍，响应时间低于 200 毫秒，这也是为什么用户打开应用能看到完整的财务历史加载出来，而不是盯着一个转圈的加载图标。

如何把区块链的摩擦从金融产品中剔除？

面向客户的目标是：链上的任何细节都不应触达客户。他们应该能够完成一笔支付，而无需先购买原生代币；通过自己能理解的签名流程为账户注资；完成一次储蓄操作，而无需接触网络设置。

可编程账户是能够承载自身规则的钱包，这样应用就可以在账户层面转移资金、执行消费限额，而不是把每个机制都推给用户去处理。Gas 代付让应用可以代客户支付网络费用，再以美元形式向客户计费。结合可靠的交易提交和实时状态更新，团队可以设计出自己想要的流程，而结算依然在链上完成。

目前这一层承载了 EVM 和 Solana 上约 85% 的免 gas 交易，正常运行时间达 99.99%，响应时间低于 50 毫秒。

Pana 使用我们的 RPC 和 gas 代付功能,在 Base 和 Ethereum 上处理稳定币汇款、银行卡充值和结算。上线不到六个月即达到超过 20 万用户，每天处理数万笔稳定币交易。

Symphony 已处理超过 5 亿美元的交易量，并在六个网络上运行。在最近的 30 天窗口期内，我们为 Symphony 处理了超过 80 万次请求，在每一条配置正确的主网上成功率均为 100%。

哪些金融团队基于 Alchemy 构建产品，他们测得的数据是什么？

应该如何评估一家面向金融业务的基础设施提供方？

要求对方提供可复现的数据，然后用你自己的流量去复现。供应商的营销材料不是基准测试，一张截图也不是。

在签任何合同之前，有四件事值得检查。

针对你所用方法、你所在地区的延迟

汇总平均值会掩盖真正重要的慢调用。要针对你产品所依赖的具体方法、在你用户所在的地区进行测试，并关注 p95 而非平均值。我们的基准测试方法文档记录了我们是如何进行测试的，包括所用地区、超时规则,以及何为失败，你可以据此对任何提供方复现同样的设置。

负载下的成功率，而非静态状态下的成功率

一家在基线状态下速度很快、但在波动高峰时却丢失请求的提供方，对金融业务来说是不可用的。要在你预期的峰值负载下进行压测，然后再翻一倍测试。

故障处理方式

当某个节点出现降级时会发生什么，流量转移走需要多长时间？在查看提供方的官网之前，先查看它的状态页面和历史事故记录。

隔离性，在你需要的时候

共享端点会把你的流量和其他所有人的流量放在一起。Dedicated Clusters 是单租户的，符合 SOC 2 Type II 合规要求，可以部署在离你用户或撮合引擎最近的地区。切换到共享 RPC 容量是可选的，用于承接超出该集群容量的流量。这一点对交易系统以及任何不能容忍"嘈杂邻居"这种不确定变量的工作负载来说尤为重要。

为正在迁移上链的金融体系构建产品

与我们合作的金融团队解决的是各不相同的问题。有些在拓宽信贷的可及性。有些在降低跨境支付的成本。有些在提供市场数据、交易工具、托管服务或投资组合分析。

把这些团队连接在一起的，是他们自己的客户对他们提出的同一套标准：快速的答案、能够成交的交易，以及一个配得上经手资金的产品。随着更多的结算、交易和投资迁移上链，这套标准会直接传导到底层的基础设施上，因为客户所体验到的"一笔确认的支付"或"一个准确的余额"，归根结底取决于与链的连接是否稳固。

我们为团队提供统一的基础，涵盖低延迟区块链访问、具备韧性的交易基础设施、实时数据、单租户专属容量，以及面向客户的执行流程,覆盖他们扩展到的每一条链。

Aave 自 2021 年起就在我们这里运行其借贷流量，经历了每一次网络扩展和每一个创纪录的存款日，而它的用户从未需要知道我们的存在。这就是我们的工作。

在 Alchemy 上构建金融产品。

常见问题

Alchemy 可靠吗？它的正常运行时间记录如何？

Alchemy 公布的正常运行时间为 99.995%,同时每年保障超过 1 万亿美元的交易量，并在状态页面上公开事故历史。经客户验证的证据包括 Bitget 在 9 个网络上处理的 2500 万次请求零错误，以及 RedStone 99.999% 的价格推送成功率。

什么是 Alchemy Cortex？

Cortex 是驱动 Alchemy 开发者平台的智能区块链引擎。它把每个请求路由到适合该特定方法的健康容量上，并随节点健康状况和流量变化而调整，而不是遵循静态路由。Alchemy 公布的结果是：相较于此前的架构，速度快 2.5 倍、可靠性提高 5 倍、吞吐量提高 500 倍。

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

RPC 延迟决定了应用读取链上状态和提交交易的速度下限。延迟越高，报价越容易过时，存款入账越晚，交易成交价也会比用户所见的更差。对交易系统而言，你所在地区的 p95 延迟比全球平均值更重要。

我应该对企业级 RPC 提供方抱有怎样的 SLA 预期？

Alchemy 的企业版计划附带签署的 SLA，正常运行时间和响应承诺按合同单独协商，而非作为一个统一的公开数字发布。无论选择哪家提供方，都应要求四项内容：正常运行时间数字、测量周期、排除条款,以及未达标时的补救措施。没有这些内容的百分比数字算不上 SLA。

在生产环境中依赖单一 RPC 提供方有哪些风险？

对任何涉及资金流动的业务来说，单一提供方都是单点故障。Bitget 的做法是一个值得借鉴的模式：用自己的节点承担大部分流量，同时为存款、取款以及任何出错代价高昂的工作流保留第二个独立的提供方，作为独立的数据来源。

哪家区块链 API 提供最可靠的 webhook 投递？

Alchemy Webhooks 保证至少一次送达，因此你这一侧的临时故障不会导致事件丢失。Slingshot 用大约 20 行代码取代了此前横跨 40 个 Google Cloud 服务的跨链存款追踪系统，并报告在 EVM 链和 Solana 上实现了零漏检存款。

在选择 RPC 提供方之前，我该如何进行基准测试？

在标准付费账户下，针对你产品所调用的具体方法、从你用户所在的地区进行测试，不做重试，并设置固定超时。报告 p95 数值的同时也要报告平均值，并把成功率和延迟分开统计。Alchemy 的基准测试方法文档记录了一套你可以对任何提供方复现的测试设置。

对于高交易量的稳定币支付基础设施，该选 Alchemy 还是 QuickNode？

两者都在大规模生产环境中运行稳定币工作负载。有意义的对比维度是：你所用方法的实测延迟、你峰值负载下的成功率，以及交易提交和 gas 代付是否与你的读取请求来自同一个提供方。Alchemy 的实时基准测试公开了与 QuickNode 对比的数据，测试方法和原始数据均公开。

哪家提供方能提供支持区域部署的单租户专属节点？

Alchemy Dedicated Clusters 是单租户的，符合 SOC 2 Type II 合规要求，不与他人共享流量或算力。它们可以部署在离你的技术栈或用户最近的地区，以降低延迟。切换到共享 RPC 容量是可选的，用于承接超出该集群容量的流量。