Solana には Prop AMM が満載なのに、EVM にはまだ何もないのはなぜですか?

著者 | @0xOptimus

Odaily Planet Daily（ @OdailyChina ）がまとめました

翻訳者 |ディンダン ( @XiaMiPP )

プロップAMMはSolanaの全取引量の40%を急速に獲得しました。なぜまだEVMに載っていないのでしょうか？

独自AMM（Prop AMM）は、Solana DeFiエコシステムにおいて急速に支配的な勢力となりつつあり、現在、主要取引ペアの取引量の40%以上を占めています。プロのマーケットメーカーによって運営されるこれらの専門流動性プラットフォームは、主に古い相場情報を用いたフロントランニング・アービトラージのリスクを大幅に軽減するため、高い流動性とより競争力のある価格設定を提供しています。

画像出典: dune.com

しかし、その成功はほぼSolanaに限られています。BaseやOptimismのような高速で低コストのレイヤー2ネットワークでさえ、Prop AMMはEVMエコシステムではまだ珍しい存在です。なぜEVMに定着しないのでしょうか？

この記事では、Prop AMM とは何か、EVM チェーン上で Prop AMM が直面する技術的および経済的ハードルは何か、そして最終的に Prop AMM を EVM DeFi の最前線に導く可能性のある有望な新しいアーキテクチャという 3 つの主要な質問について説明します。

Prop AMMとは何ですか?

プロップ AMM は、従来の AMM のように一般の人々から受動的に資金提供を受けるのではなく、流動性と価格設定が単一のプロのマーケット メーカーによって積極的に管理される自動マーケット メーカーです。

従来のAMM（Uniswap v2など）では、通常、x * y = kという式を用いて価格を決定します。ここで、xとyはそれぞれプール内の2つの資産の数量を表し、kは定数です。しかし、Prop AMMでは、価格決定式は固定ではなく、頻繁に（通常は1秒間に複数回）更新されます。ほとんどのProp AMMの内部メカニズムは「ブラックボックス」であるため、使用されているアルゴリズムの詳細は不明です。しかし、Suiチェーン上のObricのProp AMMスマートコントラクトのコードは公開されており（発見してくれた@markoggwpに感謝します）、その不変量kは内部変数mult_x、mult_y、および濃度に依存します。下の図は、マーケットメーカーがこれらの変数を継続的に更新する方法を示しています。

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

レビュー: AMM は価格をどのように決定しますか?

この記事全体を通して、「価格カーブ」という概念に何度か言及します。価格カーブは、AMMで取引する際にユーザーが支払う価格を決定するものであり、プロップAMMではマーケットメーカーが常に更新する要素です。これをより深く理解するために、まずは従来のAMMの価格設定方法を確認しましょう。

Uniswap v2のWETH-USDCプールを例に挙げましょう（手数料は発生しません）。価格はx * y = kという式によって受動的に決定されます。プールに100WETHと400,000USDCがあると仮定すると、曲線の点はx = 100、y = 400,000となり、初期価格は400,000 / 100 = 4,000USDC/WETHとなります。このことから、定数k = 100 * 400,000 = 40,000,000が得られます。

トレーダーが1WETHを購入したい場合、USDCをプールに追加し、プール内のWETHの量を99に減らす必要があります。積kを一定に保つためには、新しい点(x, y)は依然として曲線上になければならないため、yは40,000,000 / 99 ≈ 404,040.40となります。言い換えれば、トレーダーは1WETHに対して約4,040.40 USDCを支払ったことになります。これは当初の価格よりわずかに高い金額です。この現象は「スリッページ」と呼ばれます。これが、x*y=kが「価格曲線」と呼ばれる理由です。つまり、取引可能な価格はすべてこの曲線上になければなりません。

マーケットメーカーが集中型注文帳 (CLOB) ではなく AMM 設計を選択するのはなぜでしょうか?

マーケットメーカーがマーケットメイクにAMM設計を採用する理由を説明しましょう。オンチェーンの中央集権型指値注文帳（CLOB）で価格を提示するマーケットメーカーを想像してみてください。提示価格を更新するには、数千もの指値注文をキャンセルして差し替える必要があります。注文数がN個の場合、更新コストはO(N)回の演算となり、オンチェーンでは遅く、コストも高くなります。

もしすべての引用符を数学的な曲線で表現できたらどうなるでしょうか？この曲線を定義するいくつかのパラメータを更新するだけで、O(N) の操作を O(1) という一定の計算量に変換できます。

