SolanaからEVMへの移行：独自AMMにとっての新たな展望

Prop AMMはSolanaにおける全取引量の40%を急速に獲得しています。なぜEVMでは浸透していないのでしょうか？

Proprietary AMM（Prop AMM）はSolanaのDeFiエコシステムで急速に台頭し、主要ペアの取引量の40%以上を担うまで成長しています。これらはプロのマーケットメイカーが運営する専門的な取引所で、アービトラージャーによる古いクォートのフロントランニングリスクを低減することで、深い流動性と競争力のある価格を提供しています。

https://dune.com/the_defi_report/prop-amms

しかし、その成功はほぼSolanaに限られています。なぜBaseやOptimismなどの高速・低コストなLayer 2を含むEVMエコシステムでは普及しないのでしょうか？

本記事では、Prop AMMの概要、EVMチェーンで直面する技術的・経済的障壁、そしてEVM DeFiにもProp AMMを普及させる可能性を持つ新たなアーキテクチャについて解説します。

Prop AMMとは？

Prop AMMは、プールの流動性と価格設定を単一のプロフェッショナルなマーケットメイカーが積極的に管理する自動マーケットメイカーです。従来のAMMのように一般ユーザーが受動的に流動性を供給するものではありません。

従来型AMMはx * y = kという式（xとyはプール内の2資産の数量、kは定数）で価格を決定しますが、Prop AMMは通常、秒間複数回更新される独自の数式を用います。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ではマーケットメイカーが価格を更新する際に調整するものです。Prop AMMの詳細に入る前に、AMMで価格がどう決まるかを理解しておくと役立ちます。例えばUniswap v2のWETH-USDCプール（手数料なし）では、価格はx * y = kという式で受動的に決まり、xとyはプール内の2資産の数量、kは定数です。曲線上の点のみがユーザーが取引で支払える価格となります。

例として、WETH-USDCプールに100 WETHと400,000 USDCがある場合、曲線上の現在の点はx = 100 WETH、y = 400,000 USDCで、初期価格は400,000 USDC / 100 WETH = 4,000 USDC/WETHです。定積kはxy = k = 40,000,000となります。トレーダーが1 WETHを購入すると、USDCをプールに追加し、WETH残高は99に減ります。定積kを維持するため、新しいxとyは曲線上の点でなければならず、USDC残高は40,000,000 / 99 ≈ 404,040.40 USDCに増加します。つまり、トレーダーは1 WETHのために4,040.40 USDCを支払い、初期価格4,000ドルより高くなります（価格インパクト、スリッページとも呼ばれます）。このためx y = k式は価格曲線とも呼ばれ、プールで可能な価格は曲線上の点のみとなります。

なぜマーケットメイカーはCLOBよりAMM設計を選ぶのか？

マーケットメイカーが市場形成にAMM設計を選ぶ理由を考えてみましょう。オンチェーンの中央限界注文板（CLOB）でマーケットメイカーをしていると仮定します。クォートを更新するには、数千もの指値注文をキャンセルし、置き換える必要があります。注文数Nの場合、これはO(N)の線形操作となり、特にオンチェーンでは遅く計算コストも高くなります。

もし全てのクォートを単一の数学的曲線で表現できれば、N個の注文を管理する代わりに、曲線全体を定義するパラメータを数個更新するだけで済みます。これによりO(N)の問題がO(1)の定数操作に変わります。

価格曲線（例：x*y = k）が様々な有効価格を生み出す様子を可視化するため、Ellipsis Labsが作成したProp AMM「SolFi」を例に見てみましょう。価格曲線自体は非公開ですが、Ghostlabsが作成した下記チャートは、Solanaの特定スロットで異なるSOL数量のスワップ希望時の有効SOL/USDC価格を示しています（EVM読者向けに、スロット番号はブロック番号に相当）。各線は異なるWSOL/USDCプールを表し、同時に異なる価格帯を提供できることを示しています。マーケットメイカーが価格曲線を更新すると、下記の有効価格チャートはスロットごとに変化します。

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

