EVM が空白のままであるのに、Solana には Prop AMM が満載なのはなぜですか?

元記事のタイトル: Monad メインネットローンチ後に注目すべき dApps

オリジナル記事の著者: @0xOptimus

原文翻訳：Dingdang、Odaily Planet Daily

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

独自の自動マーケットメーカー（Prop AMM）は、Solana DeFiエコシステムにおいて急速に主導的な存在となりつつあり、現在、主要通貨ペアの取引量の40%以上を占めています。プロのマーケットメーカーが運営するこれらの流動性プラットフォームは、高い流動性とより競争力のある価格設定を提供します。その主な理由は、マーケットメーカーが「古い相場」を利用してフロントランニング・アービトラージを行うリスクを大幅に軽減できるからです。

画像ソース: dune.com

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

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

プロップ AMM とは何ですか?

独自の 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、および集中度に依存します。下の図は、マーケットメーカーがこれらの変数を継続的に更新する様子を示しています。

明確にしておきたい点が1つあります。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が作成したSolFi（SolanaベースのProp AMM）を参照することができます。具体的な価格曲線は不明で非公開ですが、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に影響し、シュレッド#2の価格更新はスワップ#2に影響します。

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

では、なぜSolanaのアップデートはこんなに安いのでしょうか？そして、何が優先的に実行されるのでしょうか？

まず、SolanaにおけるProp AMMの実装はブラックボックスですが、SolanaプログラムにおけるCUの記述方法を最適化するPinocchioのようなライブラリがあります。Heliusのブログには素晴らしい説明が掲載されています。このライブラリを用いることで、SolanaプログラムのCU消費量を約4000CUから約100CUに削減できます。

画像ソース: github

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

· 具体的には、Jitoを使用する場合、計算式はJitoチップ/計算単位となります。

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

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

プロップAMMアップデート：シンプルなカーブアップデートは非常に安価です。Wintermuteのアップデートは109 CUと非常に安価で、総コストはわずか0.000007506 SOLです。

ジュピタースワップ: ジュピタールートを介したスワップは最大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 上で実行できないことが判明しました。

OP-Stack レイヤー 2 ブロックチェーン (Base や Unichain など) では、トランザクションはガスごとの手数料に基づいて優先順位が付けられることを思い出してください (Solana の Fee/CU ソートと同様)。

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

· SSTORE (0 → 非0): ~22,100ガス

・SSTORE（非0→非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 GAS ですが、このストレージは一時的なものであり、単一のトランザクション内でのみ有効であり、後からデリバティブ取引で使用するために価格更新を永続化するために使用することはできません（たとえば、ブロック期間全体にわたって）。

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

答える前に、「なぜそうするのか」という問いに答えましょう。ユーザーは常により良い取引価格、つまりより多くの利益を求めています。EthereumとLayer 2のProp AMMは、これまでSolanaや中央集権型取引所でしか提供できなかった競争力のある価格をユーザーに提供できます。

Prop AMMをEVMで実現可能にするために、Solanaで成功した理由の1つを確認しましょう。

· ブロックトップアップデート保護：Solanaでは、Prop AMMアップデートはブロックトップで行われるため、流動性プロバイダーによるフロントランニングを防止できます。トップアップデートは、計算ユニットコストが最小限であるため可能であり、特にデリバティブ取引と比較して、低い手数料でも高い手数料/CU比率を実現できます。

では、レイヤー2 EVMブロックチェーンにブロックトップのProp AMMアップデートを導入するにはどうすればよいでしょうか？ 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と呼ばれる単一のアグリゲータから来ており、JupiterはAMMを簡単に統合するためのSDKを提供しています。しかし、レイヤー2 EVMでは、トラフィックは公開SDKのない複数のアグリゲータに分散されています。これはProp AMMにとって課題となるでしょうか？

· Solanaでは、Prop AMMのアップデートに必要なCUは約100個しかありません。この効率性を支える実装メカニズムは何ですか？

· ファストパスモデルは、ブロックの先頭部分のみの更新を保証します。フラッシュブロック内に複数の取引所がある場合、流動性プロバイダーはこれらの取引所間の価格をどのように更新するのでしょうか？

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

· 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