原文：《Solving the issue with slippage in EIP-4626》by Nick Addison
编译：ChinaDeFi
简介
EIP-4626 提供了一种将代币投资到投资池 ( 通常称为金库 ) 的标准方法。当我们存入自己的资产（ERC-20 代币）时，我们会收到一个份额代币，代表我们在金库里的资产。金库将把汇集的资产投资到一个或多个基础平台，为持有者产生收益。
EIP-4626 标准的一个结果是，存款和铸币函数没有提供指定回报的最小份额或资产金额的方法。这通常用于防止高滑点或三明治攻击。mStable 如何通过其 Meta Vaults 解决这个问题——在保持符合标准的同时减轻高滑点攻击？本文描述了这些挑战，并解释了他们的方法是如何工作的。
EIP-4626 和 mStable 金库存款
mStable EIP-4626 的首个金库将投资于基于 Curve 3Pool 的 Convex 池。从 EIP-4626 的角度来看，金库的资产是 Curve 3Pool 的流动性提供者代币 (3Crv)。存款函数是 EIP-4626 规范的一部分，它指定要存入多少资产以及将接收金库份额的帐户。存款函数返回给接收方会铸造多少金库份额。
function deposit(uint256 assets, address receiver)
external
returns (uint256 shares);
例如，存入 3Crv Convex mUSD 金库将从调用方转移 3Crv，并将 vcx3CRV-mUSD 金库份额转移到接收方。
EIP-4626 标准的强大之处在于，在投资池中有一种通用的投资方法，但对资产可以投资到底层平台的内容和时间没有限制。对于 mStable 的 3Crv Convx mUSD 金库来说， 3Crv 被添加到 Curve mUSD Metapool 中，然后产生的流动性提供者代币 (musd3Crv) 被存入 Convex mUSD 池中，该池会投资于 Curve mUSD gauge 并获得更高的回报。
这个过程中的一个技术挑战是如何防止三明治攻击。
什么是三明治攻击？如何预防它们？
当我们向 Curve Metapool( 或任何其他池 ) 添加流动性时，我们指定自己想存入的资产数量和流动性提供者 (LP) 代币的最小数量。对于 mUSD Metapool，金额是一个包含两项的数组。第一个是 mUSD 的量，第二个是 3Crv 的量。3Crv Convex 金库只存 3Crv，因此金额数组的第一项将为零。
function add_liquidity(uint256[2] memory amounts, uint256 min_mint_amount)
external
returns (uint256);
开发金库时的一个技术挑战是我们如何设置预期流动性提供者代币的最小数量。
仅仅将 min_mint_amount 设置为零是不够的，因为它会让存款交易受到三明治攻击。但在我们深入了解三明治攻击是如何工作之前，我们需要更多地了解 Curve Metapool 定价是如何工作的。由于金库只添加两个池代币 (mUSD 和 3Crv) 中的一个，因此它接收到的 Metapool 流动性提供者 (LP) 代币的数量将取决于 Metapool 中 mUSD 和 3Crv 的余额。池中的 3Crv 越多，当仅将 3Crv 添加到 Metapool 时，返回的 LP 代币就越少。
例如，如果 Curve 的 mUSD Metapool 添加了 200 万个 mUSD，600 万个 3Crv 和 100k 个 3Crv，则将收到 100,068 个 LP 代币 (musd3Crv)。如果 Metapool 有 600 万个 mUSD，添加了 200 万个 3Crv 和 100k 个 3Crv，将收到 100,892 个 LP 代币 (musd3Crv)。
那么三明治攻击是如何实现的呢?
攻击者在将交易包含到区块之前，就会监控 Mempool 中可能被利用的交易。为了利用交易，他们贿赂区块生产者，将他们的交易包含在可利用的交易之前和之后。也就是说，他们将易受攻击的交易与自己的交易夹在一起。如果有一笔交易将 3Crv 添加到最低 LP 金额为零的 mUSD Metapool，则攻击者的第一笔交易将是减少 Metapool 中的 mUSD 数量。这意味着在易受攻击的添加流动性交易中收到的 Metapool LP 代币数量远低于应有的数量。在第三个交易中，攻击者返还在第一个交易中删除的 mUSD，并将收益装入囊中。
例子
使用 Curve 的 mUSD Metapool，池中有 6,000,000 mUSD 和 3Crv, 11,917,295 个 LP 代币 (musd3Crv) 和 1.018095 美元的虚拟价格。
攻击者通过使用 6,500,000 (54.5%) 池流动性提供者 (musd3Crv) 代币从池中提取 5,973,425 的 mUSD，使用他们池中的大部分流动性提供者代币 (musd3Crv) 来平衡池。使用 remove_liquidity_one_coin 函数进行单边提款，池中剩下 0.43% mUSD 和 99.56% 3Crv。虚拟价格上涨了近 1%，至 1.019105，因为大量不平衡的提现为池收取了费用。
受害者使用 add_liquidity 函数将 100,000 个 3Crv 添加到不平衡的池中，且没有最小流动性提供者数量。如果池是平衡的，受害者得到 81978 个 LP 代币而不是 100371 个。这意味着受害者得到的 LP 代币比他们应该得到的少 18,393 个 (18%)。以美元计算，受害者得到的美元价值减少了 18,643(18%)。
对于第三个也是最后一个交易，攻击者使用 add_liquidity 将他们从第一个交易中提取的 5,973,425 个 mUSD 添加回池中，以接收 6,503,610 个 LP 代币 (musd3Crv)。比第一次交易多取了 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%)。
如果受害者损失了 18643 美元价值，而攻击者只获得了 10966 美元价值，那么缺失的 7677 美元价值在哪里?
使池失衡的 0.04% 费用由流动性提供者和 Curve 投票托管的 CRV (veCRV) 持有者平均分摊。攻击者未持有的 5,417,295 LP 代币的价值从 5,515,323 美元增加到 5,520,794 美元。这比池费用的 50% 增加了 5,471 美元。增加的美元价值归于托管 CRV (veCRV) 持有人。
Curve 的保护
为了防止三明治攻击，在向 Curve Metapool 添加流动性时，需要指定一个合理的最小 LP 代币数量。通常，DeFi 协议会在交易中传入相当数量的金额。Curve 池中的 add_liquidity 函数就是 min_mint_amount 的一个很好的例子。但是对于标准的 EIP-4626 存款函数，没有定义参数来指定最小金额，因此我们无法传入相当数量的链下计算的 Metapool LP 代币。
Curve 池有一个 calc_token_amount 函数，它可以计算池代币存款收到的 LP 代币数量。但这不能用来防止三明治攻击。如果已经运行了一个交易来平衡池，那么 calc_token_amount 函数将只返回当前不公平的 LP 代币数量。
function calc_token_amount(uint256[2] memory amounts, bool is_deposit) external view returns (uint256);
因此问题仍然存在，EIP-4626 函数没有办法传递最小量。打破标准来添加这一点是不可取的，使用预言机也是次优的。我们需要链上方法。
mStable 的方法
mStable 的金库获得一个公平的 Metapool LP 代币价格的方法是使用 Curve Metapool 和 Curve 3Pool 的虚拟价格。get_virtual_price 函数以美元为单位返回池的流动性提供者代币的价格。它通过计算池的不变式来实现这一点，该不变式是池中代币的美元价值除以代币的总供应量。由于池中代币的余额不影响池的不变值或总美元价值，虚拟价格不会受到三明治攻击。
function get_virtual_price() external view returns (uint256);
对于存入 mStable 金库的存款，我们需要在 Curve 的 3Pool LP 代币 (3Crv) 中对 Metapool LP 代币进行定价，因为这是我们在金库中使用的资产。为此，我们得到 3Pool 虚拟价格，并将其除以 Metapool LP 代币价格。
fair Metapool LP tokens = 3Crv assets *
3Pool virtual price /
Metapool virtual price
一旦我们有了一个合理的价格，我们就可以通过目前配置为 1% 的滑点系数来降低它。这个调整后的公平价格用于计算在向池中添加 3Crv 流动性时可以接收的 Curve Metapool LP 代币 (musd3Crv) 的最小数量。
存款的全部流程如下：
结论
虽然标准在标准化和获得采用方面起着巨大的作用，但像这样的问题提醒我们，在 DeFi 方面没有轻松的胜利。我们需要认识到现有标准的局限性，并为它们寻找最佳的解决方案。