重要なのは、価格曲線の値を数個更新するだけで、マーケットメイカーが有効価格グラフを自在に変更できることであり、N個の注文を個別に更新する必要がない点です。これがProp AMMの本質的な価値であり、マーケットメイカーが高い資本効率と計算効率で深く動的な流動性を提供できる理由です。

SolanaのアーキテクチャがProp AMMに適している理由

Prop AMMは積極的に管理されます。これには「安価な更新」と「優先実行」の2つが必要です。Solanaでは更新が安価であるため、更新が優先実行されます。

なぜマーケットメイカーはこの2つが必要なのでしょうか？まず、マーケットメイカーは現在の在庫や資産のインデックス価格（例：中央集権型取引所の価格）などに基づき、チェーンの動作速度で価格曲線を更新します。Solanaのような高速チェーンでは、更新が安価でなければコストが高くなります。

次に、マーケットメイカーがブロックの先頭で更新できなければ、古いクォートがアービトラージャーに「拾われ」、確実に損失を被ります。

これら2つの性質がなければ、マーケットメイカーは効率的に運用できず、ユーザーにとっても取引価格が悪化します。

例えばSolanaのProp AMM「HumidiFi」は1秒間に74回クォートを更新していることが観測されています（@ SliceAnalyticsによるデータ提供）、下図参照：

https://dune.com/queries/5980584/9644764

EVMの世界から来た人は「Solanaのスロットは約400msなのに、Prop AMMは1スロット内で複数回価格を更新できるのはなぜか？」と疑問に思うかもしれません。

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

• EVM：取引は一般的に、完全なブロックが提案・確定された時に順次実行されます。つまり、ブロック途中で送信された更新は次のブロック開始まで反映されません。
• Solana：リーダーバリデータはフルブロックを構築するのを待たず、受信した取引を「シュレッド」と呼ばれる小パケットに分割し、ネットワーク全体に連続的にストリーミングします。1スロット内に複数のスワップが発生することもありますが、シュレッド#1の価格更新はスワップ#1に、シュレッド#2の価格更新はスワップ#2に影響します。

注：FlashblocksのようなソリューションはSolanaのシュレッドに類似しています。Anza Labsの@ AshwinninggによるCBERカンファレンスでの講演によると、400msスロットあたり最大32,000シュレッドの上限があり、1msあたり最大80シュレッドに相当します。200ms FlashblocksがSolanaの連続アーキテクチャと比較してマーケットメイカーに十分な速さかどうかは未解決の課題です。

ではSolanaで更新がなぜ安価で、優先実行につながるのでしょうか？

まず、Solana上のProp AMMの実装はブラックボックスですが、CU最適化されたSolanaプログラムを作成できるPinocchioのようなライブラリがあります。Heliusのブログ（こちら）では、SolanaプログラムのCUを約4000から約100に削減する様子が紹介されています。

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

次に、Solanaは高レベルでは、Fee / Computer Units比率が最も高い取引を優先して選択します（Compute UnitsはEVMのGasに相当）。EVMと同様です。

• Jitoを利用する場合、式はJito Tip / Compute Units
• 未利用の場合、Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs)（https://solana.com/docs/core/fees）

Prop AMMの更新とJupiter SwapのCompute Unitsを比較すると、Prop AMMの更新は1:1000という非常に安価な比率です。

Prop AMM更新：単純な曲線更新は非常に安価で、Wintermuteは109 CUで更新でき、トランザクション手数料は0.000007506 SOLです。

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap：Jupiter経由のスワップは約100,000 CU以上かかる場合があり、手数料は0.000005 SOLです。

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

この大きな差により、マーケットメイカーは更新トランザクションに少額の手数料を支払うことで、Fee/CU比率をスワッパーよりも桁違いに高くでき、安価かつブロック先頭で確実に更新が実行され、トキシックフローによるアービトラージから保護されます。

なぜProp AMMはEVMですでに普及していないのか？

Prop AMMの更新は、取引ペアの価格曲線を決定する変数の書き込みを伴うと仮定します。Solana上のProp AMMコードはブラックボックスですが、マーケットメイカーは自らの優位性を秘密にしたいと考えています。Sui上のObricのProp AMM実装を見ると、取引ペアのクォートを決定する変数がアップデート関数を通じてスマートコントラクトに書き込まれています。

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

