なぜソラナにはProp AMMが溢れているのに、EVM上はまだ空白なのか?

原文タイトル:Monadメインネットローンチ後の必見dApps

原著者:オプティマス

オリジナルソース:

転載:マーズファイナンス

プロップAMMは、Solanaの全取引量の40%を迅速に占めています。なぜ彼らはEVM上にまだ登場していないのでしょうか?

プロプライエタリAMM(Proprietary AMMs、略してProp AMMs)は、Solana DeFiエコシステムの中で急速に主導的な力となっており、現在、主要な取引ペアの40%以上の取引量を貢献しています。このようなプロのマーケットメーカーが運営する専門的な流動性プラットフォームは、深い流動性とより競争力のある価格設定を提供することができ、その核心的な理由は、マーケットメーカーが「古い見積もり」(stale quotes)を利用されてフロントラン(front-running)アービトラージのリスクを大幅に低下させるからです。

しかし、それらの成功はほぼ完全にSolanaに限定されています。BaseやOptimismのような高速かつ低コストのLayer 2ネットワークでも、EVMエコシステムにおいてProp AMMの姿はほとんど見られません。それらがEVMに根付かなかったのはなぜでしょうか?

本稿では、3つの問題について考察します。Prop AMMとは何か、EVMチェーン上で直面する技術的および経済的障害、そして最終的にそれらをEVM DeFiの最前線に導く可能性のある新しい有望なアーキテクチャについてです。

Prop AMMとは何ですか?

Prop AMMは、従来のAMMのように大衆が受動的に資金を提供するのではなく、単一の専門的なマーケットメイカーが流動性と価格を積極的に管理する自動マーケットメイカーです。

従来のAMM(例えばUniswap v2)は、価格を決定するために式x * y = kを使用します。ここでxとyはプール内の2種類の資産の数量を表し、kは定数です。しかし、Prop AMMでは、価格設定の公式は固定されておらず、高頻度で更新されます(通常は毎秒何度も更新されます)。ほとんどのProp AMMの内部メカニズムは「ブラックボックス」であり、外部はそれらが使用している正確なアルゴリズムを知ることができません。しかし、Suiチェーン上のObricのProp AMMスマートコントラクトコードは公開されています(@markoggwpの発見に感謝します)。その不変量kは、内部変数mult_x、mult_y、およびconcentrationに依存しています。下の図は、マーケットメイカーがどのようにこれらの変数を持続的に更新するかを示しています。

明確にする必要があるのは、Obricの価格曲線の左側の公式は単純なx*yよりも複雑であるが、Prop AMMの理解の鍵は、常に可変の不変量kに等しいということであり、マーケットメーカーは価格曲線を調整するためにこのkを常に更新するということです。

復習:AMMはどのように価格を決定するのか?

この記事では、「価格曲線」という概念が何度も言及されます。価格曲線は、ユーザーがAMM取引を行う際に支払う必要のある価格を決定し、また、Prop AMMにおいてマーケットメーカーが継続的に更新する部分でもあります。この点をよりよく理解するために、まず伝統的なAMMの価格設定方法を振り返ることができます。

Uniswap v2のWETH-USDCプールを例にとると(手数料はないと仮定します)。価格は公式x * y = kによって受動的に決定されます。プールに100 WETHと400,000 USDCがあると仮定すると、この時の曲線の点はx = 100、y = 400,000で、初期価格は400,000 / 100 = 4,000 USDC/WETHになります。これにより、定数k = 100 * 400,000 = 40,000,000が得られます。

取引者が1 WETHを購入したい場合、プールにUSDCを追加する必要があり、プール内のWETHは99に減少します。定数積kを維持するために、新しい点(x, y)は曲線上に留まる必要があるため、yは40,000,000 / 99 ≈ 404,040.40に変わる必要があります。つまり、この取引者は1 WETHのために約4,040.40 USDCを支払ったことになり、初期価格よりも少し高くなります。この現象は「スリッページ」(slippage)と呼ばれます。x*y=kが「価格曲線」と呼ばれる理由は、任意の取引可能な価格はこの曲線上に存在しなければならないからです。

なぜマーケットメーカーは中央集権型オーダーブック(CLOB)ではなくAMM設計を選択するのでしょうか?

マーケットメイカーがAMMデザインを使用してマーケットメイキングを行う理由を説明しましょう。あなたがオンチェーンの中心限界注文書(CLOB)で見積もりを出しているマーケットメイカーだと想像してください。見積もりを更新したい場合、数千を超えるリミットオーダーを取り消して置き換える必要があります。もしあなたがN個の注文を持っているなら、更新コストはO(N)レベルの操作であり、これはオンチェーンでは遅く、高価です。

