Curve：NG Pools实现更便宜、免授权的Swap机制

概述

NG Pools 提供了一种创新的交换机制，`exchange_received`允许用户基于池内资金余额的变动进行交易。这种方法使得用户无需给予合约授权即可进行交换，从而在进行复杂交易时减少资金转移。

相比常规方法，`exchange_received`能显著降低交易过程中的gas消耗。在同一交易中使用`exchange_received`处理池资金是必须的，以避免资金被第三方盗用风险。

此方法还可以用于挽回错误发送到池中的资金。

介绍

`exchange_received`函数采用了一种基于AMM内部余额变动的代币交换新方法，而非依赖于传统的基于代币转移的交换方法。这对于DEX聚合器或套利者特别有利，因其具有显著的优势：首先，它消除了对AMM合约的授权需求，从而降低了gas成本，并对于那些合约可能被风险侵害的用户来说，减少了资金损失的风险。其次，对于涉及多个池的复杂交易，这种方法可以减少ERC-20资金转移，进一步降低gas成本。

`exchange_received`功能适用于所有Curve的新一代（ng）矿池，包括Twocrypto-ng、Stableswap-ng（不包括基础代币和元代币交易）和Tricrypto-ng（在非以太坊链上，部署索引为1的）。然而，截至2024年3月，其使用频率极低。以下内容将解释此功能的工作原理及其使用方法。在深入技术细节之前，让我们先进行一次概览。

免授权交换

在传统交换过程中，用户需先授权矿池从其钱包中提取特定数量的代币，然后才能执行交换并接收输出代币。这一步骤称为授权。授权后，用户可执行矿池的`exchange`函数来完成交换，交换过程将通过`transferFrom`函数从用户钱包中提取代币，并将输出代币转移至用户钱包。

以1000 USDC兑换为1 WETH的示例来说明，以下流程图展示了该过程：

通过`exchange_received`，用户可以跳过授权步骤，直接将1000 USDC发送到矿池合约。发送后，用户调用`exchange_received`并指定输入金额为1000 USDC。矿池执行交换，不通过`transferFrom`从用户钱包中提取代币，而是直接使用已加入其余额中的1000 USDC。确定输出代币数量后（在此例中为1 WETH），矿池将此金额返还给用户。

下图总结了这个过程：

重点优势

`exchange_received`的优势可能不立即明显，因为像常规`exchange`一样，它也涉及两次交易。但使用`exchange_received`具有两大优势：安全性和gas成本。

安全性

`exchange_received`的安全优势源于无需授权。如果合约被攻击，有授权权限的攻击者可能以任何他们认为合适的方式使用您的资金。仅在2024年前两个月，就有超过1000万美元的资金从被泄露的合约中被盗。今年3月，ParaSwap发起了白帽攻击来保护超过200万美元的用户资金，这些资金因新的Augustus V6合约获得无限授权而面临风险。鉴于以太坊上60%的授权交易为无限授权，这构成了大多数DeFi用户的一个重大安全威胁。对于需要节省gas成本的套利者来说，这种风险尤其显著，因为他们往往在钱包中持有大量代币。

然而，用户可以选择只授权所需金额进行交换，这样虽然每次交易都需更新授权，增加了gas成本，但提高了安全性。

Gas成本

从gas成本角度来看，授权交易通常比转账交易贵一倍，因此`exchange_received`自然是一个更经济的选择。为了量化节省的gas成本，可以使用Boa的Gas Profiler进行不同场景的比较。实际上，ERC-20函数的gas成本（如`approve`和`transferFrom`）会根据代币合约的具体实现有所不同。在这里，我们使用相同的Vyper实现来模拟所有代币交互。

使用授权的常规交换`exchange`

通过`exchange`进行的传统交换会消耗约93,859 gas。`transferFrom`在消耗完所有津贴时会得到gas退款，特别是当交易将合约中的存储槽位津贴设置为零时，这将带来15k的gas退款。如果使用了部分津贴（如之前设置了无限授权），则不会获得任何退款。

`exchange`在无限授权后的常规交换

