なぜSolanaにはProp AMMが溢れているのに、EVM上では依然として空白なのか？

原文タイトル：Must-Watch dApps After Monad Mainnet Launch

原文作者：Optimus，Waterloo Blockchain 創設者

原文翻訳：Dingdang，Odaily

Prop AMMはSolanaの全取引量の40%を急速に占めています。なぜEVM上にはまだ登場していないのでしょうか？

プロフェッショナル・オートメーテッド・マーケットメーカー（Proprietary AMMs、略してProp AMM）は、Solana DeFiエコシステムの中で急速に主導的な存在となっており、現在では主要な取引ペアの40%以上の取引量を占めています。これらはプロのマーケットメーカーによって運営される専用の流動性プールであり、深い流動性とより競争力のある価格設定を提供できます。その核心的な理由は、「古い見積もり（stale quotes）」によるフロントランニング（front-running）アービトラージのリスクを大幅に低減できることにあります。

画像出典：dune.com

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

本稿では主に3つの問題を探ります：Prop AMMとは何か、EVMチェーン上で直面する技術的・経済的障壁、そして最終的にEVM DeFiの最前線にProp AMMをもたらす可能性のある有望な新しいアーキテクチャについてです。

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が「価格曲線」と呼ばれる理由です：任意の取引可能な価格はこの曲線上になければなりません。

なぜマーケットメーカーはAMM設計をCLOB（中央集権型注文板）より選ぶのか？

なぜマーケットメーカーがAMM設計でマーケットメイクしたいのかを説明しましょう。あなたがオンチェーンの中央リミット注文板（CLOB）で見積もりを出すマーケットメーカーだと想像してください。見積もりを更新したい場合、何千ものリミット注文をキャンセルして置き換える必要があります。もしN個の注文があれば、更新コストはO(N)の操作となり、オンチェーンでは遅くて高コストです。

もしすべての見積もりを1本の数式曲線で表現できるならどうでしょう？この曲線を定義するごく少数のパラメータだけを更新すればよく、O(N)の操作をO(1)の定数時間に変換できます。

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

画像出典：github

ここでの重要なポイントは、ごく少数の価格曲線パラメータを更新するだけで、マーケットメーカーは有効価格分布をいつでも変更でき、N個の注文を個別に修正する必要がないということです。これこそがProp AMMのコアバリュープロポジションであり、マーケットメーカーがより高い資本効率と計算効率で、動的かつ深い流動性を提供できる理由です。

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

Prop AMMは「アクティブマネジメント型」システムであり、2つの重要な条件が必要です：

1. 低コストな更新（cheap updates）

2. 優先実行権（priority execution）

Solana上では、この2つは相互補完的です：低コストな更新は、しばしば更新が優先実行権を得ることを意味します。

なぜマーケットメーカーはこの2点を必要とするのでしょうか？まず、彼らは在庫の変化や資産のインデックス価格（例：中央集権取引所の価格）の変動に応じて、ブロックチェーンの動作速度で価格曲線を継続的に更新します。Solanaのような高頻度チェーンでは、更新コストが高すぎると高頻度の調整は困難です。

次に、マーケットメーカーが更新をブロックのトップに配置できなければ、古い見積もりがアービトラージャーに「奪われ」、必然的な損失が発生します。この2つの特性がなければ、マーケットメーカーは効率的に運用できず、ユーザーもより悪い取引価格を受けることになります。

Solana上のProp AMMであるHumidiFiを例にとると、@SliceAnalyticsのデータによれば、このマーケットメーカーは1秒あたり74回も見積もりを更新しています。

EVMのユーザーはこう疑問に思うかもしれません：「Solanaのslot（スロット）は約400msなのに、Prop AMMはどうやって1つのslot内で複数回価格を更新できるのか？」

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

· EVM：取引は通常、完全なブロックが提案・最終確定された後に順番に実行されます。途中で送信された更新は次のブロックまで有効になりません。

· Solana：リーダーバリデータノードは完全なブロックを待たず、取引を小さなデータパケット（「shred」と呼ばれる）に分割してネットワークに連続的にブロードキャストします。1つのslot内で複数のスワップがあり得ますが、shred #1の価格更新はswap #1に、shred #2の価格更新はswap #2に影響します。