「価格曲線」が異なる実効価格帯にどのように対応するかを視覚化するために、Ellipsis Labsが開発したSolanaベースのProp AMMであるSolFiを参照できます。SolFiの具体的な価格曲線は不明で非公開ですが、Ghostlabsは、特定のSolanaスロット（ブロック期間）内で異なる量のSOLをUSDCに交換する際の実効価格を示すグラフを作成しました。各線は異なるWSOL/USDCプールを表しており、複数の価格帯が共存できることを示しています。この実効価格チャートは、マーケットメーカーが価格曲線を更新するたびにスロットごとに変化します。

画像ソース: github

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

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

Prop AMM は「アクティブに管理される」システムであり、次の 2 つの重要な条件を満たす必要があります。

1. 安価なアップデート
2. 優先実行

Solana では、この 2 つは連携して機能し、低コストのアップデートは多くの場合、アップデートの実行が優先されることを意味します。

なぜマーケットメーカーはこれら2つの機能を必要とするのでしょうか？まず、在庫の変化や資産インデックス価格の変動（中央集権型取引所など）に基づいて、ブロックチェーンの速度で価格カーブを常に更新する必要があるためです。Solanaのような高頻度チェーンでは、更新コストが高すぎると高頻度調整を実現することは困難です。

第二に、マーケットメーカーがブロックのトップに更新情報をキューイングできない場合、以前の相場情報は裁定取引業者によってコピーされ、必然的に損失が発生します。これら2つの機能がなければ、マーケットメーカーは効率的に業務を遂行できず、ユーザーはより悪い取引価格を受け取ることになります。

Solana の Prop AMM HumidiFi を例にとると、 @SliceAnalytics のデータによると、マーケット メーカーは 1 秒あたり最大 74 回相場を更新します。

EVMから見ると、「Solanaのスロットは約400ミリ秒なのに、Prop AMMはどうやって1スロット内で価格を複数回更新できるのか？」と疑問に思うかもしれません。

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

• EVM:トランザクションは通常、ブロック全体が提案され、確定された後に順次実行されます。つまり、途中で送信された更新は次のブロックまで有効になりません。
• Solana:リーダーバリデータはブロックが完成するまで待つことはありません。代わりに、トランザクションを小さなパケット（「シュレッド」と呼ばれる）に分割し、ネットワークに継続的にブロードキャストします。1つのスロット内で複数のスワップが発生することもありますが、シュレッド#1の価格更新はスワップ#1に影響し、シュレッド#2の価格更新はスワップ#2に影響します。

注：FlashblocksはSolanaのシュレッドに似ています。CBERカンファレンスでAnza Labsの@Ashwinningg氏が述べたところによると、400msスロットは32,000シュレッドに制限されており、これは1ミリ秒あたり80シュレッドに相当します。200msのFlashblocksが、Solanaの継続的なアーキテクチャと比較してマーケットメーカーにとって十分な速度であるかどうかは、依然として疑問です。

では、なぜSolanaのアップデートはこんなにも安価なのでしょうか？そして、それがどのようにして優先実行につながるのでしょうか？

まず、SolanaにおけるProp AMMの実装はブラックボックスですが、Pinocchioのようなライブラリを使用することで、SolanaプログラムをCU最適化された方法で記述できます。Heliusのブログでは、このライブラリを使用することでSolanaプログラムのCU消費量を約4,000 CUから約100 CUに削減できることを実証する興味深い概要が提供されています。

画像ソース: github

2つ目の部分を見てみましょう。大まかに言うと、SolanaはEVMと同様に、手数料/コンピューティングユニット比率（コンピューティングユニットはEVMにおけるガスに相当）が最も高いトランザクションを選択することで、トランザクションの優先順位を決定します。