无限授权的情况下，`transferFrom`的gas成本从给用户15k的gas退款转变为大约7k的费用。这是因为只是减少了合约允许的消费金额，而不是将其设置为零。实际上，这几乎抵消了不使用授权交易所节省的gas。因为设置无限授权的初始交易本身就需要约20k gas，加上交易成本的21k。

使用`exchange_received`的授权与非授权交换

使用`exchange_received`时，无需执行授权交易。我们直接使用更经济的转账方法，没有gas退款，但总体成本比常规`exchange`方法低约8k gas。

通过减少转账次数来节省

到目前为止，我们只考虑了简单的两代币交换场景。然而，实际交易（特别是套利交易）通常更复杂，涉及多个池和代币。在这种情况下，不仅需要对每个池进行授权，还需要接收每次交换的输出代币，然后将其转移至下一个池进行下一步交易。使用`exchange_received`时，可以将下一个池设为第一个交换的接收方，以减少转账次数。因此，使用`exchange_received`的gas成本随着交易中交换次数的增加而降低。

例如，考虑一个交易者使用USDC购买CRV的情景。没有直接的USDC/CRV池，但存在USDC/WETH和WETH/CRV池。因此，用户需要先将USDC兑换成WETH，再将WETH兑换成CRV。假设WETH的价格为1000 USDC，CRV的价格为10 USDC。

在传统的`exchange`场景中，用户需要先授权USDC/WETH池以使用其USDC。然后通过调用`exchange`，矿池将从用户钱包中转出1000 USDC，并将1 WETH转回给用户。随后用户需授权WETH/CRV池以将1 WETH转移出去，之后调用`exchange`将WETH兑换成CRV。

下图总结了这些步骤：

关于【Curve：NG Pools实现更便宜、免授权的Swap机制】的延伸阅读

• 探索 Sui 生态：DEX 交易量环比增长 4 倍，游戏应用正在崛起

  Sui是一个基于权益证明的区块链，代币总供应量为100亿，具有创新功能。其生态系统获得了显著的采用，TVL环比增长了240%，DEX交易量环比增长了407%。Sui基金会正在投资社区建设活动，如Sui Overflow和Sui Basecamp。Sui应用活动可以帮助投资者分析实时趋势和用户活动。Sui网络的交易量和DeFi使用量都呈现出大幅增长，其中包括通过Telegram钱包玩游戏来挖掘OCEAN的交易。Sui的生态系统发展方向包括DeFi、游戏和社交领域。Sui基金会加强社区建设，使用Artemis的Sui Application Activity可以监控和分析实时链活动。

• 速读 Coinbase 智能钱包：有何亮点？如何与 Coinbase 交易所打通？

  Coinbase推出智能钱包，简化登录、无Gas体验、支持用余额支付，吸引交易所上亿用户，实现全新链上体验。智能钱包创建简单，可使用多种方式备份，保证资金安全。支持自托管钱包或Coinbase账户余额支付，提供无Gas费用的交易体验，易于开发者集成。已有数千个DApp集成，包括DeFi、社区、游戏和社交项目，为用户打开通往无限可能的链上世界的大门。Base还推出Onchain Summer活动，提供总共600 ETH奖励，开发者集成智能钱包有机会获得额外的40 ETH奖励。Coinbase智能钱包有望吸引大量用户，为Base链带来更多关注。

另一方面，使用`exchange_received`，用户可以简化这些步骤。他们首先将1000 USDC发送到USDC/WETH池，然后调用`exchange_received`，指定WETH/CRV池作为输出代币的接收者。因此，第一次交换产生的1个WETH直接转移到WETH/CRV池中。然后用户再次调用`exchange_received`使用WETH/CRV池，这次接收者是他们自己的钱包，从而收到100个CRV，同时节省了两次授权和一次代币转移的过程。

步骤总结如下：

这个过程不仅简化了操作，而且在gas成本上更为经济，节省了大约38k的gas。通过进一步的分析，我们可以得出两种方法的具体gas消耗比较。

与`exchange`和`transferFrom`比较