そして、もしすべての価格を1つの数学的な曲線で表現できるとしたらどうでしょうか?その場合、曲線を定義する数少ないパラメータを更新するだけで、O(N)の操作をO(1)の定数時間複雑度に変換できます。

「価格曲線」が異なる有効価格帯にどのように対応するかを直感的に示すために、Ellipsis Labs が作成した SolFi——Solana に基づく Prop AMM を参照することができます。その具体的な価格曲線は不明で隠されていますが、Ghostlabs が図を描いて、ある Solana スロット(ブロック時間帯)内で、異なる数量の SOL が USDC に交換されるときの有効価格を示しています。各ラインは異なる WSOL/USDC プールを表し、複数の価格レベルが同時に存在できることを示しています。マーケットメイカーが価格曲線を更新するにつれて、この有効価格図も異なるスロット間で変化します。

ここでの重要なポイントは、少数の価格曲線パラメータを更新することで、マーケットメイカーがN個の注文を個別に変更することなく、有効価格分布を随時変更できるということです。これがProp AMMの核心的な価値提案であり、マーケットメイカーがより高い資本と計算効率で、動的かつ深い流動性を提供できるようにします。

なぜSolanaのアーキテクチャがProp AMMに非常に適しているのか?

Prop AMMは「アクティブ管理型」システムであり、これには2つの重要な条件が必要です。

1.安価なアップデート

  1. 優先執行

Solanaでは、これら二つは相互に補完し合っています:低コストの更新は、しばしば更新が実行の優先権を得ることを意味します。

なぜマーケットメイカーはこの2点を必要とするのか?まず、彼らは在庫の変化や資産インデックス価格(例えば、中央集権型取引所の価格)の変動に基づいて、ブロックチェーンの運行速度に応じて価格曲線を継続的に更新します。Solanaのような高頻度のチェーンでは、更新コストが高すぎると高頻度調整を実現するのが難しくなります。

次に、マーケットメーカーが更新をブロックの最上部に置けない場合、彼らの古い見積もりはアービトラージャーによって「拾われ」、必然的な損失を引き起こします。この2つの特性が欠けていると、マーケットメーカーは効率的に操作できず、ユーザーもより悪い取引価格を得ることになります。

Solana上のProp AMM HumidiFiを例にすると、@SliceAnalyticsのデータによれば、このマーケットメイカーは毎秒最大74回の価格を更新しています。

EVM のプレイヤーは、「Solana のスロットは約 400ms ですが、Prop AMM はどのようにして単一のスロット内で価格を何度も更新できるのですか?」と疑問に思うかもしれません。

答えは、Solanaの連続アーキテクチャにあります。これは、本質的にEVMの離散ブロックモデルとは異なります。

· EVM:トランザクションは通常、完全なブロックが提案されて最終確認された後に順次実行されます。これは、途中で送信された更新が次のブロックでのみ有効になることを意味します。

· Solana:リーダー検証ノードは完全なブロックを待たず、取引を小さなデータパケット(「shred」と呼ばれる)に分割し、ネットワークに連続してブロードキャストします。1つのスロット内に複数の交換がある可能性がありますが、shred #1 的价格更新影响 swap #1、shred #2 的价格更新影响 swap #2。

注:Flashblocks は Solana の shred に似ています。Anza Labs の @Ashwinningg が CBER 会議での発表で述べたように、各 400ms のスロットの上限は 32,000 shred で、これは毎ミリ秒 80 個の shred に相当します。200ms の Flashblocks がマーケットメイカーの需要を満たすのに十分な速さであるかどうかは、Solana の連続アーキテクチャと比較して依然として未解決の問題です。

では、Solana 上のアップデートはなぜそんなに安価なのでしょうか?そして、どのようにして優先実行を引き起こすのでしょうか?

まず、Solana上のProp AMMの実装はブラックボックスですが、CUの最適化方法でSolanaプログラムを書くためのPinocchioのライブラリがあります。Heliusのブログではこれについて素晴らしい紹介があり、このライブラリを通じて、SolanaプログラムのCU消費を約4000 CUから約100 CUに削減することができます。

次に第二部を見てみましょう。より高いレベルでは、SolanaはFee / Compute Unitsの比率が最も高いトランザクションを優先的に選択します(Compute UnitsはEVMのGasに似ています)。

· 具体的に言うと、Jitoを使用する場合、公式はJito Tip / コンピュートユニットです。

· 未使用: Priority = ( Priority Fee + Basic Fee ) / (1 + CU Limit + Signature CU + Write Lock CU)

Prop AMMの更新とJupiter Swapのコンピュートユニットを比較すると、更新は非常に安価であり、比率は1:1000に達します。

