SolanaでProp AMMが普及する一方で、EVMで普及しない理由とは？

Original Article Title: Must-Watch dApps After Monad Mainnet Launch

Original Article Author: @0xOptimus

Original Article Translation: Dingdang, Odaily Planet Daily

Prop AMM（プロフェッショナル自動マーケットメイカー）は、Solanaの出来高の40%を急速に獲得しました。なぜこれらはまだEVM上に現れていないのでしょうか？

Prop AMMは、SolanaのDeFiエコシステムにおいて支配的な力となりつつあり、現在主要なペアの出来高の40%以上を占めています。プロのマーケットメイカーが運営するこれらの流動性提供の場は、深い流動性とより競争力のある価格を提供できます。その主な理由は、マーケットメイカーが「古い価格（stale quotes）」を悪用したフロントランニング裁定取引の標的になるリスクを大幅に軽減できるためです。

Image Source: dune.com

しかし、その成功はほぼ完全にSolanaに限定されています。BaseやOptimismのような高速かつ低コストなレイヤー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では、価格決定の公式は固定されておらず、頻繁に（多くの場合1秒間に複数回）更新されます。 ほとんどのProp AMMの内部メカニズムは「ブラックボックス」と見なされているため、外部はそれらが使用する正確なアルゴリズムを知りません。しかし、ObricによるSuiチェーン上の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を支払ったことを意味し、初期価格よりわずかに高くなります。この現象は「プライススリッページ」として知られています。これが x*y=k が「価格曲線」と呼ばれる理由です。取引可能な価格はすべてこの曲線上に存在しなければなりません。

なぜ流動性提供者は中央集権型オーダーブック（CLOB）よりもAMM設計を選ぶのか？

流動性提供者が流動性提供のためにAMM設計を使いたがる理由を説明しましょう。オンチェーンの中央集権型オーダーブック（CLOB）でクオートを出すマーケットメイカーだと想像してください。クオートを更新したい場合、数千の指値注文をキャンセルして置き換える必要があります。N個の注文がある場合、更新コストは O(N) の操作となり、オンチェーンでは遅く高価です。

しかし、すべてのクオートを数学的な曲線で表現できたらどうでしょうか？この曲線を定義するいくつかの主要なパラメータを更新するだけで、O(N) の操作を定数 O(1) の複雑さに変換できます。

「価格曲線」がどのように異なる実効価格範囲に対応するかを視覚的に示すために、SolanaベースのProp AMMであるEllipsis Labsが作成したSolFiを参照できます。その特定の価格曲線は不明で隠されていますが、Ghostlabsは、特定のSolanaスロット（ブロック時間期間）内で異なる量のSOLをUSDCと交換する際の実効価格を示すグラフを作成しました。各線は異なるWSOL/USDCプールを表しており、複数の価格帯が共存できることを示しています。流動性提供者が価格曲線を更新するにつれて、この実効価格グラフもスロット間で変化します。

Image Source: GitHub

ここでの鍵は、いくつかの価格曲線パラメータを更新するだけで、流動性提供者はN個の注文を個別に修正することなく、実効価格分布をいつでも動的に変更できるということです。これこそがProp AMMの核心的な価値提案であり、流動性提供者がより高い資本効率と計算効率で動的かつ深い流動性を提供することを可能にします。

なぜSolanaのアーキテクチャはProp AMMにとって理想的なのか？

Prop AMMは「能動的に管理される」システムであり、これは2つの重要な条件を必要とすることを意味します：

1. 低い更新コスト

2. 優先実行

Solanaでは、これら2つの側面は密接に関連しています：低コストの更新は、更新が優先実行される可能性があることを意味することが多いのです。

しかし、なぜ流動性提供者はこれら2つのポイントを必要とするのでしょうか？第一に、彼らはブロックチェーンの速度で、在庫の変化や資産のインデックス価格（中央集権型取引所の価格など）の変動に基づいて、価格曲線を継続的に更新します。 Solanaのような高頻度チェーンでは、更新コストが高すぎると、高頻度な調整を達成することは困難です。

第二に、流動性提供者が自分の更新をブロックの先頭に含めることができない場合、古いクオートは裁定取引者に「フロントラン」され、避けられない損失を被ることになります。 これらの機能がなければ、流動性提供者は効率的に運営できず、ユーザーはより悪い取引価格を受け取ることになります。

Solana上のProp AMMであるHumidiFiの例を使用すると、@SliceAnalyticsのデータによると、流動性提供者は1秒間に最大74回クオートを更新します。

EVMから来たプレイヤーはこう尋ねるかもしれません：「Solanaのスロットは約400msですが、Prop AMMはどのようにして1つのスロット内で複数回価格を更新できるのですか？」

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

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

· Solana： リーダーバリデーターノードはフルブロックを待たず、トランザクションを小さなデータパケット（「shreds」と呼ばれる）に分割し、継続的にネットワークにブロードキャストします。1つのスロット内に複数の交換が存在する可能性がありますが、shred #1の価格更新はスワップ #1に影響し、shred #2の価格更新はスワップ #2に影響します。