注：FlashblocksはSolanaのshredに似ています。Anza Labsの@AshwinninggがCBERカンファレンスで共有したところによると、各400msのslotの上限は32,000 shredで、1msあたり80 shredに相当します。200ms Flashblocksがマーケットメーカーのニーズを満たすのに十分かどうかは、Solanaの連続アーキテクチャと比較して依然としてオープンな問題です。

では、Solana上の更新はなぜこれほど安価なのか？また、どうして優先実行につながるのか？

まず、Solana上のProp AMMの実装はブラックボックスですが、Pinocchioのようなライブラリが存在し、CU（Compute Units）を最適化する形でSolanaプログラムを書くことができます。Heliusのブログではこれについて素晴らしい解説があり、このライブラリを使うことでSolanaプログラムのCU消費は約4000CUから約100CUに減少します。

画像出典：github

次に2つ目の部分です。より高いレベルでは、SolanaはFee / Compute Units比率が最も高い取引を優先的に並べ替えます（Compute UnitsはEVMのGasに類似）、EVMと同様です。

· Jitoを使う場合、公式はJito Tip / Compute Units

· 未使用時：Priority = (優先手数料 + 基本手数料) / (1 + CU上限 + 署名CU + 書き込みロックCU)

Prop AMMの更新とJupiter SwapのCompute Unitsを比較すると、更新は極めて安価で、その比率は1:1000です。

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

Jupiter Swap：Jupiterルーティングによるswapは~100,000CUに達し、総コストは0.000005 SOLです。

この大きな差により、マーケットメーカーは更新取引にごくわずかな手数料を支払うだけで、スワップよりはるかに高いFee/CU比率を実現でき、更新がブロックのトップで実行されることを保証し、アービトラージ攻撃から自分を守ることができます。

なぜProp AMMはEVM上でまだ実現していないのか？

Prop AMMの更新が、取引ペアの価格曲線を決定する変数への書き込みを伴うと仮定します。Solana上のProp AMMコードは「ブラックボックス」ですが、マーケットメーカーはその戦略を秘密にしたいと考えています。しかし、この仮定を使えば、Sui上のObricがProp AMMをどのように実装しているかを理解できます：取引ペアの見積もりを決定する変数はupdate関数を通じてスマートコントラクトに書き込まれます。

@markoggwpの発見に感謝！

この仮定を利用すると、EVMのアーキテクチャには重大な障害があり、SolanaのProp AMMモデルがEVM上で実現できないことが分かります。

振り返ると、OP-Stack Layer 2ブロックチェーン（BaseやUnichainなど）では、取引はGasごとの優先手数料で並べ替えられます（SolanaのFee / CUの並べ替えと類似）。

EVM上では、書き込み操作のGas消費が非常に高いです。Solanaの更新と比べて、EVM上でSSTOREオペコードを使って値を書き込むコストは驚くほど高いです：

· SSTORE（0 → 非0）：約22,100 gas

· SSTORE（非0 → 非0）：約5,000 gas

· 典型的なAMMスワップ：~200,000–300,000 gas

注：EVM上のGasはSolana上のCompute Units（CU）に類似しています。上記のSSTORE gas数値は、各取引で1回だけ書き込む（コールド書き込み）と仮定しています。これは妥当で、通常1回の取引で複数回の更新を送信することはありません。

更新は依然としてスワップより安価ですが、gas使用率は約10倍（更新は複数のSSTOREを含む可能性あり）であり、Solana上ではこの比率は約1000倍です。

このことから、SolanaのProp AMMモデルがEVM上でよりリスクが高いという2つの結論が導かれます：

1. Gas消費が高いため、優先手数料で更新の優先順位を確保しにくい、低い優先手数料では高い手数料/Gas比率を実現できません。更新が先に実行されてブロックのトップに配置されることを保証するには、より高い優先手数料が必要となり、コストが増加します。