• 具体的には、Jitoを使用する場合、計算式はJitoチップ/計算単位となります。
• 未使用: 優先度 = (優先度手数料 + 基本手数料) / (1 + CU 上限 + 署名 CU + 書き込みロック CU) ( https://solana.com/docs/core/fees)

Prop AMM のアップデートと Jupiter Swap のコンピューティング ユニットを比較すると、アップデートの比率が 1:1000 と非常に安価であることがわかります。

プロップAMMアップデート：シンプルなカーブアップデートは非常に安価です。ウィンターミュートアップデートは109 CUと非常に安価で、合計料金はわずか0.000007506 SOLです。

Jupiter Swap : Jupiter を経由するスワップは最大 100,000 CU に達し、手数料は合計 0.000005 SOL です。

この大きな違いにより、マーケットメーカーは更新トランザクションに対して非常に小さな手数料を支払うだけで、取引所よりもはるかに高い手数料/CU 比率を実現できます。これにより、更新がブロックの先頭で実行されることが保証され、裁定攻撃から保護されます。

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

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

これを発見してくれた@markoggwpに感謝します!

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

要約すると、BaseやUnichainなどのOP-Stackレイヤー2ブロックチェーンでは、トランザクションはGasあたりの優先手数料でソートされます（Solanaの手数料/CUによるソートと同様）。

EVMでは、書き込み操作は非常に高価です。Solanaのアップデートと比較すると、SSTOREオペコードを介してEVMに値を書き込むのは驚くほど高価です。

• SSTORE (0 → 非0): ~22,100ガス
• SSTORE（非ゼロ→非ゼロ）: 約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ではアップデートガスとスワップガスの比率が1:10であるのに対し、Solanaでは1:1000であるため、裁定リスクは高くなります。つまり、裁定業者はマーケットメーカーのアップデートを先行して行うために優先手数料を10倍に増やすだけで済みますが、Solanaでは1000倍に増やす必要があります。この比率が低いため、裁定業者はコストが低いため、古い相場情報を得るためにトレード価格のアップデートを先行して行う可能性が高くなります。

一部のイノベーション（一時ストレージ用の EIP-1153 の TSTORE など）では、約 100 GAS で書き込みが可能ですが、このストレージは一時的なものであり、単一のトランザクション内でのみ有効であり、後続のスワップ（ブロック全体など）の価格更新を永続化するために使用することはできません。

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

答える前に、まず「なぜそうするのか？」という問いに答えましょう。ユーザーは常により良い取引価格、つまりより費用対効果の高い取引を望んでいます。EthereumとLayer 2 Prop AMMは、これまでSolanaや中央集権型取引所でしか提供できなかった競争力のある価格をユーザーに提供できます。

Prop AMMをEVMで実行可能にするために、Solanaで成功した理由の1つを再考してみましょう。

• ブロックトップ更新保護： Solanaでは、Prop AMMの更新はブロックトップに配置され、マーケットメーカーによるフロントランニングを防ぎます。このブロックトップ更新配置は、計算ユニット（CU）の消費を最小限に抑えるためであり、特にスワップと比較して、低い手数料でも高い手数料/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アーキテクチャでは、このような操作はコストとリスクを伴いますが、新しい設計は異なるアプローチを提供します。オンチェーンのグローバルストレージスマートコントラクトとオフチェーンのビルダー戦略を組み合わせることで、専用の「ファストレーン」を作成し、ブロックのトップでの更新を確実に実行すると同時に、ローカルで管理された手数料市場を確立します。これにより、EVM上でProp AMMを実現できるだけでなく、ブロックのトップでのオラクル更新に依存するすべてのEVM DeFiプロジェクトに革命をもたらす可能性を秘めています。

未解決の質問

• Prop AMMのEVM上の200msのフラッシュブロック速度は、Solanaの継続的なアーキテクチャと競合するのに十分な速さですか？
• Solana上のAMMトラフィックの大部分は、単一のアグリゲータであるJupiterから発生しており、JupiterはAMMへのアクセスを容易にするSDKを提供しています。しかし、レイヤー2 EVMではトラフィックが複数のアグリゲータに分散されており、公開SDKは存在しません。これはProp AMMにとって課題となるでしょうか？
• SolanaではProp AMMのアップデートに約100 CUしか消費しません。その実装メカニズムはどのようなものですか？
• ファストチャネルモデルは、ブロックの先頭部分のみの更新を保証します。フラッシュブロック内に複数のスワップがある場合、マーケットメーカーはこれらのスワップ間の価格をどのように更新するのでしょうか？
• Solana の Pinocchio 最適化ソリューションと同様に、Yul や Huff などの言語で最適化された EVM プログラムを作成することは可能ですか?
• Prop AMM と RFQ を比較するとどうなりますか?
• マーケットメーカーがブロックNで高品質な相場情報を提供し、ブロックN+1でそれを低品質な相場情報に更新することでユーザーを誤解させるのを防ぐにはどうすればよいでしょうか？Jupiterはどのようにしてこれを防ぐのでしょうか？
• Jupiter Ultra V3のUltraシグナリング機能により、Prop AMMは有害なトラフィックと無害なトラフィックを区別し、より正確な見積もりを提供できます。EVM上のProp AMMにとって、これらのアグリゲーター機能はどの程度重要ですか？