在`exchange`和`transferFrom`的常规过程中，如果清除了配额存储槽位，可以得到gas退款。例如，在WETH交换时，如果所有接收的WETH都被交换，余额存储槽将归零，可能得到额外的退款。但这通常不能完全抵消授权和额外转移的成本。

与`exchange_received`比较

相较于`exchange_received`，这种方式节省了授权、额外转移和交换本身的操作，从而在总体上节省了38k的gas。

警示

新功能`exchange_received`带有一定的风险。如果不正确实施，任何人都可能利用这一点盗取存于池中的资金。这个合约不区分资金来源，只关注额外的余额来执行交换。例如，如果Alice将代币发送到AMM池但未立即调用`exchange_received`，Bob可能会先一步使用这些代币进行交换。

为了减少此类风险，代币的转移和`exchange_received`操作必须在同一笔交易中完成。最佳做法是使用代理合约将这两个操作一起批处理，或者将交易打包到一个事务捆绑中。

此外，如果用户错误地发送代币到池中，使用`exchange_received`可以回收这些代币。

`exchange_received`的内部机制

要了解`exchange_received`功能背后的机制及其如何处理资金转移，需要先了解Curve池的基本运作。

`exchange_received`函数处理池内两种代币的交换，与常规`exchange`函数的逻辑几乎相同。参考NG池的实现代码，我们看到两个函数背后都调用了相同的内部函数。主要区别在于`exchange_received`传递的最后一个参数`expect_optimistic_transfer`，其值设为true，而在常规`exchange`中为false。

下面是代码 `exchange_received`：

而对于标准 `exchange` ：

在内部 `_exchange` 函数中， `expect_optimistic_transfer` 参数被传递给另一个内部函数 `_transfer_in` 。其余逻辑是相同的，无论用户调用 `exchange` 还是 `exchange_received` ：

因此， `_transfer_in` 函数是动作发生的地方，标志着两种类型的交换函数之间的分歧点—— `exchange_received` 以及标准 `exchange` ：

该函数首先获取池中交换代币的当前余额，并存储于`_dx`变量中。接着，根据`expect_optimistic_transfer`参数的值（对于`exchange_received`为True，对于常规`exchange`为False），逻辑将分叉进行处理。

使用`exchange_received`（`expect_optimistic_transfer`==True）传输逻辑

当使用`exchange_received`时，该函数会从池的当前代币余额中扣减`_dx`指定的金额。这里的`stored_balances`变量是内部会计用的，记录通过标准交换（`exchange`或`exchange_underlying`）或通过添加或移除流动性的操作而进出池的代币。它也追踪了池中累积的费用，这些费用最终会被提取并分配给veCRV持有者。

实际上，`stored_balances`等同于池中的流动性储备加上待提取的管理费。当访问`stored_balances[0]`时，我们得到的是代币0的流动性量和相应的费用。与之相对的是，使用`balanceOf(pool_address)`时，我们得到的是池内代币的总余额。

如果有人直接向池发送代币（而非通过添加流动性或交换），则`balanceOf(pool_address)`的值可能会大于`stored_balances[0]`。因此，在使用`exchange_received`时，通过从池总余额中减去`_dx`，我们得到了可用于交换的“额外”代币量，这些是在调用`exchange_received`之前转移进池的。

使用常规`exchange`（`expect_optimistic_transfer`==False）传输逻辑

对于常规的`exchange`交换，使用`transferFrom`强制实现明确的资金转移。这就是为何池需要先获得批准的原因，因为如果未获得预先批准，合约将无法从用户钱包中提取代币。

`transferFrom`操作会确保池仅交换接收到的代币量，通过从池当前余额中减去`_dx`来实现。这比简单地重用`_dx`值更安全，因为不能保证实际收到的金额与`_dx`匹配（例如，如果令牌对转账征税，可能只返回指定比例的`_dx`）。

在执行剩余交换逻辑之前，`_dx`值（即要交换的输入代币数量）会被加入到池的`stored_balances`中，确保后续的交换逻辑正确执行。

免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：MarsBit，如有侵权请联系删除。转载或引用请注明文章出处！

标签：gasUSDC交易代币用户