@ markoggwpによる発見に感謝します。

この前提のもと、EVMのアーキテクチャはSolanaのProp AMMモデルを成立不可能にする大きな障壁となっています。

OP-Stack Layer 2（BaseやUnichainなど）では、取引はPriority Fee per Gasで並べ替えられます（SolanaのFee / CUによる優先順位付けと同様）。

EVMでは、書き込みのガス消費量が高いです。SSTOREオペコードによる1値のストレージ書き込みは、Solanaの更新と比べて非常に高コストです。

• SSTORE（ゼロ→非ゼロ）：約22,100 gas
• SSTORE（非ゼロ→非ゼロ）：約5,000 gas
• 典型的なAMMのスワップ：約200,000～300,000 gas

GasはEVMではSolanaのCompute Unitsに相当します。

また、上記SSTOREのガス値は1トランザクションにつき1回の書き込み（コールドライト）を前提としており、1トランザクションで複数回更新することはありません。

更新はスワップよりも安価ですが、ガス消費比率は約10倍程度（更新で複数回SSTOREを使う場合もあり）、Solanaの約1000倍と比べて大きく劣ります。

このことから、SolanaのProp AMMモデルをEVMで採用する場合、2つのリスクが生じます。

1. ガス消費量が高いため、少額の優先手数料では高いPriority Fee / Gasを達成できません。更新がフロントランされずブロック先頭に来るには、より高額な優先手数料が必要となり、コストが増加します。
2. EVM上では更新のガス消費とスワップのガス消費比率が1:10しかないため、アービトラージャーは更新トランザクションの10倍のPriority Feeを支払うだけでマーケットメイカーの更新を上回りフロントランできてしまいます。Solanaの1:1000と比べて、EVMではアービトラージャーが価格更新をフロントランし古いクォートを取るコストが低く、リスクが高まります。

EIP-1153（TSTOREによる一時ストレージ）のような革新は100ガスで書き込み可能ですが、このストレージは一時的でトランザクションの期間しか持続せず、次のスワップトランザクションまで価格更新を保持できません（ブロック期間など）。

Prop AMMをEVMにどう持ち込むか？

この問いに答える前に「なぜ」を簡単に説明します。ユーザーは常により良いクォートを求めており、それがより有利な取引につながります。EthereumやLayer 2ブロックチェーン上でProp AMMが実現すれば、Solanaや中央集権型取引所でしか得られない競争力のあるクォートをユーザーが享受できます。

Prop AMMをEVMで実現するためには、SolanaでProp AMMが機能する理由の一つを思い出しましょう：

• SolanaではProp AMMの更新がブロック先頭（Top of Block）に来ることで、マーケットメイカーはフロントランを防げます。更新はCompute Units消費が非常に少なく、低手数料でも高いFee / CUを達成でき、スワップと比べて優先されます。

Layer 2 EVMブロックチェーンでTop of BlockのProp AMM更新を実現するにはどうすればよいでしょうか？アプローチは2つあります。書き込みコストを下げるか、Prop AMM更新専用の優先レーンを作るかです。

書き込みコストを下げる方法は、EVMのステート成長問題（安価なSSTOREがステートスパムを助長する）により現実的ではありません。

そこで、Prop AMM更新専用の優先レーンを作るという第2の方法を提案します。

Uniswapチームの@ MarkTodaが提案した新しいアプローチでは、Global Storageスマートコントラクト（リポジトリ）と特化したビルダーポリシーを組み合わせます。

https://github.com/flashbots/global-storage-smart-contract

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

• Global Storage Contract：単純なスマートコントラクトを公開鍵値ストアとしてデプロイします。マーケットメイカーは価格曲線パラメータ（例：set(ETH-USDC_CONCENTRATION, 4000)）を書き込みます。

Builder Policy：これは重要なオフチェーン要素です。ブロックビルダーはGlobal Storageコントラクトアドレスへのトランザクションを認識するポリシーを実装し、ブロックのガスの最初の5～10%をこれら更新トランザクション専用に割り当て、優先手数料順に並べます。スパム防止のためです。

