原作者: エイドリアン・チョウ
Jonathan Yuen と WinterSoldier による寄稿
まとめ
DeFiプロトコルのロックされた価値を保証するためにオラクルは不可欠であり、DeFiのロックアップ総額500億米ドルのうち、330億米ドルがオラクルによって保証されています。
ただし、オラクル価格フィードの更新に固有の時間遅延により、Oracle Extractable Value (OEV) と呼ばれる Maximal Extractable Value (MEV) と呼ばれる価値抽出のサブタイプが発生します。OEV には、Oracle フロントランニング、アービトラージ、および非効率な清算が含まれます。
マイナスの OEV ブリードを防止または軽減するために利用できる設計実装の数は増えていますが、それぞれに独自のトレードオフがあります。この記事では、既存の設計オプションとそのトレードオフについて説明するとともに、2 つの新しいアイデア、その価値提案、未解決の問題、開発のボトルネックを提案します。
導入
オラクルは、今日のDeFiにおいて最も重要なインフラストラクチャの1つであると言えます。これらはほとんどの DeFi プロトコルに不可欠な部分であり、デリバティブ契約の決済、担保不足のポジションのクローズなどを価格フィードに依存しています。現在、オラクルは 330 億米ドルの価値を保証しており、これはチェーン上のロックアップ総額 500 億米ドルの少なくとも 3 分の 2 を占めています 1 。ただし、アプリケーション開発者にとって、オラクルの追加は、フロントランニング、裁定取引、非効率な清算による価値の損失に起因する、明らかな設計上のトレードオフと問題をもたらします。この記事では、この価値の損失をOracle Extractable Value (OEV)として分類し、アプリケーションの観点からその主要な問題を概説し、業界調査に基づいてDeFiプロトコルへのOEVの安全かつ信頼性の高い追加について説明することを試みます。
Oracle 抽出可能値 (OEV)
このセクションでは、読者がオラクルの機能と、プッシュベースとプルベースのオラクルの違いについて基本的に理解していることを前提としています。個々のオラクルの価格フィードは異なる場合があります。概要、分類、定義については、付録を参照してください。
オラクル価格フィードを使用するほとんどのアプリケーションでは、価格の読み取りのみが必要です。独自の価格設定モデルを実行している分散型取引所は、オラクル価格フィードを参照価格として使用します。超過担保ローンポジションの担保の預け入れには、オラクルの読み取りのみが必要です。借入額などの初期パラメータを決定するために価格を取得します。対終値; 価格の更新があまりにも頻繁でないロングテール資産などの極端なケースを除くと、基本的に、システムの設計を検討する際に、オラクルによる価格フィードの更新の遅延は重要ではありません。したがって、オラクルにとって最も重要な考慮事項は、価格寄与者の正確性とオラクルプロバイダーの分散パフォーマンスです。
ただし、価格フィード更新の遅延が重要な考慮事項である場合は、オラクルがアプリケーションとどのように対話するかにさらに注意を払う必要があります。通常、この場合、そのような遅延は、フロントランニング、裁定取引、清算などの価値抽出の機会につながります。 MEV のこのサブタイプは OE V2 と呼ばれます。さまざまな実装とそのトレードオフについて説明する前に、OEV のさまざまな形式について概説します。
裁定取引
オラクルのフロントランニングとアービトラージは、これらの取引が情報の非対称性の下で行われ、多くの場合、流動性プロバイダーの利益を犠牲にしてリスクを伴わないため、デリバティブプロトコルにおける「有害なフロー」として一般に知られています。 Synthetix のような OG DeFi プロトコルは、2018 年からこの問題に取り組んできており、これらの負の外部性を軽減するために時間をかけてさまざまなソリューションを試してきました。
簡単な例で説明します。永久契約の分散型取引所 xyz は、ETH/USD 市場で Chainlink オラクルを使用します。この例では、ETH/USD 価格フィードを使用して次のことを説明します。
図 1: Chainlink オラクルを使用したアービトラージの例
上記は、スリッページ、手数料、資金調達などの要因を考慮していない過度に単純化された例ですが、偏差しきい値の役割によって引き起こされる価格粒度の欠如から生じる機会を示しています。検索者は、スポット市場価格更新のレイテンシーを監視し、Chainlink のオンチェーン ストレージに基づいて流動性プロバイダー (LP) からゼロリスク価値を抽出できます。
最前線の
フロントランニングは、アービトラージと同様、価値抽出の別の形式であり、サーチャーがオラクルの更新のためにメモリプールを監視し、オンチェーンでコミットする前に実際の市場価格をフロントランします。このようにして、検索者はオラクルが更新される前に入札して取引する時間があり、取引の方向に有利な価格で取引が完了します。
GMX のような永久契約の分散型取引所は常に有害なフロントランニングの犠牲者であり、GMX のすべてのオラクルが KeeperDAO 調整プロトコルを通じて更新される前は、プロトコルの利益の約 10% がフロントランニングによって失われていました 4 。
プルモデルだけを採用したらどうなるでしょうか?
Python の価値提案の 1 つは、Solana アーキテクチャに基づく Python を使用することで、パブリッシャーが価格更新を 300 ミリ秒ごとにネットワークにプッシュできることです 5 。これにより、低遅延の価格フィードを維持できます。したがって、アプリケーションが Pyth のアプリケーション プログラミング インターフェイス (API) を通じて価格をクエリすると、最新の価格を取得してターゲット チェーンのオンチェーン ストレージに更新し、単一のトランザクションでアプリケーション ロジックのダウンストリーム操作を実行できます。
上で述べたように、アプリケーションは Python に直接クエリして最新の価格更新を取得したり、オンチェーン ストレージを更新したり、関連するすべてのロジックを 1 つのトランザクションで完了したりできます。
それだけではありません。トランザクションで使用する価格をユーザーが選択できるようにする Pyth の更新は、逆選択につながる可能性があります (これも毒の比喩です)。価格は長期にわたってオンチェーンに保存する必要がありますが、ユーザーはこれらの制約を満たす任意の価格を選択できます。つまり、検索者は過去の価格を使用する前に将来の価格を確認できるため、裁定取引が依然として存在します。 Pyth のドキュメント 6 では、この攻撃ベクトルから保護する簡単な方法は、価格が十分に新しいことを確認するために失効チェックを追加することであると示唆しています。ただし、次のブロックでトランザクション データを更新する前に一定のバッファ時間が必要です。最適な時間閾値は?
分析の例として永久契約の分散型取引所 xyz を取り上げます。今回は Pyth ETH/USD 価格フィードを使用しており、有効期限チェック時間は 20 秒です。これは、Pyth 価格のタイムスタンプが実行中である必要があることを意味します。ダウンストリーム トランザクションのブロック タイムスタンプから 20 秒以内:
図 2: Pyth を使用したフロントランニングのサンプル プロセス
直感的なアイデアは、単に有効期限チェックのしきい値を下げることですが、しきい値を低くすると、ブロック時に予測できないネットワーク応答が発生する可能性があり、ユーザー エクスペリエンスに影響を与える可能性があります。 Pyth の価格フィードはブリッジングに依存しているため、a) ワームホール ガーディアンが価格を証明する時間を提供し、b) ターゲット チェーンがトランザクションを処理してブロックに含めることができるようにするために、十分なバッファリングが必要です。これらのトレードオフについては、次のセクションで詳しく説明します。
クローズポジション
ポジションのクローズはレバレッジを伴う契約の中核部分であり、価格フィードの更新の粒度はポジションのクローズの効率を決定する上で重要な役割を果たします。
しきい値ベースのプッシュオラクルの場合、スポット価格がしきい値に達しても、オラクルの価格フィードの事前設定パラメーターを満たさない場合、価格更新の粒度（または粒度の欠如）により、価格更新の機会が失われることになります。ポジションをクローズします。これにより、市場の非効率性という形で負の外部性が生じます。
清算が発生すると、多くの場合、アプリケーションは清算担保の一部を支払い、場合によっては清算を開始したユーザーに報酬を提供します。たとえば、2002 年に Aave はメインネットだけで清算報酬として 3,790 万ドルを支払いました 7 。これは明らかにサードパーティを過剰に補償し、ユーザーのパフォーマンスを低下させます。さらに、抽出可能な価値がある場合、その後のガス戦争によりアプリケーションから価値が流出し、MEV サプライ チェーンに流れます。
設計スペースと考慮事項
上記の問題を考慮して、プッシュ、プル、および代替設計に基づくさまざまな実装ソリューションについて以下で説明しますが、それぞれが上記の問題と関連するトレードオフを解決するのに効果的です。トレードオフは追加の集中化の形で発生する可能性があります。信頼の前提条件、またはユーザーエクスペリエンスが低い。
オラクル専用のオーダー フロー オークション (OFA)
オーダーフロー入札 OFA は、MEV によって生成される負の外部性を排除するソリューションとして登場しました。大まかに言えば、OFA は汎用のサードパーティ入札サービスであり、ユーザーはこのサービスに注文 (取引またはインテント) を送信でき、MEV を抽出するサーチャーは自分の注文で戦略を実行する独占的権利を入札できます。オークション収益の大部分は、ユーザーがこれらの注文で生み出した価値を補うためにユーザーに還元されます。 OFA の採用率は最近急上昇しており、イーサリアム トランザクションの 10% 以上がプライベート チャネル (プライベート RPC/OFA) を通じて行われており (図 3)、これが成長をさらに促進すると考えられています。
図 3: プライベート イーサリアム トランザクションの毎日の統合数。出典: ブロックネイティブ
オラクルの更新にユニバーサル OFA を実装する場合の問題は、標準ルールに基づく更新によって OEV が生成されるかどうかをオラクルが知る方法がなく、生成されない場合、オラクルがトランザクションをオークションに送信するときに追加の遅延が発生することです。一方、OEV を合理化し、待ち時間を最小限に抑える最も簡単な方法は、すべてのオラクル注文フローを単一の支配的なサーチャーにフィードすることです。しかし、これは明らかに集中化の大きなリスクをもたらし、レントシーキング行為や検閲を促進し、ユーザーエクスペリエンスの低下につながる可能性があります。
図 4: 一般的な OFA と Oracle 固有の OFA
既存のルールベースの更新を含まないオラクル固有の OFA の価格更新は、引き続きパブリック メモリプールで行われます。これにより、オラクルの価格更新と、その結果として得られる抽出可能な値をアプリケーション層に残すことができます。副産物として、Oracle ノードがより頻繁な更新に伴う追加コストを負担することなく、検索者がデータ ソースの更新をリクエストできるようになり、データの粒度も向上します。
オラクル固有のOFAは、よりきめ細かい価格更新を実現し、ポジションが清算される借り手に資本のリターンを最大化し、清算人に支払われるプロトコル報酬を削減し、プロトコルで抽出される値を削減できるため、ポジションの清算に最適です。ビッダーはユーザーに再配布するためにビッダー内に保持されます。また、フロントランニングとアービトラージの問題も完全ではありませんが、ある程度解決されます。完全競争および初値固定入札オークション プロセスの下では、オークションの結果は、最前線の OEV データ フィードから抽出された実行機会 8 の値に近いブロック スペース コストになるはずであり、また、価格フィード更新の価格粒度の向上。
現在、オラクル固有の OFA を実装するには、サードパーティの入札サービス (OEV-Share など) に参加するか、アプリケーションの一部として入札サービスを構築する必要があります。 Flashbot からインスピレーションを得た API 3 は、入札用の DoS 保護サービスを実行するように設計された API として OEV リレー (図 5) を利用します。このリレーは、オラクルからメタトランザクションを収集し、検索者の入札を照合して集計し、入札を制御することなくトラストレスな方法で収益を再分配する責任を負います。サーチャーが入札に勝った場合、データ ソースの更新は、入札金額をプロトコル所有のプロキシ コントラクトに転送することのみに依存し、プロキシ コントラクトは中継者によって提供された署名付きデータで価格ソースを更新します。
図 5: API 3 の OEV リピーター
あるいは、プロトコルは仲介者を排除し、OEV から抽出されたすべての価値を取得する独自の入札サービスを構築することもできます。 BBOX は、OEV を捕捉してアプリケーションとそのユーザーに返すための清算メカニズムに入札を組み込むことを望んでいる次期プロトコルの 1 つです 9 。
セントラルノードまたはKeeperを実行する
OEV に対抗するための永久契約分散型取引所の第一波から生まれた初期のアイデアは、集中型キーパー ネットワーク (ゲートキーパー ネットワーク) を実行して、サードパーティ ソース (集中型取引所など) から受け取った価格を集約し、その後、Chainlink のようなデータ フィードを活用することでした。緊急時対応計画またはサーキットブレーカー。このモデルは、GMX v1 10 とそれに続く多くのフォークで普及しました。その主な価値提案は、Keeper ネットワークが単一のオペレーターによって実行されるため、フロントランニングから完全に保護されることです。
これにより、上で述べた問題の多くは解決されますが、明らかに集中化に関する懸念があります。集中管理された Keeper システムは、価格設定ソースや集計方法を適切に検証せずに約定価格を決定する可能性があります。 GMX v1 の場合、Keeper はオンチェーンまたは透過的なメカニズムではなく、集中サーバー上で実行されるチームのアドレスによって署名されたプログラムです。 Keeper の中核的な役割は、注文を実行するだけでなく、独自の事前設定された定義に従って注文を実行することでもあります。"決める"取引価格、使用された約定価格の信頼性または出所を検証する方法はありません。
自動化されたキーパーネットワークとチェーンリンクのデータフロー
単一オペレーターの Keeper ネットワークによってもたらされる前述の集中化リスクの解決策は、サードパーティのサービス プロバイダーを使用して、より分散化された自動化ネットワークを構築することです。 Chainlink Automation はそのような製品の 1 つであり、新しいプルベースの低遅延オラクルである Chainlink Data Streams と組み合わせてこのサービスを提供します。この製品は最近リリースされ、現在クローズド ベータ版ですが、GMX v2 11 ではすでに使用されており、この設計を使用するシステムのリファレンスとして役立ちます。
概要として、Chainlink データ フローは、データ DON (分散型オラクル ネットワーク)、自動化 DON、およびオンチェーン検証コントラクトの 3 つの主要な部分で構成されます 12 。 Data DON は、Python がデータを維持および集約する方法と同様のアーキテクチャを備えたオフチェーン データ ネットワークです。自動化された DON は、データ DON と同じノード オペレーターによって保護されたガーディアンのネットワークであり、オンチェーンのデータ DON から価格を抽出するために使用されます。最後に、バリデーターコントラクトを使用して、オフチェーン署名が正しいことを検証します。
図 6: Chainlink データ フロー アーキテクチャ
上の図は、オープン トランザクション関数を呼び出すトランザクション プロセスを示しています。このプロセスでは、自動 DON がデータ DON から価格を取得し、オンチェーン ストレージを更新します。現在、データ DON に直接クエリを実行するエンドポイントはホワイトリスト ユーザーに限定されているため、プロトコルは Keeper のメンテナンス作業を Automation DON (Automation DON) にオフロードするか、独自の Keeper を実行するかを選択できます。しかし、製品開発ライフサイクルが進むにつれて、これが徐々に許可のない構造に移行することが予想されます。
セキュリティ レベルでは、自動化された DON に依存する信頼の前提条件は、データ DON のみの場合と同じです。これは、単一の Keeper 設計に比べて大幅に改善されています。ただし、価格フィードを更新する権限が自動 DON に与えられている場合、価値抽出の機会は Keeper ネットワーク内のノードにのみ残されます。これは、プロトコルが LinkToken ノード オペレーター (主に機関) の社会的評判を維持し、ユーザーの操作を横取りしないことを信頼することを意味します。これは、Lido ノード ノード オペレーターを信頼するのではなく、評判を維持することを信頼するのと似ています。そしてブロックスペースを独占します
プル: 遅延決済
Synthetix perps v2 の最大の変更点の 1 つは、無期限契約決済 13 用の Python 価格フィードの導入です。これにより、事前定義されたしきい値を超えて逸脱せず、タイムスタンプが有効期限チェックに合格した場合に限り、注文を Chainlink または Pyth 価格で決済することができます。ただし、前述したように、プルベースのオラクルに切り替えるだけでは、すべてのプロトコルの OEV 関連の問題が解決されるわけではありません。フロントランニングの問題を解決するには、遅延注文の形で導入することができます。"最後に閲覧した"価格設定メカニズム。実際には、これによりユーザーの市場注文が 2 つの部分に分割されます。
トランザクション #1: オンチェーンで送信して成行注文をオープンします"意図"、サイズ、レバレッジ、担保、スリッページ許容範囲などの標準的な注文パラメーターを提供します。同時に、トランザクション #2 の実行に対してキーパーに報酬を与えるために、追加のキーパー料金が必要です。
トランザクション #2: Keeper はトランザクション #1 で送信された注文を受け取り、最新の Python 価格フィードをリクエストし、Synthetix を呼び出して 1 つのトランザクションで契約を実行します。契約では、適時性や価格スリッページなどの事前定義されたパラメータがチェックされ、両方が合格した場合、注文が実行され、オンチェーンの価格ストレージが更新され、ポジションが確立されます。キーパーは、ネットワークの使用と維持に使用したガスを補うために料金を請求します。
この実装では、ユーザーがオンチェーンで送信された価格を逆に選択する機会を与えず、プロトコルのフロントランニングと裁定取引の機会を効果的に解決します。ただし、この設計のトレードオフはユーザー エクスペリエンスです。この成行注文の実行には 2 つのトランザクション プロセスが必要です。ユーザーは Keeper 操作のガスを補償し、オラクル チェーン上のストレージを更新するコストを共有する必要があります。以前は 2 sUSD の固定料金でしたが、最近、オプティミズム ガス オラクル + プレミアムに基づく動的料金に変更されました。この料金は、レイヤー 2 ネットワーク アクティビティに基づいて変化します。いずれにせよ、これはトレーダーのユーザーエクスペリエンスを犠牲にしてLPの収益性を向上させる解決策と見なすことができます。
プル型：楽観決済
注文が遅延すると、ユーザーに追加のネットワーク料金（第 2 層ネットワークの DA 料金に比例）が発生するため、ブレーンストーミングの結果、別の注文決済モデルを考案しました。"ポジティブ決済"、このモデルは、プロトコルの分散化とセキュリティを維持しながら、ユーザーのコストを削減する可能性があります。名前が示すように、このメカニズムではトレーダーが市場取引をアトミックに実行できるようになり、システムはすべての価格を積極的に受け入れ、検索者が注文が悪意を持って行われたという証拠を提出する窓口を提供します。このセクションでは、このアイデアのさまざまなバージョン、私たちの思考プロセス、および未解決の問題について概説します。
私たちの最初のアイデアは、ユーザーが成行注文を開くときに parsePriceFeedUpdates を介して価格を送信できるようにし、ユーザーまたは第三者が価格フィード データを使用して決済トランザクションを送信できるようにし、その価格でトランザクションを完了できるようにするメカニズムを構築することでした。取引が確認されました。決済時に、2 つの価格間のマイナスの差がスリッページとしてユーザーの損益計算書に組み込まれます。このアプローチの利点には、ユーザーのコスト負担の軽減とフロントランニングのリスクの軽減が含まれます。ユーザーは防御側に報酬を与えるプレミアムを負担する必要がなくなり、注文が送信される時点では決済価格がわからないため、フロントランニングのリスクは依然として管理可能です。ただし、これでも 2 段階の決済プロセスが導入されます。これは、Synthetix の繰延決済モデルで発見された欠点の 1 つです。ほとんどの場合、注文と決済の間のボラティリティがシステムで定義された収益性の高いフロントランニングしきい値を超えない場合、追加の決済トランザクションは不要になる可能性があります。
上記の問題を回避するもう 1 つの解決策は、システムが積極的に注文を受け入れ、その後、価格タイムスタンプとブロック タイムスタンプの間の価格偏差の続行が許可されていることを証明する証拠を提出できる、許可のないチャレンジ期間を開くことを許可することです。セールを実施中。
具体的な操作は以下の通りです。
ユーザーは現在の市場価格に基づいて注文を作成します。次に、埋め込まれた Python 価格フィードのバイト データとともに価格を注文作成トランザクションとして渡します。
スマート コントラクトは、この情報を積極的に検証して保存します。
注文がオンチェーンで確認された後、検索者が逆選択の証拠を提出できるチャレンジ期間が設けられます。この証拠は、トレーダーがシステムの裁定取引を目的として古い価格フィード データを使用したことを裏付けるものとなります。証明がシステムに受け入れられた場合、その差額はスリッページとしてトレーダーの約定価格に適用され、超過額は報酬としてキーパーに与えられます。
チャレンジ期間の後、システムはすべての価格を有効であるとみなします。
このモデルには 2 つの利点があります: ユーザーのコスト負担が軽減される: ユーザーは、追加の決済トランザクションを必要とせず、同じトランザクションで注文作成とオラクル更新のガス料金のみを支払う必要があります。また、フロントランニングを防止し、流動性プールの完全性を保護し、フロントランニングを証明する証拠をシステムに提出するための金銭的インセンティブを備えた健全な Keeper ネットワークを確保します。
ただし、このアイデアを実践する前に解決すべき問題がまだいくつかあります。
意味"逆選択": システムは、ネットワークの遅延により期限切れの価格を送信するユーザーと、意図的に裁定取引を行うユーザーをどのように区別しますか?最初のアイデアは、有効期限チェック期間 (たとえば 15 秒) 内のボラティリティを測定し、ボラティリティが正味約定手数料を超えた場合、注文に潜在的なエクスプロイトとしてフラグを立てるというものです。
適切なチャレンジ期間を設定する: 有毒な注文フローが短期間しかオープンしない可能性があることを考慮すると、キーパーが価格にチャレンジするための適切な時間枠はどれくらいでしょうか?バッチ プルーフの方がコスト効率は高いかもしれませんが、時間の経過とともに注文の流れが予測できないことを考えると、すべての価格情報が証明されるか、異議を申し立てるのに十分な時間を確保するためにバッチ プルーフの時間を調整することは困難です。
キーパーへの経済的報酬: 経済的に奨励されているキーパーにとってプルーフの提出が合理的であるためには、勝利したプルーフの提出に関連する報酬が、プルーフの提出に関連するガスコストよりも大きくなければなりません。注文サイズが異なるため、この仮定は保証されない場合があります。
注文のクローズにも同様のメカニズムが必要ですか?もしそうなら、ユーザーエクスペリエンスはどのように低下しますか?
「不当な」スリッページがユーザーに降りかからないようにする: フラッシュクラッシュが発生した場合、注文の作成とオンチェーンの確認の間に非常に大きな価格差が生じる可能性があります。何らかのフォールバックまたはサーキット ブレーカーが必要になる場合があるため、使用前に価格フィードの安定性を確保するために Pyth の EMA 価格の使用を検討してください。
ZK コプロセッサ - 別の形式のデータ消費
探求する価値のあるもう 1 つの方向は、ZK 補助プロセッサの使用です。ZK 補助プロセッサは、オフチェーンで複雑な計算を実行するためにオンチェーンの状態を取得し、同時に計算がどのように実行されるかの証明を提供するように設計されています。この方法は許可なく使用できます。確認する。 Axiom などのプロジェクトにより、コントラクトは過去のブロックチェーン データをクエリし、オフチェーンで計算を実行し、計算結果が有効なオンチェーン データに基づいて正しく計算されたことを証明する ZK 証明を提出できるようになります。セカンダリプロセッサは、複数のDeFiネイティブ流動性ソース（Uniswap + Curveなど）からの過去の価格を使用して、操作耐性を備えたカスタムTWAPオラクルを構築する可能性を開きます。
現在最新の資産価格データのみにアクセスできる従来のオラクルと比較して、ZK 補助プロセッサは、安全な方法で dApps に提供されるデータの範囲を拡大します (Pyth は、開発者が最新の資産価格のリファレンス チェックとして使用できる EMA 価格を提供します)価格）。これにより、アプリケーションは履歴ブロックチェーン データを操作するビジネス ロジックをさらに導入して、プロトコルのセキュリティを向上させたり、ユーザー エクスペリエンスを向上させることができます。
ただし、ZK 補助プロセッサはまだ開発の初期段階にあり、次のようなボトルネックがいくつかあります。
補助プロセッサ環境では、大量のブロックチェーン データの取得と計算に長い証明時間が必要になる場合があります
ブロックチェーン データのみを提供しても、非 Web3 アプリケーションとの安全な通信のニーズには対応できません。
オラクルレスのソリューション – DeFi の未来?
この問題を解決するもう 1 つの方法は、プリミティブを最初から設計することで外部の価格フィードの必要性を排除することです。
DeFi のオラクルへの依存を解決します。この分野の最新の開発は、価格設定手段としてのさまざまな AMM LP トークンの使用です. 中心となるアイデアは、定数関数マーケット メーカーの LP ポジションは 2 つの資産の事前設定されたウェイトを表すトークンであり、2 つのトークンがあるということです。自動価格設定式 (つまり、xy=k)。 LP トークンを (担保、ローンベースとして、または最近の使用例では v3 LP ポジションを別のティックポイントに移動するために) 利用することにより、プロトコルは通常はオラクルから取得される情報を取得できます。その結果、上記の課題から解放されたオラクルレス ソリューションの新しい波が実現しました。この方向性に基づくアプリケーション例には次のものがあります。
Panoptic は、Uniswap v3 の集中流動性ポジションを活用して、恒久的なオラクルレスのオプション プロトコルを構築しています。スポット価格が LP ポジションの上限を超えると、集中流動性ポジションは原資産に 100% 変換されるため、流動性プロバイダーへの収益はプット オプションの売り手への収益と非常に似ています。したがって、オプション市場は、流動性プロバイダーがLP資産またはポジションを預け、オプションの買い手と売り手が流動性を借りてレンジ内またはレンジ外に移動することによって機能し、それによって動的なオプションの収益が生成されます。ローンはLPポジション建てであるため、決済にオラクルは必要ありません。
Infinity Poolsは、Uniswap v3の一元化された流動性ポジションを活用して、清算やオラクルのないレバレッジド取引プラットフォームを構築しています。 Uniswap v3 の流動性プロバイダーは LP トークンを貸し出すことができ、トレーダーは担保を預け、LP トークンを借りて、方向性取引関連資産を償還します。償還時のローンは、償還時の価格に応じて資産ベースまたは相場資産建てで指定され、Uniswap で LP 構成を確認することで直接計算できるため、オラクルへの依存はなくなります。
Timeswap は、期限付き、清算なし、オラクルなしの融資プラットフォームを構築しています。これは、貸し手、借り手、流動性プロバイダーで構成される三者市場です。従来の融資市場とは異なり、"時間ベース"（「時間ベースの」）清算ではなく"価格ベース"(価格ベースの) ポジションのクローズ。分散型取引所では、流動性プロバイダーは常に売り手から買い、買い手に売るように自動的に設定されますが、タイムスワップでは、流動性プロバイダーは常に借り手に貸し、市場の貸し手から借ります。彼らはローン不履行にも責任を負い、没収された担保を補償として優先的に受け取ることができます。
結論は
価格データは依然として多くの分散型アプリケーションの重要な部分を占めており、オラクルが獲得する合計価値は時間の経過とともに増加し続けており、オラクルの製品市場適合性（p 製品市場適合性）がさらに確認されています。この記事の目的は、読者に情報を提供し、現在直面している OEV 関連の課題の概要と、AMM 流動性プロバイダーやオフチェーン補助を使用したプッシュ、プル、その他の設計に基づく実装の設計空間を提供することです。プロセッサー。
私たちは、これらの難しい設計上の課題を解決しようとしている精力的な開発者に会えることを楽しみにしています。あなたもこの分野で破壊的なプロジェクトに取り組んでいるのであれば、ぜひご連絡ください。
参考文献と謝辞
この記事に大きく貢献した Jonathan Yuen と WinterSoldier の寄稿と会話に感謝します。
貴重なコメント、フィードバック、レビューをくださった Erik Lie、Richard Yuen (Hailstone)、Marc、Mario Bernardi、Anirudh Suresh (Pyth)、Ugur Mersin (API 3 DAO)、および Mimi (Timeswap) に感謝します。
https://defillama.com/oracles(14 Nov) ↩︎
OEV Litepaper https://drive.google.com/file/d/1wuSWSI8WY9ChChu2hvRgByJSyQlv_8SO/edit
Frontrunning on Synthetix: A History by Kain Warwick https://blog.synthetix.io/frontrunning-synthetix-a-history/
https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand↩︎
https://docs.pyth.network/documentation/solana-price-feeds/best-practices#latency↩︎
Aave liquidation figures https://dune.com/queries/3247324
https://drive.google.com/file/d/1wuSWSI8WY9ChChu2hvRgByJSyQlv_8SO/edit
https://gmx-io.notion.site/gmx-io/GMX-Technical-Overview-47fc5ed832e243afb9e97e8a4a036353
https://gmxio.substack.com/p/gmx-v2-powered-by-chainlink-data ↩︎
︎
付録
定義: プッシュ オラクルとプル オラクル
プッシュ オラクル マシンは、P2P ネットワーク内のオフチェーン価格を維持し、事前定義されたオンチェーン ノードに基づいて価格の更新を維持します。 Chainlinkを例に挙げると、価格の更新は、偏差しきい値（偏差しきい値）とハートビート（ハートビート）という2つのトリガーパラメータに基づいています。以下のイーサリアム ETH/USD 価格フィードは、オフチェーン価格が最新のオンチェーン価格から 0.5% 逸脱するか、1 時間のハートビート タイマーがゼロになるたびに更新されます。
この場合、オラクルオペレーターは価格更新ごとに取引手数料を支払う必要がありますが、これはコストとスケーラビリティのトレードオフになります。価格ソースの数を増やしたり、追加のブロックチェーンをサポートしたり、より頻繁な更新を追加したりすると、追加のトランザクションコストが発生します。したがって、より高いトリガーパラメーターを持つロングテール資産には、必然的に信頼性の低い価格ソースが含まれます。これを説明するために CRV/USD を例に挙げてみましょう。新しい価格がチェーン上で更新されるためには、24 時間のハートビートで 1% の偏差しきい値が必要です。つまり、価格が 24 時間偏差しない場合は、 24 時間以内に 1% を超える場合、新しい価格の更新は 24 時間ごとに 1 回のみとなります。直観的には、ロングテール資産の価格ソースの粒度が欠如しているため、これらの資産の市場を作成する際にアプリケーションは必然的に追加のリスク要因を考慮する必要が生じ、これが DeFi 活動の大部分が依然として最も流動性の高い資産を中心に展開している理由を説明しています。最強かつ最大の時価総額トークンを使用します。
対照的に、プルオラクルでは、オンデマンドで価格をチェーンにプルすることができます。 Pyth は今日最も顕著な例であり、オフチェーンで価格更新を送信し、誰もがその信頼性を検証できるように各更新に署名し、Solana コード チェーンに基づくプライベート ブロックである Pythnet で総価格を維持します。更新が必要な場合、データはワームホール経由で転送され、Python で検証された後、許可なくチェーンにプルされます。
上の図は、Pyth 価格フィードの構造を示しています: チェーン上の価格を更新する必要がある場合、ユーザーは Pyth API を通じて更新をリクエストできます。Pythnet 上で検証された価格は、ワームホール コントラクトに送信されます。ワームホール コントラクトは、場所名 VAA を観察、作成、送信します。これは、Pyth コントラクトがデプロイされているブロックチェーン上で検証できます。
免責事項: この記事は投資アドバイスを構成するものではありません。ユーザーは、この記事の意見、見解、結論が自分の特定の状況と一致するかどうかを検討し、居住する国や地域の関連法規に従う必要があります。