2. EVM上ではアービトラージリスクが高い、EVM上では更新GasとスワップGasの比率は1:10であり、Solana上では1:1000です。つまり、アービトラージャーは優先手数料を10倍にするだけでマーケットメーカーの更新を先回りできますが、Solanaでは1000倍にする必要があります。この低い比率では、アービトラージャーが価格更新を先回りして古い見積もりを取得するコストが安価になるため、リスクが高まります。

一部のイノベーション（例えばEIP-1153のTSTORE、一時的なストレージ用）は約100gasで書き込みできますが、このストレージは一時的で、単一取引内でのみ有効です。価格更新を永続化して後続のスワップ取引（例えばブロック全体の間）で利用することはできません。

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

その前に「なぜやるのか」に答えます：ユーザーは常により良い取引見積もりを望んでおり、それはより有利な取引を意味します。EthereumやLayer 2のProp AMMは、Solanaや中央集権取引所でしか得られなかった競争力のある見積もりをユーザーに提供できます。

Prop AMMをEVM上で実現可能にするには、Solanaで成功した理由の1つを振り返ります：

· ブロックトップ更新保護：Solana上では、Prop AMMの更新がブロックのトップに配置され、マーケットメーカーが先回り取引から保護されます。更新がトップにあるのは、計算単位の消費が非常に少なく、手数料が低くても高い手数料/CU比率を実現できるからです。特にスワップ取引と比較して。

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

EVMの状態増大問題のため、書き込みコストを下げる方法は現実的ではありません。安価なSSTOREはガベージ状態攻撃を招くからです。

ここではProp AMM更新用の優先チャネルを作ることを提案します。これが実現可能な方法であり、本稿のポイントです。

Uniswapチームの@MarkTodaは、新しい方法を提案しています。グローバルストレージスマートコントラクト＋専用ブロックビルダーストラテジーによるものです：

その仕組みは次の通りです：

· グローバルストレージコントラクト：シンプルなスマートコントラクトを公開キー・バリューストアとしてデプロイします。マーケットメーカーは価格曲線パラメータをこのコントラクトに書き込みます（例：set(ETH-USDC_CONCENTRATION, 4000)）。

· ビルダーストラテジー：これはオフチェーンの重要なコンポーネントです。ブロックビルダーはグローバルストレージコントラクトに送信された取引を認識し、ブロックの最初の5～10%のGasをこれらの更新取引に割り当て、手数料順に並べ替えてスパム取引を防ぎます。

注意：取引はグローバルストレージアドレスに直接送信する必要があり、そうでなければブロックのトップに配置される保証はありません。

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

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

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

1. 保護：ビルダーストラテジーが「高速チャネル」を作り、ブロック内のすべての価格更新が取引前に実行されることを保証し、先回り取引リスクを排除します。

2. コスト効率：マーケットメーカーはすべてのDeFiユーザーと高いGas Priceでブロックトップ取引を競う必要がなくなり、ローカル手数料市場で更新取引用に予約されたトップブロックだけで競争すればよく、コストが大幅に削減されます。

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

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

結論

Prop AMMの実現可能性は、コアな経済問題——安価かつ優先的な実行で先回り取引を防ぐこと——の解決に依存します。

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

オープンな課題

· Prop AMMはEVM上の200ms Flashblockの速度でSolanaの連続アーキテクチャと競争できるか？

· Solana上のAMMトラフィックの大部分は単一のアグリゲーターJupiterから来ており、AMMの統合を容易にするSDKを提供しています。しかしLayer 2 EVM上ではトラフィックが複数のアグリゲーターに分散し、共通のSDKがありません。これはProp AMMにとって課題となるでしょうか？

· Prop AMMはSolana上での更新が約100CUしか消費しませんが、その実装メカニズムは？

· 高速チャネルモデルはブロックトップの更新のみを保証します。1つのFlashblock内に複数のスワップがある場合、マーケットメーカーはこれらのスワップ間でどのように価格を更新するのでしょうか？

· YulやHuffなどの言語を使ってSolana上のPinocchioのような最適化EVMプログラムを書くことは可能でしょうか？

· Prop AMMとRFQの比較は？

· マーケットメーカーがブロックNで良い見積もりを出してユーザーを誘導し、ブロックN+1で悪い見積もりに更新することをどう防ぐか？Jupiterはどのように防いでいるか？

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

原文リンク