Global Storageアドレスへのto値を持つトランザクションであることが重要です。他のスワップ関数も呼ぶようなトランザクションがTop of Blockに来ることは避けたいからです。

• 以下はrblibを使ったカスタムブロック構築アルゴリズムの例です。

• Prop AMM統合：マーケットメイカーのProp AMMコントラクトは、スワップ時にGlobal Storageコントラクトから価格曲線データを読み取り、ユーザーへのクォート決定に利用します。

このアーキテクチャは両方の問題を巧みに解決します。

• 保護：ビルダーポリシーにより「高速レーン」が作られ、ブロック内の全ての価格更新がスワップ前に実行され、同一ブロック内でのフロントランリスクが排除されます。
• コスト効率：マーケットメイカーは全DeFiユーザーとガス価格でTop of Blockを争う必要がなく、更新トランザクション同士のみでローカルな手数料市場で競争するため、優先実行のコストが劇的に低減します。

ユーザーのスワップは、そのブロックの最初にマーケットメイカーが更新した価格曲線に対して実行され、常に新鮮かつ保護されたクォートが提供されます。このモデルにより、SolanaでProp AMMが繁栄した低コスト・高優先更新環境がEVMでも再現され、市場効率性の新時代が切り開かれます。

ただし、このモデルにも課題があり、記事末尾で議論のためにオープンクエスチョンとして残しています。

まとめ

Proprietary AMMの実現可能性は、フロントラン防止のための安価かつ優先的な実行という経済的課題の解決にかかっています。

標準的なEVMアーキテクチャではこれが非常に高コストかつリスクが高いですが、新しい設計によってこの問題へのアプローチが可能となります。オンチェーンGlobal Storageコントラクトとオフチェーンビルダーポリシーを組み合わせることで、価格更新専用の「高速レーン」を構築できます。このモデルはオラクル更新のTop of Block実行を保証し、ローカルかつ閉じた手数料市場を確立することで、Prop AMMのみならず、Top of Blockでオラクル更新が必要な全てのEVMベースDeFiを変革する可能性を秘めています。

オープンクエスチョン

• Prop AMMはEVM上で200ms Flashblock速度で運用してSolanaの連続アーキテクチャと競争できるか？
• SolanaではAMMの注文フローのほとんどが1つのアグリゲーターJupiter経由であり、AMMをアグリゲーターに接続するSDKも提供されています。一方、Layer 2 EVMブロックチェーンでは複数のアグリゲーターに注文フローが分散し、公開SDKがありません。これはEVMでのProp AMMに障壁となるか？
• SolanaでProp AMMの更新が約100 CUしか消費しない理由は？
• 提案された高速レーンモデルではProp AMM更新のみがTop of Blockに来ます。Flashblockが200msしかない場合、複数のスワップがFlashblock内で発生し、マーケットメイカーがその間に価格を更新したい場合はどう実装すればよいか？
• YulやHuffのような言語でEVMプログラムを最適化できるか？SolanaでPinocchioが最適化プログラムを書くのと同様に。
• Prop AMMはRFQとどう比較されるか？
• マーケットメイカーがブロックNで素晴らしいクォートを表示してユーザーを誘導し、ユーザーがブロックN+1でトランザクションを送信した際に、マーケットメイカーがN+1で悪いクォートに更新することを防ぐには？Jupiterはどう防止しているか？
• JupiterのUltra V3は「Ultra Signaling」を導入し、Prop AMMがトキシックフローと非トキシックフローを区別して3bpsタイトなクォートを提供可能にしています。こうしたアグリゲーター機能はEVMでProp AMMを実現する上でどれほど重要か？

P.S: 本テーマについてカンファレンス登壇の機会を探しています。Devconnect期間中のイベント関係者とつながりがあれば、ぜひご連絡ください！

免責事項：

1. 本記事は[0xOptimus]からの転載です。著作権は原著者[0xOptimus]に帰属します。転載にご異議がある場合はGate Learnチームまでご連絡ください。速やかに対応いたします。
2. 免責事項：本記事の見解・意見は著者個人のものであり、投資助言を構成するものではありません。
3. 本記事の他言語翻訳はGate Learnチームが行っています。特記がない限り、翻訳記事の無断転載・配布・盗用は禁止します。