Solana には Prop AMM が満載なのに、EVM にはまだ何もないのはなぜですか?
原題: Monad メインネットローンチ後に注目すべき dApps
原著者: Optimus、Waterloo Blockchain 創設者
原訳者: Dingdang、Odaily Planet Daily
独自の AMM (Prop AMM) は、Solana の全取引量の 40% を急速に獲得しました。なぜまだ EVM に載っていないのでしょうか?
独自の自動マーケットメーカー (Prop AMM) は、Solana DeFi エコシステムで急速に支配的な勢力になりつつあり、現在主要な取引ペアの取引量の 40% 以上を占めています。プロのマーケットメーカーによって運営されるこれらの特殊な流動性会場は、主に古い相場を使用したフロントランニング・アービトラージのリスクを大幅に軽減するため、深い流動性とより競争力のある価格設定を提供しています。
画像ソース: dune.com
しかし、その成功はほぼ完全に Solana に限られています。Base や Optimism のような高速で低コストのレイヤー 2 ネットワークでさえ、Prop AMM は EVM エコシステムでは依然としてまれです。なぜ EVM に定着していないのでしょうか?
この記事では、Prop AMM とは何か、EVM チェーン上でどのような技術的および経済的ハードルに直面しているか、そして最終的に EVM DeFi の最前線に立つ可能性のある有望な新しいアーキテクチャという 3 つの質問に焦点を当てています。
Prop AMM とは何ですか? 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トランザクションを使用する際に支払う必要がある価格を決定するものであり、Prop 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個の注文を1つずつ変更することなく、いつでも有効な価格分布を変更できることです。これが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スロット内で価格を複数回更新できるのですか？」と疑問に思うかもしれません。
その答えは、Solanaの連続アーキテクチャにあります。これはEVMの個別ブロックモデルとは根本的に異なります。· 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 の実装はブラック ボックスですが、CU 用に Solana プログラムを最適化できる Pinocchio のようなライブラリが存在します。 Helius のブログには、このライブラリを使用することで Solana プログラムが CU 消費量を約 4,000 CU から約 100 CU に削減できることを紹介する素晴らしい記事があります。
画像ソース: github
2 番目の部分を見てみましょう。大まかに言うと、SolanaはEVMと同様に、最も高い手数料/コンピューティング単位比率（コンピューティング単位はEVMガスに似ています）を持つトランザクションを選択することで、トランザクションを優先順位付けします。
· 具体的には、Jito を使用する場合、式は Jito チップ / コンピューティング単位
· Jito を使用しない場合: 優先度 = (優先度手数料 + 基本手数料) / (1 + CU キャップ + 署名 CU + 書き込みロック CU)
Prop AMM アップデートと Jupiter Swap のコンピューティング単位を比較すると、比率が 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 に感謝します!
この仮説を使用して、EVM のアーキテクチャには、Solana の Prop AMM モデルを EVM 上で実行不可能にする重大な障害があることを発見しました。
Base や Unichain などの OP-Stack レイヤー 2 ブロックチェーンでは、トランザクションは優先度ごとのガス料金でソートされます (Solana の Fee/CU ソートと同様)。
EVM では、書き込み操作には非常に高いガス コストがかかります。 Solana のアップデートと比較すると、SSTORE オペコードを介して EVM に値を書き込むのは驚くほど高価です。 · SSTORE (0 → not-0): 約 22,100 ガス · SSTORE (not-0 → not-0): 約 5,000 ガス · 一般的な AMM スワップ: 約 200,000～300,000 ガス 注: EVM のガスは、Solana の Compute Units (CU) に類似しています。上記の SSTORE ガスの数値は、トランザクションごとに 1 回の書き込み (コールド ライト) のみを想定していますが、これは通常、単一のトランザクションで複数のアップデートを送信することはないため妥当です。アップデートはスワップよりも安価ですが、ガス使用量は約 10 倍しか高くありません (アップデートには複数の SSTORE が含まれる場合があります)。一方、Solana では約 1000 倍高くなります。これにより、同じ Solana Prop AMM モデルが EVM 上でよりリスクが高くなります。 1. ガス消費量が多いと、優先料金でアップデートを優先することが難しくなります。優先手数料を低く設定することで、手数料とガス価格の比率が高くなるのを防ぎます。アップデートがフロントランナーではなくブロックの上位に配置されるようにするには、より高い優先手数料が必要となり、コストが増加します。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で成功している理由の1つを再考してみましょう。ブロックトップ更新保護：Solanaでは、Prop AMMの更新はブロックトップに配置され、マーケットメーカーによるフロントランニングから保護されます。この更新の配置は、計算ユニット（CU）の消費を最小限に抑えるためであり、特にスワップと比較して、低い手数料でも高い手数料/CU比率を実現できます。では、ブロックの先頭にあるProp AMM更新をレイヤー2 EVMブロックチェーンに導入するにはどうすればよいでしょうか？ 2つのアプローチがあります。書き込みコストを削減するか、Prop AMM更新用の優先チャネルを作成するかです。書き込みコストを削減することは、EVMの状態増加問題のため実現不可能です。安価なSSTOREはガベージステート攻撃につながる可能性があるためです。そこで、Prop AMM更新用の優先チャネルを作成することを提案します。これは実行可能な解決策であり、この記事の焦点となります。
Uniswap チームの @MarkToda は、グローバル ストレージ スマート コントラクト + 特化したブロック ビルダー戦略を使用した新しいアプローチを提案しました:
仕組みは次のとおりです:
· グローバル ストレージ コントラクト:シンプルなスマート コントラクトを公開キーバリュー ストアとしてデプロイします。マーケット メーカーは、このコントラクトに価格曲線のパラメータを書き込みます (例: set(ETH-USDC_CONCENTRATION, 4000))。
マーケットメーカー向けのProp AMMコントラクトは、スワップ中にグローバルストレージコントラクトから価格曲線データを読み取り、クォートを提供します。このアーキテクチャは、2つの問題を巧みに解決します。1. 保護：ビルダー戦略は「ファストレーン」を作成し、ブロック内のすべての価格更新がトランザクションよりも先に実行されるようにすることで、フロントランニングのリスクを排除します。2. コスト効率：マーケットメーカーは、ブロックの先頭で取引するために、すべてのDeFiユーザーと高ガス価格を競う必要がなくなりました。代わりに、彼らは更新されたトランザクション用に予約された最上位ブロックをめぐってローカル手数料市場で競争し、コストを大幅に削減します。ユーザートランザクションは、同じブロックの最初の更新時にマーケットメーカーによって設定された価格曲線に従って実行され、クォートの鮮度とセキュリティが確保されます。このモデルは、EVM上でSolanaの低コストで優先度の高い更新環境を再現し、EVM上のProp AMMへの道を開きます。ただし、このモデルにはいくつかの欠点もあり、それについてはこの記事の最後で説明します。 結論
Prop AMMの実行可能性は、フロントランニングを防ぐための安価で優先度の高い実行という、中核的な経済問題を解決することにかかっています。
標準的なEVMアーキテクチャでは、このような操作はコストがかかりリスクが高くなりますが、この新しい設計は、この問題に対する異なるアプローチを提供します。この新しい設計は、オンチェーンのグローバルストレージスマートコントラクトとオフチェーンのビルダー戦略を組み合わせることで、専用の「ファストレーン」を構築し、ブロックトップでの更新実行を保証すると同時に、ローカルで管理された手数料市場を確立します。これにより、Prop AMMがEVM上で実行可能になるだけでなく、ブロックトップでのオラクル更新に依存するすべてのEVM DeFiに革命をもたらす可能性を秘めています。
未解決の質問
· EVM上のProp AMMの200msフラッシュブロック速度は、Solanaの継続的なアーキテクチャと競合するのに十分な速さですか？
· Solana上のほとんどのAMMトラフィックは、AMMの統合を容易にするためのSDKを提供する単一のアグリゲータであるJupiterから来ています。しかし、レイヤー2 EVMでは、トラフィックは複数のアグリゲータに分散されており、パブリックSDKはありません。これはProp AMMにとって課題となりますか？
· Solana上のProp AMMアップデートは約100 CUしか消費しません。これはどのように実装されていますか？
· 高速チャネルモデルは、ブロックの先頭での更新のみを保証します。フラッシュブロック内に複数のスワップがある場合、マーケットメーカーはこれらのスワップ間でどのように価格を更新するのでしょうか？
· Solana の Pinocchio 最適化スキームと同様に、最適化された EVM プログラムを Yul や Huff などの言語で記述できますか?
· Prop AMM と RFQ を比較するとどうなりますか?
· マーケットメーカーがブロック N で高品質の見積もりを提供してユーザーを誘導し、ブロック N+1 で低品質の見積もりに更新するのをどのように防ぐことができますか? Jupiter はこれをどのように防ぎますか?
· Jupiter Ultra V3 の Ultra Signaling 機能により、Prop AMM は有害なトラフィックと無害なトラフィックを区別し、より厳密な見積もりを提供できます。これらのアグリゲーター機能は EVM 上の Prop AMM にとってどの程度重要ですか?
BlockBeats の公式コミュニティに参加しよう：
Telegram 公式チャンネル：https://t.me/theblockbeats
Telegram 交流グループ：https://t.me/BlockBeats_App
Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia
