Uniswap を例として、DEX ルーターの構築と分析に使用される構成要素について説明します。

星球君的朋友们

Odaily资深作者

2021-10-27 15:46 (UTC+8)

この記事は約4897文字で、全文を読むには約7分かかります

この記事では、Uniswap V2 プロトコル以降のルーターを構築および分析するために使用できる構成要素について説明します。

AI要約

展開

この記事では、Uniswap V2 プロトコル以降のルーターを構築および分析するために使用できる構成要素について説明します。

概要

ある資産を別の資産と交換することは、金融市場の基本的な概念です。暗号通貨市場では、これは通常、トークンまたは通貨が他のものと交換または取引されるときに発生します。 Uniswap は、この種の交換を容易にする自動流動性プロトコルです。これは、2 つの資産のプール予約であるペアまたはプール (以下、ペアと呼びます) を使用し、ユーザーが 1 つの資産を別の資産と交換できるようにします。

図 1.0: Uniswap トークン A および B のプール、および流動性プロバイダー (LP) とトレーダーのスワップと預金の相互作用の例。 LP は流動性を提供するためにプールトークンを受け取ります。

誰かが望む資産が取引したい資産とペアになっていない場合はどうなりますか? この場合、目的の資産を取得するために複数のペアの間で一連のスワップが行われます - これを容易にするために使用されますトランザクションのペアはルートと呼ばれます。

図 2.0: USDC と引き換えに DAI を取引する複数のペアを含むルート。

画像の説明

図 3.0: Paraswap ルーターによって示されたマルチパスルーティング

画像の説明

図 4.0: 複数のルーティング

スリッページとは、資産に対して支払われると予想される価格と実際に支払われる金額との差であり、注文が市場に投入されてから取引が実行されるまでの価格変動、または取引量や流動性の低さなどの要因によって引き起こされます。

ルーターは、トランザクションの数に適したルートを生成するために、これらの要素を考慮する必要があります。また、市況は頻繁に変化し、ガス料金やプールの流動性に影響を与えるため、結果として得られるルートも動的になるため、現在良好なルートが 1 時間後や翌日には必ずしも良好なパフォーマンスを発揮するとは限りません。

この記事の残りの部分では、Uniswap V2 プロトコル以降のルーターの構築と分析に使用できる構成要素について説明します。

最初のレベルのタイトル

データモデリング

注: ここで説明するグラフプロトコルは、次のセクションで説明するグラフデータ型とは異なります。グラフプロトコルは 1 つ以上のスマートコントラクトのブロックチェーントランザクションのインデックスであり、グラフデータタイプは数学的グラフ理論を使用したデータ表現を指します。
マップを使用してポイント間を移動するのと同じように、グラフデータ型を使用して利用可能な流動性ペアを移動し、収益を向上させるために評価できるルートを生成できます。 Uniswap ペアをモデル化する場合、最初に実装を選択する必要があります。
頂点またはエッジとしてのペア、シンボル、またはアセット識別子?

有向か無向か?

シンプルまたは複数の画像?
上記の実装を選択するには、Uniswap ペアのプロパティを理解することが重要です。
各ペアには一意の ID があります。
各ペアには、シンボル、名前、ID のデータペアの 2 つのトークンが含まれています。
トークンシンボルは一意ではありません。たとえば、シンボル BOND は多くの異なる資産や異なる ID を表します。

トークン名も一意である必要はありません。

Uniswap ペアのこれらのプロパティは、グラフデータ型の頂点としてトークン ID を使用することを提案します。グラフの端が ID の一意のペアを表していることがわかります。この形式では、グラフは無向または有向であり、各エッジは ID、トークン価格、およびリザーブのペアを表します。ただし、トークンの価格と予約情報を常に更新する必要があることから、特にリアルタイムトランザクションを使用するアプリケーションの場合、静的分析よりも、適切なリアルタイム設定を使用してこのデータをキャッシュ構造に保存する方が効率的でスケーラブルである可能性があることが示唆されています。

今後は、Uniswap V2 と V3 プロトコルのペア間のルーティングが望ましいと考えられます。このシナリオでは、同じトークン ID のペアが複数存在する可能性があります。 ID のペアの間に追加のエッジを追加することは可能ですが、別の解決策は、異なるペア ID を同じエッジにグループ化して、マルチグラフの走査によるパフォーマンスコストを回避することです。以下は、グループ化されたペア ID の単純な無向グラフの構造の部分的な例です。ここでは、シンボル名がシンボル ID に置き換えられます。

画像の説明

図 5.0: 単純な無向グラフでの Uniswap V2 および V3 プロトコルのペアのモデル化 (実際の構造はトークンシンボルではなくトークン ID を使用しているため、ここでは複雑になることに注意してください)。

当初、深さ優先検索 (DFS) はグラフを横断することが示されており、一般に深さ制限は 4 です。この深さの例外は、接続されているノードの数が 30000 を超える WETH からのルートです。ルートが WETH から出発する場合、通過時間を短縮するために DFS は 2 に制限されます。

グラフデータベース Neo4J や RedisGraph など、グラフデータ型を操作するためのツールは数多くあります。これらの議論はこの記事の範囲を超えており、現在のプロジェクト要件は Javascript ライブラリ Graphlib によって満たされます。ただし、ルーティングの問題が LinkedIn またはその他の大規模ネットワークの規模にまで拡大する場合は、コストと開発の複雑さをトレードオフして、上記のグラフデータベースの規模がこれらのニーズを満たします。

制約

WETH
DAI
USDC
USDT
COMP
MKR

制約は、グラフデータ構造でルートを計算するときに役立ちます。たとえば、限られた数のペアのみを通過するルートを識別したり、特定のアセットを含むペアを無視するために使用したりできます。