注：FlashblocksはSolanaのshredsに似ています。CBERカンファレンスでのAnza Labsの@Ashwinningg氏によると、400msごとに32,000 shredsというスロットの制限は、1ミリ秒あたり80 shredsに相当します。200msのFlashblocksが流動性提供者の要件を満たすのに十分かどうかは、Solanaの連続的なアーキテクチャと比較して未解決の問題です。

では、なぜSolanaでの更新はこれほど安いのでしょうか？そして何が優先実行につながるのでしょうか？

第一に、SolanaでのProp AMMの実装はブラックボックスですが、SolanaプログラムでCU（計算ユニット）が記述される方法を最適化するPinocchioのようなライブラリが存在します。Heliusのブログが素晴らしい説明を提供しています。このライブラリを使用すると、SolanaプログラムのCU消費量を約4000 CUから約100 CUに削減できます。

Image Source: github

次に2番目の部分を見てみましょう。より高いレベルでは、SolanaはEVMと同様に、手数料 / 計算ユニット（CU）比率が最も高いトランザクションを選択することでトランザクションを優先します（計算ユニットはEVMのガスに似ています）。

· 具体的には、Jitoを使用する場合、公式は Jito Tip / 計算ユニット です

· それ以外の場合：優先度 = (チップ + 基本手数料) / (1 + CU制限 + 署名CU + 書き込みロックCU)

Prop AMM更新の計算ユニットをJupiterスワップと比較すると、更新が非常に安価であり、比率が1:1000であることがわかります。

Prop AMM更新： 単純な曲線更新は非常に安価です。Wintermuteの更新は109 CUと低く、総コストはわずか0.000007506 SOLです

Jupiterスワップ： Jupiterルートを介したスワップは約100,000 CUに達し、総コストは0.000005 SOLです

この大きな違いにより、流動性提供者は更新トランザクションに対して最小限の手数料を支払うだけで済み、取引所よりもはるかに高い手数料/CU比率を達成し、更新がブロックの先頭で実行されることを保証し、裁定取引攻撃から身を守ることができます。

なぜProp AMMはまだEVMに上陸していないのか？

Prop AMMの更新には、資産ペアの価格曲線を決定する変数の書き込みが含まれると仮定します。流動性提供者が戦略を機密に保ちたいと考えているため、Solana上のProp AMMのコードは「ブラックボックス」ですが、この仮定を使用して、ObricがSui上でどのようにProp AMMを実装したかを理解できます：資産ペアの価格を決定する変数は、更新関数を通じてスマートコントラクトに書き込まれます。

@markoggwp氏の発見に感謝します！

この仮定により、SolanaのProp AMMモデルをEVM上で実行不可能にする、EVMのアーキテクチャにおける重大な障壁を発見しました。

OP-Stackレイヤー2ブロックチェーン（BaseやUnichainなど）では、トランザクションはガスあたりの手数料に基づいて優先順位付けされることを思い出してください（Solanaの手数料/CUソートに似ています）。

EVMでは、書き込み操作のガスコストが非常に高くなります。Solanaの更新と比較して、SSTOREオペコードを介してEVM上に値を書き込むコストは驚異的です：

· SSTORE (0 → non-0)：約22,100ガス

· SSTORE (non-0 → non-0)：約5,000ガス

· 一般的なAMMスワップ：約200,000–300,000ガス

注：EVMのガスはSolanaの計算ユニット（CU）に似ています。上記のSSTOREガス数値は、各トランザクションに1つの書き込み（コールド書き込み）しかないと仮定しています。これは、通常1つのトランザクション内で複数の更新が送信されないため合理的です。

更新は依然としてスワップよりも安価ですが、ガス効率は約10倍に過ぎません（更新には複数のSSTOREが含まれる場合があります）。一方、Solanaではこの比率は約1000倍です。

これは、同じSolana Prop AMMモデルをEVM上でよりリスクの高いものにする2つの結論を導き出します：

1. 高いガスコストにより、更新の優先順位を確保することが困難： 低いガス手数料では高い手数料/ガス比率を確保できません。更新がフロントランされず、ブロックの先頭に配置されることを保証するには、より高いガス手数料が必要となり、コストが増加します。

2. EVM上でのより高い裁定取引リスク： EVMにおける更新ガスとスワップガスの比率は1:10に過ぎませんが、Solanaでは1:1000です。これは、裁定取引者が流動性提供者の更新をフロントランするために手数料を10倍にするだけでよいことを意味し、Solanaの1000倍と比較されます。この低い比率のシナリオでは、裁定取引者が低コストのために古いクオートをキャプチャしようとして価格更新をフロントランする可能性が高くなります。

一部のイノベーション（EIP-1153のTSTOREなど、一時的なストレージ用）は、約100ガスの書き込みコストを提供しますが、このストレージは一時的であり、単一のトランザクション内でのみ有効であり、デリバティブ取引（ブロック期間全体など）で後で使用するために価格更新を永続化することはできません。

どのようにProp AMMをEVMに導入するか？

