---
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)。