Prop AMM の更新:シンプルなカーブが非常に安価に更新されました。Wintermute の更新は 109 CU まで低下し、総費用はわずか 0.000007506 SOL です。

ジュピタースワップ:ジュピタールーティングを通じてのスワップは約100,000 CUに達し、総費用は0.000005 SOLです。

この巨大な差異のため、マーケットメーカーは更新取引に対して非常に少ない手数料を支払うだけで、交換のFee/CU比率を大幅に上回ることができるため、更新がブロックの先頭で実行されることを保証し、アービトラージ攻撃から自らを保護します。

なぜ Prop AMM は EVM 上にまだ実装されていないのですか?

Prop AMMの更新が、取引ペアの価格曲線を決定する変数の書き込みを含むと仮定します。Solana上のProp AMMコードは「ブラックボックス」であり、マーケットメーカーはその戦略を秘密に保ちたいと考えていますが、この仮定を用いてObricがSui上でProp AMMを実装する方法を理解することができます:取引ペアの提示価格を決定する変数は、update関数を通じてスマートコントラクトに書き込まれます。

発見してくれてありがとう@markoggwp!

この仮定を利用して、EVMのアーキテクチャには重大な障害があることがわかり、SolanaのProp AMMモデルはEVM上で実行不可能です。

振り返ると、OP-Stack Layer 2 ブロックチェーン(BaseやUnichainなど)では、取引はガス優先料金でソートされます(Solanaが手数料/CUでソートされるのに似ています)。

EVM上での書き込み操作のガス消費は非常に高いです。Solanaのアップデートと比較して、EVM上でSSTOREオペコードを使用して値を書き込むコストは驚くべきものです:

· SSTORE(0→非0):~22,100ガス

· SSTORE(非0→非0):~5,000ガス

· 典型的 AMM スワップ:~200,000–300,000 ガス

注意:EVM上のGasはSolana上の計算単位(CU)に似ています。上記のSSTORE gasの数字は、各取引が一度だけ書き込まれる(コールド書き込み)と仮定しています。これは、通常、一度の取引で複数回の更新が送信されることはないため、合理的です。

更新は依然として交換よりも安いですが、ガス使用率は約10倍(更新には複数のSSTOREが関与する可能性があります)であり、Solanaではこの比率は約1000倍です。

これにより、同じ Solana Prop AMM モデルが EVM 上でリスクが高くなるという二つの結論がもたらされました:

  1. ガス消費が高いため、優先費用の更新が難しく、低い優先費用では高い料金/Gas の比率を実現できません。更新が先に実行されず、ブロックの上部に位置することを保証するためには、より高い優先費用が必要であり、それによりコストが増加します。

  2. EVM上のアービトラージリスクはより高く、EVM上でのガスの更新と交換の比率はわずか1:10であるのに対し、Solanaでは1:1000です。これは、アービトラージャーが優先料金を10倍に引き上げるだけで、マーケットメーカーの更新を先取りできることを意味し、Solanaでは1000倍の引き上げが必要です。このような低い比率では、アービトラージャーはコストが安いため、価格更新を先取りして過去の価格を取得する可能性が高くなります。

いくつかの革新(例えば、EIP-1153のTSTORE、一時的なストレージ用)は、約100ガスの書き込みを提供しますが、このストレージは一時的で、単一のトランザクション中のみ有効であり、価格更新を保持して後続のスワップ取引で使用することはできません(例えば、ブロック全体の期間中)。

Prop AMM を EVM に導入するにはどうすればよいですか?

回答する前に、「なぜそれをするのか」を先に答えておきます:ユーザーは常により良い取引価格を得たいと思っています。これは、よりお得な取引を意味します。EthereumとLayer 2のProp AMMは、ユーザーに本来Solanaや中央集権型取引所でしか得られない競争力のある価格を提供することができます。

Prop AMM を EVM で機能させるために、Solana で成功した理由の一つを振り返ります:

· ブロックトップ更新保護:Solana上で、Prop AMMの更新はブロックのトップにあり、マーケットメーカーをフロントランから保護できます。更新がトップにあるのは、計算ユニットの消費が非常に少なく、手数料が低くても高い手数料/CU比率を実現でき、特にスワップ取引と比較して顕著です。

では、ブロックのトップの Prop AMM 更新を Layer 2 EVM ブロックチェーンにどのように導入しますか? 2 つの方法があります。書き込みコストを下げるか、Prop AMM 更新のための優先チャネルを作成することです。

EVMの状態成長問題のため、書き込みコストを下げるという方法はあまり実行可能ではありません。なぜなら、安価なSSTOREがゴミ状態攻撃を引き起こすからです。