答える前に、「なぜそれを行うのか」に対処しましょう：ユーザーは常に、より良い取引クオートを求めています。つまり、投資に対してより多くの価値を求めています。Ethereumとレイヤー2のProp AMMは、以前はSolanaや中央集権型取引所でしか利用できなかった競争力のあるクオートをユーザーに提供できます。

Prop AMMをEVM上で実行可能にするために、Solanaでの成功理由の1つを復習しましょう：

· ブロック先頭の更新保護： Solanaでは、Prop AMMの更新はブロックの先頭にあり、流動性提供者をフロントランニングから保護します。計算ユニットコストが最小限であるため、トップの更新が可能であり、低い手数料でも高い手数料/CU比率を達成でき、特にデリバティブ取引と比較して顕著です。

では、どのようにしてブロック先頭のProp AMM更新をレイヤー2 EVMブロックチェーンに導入できるでしょうか？2つのアプローチがあります：書き込みコストを削減するか、Prop AMM更新のための優先チャネルを作成することです。

EVMの状態肥大化問題のため、書き込みコストを削減するアプローチはあまり実行可能ではありません。安価なSSTOREは状態肥大化攻撃につながる可能性があるためです。

Prop AMM更新のための優先チャネルを作成することを提案します。これは実行可能な解決策であり、本記事の焦点です。

Uniswapの@MarkToda氏は、グローバルストレージスマートコントラクト + 専用ブロックビルダー戦略を活用する新しいアプローチを提案しています：

仕組みは以下の通りです：

· グローバルストレージコントラクト： 単純なスマートコントラクトをパブリックキーバリューストアとしてデプロイします。流動性提供者は価格曲線パラメータをこのコントラクトに書き込みます（例：set(ETH-USDC_CONCENTRATION, 4000)）。

· ビルダー戦略： これは重要なオフチェーンコンポーネントです。ブロックビルダーはグローバルストレージコントラクトに送信されたトランザクションを識別し、ブロックのガスの5〜10%をこれらの更新トランザクションに割り当て、手数料によって優先順位を付け、スパムトランザクションを防ぐために並べ替えます。

注意：トランザクションは、ブロックの先頭への配置を保証するために、グローバルストレージアドレスに直接送信する必要があります。

カスタムブロック構築アルゴリズムの例はrblibで見つけることができます。

Prop AMM統合： 流動性提供者のProp AMMコントラクトは、クオートを提供するためにスワップ中にグローバルストレージコントラクトから価格曲線データを読み取ります。

このアーキテクチャは2つの問題に巧みに対処します：

1. 保護： ビルダー戦略は「ファストレーン」を作成し、ブロック内のすべての価格更新がトランザクションの前に実行されることを保証し、フロントランニングリスクを排除します。

2. コスト効率： 流動性提供者は、ブロックの先頭に入るためにすべてのDeFiユーザーと高いガス価格を競う必要がなくなります。代わりに、ローカル手数料市場で更新トランザクション用に予約されたトップブロックを競うだけで済み、コストを大幅に削減できます。

ユーザーのトランザクションは、同じブロックの開始時に流動性提供者によって設定された価格曲線に基づいて実行され、クオートの鮮度とセキュリティを保証します。このモデルは、Solanaの低コストで優先度の高い更新環境をEVMで再現し、EVM上でのProp AMMへの道を切り開きます。

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

結論

Prop AMMの実現可能性は、核心的な経済問題に対処できるかどうかにかかっています：フロントランニングを防ぐための安価で優先的な実行です。

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

未解決の質問

· EVM上のProp AMMの200ms Flashblock速度は、Solanaの連続的なアーキテクチャと競合するのに十分でしょうか？

· Solanaでは、ほとんどのAMMトラフィックはJupiterと呼ばれる単一のアグリゲーターから来ており、簡単なAMM統合のためのSDKを提供しています。しかし、レイヤー2 EVMでは、トラフィックはパブリックSDKのない複数のアグリゲーターに分散しています。これはProp AMMにとって課題となりますか？

· Solanaでは、Prop AMMの更新はわずか約100 CUしか消費しません。この効率の背後にある実装メカニズムは何ですか？

· ファストパスモデルはブロックの先頭での更新のみを保証します。Flashblock内に複数の交換がある場合、流動性提供者はこれらの交換間でどのように価格を更新しますか？

· SolanaのPinocchio最適化アプローチと同様に、YulやHuffのような言語を使用して最適化されたEVMプログラムを書くことは可能ですか？

· Prop AMMはRFQとどのように比較されますか？

· 流動性提供者がブロックNで競争力のあるクオートを提供してユーザーを誘い、その後ブロックN+1で競争力のないクオートに更新することをどのように防ぐことができますか？Jupiterはこのリスクをどのように軽減しますか？

· Jupiter Ultra V3のUltra Signaling機能は、Prop AMMが有害なトラフィックと良性のトラフィックを区別し、よりタイトなクオートを提供することを可能にします。これらのアグリゲーター機能は、EVM上のProp AMMにとってどの程度重要ですか？

Original Post Link