なぜSolanaにはProp AMMが満載なのに、EVM上はまだ空白なのか？

原文标题：Monadメインネットのローンチ後に見るべきdApps

原文作者：Optimus、ウォータールー・ブロックチェーン創設者

原文编译：叮当、Odaily星球日报

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

プロプライエタリ自動マーケットメーカー（Prop AMM）は、Solana DeFiエコシステムの主導的な力となりつつあり、現在、主要な取引ペアの40%以上の取引量を貢献しています。この専門のマーケットメーカーが運営する流動性プールは、深い流動性と競争力のある価格設定を提供できるのは、マーケットメーカーが「古い価格」（stale quotes）を利用したフロントランニング（front-running）アービトラージのリスクを大幅に低減できるからです。

画像出典：dune.com

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

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

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は、内部変数multx、multy、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)レベルの操作であり、これはチェーン上では遅くて高価です。

もしすべての見積もりを数学的な曲線で表現できるとしたらどうでしょう？あなたはその曲線を定義する少数のパラメータを更新するだけで済み、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. 更新コストが低い（cheap updates）

2. 優先実行権（priority execution）

Solanaでは、これら2つは相互に関連しています：低コストの更新は、しばしば更新が優先実行されることを意味します。

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

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

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

EVMのプレイヤーは「Solanaのスロットは約400msですが、Prop AMMはどのようにして単一のスロット内で複数回価格を更新できるのですか？」と尋ねるかもしれません。

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

· EVM：取引は通常、完全なブロックが提案され、最終確認された後に順番に実行されます。これは、途中で送信された更新が次のブロックまで有効にならないことを意味します。

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

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

では、なぜSolanaでの更新はこれほど安価なのでしょうか？また、どのように優先実行をもたらすのでしょうか？

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

次に、第二の部分を見てみましょう。より高いレベルでは、SolanaはFee / Compute Units比率が最も高い取引を優先的にソートします（Compute UnitsはEVMのGasに似ています）。

· 具体的には、Jitoを使用する場合、公式はJito Tip / Compute Unitsです。

· 使用しない場合：Priority = (優先費 + 基本費) / (1 + CU上限 + 署名CU + 書き込みロックCU)

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

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

Jupiter Swap：Jupiterルーティングによるスワップは約100,000 CUに達し、総費用は0.000005 SOLです。

この巨大な差異により、マーケットメーカーは更新取引に対して非常に少ない費用を支払うだけで、交換よりもはるかに高いFee/CU比率を実現でき、更新がブロックのトップで実行されることを保証し、アービトラージ攻撃から自らを守ることができます。

なぜProp AMMはEVMにまだ実装されていないのか？

Prop AMMの更新が取引ペアの価格曲線を決定する変数の書き込みを含むと仮定しましょう。Solana上のProp AMMコードは「ブラックボックス」であり、マーケットメーカーはその戦略を秘密にしたいと考えていますが、この仮定を用いてObricがSui上で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上の計算単位（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など、一時的なストレージ用）は約100 gasの書き込みを提供しますが、このストレージは一時的であり、単一の取引内でのみ有効であり、価格更新を持続化して後続のスワップ取引に使用することはできません（例えば、ブロック全体の期間中）。

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に変革をもたらす可能性があります。

オープンな問題

· EVM上の200ms Flashblockの速度は、Solanaの連続アーキテクチャと競争するのに十分ですか？

· Solana上のほとんどのAMMトラフィックは、単一のアグリゲーターJupiterから来ています。これはAMMの接続を容易にするSDKを提供しています。しかし、Layer 2 EVMでは、トラフィックが複数のアグリゲーターに分散し、公共のSDKがないことは、Prop AMMにとって挑戦となるでしょうか？

· Prop AMMはSolana上で約100 CUの更新を消費しますが、その実現メカニズムはどのようなものですか？

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

· YulやHuffなどの言語を使用して、Solana上のPinocchio最適化ソリューションに似た最適化されたEVMプログラムを書くことは可能ですか？

· Prop AMMとRFQの比較はどのようになりますか？

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

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