---
title: "Route 如何在 Robinhood Chain 上保持兑换快速可靠"
description: "Route 在 Robinhood Chain 上的 240 万多个池中为每笔兑换定价。在路由器背后使用 Alchemy Node RPC 后，超过 99% 的报价成功返回。"
---
# Route 如何在 Robinhood Chain 上保持兑换快速可靠
兑换路由器只做一个承诺：你拿到的永远不会低于它给你的报价。
[Route](https://route.fun) 为 Robinhood Chain 上的兑换提供支持，并在交易的两端兑现这一承诺。每笔交易，它都会检查该代币在链上的所有交易场所，把订单拆分到加起来价格最优的那些池中，再通过自己的 executor（在链上执行兑换的合约）在一笔交易内完成全部结算。在你签名之前，Route 会模拟整个方案，所以屏幕上的数字是真实的。在你签名之后，它会根据你的交易实际落入的区块重新规划，这样如果市场朝对你有利的方向变动，你的成交价会变得更好，而不是与机会擦肩而过。
两个阶段在底层需要的是同一样东西：新鲜、准确、随取随用的链状态。
这正是 Alchemy 发挥作用的地方。Route 自己的节点负责最快的读取，也就是实时报价中的那些小查询。其余部分由我们负责：备用读取、模拟校验和历史扫描，让 Route 的数据保持新鲜、随时可用。
## Route 概览
- 运行在 Robinhood Chain、Base、BSC、Arbitrum、Optimism 和 Ethereum 上的兑换路由器
- 仅在 Robinhood Chain 上就索引了 240 万多个流动性池
- 路由经过 Uniswap 池（包括在兑换过程中运行自定义代码的池），以及启动平台的联合曲线、预言机定价的 AMM 和代币化股票
- 用户包括 [route.fun](https://route.fun) 上的交易者，以及合作伙伴的钱包、交易应用、vault、做市商和启动平台
**所用产品:** [Alchemy Node RPC](/rpc-api)
## 挑战：路由器只能使用它能及时读到的池
报价一慢，交易者看到的就是过时的数字。在 route.fun 上，报价会随着输入实时刷新；在合作伙伴的应用里，它还得赶在对方的超时时间之前返回。报价一错，兑换就会回滚，交易者白白损失 gas，只能重来。报价彻底失败时，即使交易对的流动性很充足，他们看到的也是 "no route"，而在合作伙伴看来，就像自己的产品坏了。
这三种情况都源于同一个地方。在 240 万多个池中为一笔交易定价，首先是读取问题，然后才是数学问题。每次报价都要先为候选池定价，再按交易实际要支付的 gas 价格，让整个方案在 Route 的 executor 上跑一遍，然后才把结果返回给发起请求的应用。在这之下，Route 还在从事件日志中发现新池、重新检查已知的池，并为手续费核算和分析扫描历史数据。
这对 RPC 提供商提出了三项要求。
- **构建报价时的快速读取。** 状态没能及时返回的池会被排除在路由之外，价格随之变差。
- **完全准确的状态。** 针对某个特定区块运行的模拟，必须与链实际会执行的结果一致。如果不一致，兑换可能失败，或成交低于交易者同意的最低数量。
- **大量的历史数据。** 发现池和核对手续费，意味着要扫描跨越数万个区块的日志。
Route 原先把读取分散在多家提供商之间，用重试和重复请求来消化彼此的差异。这在一定程度上行得通。但每家提供商仍会以各自的方式出故障，而每一个变通办法都会让报价耗时再次增加。
后来，Route 的主要提供商宕机了。route.fun 上的报价在几个小时内断断续续地失败，流动性明明就在那里，交易者看到的却是 "no route"。Route 当天就把公共端点从那家提供商迁走了。
## 解决方案：一切背后只有一家提供商
Route 早已在内部任务、历史扫描和模拟中使用 Alchemy，所以当这些公共端点需要新去处时，Alchemy 当天就接了过来，并在没有改变任何一个报价的情况下恢复了失败的读取。同样的输入，同样的区块，同样的校验。如今，路由器、API、网站、开发者门户和收益服务背后都是同一个端点。
Route 产品中有三个部分直接依赖这些读取。
### 在所有池之间路由
Route 会把每笔订单拆分到价格最优的池中。过去，一次慢读取就会让某个池被排除在路由之外，代价由交易者承担。Alchemy 的备用读取在 300 毫秒内返回，所以这个池会留在路由中。
### 交易者可以放心执行的报价
Route 在你签名前模拟方案，然后在执行时通过 JIT 路由重新规划。过去，状态不一致意味着回滚或达不到最低数量。Alchemy 把两者固定在同一个区块上，所以报价成为成交价可以超越的底线。
### 首先要找到这些池
Route 索引了 240 万多个池，并持续重新检查。过去，提供商的配额限制会让这些扫描中途中断。Alchemy 单次请求最多返回 10,000 条日志，足以让 Route 在一个可预测的上限内扫描数万个区块。
> "我们之前同时使用多家提供商，每家都有自己的限制、故障模式和需要维护的回退逻辑。我们整合到了 Alchemy，让路由器、API 以及其他链上的路由器背后都只有一家提供商、一个套餐。这让我们的技术栈更简单、更可预测，也让我们在不增加基础设施供应商的情况下，在 Base、BSC、Arbitrum、Optimism 和 Ethereum 上推出了 Route。"
>
> — Micah（创始人，Route）
## 结果：在 Alchemy 上超过 99% 的报价成功
Route 会记录每一次报价请求。在最近 48 小时的合作伙伴和网站流量中，超过 99% 的请求成功了。没有成功的，要么是针对流动性太低、无法交易的代币返回的 "no route"，要么是 Route 自身容量已满的时刻。没有一次是 RPC 错误。迁移之前，提供商的错误会以 "no route" 的形式出现在交易者面前，Route 需要靠重试和变通办法来控制。
改变的是读取没有返回时会发生什么。过去会失败、或到达得太晚而派不上用场的读取，现在都能按时到达。
## 下一步：能够自主交易的代理
下一步是代理式执行。Route 正在构建运行在 SDQ 之上的常设订单。SDQ 是 Route 的实时报价流，每个区块都会重新定价。这样，钱包或 AI 代理就可以在链上强制执行的支出限额内，无需人工操作，通过 Route 进行交易。它与 JIT 依赖的是同样的读取。
## 在 Alchemy 上构建你的路由器
报价能否成立，取决于背后的读取能否成立。这部分由我们负责。
[浏览 Alchemy 开发者文档](https://www.alchemy.com/docs) 或 [联系我们的团队](/contact-sales)。