RouteはRobinhood Chainでスワップの速さと信頼性をどう保っているか

スワップルーターが約束することはひとつです。提示した価格を下回ることは決してない、ということです。

RouteはRobinhood Chainのスワップを支えており、取引の両端でその約束を守っています。取引ごとに、そのトークンが取引されているオンチェーン上のあらゆる場所を確認し、合計で最良の価格になるプールに注文を分割し、独自のexecutor(オンチェーンでスワップを実行するコントラクト)を通じて全体を1つのトランザクションで決済します。署名の前に、Routeは計画全体をシミュレーションするため、画面に表示される数字は本物です。署名の後には、トランザクションが実際に取り込まれるブロックに対して計画をやり直すため、相場が有利に動いた場合は、その機会を逃すことなく約定価格が改善されます。

どちらの段階も、その下に同じものを必要とします。新しく、正確で、求められたときにすぐ返ってくるチェーン状態です。

そこでAlchemyの出番です。Route自身のノードは、ライブのクォート内で行われる小さな参照といった最速の読み取りを担います。残りはAlchemyが担当します。バックアップの読み取り、シミュレーションの検証、履歴のスキャンによって、Routeのデータを新しく、いつでも利用できる状態に保ちます。

Routeの概要

Robinhood Chain、Base、BSC、Arbitrum、Optimism、Ethereumで動くスワップルーター
Robinhood Chainだけで240万以上の流動性プールをインデックス
スワップの途中でカスタムコードを実行するものを含むUniswapのプールに加え、ローンチパッドのボンディングカーブ、オラクル価格のAMM、トークン化株式を経由してルーティング
route.funのトレーダーのほか、パートナーのウォレット、トレーディングアプリ、vault、マーケットメイカー、ローンチパッドが利用

利用製品: Alchemy Node RPC

10万+

ルーティングしたスワップ

5,000+

ユニークウォレット

約1,100万ドル

1週間の取引量

課題:ルーターが使えるのは、時間内に読み取れたプールだけ

クォートが遅ければ、トレーダーは古い数字を見ていることになります。route.funでは入力に合わせてクォートが更新され、パートナーのアプリ内ではそのパートナー自身のタイムアウトに間に合わせる必要があります。クォートが間違っていればスワップはリバートし、トレーダーはガス代を失ってやり直すことになります。完全に失敗すれば、十分な流動性があるペアでも「no route」と表示され、パートナーからは自社の製品が壊れたように見えてしまいます。

この3つはすべて同じところに行き着きます。240万以上のプールで取引の価格を算出することは、計算の問題である前に読み取りの問題です。各クォートは候補プールの価格を算出し、取引が実際に支払うガス価格で計画全体をRouteのexecutorに通してから、リクエスト元のアプリに答えを返します。その裏では、Routeはイベントログから新しいプールを見つけ、既知のプールを再確認し、手数料の会計や分析のために履歴をスキャンしています。

これがRPCプロバイダーに3つの要件を課します。

クォートの構築中の高速な読み取り。 状態が時間内に返ってこないプールはルートから外れ、価格が悪化します。
完全に正確な状態。 特定のブロックに対して実行したシミュレーションは、チェーンが実際に行う処理と一致しなければなりません。一致しなければ、スワップは失敗するか、トレーダーが同意した最低額を下回る可能性があります。
履歴データの量。 プールの発見や手数料の照合には、数万ブロックにわたるログのスキャンが必要です。

Routeはこれまで読み取りを複数のプロバイダーに分散し、その差異をリトライや重複リクエストで吸収していました。ある程度まではそれで機能していました。それでも各プロバイダーはそれぞれ異なる形で障害を起こし、回避策を加えるたびにクォートにかかる時間が増えていきました。

そしてRouteのメインプロバイダーがダウンしました。route.funのクォートは数時間にわたって断続的に失敗し、流動性はそこにあるのに、トレーダーには「no route」と表示されました。Routeはその日のうちに公開エンドポイントをそのプロバイダーから移しました。

ソリューション:すべての裏側にひとつのプロバイダー

Routeはすでに社内ジョブ、履歴スキャン、シミュレーションにAlchemyを使っていたため、公開エンドポイントの移行先が必要になったとき、Alchemyは同じ日に引き受け、クォートを1つも変えることなく失敗した読み取りを復旧しました。同じ入力、同じブロック、同じチェック。現在はひとつのエンドポイントが、ルーター、API、Webサイト、開発者ポータル、利回りサービスの裏側にあります。

Routeの製品のうち3つの部分が、これらの読み取りに直接依存しています。

すべてのプールにわたるルーティング

Routeは各注文を最良の価格を出すプールに分割します。以前は読み取りが遅いとプールがルートから外れ、そのしわ寄せはトレーダーに及んでいました。Alchemyのバックアップは300ミリ秒以内に応答するため、プールはルートに残ります。

トレーダーがそのまま使えるクォート

Routeは署名前に計画をシミュレーションし、実行時にJITルーティングで計画をやり直します。以前は状態に不整合があると、リバートや最低額の未達につながっていました。Alchemyは両方を同じブロックに固定するため、クォートは約定がそれを上回ることのできる下限になります。

そもそもプールを見つけること

Routeは240万以上のプールをインデックスし、再確認を続けています。以前はプロバイダーのクォータ制限によってスキャンが途中で止まっていました。Alchemyは1回のリクエストで最大10,000件のログを返すため、Routeはひとつの予測可能な上限のもとで数万ブロックをスキャンできます。

「複数のプロバイダーを使っていて、それぞれに固有の制限や障害のパターン、維持しなければならないフォールバックのロジックがありました。そこでAlchemyに集約し、ルーター、API、他チェーンのルーターの裏側をひとつのプロバイダー、ひとつのプランにまとめました。スタックはよりシンプルで予測しやすくなり、インフラベンダーを増やすことなく、Base、BSC、Arbitrum、Optimism、EthereumでRouteをローンチできました。」

— Micah（創業者、Route）

結果:Alchemy上で99%以上のクォートが成功

Routeはすべてのクォートリクエストを記録しています。直近48時間のパートナーとWebサイトのトラフィックでは、99%以上が成功しました。成功しなかったものは、取引に十分な流動性がないトークンに対する「no route」の回答か、Route自体が処理能力の上限に達していた時間帯のものでした。RPCエラーは1件もありませんでした。移行前は、プロバイダーのエラーが「no route」としてトレーダーに届き、Route側でリトライや回避策を講じて抑え込む必要がありました。

変わったのは、読み取りが返ってこないときに何が起きるかです。以前は失敗していた読み取りや、遅すぎて役に立たなかった読み取りが、今は届きます。

次に向けて:自律的に取引するエージェント

次はエージェントによる実行です。Routeは、ブロックごとに価格を再計算するライブのクォートストリームであるSDQの上で動く常設注文を構築しています。これにより、ウォレットやAIエージェントが、オンチェーンで強制される支出上限の範囲内で、人が操作しなくてもRouteを通じて取引できるようになります。これはJITと同じ読み取りの上で動きます。