原題：「Solving the issue with slippage in EIP-4626 》

最初のレベルのタイトル

オリジナル編集: ChinaDeFi

導入

導入

EIP-4626 標準の結果の 1 つは、デポジット機能と造幣機能では、リターンの最低シェアまたは資産額を指定する方法が提供されないことです。これは、高滑りやサンドイッチ攻撃を防ぐためによく使用されます。 mStable は、メタ ボールトを使用してこの問題にどのように対処し、コンプライアンスを維持しながら高スリッページ攻撃を軽減しますか?このホワイトペーパーでは、これらの課題について説明し、そのアプローチがどのように機能するかを説明します。

最初のレベルのタイトル

EIP-4626 および mStable Gold Vault デポジット

function deposit(uint 256 assets, address receiver)

external

returns (uint 256 shares);

たとえば、3 Crv Convex mUSD ボールトを預けると、発信者から 3 Crv が転送され、vcx 3 CRV-mUSD ボールト シェアが受信者に転送されます。

EIP-4626 の高スリッページ問題を解決するにはどうすればよいですか?

EIP-4626 の高スリッページ問題を解決するにはどうすればよいですか?

最初のレベルのタイトル

サンドイッチ攻撃とは何ですか？それらを防ぐにはどうすればよいでしょうか?

function add_liquidity(uint 256 [ 2 ] memory amounts, uint 256 min_mint_amount)

external

returns (uint 256 );

Curve Metapool (またはその他のプール) に流動性を追加するときは、預けたい資産の量と流動性プロバイダー (LP) トークンの最小量を指定します。 mUSD メタプールの場合、金額は 2 つの項目を含む配列です。 1 つ目は mUSD の金額、2 つ目は 3 Crv の金額です。 3 Crv Convex ボールトは 3 Crv のみを保持するため、金額配列の最初の項目はゼロになります。

ボールトを開発する際の技術的な課題は、予想される流動性プロバイダー トークンの最小数をどのように設定するかでした。

たとえば、Curve の mUSD メタプールが 200 万 mUSD、600 万 3 Crv、および 100,0068 LP トークン (musd 3 Crv) を受け取ることになります。メタプールが 600 万 mUSD を持っている場合、200 万 3 Crv と 100,000 3 Crv を追加すると、100,892 LP トークン (musd 3 Crv) を受け取ります。

最初のレベルのタイトル

攻撃者は、ブロックに含める前に、悪用可能なトランザクションがないか Mempool を監視します。トランザクションを悪用するために、彼らはブロックプロデューサーに賄賂を渡して、悪用可能なトランザクションの前後にトランザクションを含めるようにします。つまり、脆弱なトランザクションを自分自身のトランザクションで挟み込むことになります。最小 LP 量がゼロである mUSD メタプールに 3 Crv を追加するトランザクションがある場合、攻撃者の最初のトランザクションは、メタプール内の mUSD の量を減らすことになります。これは、脆弱な追加流動性トランザクションで受け取った Metapool LP トークンの量が、本来よりもはるかに少ないことを意味します。 3 番目のトランザクションでは、攻撃者は最初のトランザクションで削除された mUSD を返し、収益をポケットに入れます。

例

例

Curve の mUSD メタプールを使用すると、プールには 6,000,000 mUSD と 3 Crv、11,917,295 LP トークン (musd 3 Crv)、および仮想価格は 1.018095 ドルになります。

攻撃者は、プールの流動性プロバイダー (musd 3 Crv) トークン (musd 3 Crv) の 6,500,000 (54.5%) を使用してプールのバランスをとり、プールから 5,973,425 mUSD を引き出し、プール内の LP トークンの大部分を使用しました。 Remove_liquidity_one_coin 関数を使用して一方的な出金を行い、プールに 0.43% mUSD と 99.56% 3 Crv を残します。大規模なアンバランスな出金によりプールに手数料が請求されたため、ダミー価格はほぼ 1% 上昇して 1.019105 となりました。

被害者は、add_liquidity 関数を使用して、流動性プロバイダーの最小数のないアンバランス プールに 100,000 の 3 Crv を追加します。プールのバランスが取れている場合、被害者は 100371 ではなく 81978 の LP トークンを取得します。これは、被害者が受け取った LP トークンが、本来受け取るべきものより 18,393 (18%) 少ないことを意味します。ドル換算すると、被害者は 18,643 ドル (18%) の減額を受けました。

3 番目の最後のトランザクションでは、攻撃者は add_liquidity を使用して最初のトランザクションから引き出した 5,973,425 mUSD をプールに戻し、6,503,610 LP トークン (musd 3 Crv ) を受け取ります。最初の取引よりも 3610 ドル多く出金しました。これも不均衡なトランザクションであるため、プールの仮想価格は 1% 増加して 1.019216 になります。米ドル換算で、攻撃者の LP 価値は、6,500,000 ドル * 1.018095 = 6,617,617 ドルから 6,503,610 ドル * 1.019216 = 6,628,583 ドルに増加し、10,966 ドル (1.65%) 増加しました。

プールのバランスを崩すための 0.04% の手数料は、流動性プロバイダーとカーブ投票エスクロー CRV (veCRV) 保有者の間で均等に分配されます。攻撃者が保有していない 5,417,295 LP トークンの価値は、5,515,323 ドルから 5,520,794 ドルに増加しました。これはプール料金の 50% を上回る 5,471 ドルの増加です。増加した USD 価値はエスクローされた CRV (veCRV) 保有者に送られます。

最初のレベルのタイトル

カーブプロテクション

サンドイッチ攻撃を防ぐために、Curve Metapool に流動性を追加する際には、適切な最小数の LP トークンを指定する必要があります。通常、DeFiプロトコルはトランザクションでかなりの金額を渡します。 Curve プールの add_liquidity 関数は、min_mint_amount の良い例です。ただし、標準の EIP-4626 デポジット関数の場合、最小金額を指定するパラメーターが定義されていないため、オフチェーンで計算された大量の Metapool LP トークンを渡すことができません。

function calc_token_amount(uint 256 [ 2 ] memory amounts, bool is_deposit) external view returns (uint 256 );

したがって、EIP-4626 関数が最小量を渡す方法がないという問題は残ります。標準を破ってこれを追加することは望ましくなく、オラクルを使用することは最適ではありません。オンチェーンメソッドが必要です。

最初のレベルのタイトル

mStable のメソッド

function get_virtual_price() external view returns (uint 256 );

mStable の財務省が Metapool LP トークンの適正価格を取得する方法は、Curve Metapool および Curve 3 Pool からの仮想価格を使用することです。 get_virtual_price 関数は、プールの流動性プロバイダー トークンの価格を米ドルで返します。これは、プールの不変式を計算することによって行われます。これは、プール内のトークンのドル価値をトークンの総供給量で割ったものです。プール内のトークンの残高はプールの不変または合計ドル価値に影響を与えないため、仮想価格はサンドイッチ攻撃の影響を受けません。

fair Metapool LP tokens = 3 Crv assets *

 3 Pool virtual price /

Metapool virtual price

mStable ボールトへの入金の場合、メタプール LP トークンの価格を Curve の 3 プール LP トークン (3 Crv) で設定する必要があります。これはボールトで使用する資産であるためです。このために、3 プールの仮想価格を取得し、それをメタプール LP トークンの価格で割ります。

最初のレベルのタイトル

結論は

結論は