私たちは、Prop AMMの更新のための優先的な通路を作成することを提案します。これは実行可能なソリューションであり、この記事の重点でもあります。

Uniswap チームの @MarkToda は、グローバルストレージスマートコントラクト + 専用のブロックビルダー戦略を通じて、新しい方法を提案しました。

その動作原理は次のとおりです:

· グローバルストレージ契約:デプロイが簡単なスマート契約を公有キー値ストレージとして使用します。マーケットメイカーはこの契約に価格曲線パラメータを書き込みます(例:set(ETH-USDC_CONCENTRATION, 4000))。

· ビルダー戦略:これはオフチェーンの重要なコンポーネントです。ブロックビルダーは、グローバルストレージ契約に送信されるトランザクションを識別し、ブロックの最初の5〜10%のGasをこれらの更新トランザクションに割り当て、手数料優先でソートすることで、ゴミトランザクションを防ぎます。

注意:取引はグローバルストレージアドレスに直接送信する必要があります。そうしないと、ブロックの最上部に位置することは保証されません。

カスタムブロック構築アルゴリズムの例は、rblibを参照してください。

Prop AMM 統合:マーケットメーカーの Prop AMM コントラクトは、交換時にグローバルストレージコントラクトから価格曲線データを読み取って、見積もりを提供します。

このアーキテクチャは二つの問題を巧妙に解決しました:

  1. 保護:ビルダー戦略は「ファストトラック」を構築し、ブロック内のすべての価格更新が取引前に実行され、フロントランニングリスクを排除します。

  2. コスト効率:マーケットメーカーはもはやすべてのDeFiユーザーと高いガス料金でブロックのトップトランザクションを競う必要はなく、ローカル手数料市場で更新されたトランザクションの予約トップブロックのみを競うことで、コストを大幅に削減します。

ユーザーの取引は、マーケットメーカーが同じブロックの初期更新で設定した価格曲線に従って実行され、新しい見積もりの鮮度と安全性が確保されます。このモデルは、EVM上でSolanaの低コストで高優先度の更新環境を再現し、EVM上でのProp AMMの道を開きました。

しかし、このモデルにはいくつかの欠点もあり、これらの問題は本文の最後に議論のために残しておきます。

結論

Prop AMMの実現可能性は、先行取引を防ぐために、安価で優先的に実行されるという核心的な経済問題を解決することに依存しています。

標準EVMアーキテクチャはこのような操作のコストが高く、リスクが大きいですが、新しい設計はこの問題を解決するための異なるアプローチを提供します。オンチェーンのグローバルストレージスマートコントラクトとオフチェーンビルダー戦略を組み合わせた新しい設計により、専用の「ファストトンネル」を作成し、ブロックのトップでの更新の実行を保証し、同時にローカルで制御された料金市場を構築します。これにより、Prop AMMがEVM上で機能するだけでなく、ブロックのトップでのオラクル更新に依存するすべてのEVM DeFiに変革をもたらす可能性があります。

オープンエンドの質問

· EVM上の200msフラッシュブロックの速度は、Solanaの連続アーキテクチャと競争するのに十分ですか?

· Solana の大部分の AMM トラフィックは、AMM の接続を容易にする SDK を提供する単一のアグリゲーター Jupiter から来ています。しかし、Layer 2 EVM では、トラフィックが複数のアグリゲーターに分散しており、共通の SDK が存在しません。これは Prop AMM に対する挑戦となるのでしょうか?

· Prop AMMはSolana上での更新に約100 CUしか消費しませんが、その実現メカニズムはどのようになっていますか?

· クイックパスモデルはブロックの上部の更新のみを保証します。Flashblock内に複数の交換がある場合、マーケットメーカーはこれらの交換間でどのように価格を更新しますか?

· YulやHuffなどの言語を使用して、Solana上のPinocchio最適化スキームに類似した最適化されたEVMプログラムを書くことはできますか?

· Prop AMM と RFQ の比較はどうですか?

· どのようにしてマーケットメイカーがブロックNで優れたオファーを提示してユーザーを誘導し、その後ブロックN+1で悪いオファーに更新するのを防ぐことができますか?Jupiterはどのように対策を講じていますか?

· Jupiter Ultra V3のUltra Signaling機能は、Prop AMMが有害なトラフィックと無害なトラフィックを区別できるようにし、より密接な価格を提供します。このようなアグリゲーターの特性は、EVM上のProp AMMにとってどのように重要でしょうか?

SOL0.55%
USDC0.01%
ETH0.32%
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
0/400
コメントなし
  • ピン
いつでもどこでも暗号資産取引
qrCode
スキャンしてGateアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)