既存の Uniswap V2 ルーティングは主に、空港ハブに匹敵する 6 つの資産を経由するルーティングです。これら 6 つの資産は次のとおりです。

これら 6 つの資産は、一般的に使用され、他の資産と組み合わせるときに流動性の制約を課さないため有用です (つまり、希少ではなく、同じリスクを引き起こす証明されていない新しい暗号資産と競合しません)。ただし、これらを使用すると、次に示すように効率上の問題が発生する可能性があります。

「Uniswapは分散型の方法で交換をルーティングしません。」
前述の 6 つの「ピボット」アセットを無視するなどの制約を使用すると、現在の Uniswap V2 インターフェイスがユーザーに提供するものよりも効率的な潜在的なルーティングを探索できます。制約は、次のような他の基準にも拡張できます。

特定の料金設定で特定のプールを経由するルーティング。 (Uniswap V3 プロトコルの場合)。

また、制約は構成可能であること、つまり、ルーティングをそれぞれ X を超える流動性を持つ最大 2 つのプールに制限できるように組み合わせられることも注目に値します。現在のデータモデルは、グラフデータ型とルックアップテーブルの間でデータを分割します。つまり、グラフの走査中とその後の両方でペアデータが検出された場合、ルーティングをプルーニングできるということです。

最初のレベルのタイトル

拡大する
この拡張機能は主に、現在の市場データに基づいてルートを計算するためにパブリック API をルーターに公開することを考慮しています。パフォーマンスは次の関数によって決まります。
ルートを計算する時間

ルーティングリクエストの影響を計算するのに必要な時間

以下の図は、最も頻繁にリクエストされるルートのキャッシュと、ルーティングされたリクエストの影響を計算するために使用されるキャッシュペアデータを備えた初期システムアーキテクチャを示しています。このアーキテクチャは非常に柔軟で、さまざまな方法で水平方向に拡張できます。たとえば、グラフデータ構造とルーティングキャッシュ、リクエストアグリゲータとペアキャッシュを完全に複製するか、単純にキャッシュを複製してキャッシュ間でルーティングリクエストを分散します。

図 6.0: スケーラブルなコンポーネント、キャッシュ、定期的な更新を備えたルーティングサービスアーキテクチャ。

もう 1 つの潜在的なスケーラビリティ変更は、配線要求と数量を考慮した完全な配線ソリューションキャッシュです。数量が特定の許容範囲内であれば、最近計算された結果を再利用できます。ユーザーエクスペリエンスとアプリケーションのニーズに応じて、より正確な結果がユーザーのために計算される一方で、最も最近計算された結果を中間結果として使用することもできます。

ルーティングキャッシュ

ルートキャッシュは、データソースの定期的な更新頻度に関連する存続時間 (TTL) を伴う、最も頻繁に要求されたルートの結果で構成されます。たとえば、WETH と DAI の間のルートが以前にリクエストされていた場合、グラフトラバーサルの結果は、ルートキャッシュ内で可能なルートの配列として見つけることができます: [WETH -> USDC -> DAI、WETH -> WBTC -> DAI] 、...]。トークン価格やリザーブなどのペアデータとは異なり、ルーティング確率 (特にペアの存在) は変化が少ないため、このキャッシュの TTL はペアデータキャッシュよりもはるかに大きくなることが予想されます。さらに、コンポーネントを拡張して、無効なルート (つまり、期限切れまたは置き換えられたトークンアドレスまたは非流動的なペア) のヒューリスティックを含めることができます。

最初のレベルのタイトル

ペアデータキャッシュ

また、ユーザーエクスペリエンスを向上させるために、更新されたデータを取得して計算するときに、古いデータに基づく事前結果が表示される場合があります。

静的解析

最初のレベルのタイトル

ルーティングのパフォーマンスは、生成されたルートを既存の Uniswap V2 ルーターのルートと比較することによって評価されます。具体的には、特定の量のソーストークンに対するペイオフを計算することによって行われます。たとえば、DAI から COMP へのトランザクションでは、100 万個の DAI トークンからどれだけの COMP を受け取るかを計算し、Uniswap V2 ルーターによって提案されたルートから得られる同じ結果を確認することで、ルーターのパフォーマンスが比較されます。パフォーマンスは、さまざまな異なる入力、たとえば、異なる初期数値、異なる検索深さの制限などに対して測定されます。

静的分析を実行する場合、図 6.0 に示すように、データのキャッシュやバンドル要求は必要ありません。静的分析は、ブロックチェーンの特定のブロック時間におけるトランザクションの計算です。これにより、比較のための結果の一貫性と再現性が容易になります。 Uniswap V2 用の新しいルーターを設計する最初の作業範囲は、一連のトランザクションを 1 ブロック時間で評価し、既存のルーティングアルゴリズムまたはバリアントと比較できる静的分析によって支援されました。基礎となるペアのデータが変化した場合、取引結果の改善または低下がアルゴリズムの変更によるものなのか、ペアの流動性や価格設定によるものなのかは明らかではありません。

最初のレベルのタイトル

情報元
ブロックチェーン技術が成熟するにつれて、ブロックチェーン上の現在および過去のデータを提供するサービスが多数登場しました。データソースの選択には、次の考慮事項が含まれます。
予算
開発労力とコスト

遅れ

データの精度

スイッチルータの設計が評価されると、リアルタイムデータには競争力が必要であるため、このデータソースはルート生成には適さないことがわかります。このようなシナリオでは、Alchemy、Infura、またはその他のソースからの Ethereum ノードなど、ブロックチェーンの現在の状態から直接データが必要です。