作为最大的DEX，值得看看官方文档学习学习。 本文是作者第一次尝试阅读Defi源码，先从V2源码入手，然后分析V3的改进，并不涉及V3源码的分析。

v2

总览

UniSwap作为DEX，最大的功能就是币币交换了。

1. 流动性：交易对的两种资产能顺利兑换的容易程度。在UniSwap中，用户进行币币交换是在流动池中通过放入币取出币来实现的，比如说用户想用USDT换ETH，那么只需要按照兑换比例放入一定USDT到流动池，再从流动池取出对应数量的ETH即可。
2. LP（liquidity provider，流动性提供者）通过往UniSwap存入币币对来为其提供流动性，UniSwap会回馈LP以Pool Token，LP可以随时燃烧Pool Token来取回它们存入的流动性，也就是币币对。当LP的流动性在交易中被触发时，LP会获得0.3%的手续费作为流动性的奖赏，这就是流动性挖矿能获利的原因。
3. 币与币之间是由金额换算关系的，比如1个A币能够换10个B币。这种换算关系是怎么得来的呢？UniSwap使用如下公式x*y=k(该公式被称为constant product formula)*。这里x和y分别代表交易对中两种代币的储备余额。例如，在一个 ETH - USDT 交易对中，x可能是 ETH 的储备数量，y是 USDT 的储备数量。k是一个常数，这意味着在每一次交易过程中，从这次交易的角度来看，x和y的乘积（k）必须保持不变。 下面是一个UniSwap完成价格定价的例子： 例如，假设初始时，在一个 ETH - USDT 的交易对中，ETH 的储备量x = 20个，USDT 的储备量y = 500个，那么根据公式可得`k = 20 500 = 10000。 现在有用户进行了一笔小额交易，用 USDT来换取1个 ETH 。交易完成后，ETH 的储备量x变为20 - 1 = 19个。为了保证k不变，依旧是10000，则此时 USDT 的储备量y就变为10000 ÷ 19 ≈ 526.32个（这里保留两位小数），也就是说对于这次交易而言，1eth=26.32USDT。可以看到，通过少量 ETH 的兑换，USDT 的储备量相应增加了，而k始终保持为10000`，整体交易对的这个 “内在价值” 没有改变，只是两种资产的储备数量进行了调整以适应交易。 可见v2的价格定价是根据constant product formula 来决定的，而v1有专门的定价函数来确认价格，通过constant product formula 来确认价格更加方便安全快捷。 除了依赖公式以外，还依赖预言机**：市场价格是动态变化的。为了防止价格操纵（如抢先交易），Uniswap 的定价也会参考预言机提供的 “公平” 价格。预言机可以是简单的链外市场价格观察，也可以是原生 V2 预言机等其他方式。由于套利机制，同区块内交易对储备的比率往往接近 “真实” 市场价格。如果市场上 ETH - USDT 的外部参考价格发生变化，或者流动性池中的储备量因为其他交易而改变，那么你能换取的 USDT 数量也会相应地根据上述定价机制进行调整。
4. 由于不同交易所对币对之间的价值是按照流动池判定的，所以会出现不同交易所同样的币对相对价值不一样的情况，这种情况会被套利者进行套利，从而使各大交易所的价格趋同。这一点UniSwap是很支持的
5. Uniswap也提供Flash Swaps也就是闪电贷

代码分析-core

https://github.com/Uniswap/v2-core 源码地址。

v2由两部分合约组成，core合约和periphery合约。 core合约就是主心骨，但它对用户不太友好：用户直接调用core合约做交易并不是推荐的方法，periphery合约就是和主心骨打交道的外围合约，用户用periphery合约作为中介和core合约交互完成交易。

core合约由三个文件构成：

UniswapV2Factory.sol 它的主要工作是为每个唯一的代币对创建且仅创建一个智能合约。

UniswapV2Pair.sol充当自动做市商以及跟踪资金池代币余额。它们还公开可用于构建去中心化价格预言机的数据。

UniswapV2ERC20.sol Pair合约的ERC实现

下面将会从这三个sol文件入手分析uniswap的逻辑。

Pairs ERC20

Pair合约的ERC实现

官方文档https://docs.uniswap.org/contracts/v2/reference/smart-contracts/pair-erc-20

pragma solidity =0.5.16;

import './interfaces/IUniswapV2ERC20.sol';
import './libraries/SafeMath.sol';

contract UniswapV2ERC20 is IUniswapV2ERC20 {
    using SafeMath for uint;

    string public constant name = 'Uniswap V2';
    string public constant symbol = 'UNI-V2';
    uint8 public constant decimals = 18;
    uint  public totalSupply;
    mapping(address => uint) public balanceOf;
    mapping(address => mapping(address => uint)) public allowance;

    bytes32 public DOMAIN_SEPARATOR;
    // keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)");
    bytes32 public constant PERMIT_TYPEHASH = 0x6e71edae12b1b97f4d1f60370fef10105fa2faae0126114a169c64845d6126c9;
    mapping(address => uint) public nonces;

    event Approval(address indexed owner, address indexed spender, uint value);
    event Transfer(address indexed from, address indexed to, uint value);

    constructor() public {
        uint chainId;
        assembly {
            chainId := chainid
        }
        DOMAIN_SEPARATOR = keccak256(
            abi.encode(
                keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
                keccak256(bytes(name)),
                keccak256(bytes('1')),
                chainId,
                address(this)
            )
        );
    }

    function _mint(address to, uint value) internal {
        totalSupply = totalSupply.add(value);
        balanceOf[to] = balanceOf[to].add(value);
        emit Transfer(address(0), to, value);
    }

    function _burn(address from, uint value) internal {
        balanceOf[from] = balanceOf[from].sub(value);
        totalSupply = totalSupply.sub(value);
        emit Transfer(from, address(0), value);
    }

    function _approve(address owner, address spender, uint value) private {
        allowance[owner][spender] = value;
        emit Approval(owner, spender, value);
    }

    function _transfer(address from, address to, uint value) private {
        balanceOf[from] = balanceOf[from].sub(value);
        balanceOf[to] = balanceOf[to].add(value);
        emit Transfer(from, to, value);
    }

    function approve(address spender, uint value) external returns (bool) {
        _approve(msg.sender, spender, value);
        return true;
    }

    function transfer(address to, uint value) external returns (bool) {
        _transfer(msg.sender, to, value);
        return true;
    }

    function transferFrom(address from, address to, uint value) external returns (bool) {
        if (allowance[from][msg.sender] != uint(-1)) {
            allowance[from][msg.sender] = allowance[from][msg.sender].sub(value);
        }
        _transfer(from, to, value);
        return true;
    }

    function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external {
        require(deadline >= block.timestamp, 'UniswapV2: EXPIRED');
        bytes32 digest = keccak256(
            //构建签名摘要
            abi.encodePacked(
                '\x19\x01',
                DOMAIN_SEPARATOR,
                keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline))
            )
        );
        address recoveredAddress = ecrecover(digest, v, r, s);
        require(recoveredAddress != address(0) && recoveredAddress == owner, 'UniswapV2: INVALID_SIGNATURE');
        _approve(owner, spender, value);
    }
}

除了permit函数外其它函数都好理解，都是ERC20的标准函数。

    function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external {
        require(deadline >= block.timestamp, 'UniswapV2: EXPIRED');
        bytes32 digest = keccak256(
            //构建签名摘要
            abi.encodePacked(
                '\x19\x01',
                DOMAIN_SEPARATOR,
                keccak256(abi.encode(PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline))
            )
        );
        address recoveredAddress = ecrecover(digest, v, r, s);
        require(recoveredAddress != address(0) && recoveredAddress == owner, 'UniswapV2: INVALID_SIGNATURE');
        _approve(owner, spender, value);
    }
}

在 Uniswap（以及许多去中心化金融应用）中，用户经常需要授权合约对其资产（如 ERC - 20 代币）进行操作。传统的授权方式可能需要用户发送一笔交易来调用授权函数（approve），这可能涉及到一些交易成本（如以太坊网络的燃气费），并且操作相对繁琐。 Uniswap 的permit函数提供了一种更便捷的授权机制。它允许用户通过签名（通常是使用以太坊账户的私钥进行签名）来授权合约对其资产进行特定操作，而无需发送专门的授权交易。这类似于提供了一个 “离线签名授权” 的功能，提高了授权的效率，特别是在一些复杂的交易场景或者批量授权操作中非常有用。

以下是一个更详细的permit函数使用示例，假设在一个简化的去中心化金融场景中，这个签名校验是ERC-712的杰作：

1. 角色与目标

   • 有用户 Alice，她持有一定数量的某种 ERC - 20 代币（假设为 ABC 代币），并且想要在一个去中心化交易所（类似于 Uniswap）上进行交易，但不想通过传统的链上授权方式（approve函数）来授权交易所合约使用她的代币，因为她希望节省燃气费用并且加快交易流程。
   • 还有一个去中心化交易所合约 DEXContract，它需要获得用户的授权才能操作用户的代币进行交易。

2. 生成签名（Alice 端）

   • Alice 使用她的以太坊钱包（如 MetaMask）来生成签名。她打开钱包并找到与她的以太坊地址相关联的 ABC 代币账户。
   • 她确定要授权 DEXContract 花费她的 10 个 ABC 代币，并且设定授权的截止时间为未来 24 小时后的 Unix 时间戳（假设当前时间戳为 1609459200，那么截止时间戳可以设置为 1609545600）。
   • 钱包软件会根据 Alice 提供的这些信息（授权者地址 Alice、被授权者地址 DEXContract、授权金额 10、截止时间 1609545600 以及当前的 nonce 值，假设初始 nonce 为 0），按照 ERC - 712 标准构建一个包含这些信息的结构化数据，并使用 Alice 的以太坊私钥对其进行签名。签名结果得到v = 27，r = 0x123456789abcdef...（64 字节的哈希值），s = 0xfedcba987654321...（64 字节的哈希值）。

3. 提交授权（Alice 向 DEXContract 提交）

   • Alice 将生成的签名（v、r、s）以及授权的相关信息（自己的地址 Alice、DEXContract 的地址、授权金额 10、截止时间 1609545600）发送给 DEXContract。

4. 验证签名（DEXContract 端）

   • DEXContract 收到 Alice 的签名和相关信息后，首先会按照 ERC - 712 标准解码这些信息，获取原始的授权数据结构。
   • 然后，DEXContract 使用ecrecover函数，结合接收到的v、r、s以及解码后的授权数据结构中的信息（特别是包含的 Alice 的地址等）来验证签名的有效性。
   • 如果签名验证成功，意味着 DEXContract 可以信任这个授权，并且知道是 Alice 授权它可以使用 10 个 ABC 代币进行交易操作（在截止时间 1609545600 之前）。此时，DEXContract 就可以在交易中使用 Alice 的这 10 个 ABC 代币，例如在交易对 ABC/ETH 中，用这 10 个 ABC 代币去兑换 ETH，为 Alice 执行交易操作。

Pairs

Pair合约主要实现了三个方法：mint（添加流动性）、burn（移除流动性）、swap（兑换）。

mint

当有人提供流动性时，提供LP代币。

    function mint(address to) external lock returns (uint liquidity) {

        //amount0,amount1为获取用户提供的两种代币的值
        (uint112 _reserve0, uint112 _reserve1,) = getReserves();
        uint balance0 = IERC20(token0).balanceOf(address(this));
        uint balance1 = IERC20(token1).balanceOf(address(this));
        uint amount0 = balance0.sub(_reserve0);
        uint amount1 = balance1.sub(_reserve1);

        //计算交易费，只有当对应factory的feeTO为true时才调用
        bool feeOn = _mintFee(_reserve0, _reserve1);
        uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
        if (_totalSupply == 0) {//总价值为0说明是刚开的流动性池
            liquidity = Math.sqrt(amount0.mul(amount1)).sub(MINIMUM_LIQUIDITY);
           _mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens
        } else {//计算本次提供的流动性能获得的代币
            liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);
        }
        require(liquidity > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_MINTED');
        _mint(to, liquidity); //基于流动性提供者LP代币

        _update(balance0, balance1, _reserve0, _reserve1);
        if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
        emit Mint(msg.sender, amount0, amount1);
    }

burn

移除流动性，烧毁LP代币兑换为原货币

 function burn(address to) external lock returns (uint amount0, uint amount1) {
        (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
        address _token0 = token0;                                // gas savings
        address _token1 = token1;                                // gas savings
        uint balance0 = IERC20(_token0).balanceOf(address(this));
        uint balance1 = IERC20(_token1).balanceOf(address(this));
        uint liquidity = balanceOf[address(this)]; //这里我曾诞生出一个疑问：通过address(this)获取LP代币不是意味着获取整个矿池的LP代币吗，后来分析了一下，只有当移除流动性时用户才会把LP代币发到该合约上，LP代币被销毁后再完成移除流动性交易的转账操作后，所以这里获取的LP代币其实就是用户移除流动性时发过来的。 那是不是可以通过钓鱼钓LP代币来盈利？

        bool feeOn = _mintFee(_reserve0, _reserve1);
        uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
        amount0 = liquidity.mul(balance0) / _totalSupply; // using balances ensures pro-rata distribution，这样计算能够回收手续费
        amount1 = liquidity.mul(balance1) / _totalSupply; // using balances ensures pro-rata distribution
        require(amount0 > 0 && amount1 > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_BURNED');
        _burn(address(this), liquidity);
        _safeTransfer(_token0, to, amount0);
        _safeTransfer(_token1, to, amount1);
        balance0 = IERC20(_token0).balanceOf(address(this));
        balance1 = IERC20(_token1).balanceOf(address(this));

        _update(balance0, balance1, _reserve0, _reserve1);
        if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
        emit Burn(msg.sender, amount0, amount1, to);
    }

关于手续费：总的来说，在burn函数中，通过计算 LP 在流动性池中的份额，并根据当前包含手续费累积后的余额按比例分配两种代币，从而实现了 LP 在退出流动性提供时回收手续费收益的操作。这种计算方式保证了 LP 能够公平地获取自己应得的包括手续费在内的资产部分。

关于手续费收益：一个池子tvl越少，同一笔钱投进去占得份额越大，取手续费时所分得比例越多，越赚。总体而言进行流动性挖矿时tvl越少，交易量越大的池子手续费收益越高。

swap

    function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
        require(amount0Out > 0 || amount1Out > 0, 'UniswapV2: INSUFFICIENT_OUTPUT_AMOUNT');
        (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
        require(amount0Out < _reserve0 && amount1Out < _reserve1, 'UniswapV2: INSUFFICIENT_LIQUIDITY');

        uint balance0;
        uint balance1;
        { // scope for _token{0,1}, avoids stack too deep errors
        address _token0 = token0;
        address _token1 = token1;
        require(to != _token0 && to != _token1, 'UniswapV2: INVALID_TO');

        //这两个 if 语句根据要输出的代币数量是否大于 0，分别调用 _safeTransfer 函数（应该是合约内自定义的用于安全转移代币的函数，可能包含一些异常处理机制确保代币转移的安全性）将 amount0Out 数量 的第一种代币转移到 to 地址，以及将 amount1Out 数量的第二种代币转移到 to 地址。这里采用的是一种 “乐观” 转移的方式，先尝试进行转移操作，后续再根据实际情况进行进一步的验证和调整。
        if (amount0Out > 0) _safeTransfer(_token0, to, amount0Out); // optimistically transfer tokens
        if (amount1Out > 0) _safeTransfer(_token1, to, amount1Out); // optimistically transfer tokens

        if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data);

        balance0 = IERC20(_token0).balanceOf(address(this));
        balance1 = IERC20(_token1).balanceOf(address(this));
        }
        //判断用户的代币输入是否符合预期
        uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
        uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
        require(amount0In > 0 || amount1In > 0, 'UniswapV2: INSUFFICIENT_INPUT_AMOUNT');
        { // scope for reserve{0,1}Adjusted, avoids stack too deep errors k值判断
        uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));
        uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(3));
        require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'UniswapV2: K'); //当用户进行币币交换时，为了补偿流动性提供者（LP）提供流动性的服务以及覆盖平台的运营成本等，交易通常会收取一定的手续费。这个手续费会导致交换后的两种代币储备量乘积（balance0Adjusted.mul(balance1Adjusted)）比没有手续费情况下的理论乘积（uint(_reserve0).mul(_reserve1)）稍微大一点。
        }

        _update(balance0, balance1, _reserve0, _reserve1);
        emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
    }

在调用时，用户需要传入必要的参数，包括 amount0Out（要输出的代币 A 的数量）、amount1Out（要输出的代币 B 的数量，可能为 0，如果用户只希望输出一种代币来换取另一种代币）、to（用户自己的钱包地址或者其他指定的接收交换后代币的地址），以及可能的 data（字节类型的数据，用于一些特殊的回调或者额外的信息传递，通常如果没有特殊需求可以为空）。

Factory

它的主要工作是为每个唯一的代币对创建且仅创建一个Pair合约。重点看看createPair函数，下面的代码中我对其进行了注释方便理解。

官方解释文档：https://docs.uniswap.org/contracts/v2/reference/smart-contracts/factory

pragma solidity =0.5.16;

import './interfaces/IUniswapV2Factory.sol';
import './UniswapV2Pair.sol';

contract UniswapV2Factory is IUniswapV2Factory {
    address public feeTo;
    address public feeToSetter;

    mapping(address => mapping(address => address)) public getPair;
    address[] public allPairs;

    event PairCreated(address indexed token0, address indexed token1, address pair, uint);

    constructor(address _feeToSetter) public {
        feeToSetter = _feeToSetter;
    }

    function allPairsLength() external view returns (uint) {
        return allPairs.length;
    }

    function createPair(address tokenA, address tokenB) external returns (address pair) {
        require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
        (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
        require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
        require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); // single check is sufficient

        //这个地方用于创建Pair合约
        bytes memory bytecode = type(UniswapV2Pair).creationCode; //获取Pair合约字节码
        bytes32 salt = keccak256(abi.encodePacked(token0, token1)); //获取token0和token1作为参数的bytes32作为salt
        assembly {
            pair := create2(0, add(bytecode, 32), mload(bytecode), salt) //生成的地址是根据salt来演算的，我们希望提供A/B地址的时候可以直接算出pair(A,B)的地址
      //v=0：向新创建的pair合约中发送的ETH代币数量（单位wei）
      //p=add(bytecode, 32)：合约字节码的起始位置
      //此处为什么要add 32呢？因为bytecode类型为bytes，根据ABI规范，bytes为变长类型，在编码时前32个字节存储bytecode的长度，接着才是bytecode的真正内容，因此合约字节码的起始位置在bytecode+32字节
      //n=mload(bytecode)：合约字节码总字节长度
      //根据上述说明，bytecode前32个字节存储合约字节码的真正长度（以字节为单位），而mload的作用正是读出传入参数的前32个字节的值，因此mload(bytecode)就等于n
      //s=salt：s为自定义传入的salt，即token0和token1合并编码
        }

        IUniswapV2Pair(pair).initialize(token0, token1);
        getPair[token0][token1] = pair;
        getPair[token1][token0] = pair; // populate mapping in the reverse direction
        allPairs.push(pair);
        emit PairCreated(token0, token1, pair, allPairs.length);
    }

    function setFeeTo(address _feeTo) external {
        require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
        feeTo = _feeTo;
    }

    function setFeeToSetter(address _feeToSetter) external {
        require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
        feeToSetter = _feeToSetter;
    }
}

代码分析-periphery

Library

一堆工具方法，用来方便的获取价格或者各类数据

Router

https://github.com/Uniswap/v2-periphery/blob/master/contracts/UniswapV2Router02.sol

由于UniswapV2Router01在处理FeeOnTransferTokens时有bug，目前已不再使用。此处我们仅介绍最新版的UniswapV2Router02合约。

为前端提供交易和流动性管理功能的所有基本要求

添加流动性

function addLiquidity(
    address tokenA,
    address tokenB,
    uint amountADesired,
    uint amountBDesired,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline
) external virtual override ensure(deadline) returns (uint amountA, uint amountB, uint liquidity) {
    (amountA, amountB) = _addLiquidity(tokenA, tokenB, amountADesired, amountBDesired, amountAMin, amountBMin);
    address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
    TransferHelper.safeTransferFrom(tokenA, msg.sender, pair, amountA);
    TransferHelper.safeTransferFrom(tokenB, msg.sender, pair, amountB);
    liquidity = IUniswapV2Pair(pair).mint(to);
}

由于Router02是直接与用户交互的，因此接口设计需要从用户使用场景考虑。addLiquidity提供了8个参数：

• address tokenA：代币A
• address tokenB：代币B
• uint amountADesired：希望存入的代币A数量
• uint amountBDesired：希望存入的代币B数量
• uint amountAMin：最少存入的代币A数量
• uint amountBMin：最少存入的代币B数量
• address to：流动性代币接收地址
• uint deadline：请求失效时间

用户提交交易后，该交易被矿工打包的时间是不确定的，因此提交时的代币价格与交易打包时的价格可能不同，通过amountMin可以控制价格的浮动范围，防止被矿工或机器人套利；同样，deadline可以确保该交易在超过指定时间后将失效。

在core合约中提到，如果用户提供流动性时的代币价格与实际价格有差距，则只会按照较低的汇率得到流动性代币，多余的代币将贡献给整个池子。_addLiquidity可以帮助计算最佳汇率。如果是首次添加流动性，则会先创建交易对合约；否则根据当前池子余额计算应该注入的最佳代币数量。

最后调用core合约mint方法铸造流动性代币。

移除流动性

首先将流动性代币发送到pair合约，根据收到的流动性代币占全部代币比例，计算该流动性代表的两种代币数量。合约销毁流动性代币后，用户将收到对应比例的代币。如果低于用户设定的最低预期（amountAMin/amountBMin），则回滚交易。

// **** REMOVE LIQUIDITY ****
function removeLiquidity(
    address tokenA,
    address tokenB,
    uint liquidity,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline
) public virtual override ensure(deadline) returns (uint amountA, uint amountB) {
    address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
    IUniswapV2Pair(pair).transferFrom(msg.sender, pair, liquidity); // send liquidity to pair
    (uint amount0, uint amount1) = IUniswapV2Pair(pair).burn(to);
    (address token0,) = UniswapV2Library.sortTokens(tokenA, tokenB);
    (amountA, amountB) = tokenA == token0 ? (amount0, amount1) : (amount1, amount0);
    require(amountA >= amountAMin, 'UniswapV2Router: INSUFFICIENT_A_AMOUNT');
    require(amountB >= amountBMin, 'UniswapV2Router: INSUFFICIENT_B_AMOUNT');
}

removeLiquidityWithPermit 使用签名移除流动性

用户正常移除流动性时，需要两个操作：

1. approve：授权Router合约花费自己的流动性代币
2. removeLiquidity：调用Router合约移除流动性

除非第一次授权了最大限额的代币，否则每次移除流动性都需要两次交互，这意味着用户需要支付两次手续费。而使用removeLiquidityWithPermit方法，用户可以通过签名方式授权Router合约花费自己的代币，无需单独调用approve，只需要调用一次移除流动性方法即可完成操作，节省了gas费用。同时，由于离线签名不需要花费gas，因此可以每次签名仅授权一定额度的代币，提高安全性。

function removeLiquidityWithPermit(
    address tokenA,
    address tokenB,
    uint liquidity,
    uint amountAMin,
    uint amountBMin,
    address to,
    uint deadline,
    bool approveMax, uint8 v, bytes32 r, bytes32 s
) external virtual override returns (uint amountA, uint amountB) {
    address pair = UniswapV2Library.pairFor(factory, tokenA, tokenB);
    uint value = approveMax ? uint(-1) : liquidity;
    IUniswapV2Pair(pair).permit(msg.sender, address(this), value, deadline, v, r, s);
    (amountA, amountB) = removeLiquidity(tokenA, tokenB, liquidity, amountAMin, amountBMin, to, deadline);
}

swapExactTokensForTokens

根据指定的输入代币，获得最多的输出代币

function swapExactTokensForTokens(
    uint amountIn,
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint deadline
) external virtual override ensure(deadline) returns (uint[] memory amounts) {
    amounts = UniswapV2Library.getAmountsOut(factory, amountIn, path);
    require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
    TransferHelper.safeTransferFrom(
        path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
    );
    _swap(amounts, path, to);
}

swapTokensForExactTokens

该方法实现交易的第二个场景，根据指定的输出代币，使用最少的输入代币完成兑换。

function swapTokensForExactTokens(
    uint amountOut,
    uint amountInMax,
    address[] calldata path,
    address to,
    uint deadline
) external virtual override ensure(deadline) returns (uint[] memory amounts) {
    amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
    require(amounts[0] <= amountInMax, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
    TransferHelper.safeTransferFrom(
        path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]
    );
    _swap(amounts, path, to);
}

v3

LP的权衡：集中流动性机制

concentrated liquidity（集中流动性）

v2流动性的困境：

1. niswap v2 的 AMM 机制（x⋅y = k）回顾
   • 在 Uniswap v2 的自动做市商（AMM）机制中，x⋅y = k这个公式是核心。这里x和y分别代表交易对中的两种资产数量，k是一个常数。例如在 ETH - USDT 交易对中，x可以是 ETH 的数量，y是 USDT 的数量。这个公式保证了在任何交易情况下，两种资产数量的乘积保持不变。
   • 当有用户进行交易，比如用 ETH 换 USDT 时，ETH 的数量x增加，为了保持k不变，USDT 的数量y就会相应减少，并且价格是根据交易前后两种资产数量的变化自动计算出来的。
2. 资金利用率低的问题
   • 全价格范围提供流动性：
     • 根据 Uniswap v2 的设计，流动性提供者（LP）需要为从价格为 0 到正无穷的整个价格区间提供流动性。这是因为在x⋅y = k的机制下，交易对的价格可以在理论上的任何位置出现，所以 LP 需要在整个价格曲线上都有资产储备。
   • 举例说明低效率情况：
     • 以当前价格为 1ETH = 1800USDT 为例，在 Uniswap v2 中，即使在非常不合理的价格，如 1ETH = 10USDT 这样的价格点上，LP 在 ETH - USDT 池中也需要按照比例持有一定数量的 ETH（和相应的 USDT）来提供流动性。这就导致了资金的浪费，因为在实际情况中，像 1ETH = 10USDT 这样的价格出现的概率极低，但 LP 的资金却被束缚在这种几乎不可能出现的价格区间上，无法高效地利用资金在更合理、更可能出现交易的价格区间提供流动性。例如，如果 LP 的大部分资金都被分配到这些不合理的价格区间用于提供流动性，那么在实际交易频繁发生的价格区间（如 1ETH = 1800USDT 附近），LP 能够提供的有效流动性就相对较少，资金利用率也就变低了。

v3解决方案

Uniswap v3版本的AMM曲线从无限变成局部。通过引入虚拟流动性，允许用户只在一段价格区间内提供流动性。在 x⋅y=k 的函数曲线图中，为了满足让用户可以选择只在[a,b]价格区间内提供流动性。

• 对于 ETH - USDT 交易对，假设当前价格是 1ETH = 1800USDT，LP 可以选择将资金集中在例如 1700 - 1900USDT 这个价格区间。这样一来，LP 的资金就不用像在 v2 中那样分散在从 0 到无穷大的整个价格区间，而是重点关注更有可能发生交易的价格区间，从而提高资金的利用率。

UniswapV3将连续的价格范围，分割成有限个离散的价格点。每一个价格对应一个 tick，用户在设置流动性的价格区间时，只能选择这些离散的价格点中的某一个作为流动性的边界价格。

如下是一个例子：

假设在 Uniswap v3 的交易世界里，你是一位精明的流动性提供者（LP），你精心选择将自己的资金投入到 ETH - USDT 交易对中，并设置了一个流动性头寸，其价格区间为 [1000 USDT/ETH, 1100 USDT/ETH]。

现在把价格空间想象成一个巨大的尺子，而 Ticks 就是尺子上的刻度。每一个微小的刻度代表着价格 0.01% 的变化，这就像是尺子上极其精细的标记，它们将整个价格范围划分得密密麻麻。对于你设置的这个价格区间 [1000, 1100]，就相当于在这把尺子上选定了一段特定的区域。

当市场价格在 900 USDT/ETH 或者 1200 USDT/ETH 时，这就好像市场的价格 “指针” 还在你选定的价格区间 “尺子段” 之外徘徊。此时，你提供的流动性不会加入到交易中。

然而，一旦市场价格的 “指针” 踏入了 1000 USDT/ETH 到 1100 USDT/ETH 这个区间，你提供的流动性就会加入到交易。

每达到一个新的 Tick 刻度，合约都会迅速做出反应，根据新的价格情况和流动性分布，灵活地调整资产交换的策略。就好像一场紧张刺激的接力赛，每跨越一个 Tick，合约就会利用新激活的 Tick 边界头寸内可能存在的休眠流动性（如果有其他 LP 也在类似边界设置了头寸），如同接过接力棒一般，持续为市场提供充足且高效的流动性，确保交易的 “赛道” 畅通无阻

交易费

v2 交易费的困境

• v1 和 v2 的手续费模式：
  • 在 Uniswap v1 和 v2 版本中，采用了一种相对简单直接的手续费收取方式。每个交易对都有自己独立的流动性池，并且对所有这些流动性池统一收取 0.30% 的手续费。例如，ETH - USDT 交易对的流动性池和其他任意交易对（如 LINK - ETH）的流动性池，无论它们的资产特性如何，都按照这个固定的 0.30% 比例收取手续费。
• 稳定币池的情况：
  • 对于稳定币池来说，0.30% 的手续费可能过高。稳定币对（如 DAI - USDC）的价格波动相对较小，交易风险也较低。这意味着在这些交易对中，流动性提供者（LP）不需要承担像高波动资产交易对那样高的价格风险。而且，稳定币之间的兑换需求通常比较频繁，交易量大。如果手续费过高，会增加交易者的成本，可能会使一些交易者望而却步，转而寻找其他交易成本更低的平台。例如，在进行大量的 DAI - USDC 兑换时，0.30% 的手续费可能会让频繁交易的用户觉得不划算，因为稳定币交易本身利润空间相对较窄，较高的手续费会明显压缩他们的收益。
• 高波动性池子的情况：
  • 对于高波动性的交易池，0.30% 的手续费又可能显得过低。高波动性资产（如某些新兴加密货币与主流加密货币组成的交易对）价格变化迅速且幅度较大，这使得 LP 在提供流动性时面临更高的风险。他们需要承担资产价格大幅波动可能导致的损失风险（无常损失、流动性风险、滑点风险），而且在这种交易对中，流动性管理也更加复杂。相对较低的手续费可能无法充分补偿 LP 所承担的风险，从而影响 LP 的积极性，也可能导致流动性池的资金不足，影响交易的顺利进行。例如，对于一个价格波动剧烈的小众加密货币与 ETH 的交易对，LP 需要时刻关注价格变化，因为资产价值可能在短时间内大幅变化，而 0.30% 的手续费可能不足以弥补他们在这种高风险环境下提供流动性的成本和风险。

v2在提供流动性中途，不能提取手续费，必须取消流动性才能把手续费提出，v3解决了这个问题随时可以取出

v3 解决方案

Uniswap v3 引入多种手续费池，目的是为了让每个交易对能够根据自身的特点（如资产的波动性、交易频率等）选择更合适的手续费机制，从而优化交易成本和收益结构，吸引更多的流动性提供者（LP）和交易者，提高整个交易生态系统的效率和稳定性。默认允许创建三个手续费等级：0.05%，0.30%和1%。可以通过UNI治理添加更多手续费等级。

• 0.05% 手续费等级：
  • 这个等级手续费较低，比较适合稳定币交易对。稳定币之间的价格波动小，交易频繁且利润空间相对较窄。较低的手续费可以降低交易者的成本，提高交易的吸引力。例如，对于 DAI - USDC 这样的稳定币交易对，采用 0.05% 手续费可以鼓励更多的用户进行交易，同时也能吸引 LP 提供流动性。因为虽然手续费率低，但由于交易量大，LP 仍然可以通过大量的交易来积累可观的手续费收益，而且稳定币交易对的无常损失风险较小，LP 在这种低手续费环境下也能获得相对稳定的收益。
• 0.30% 手续费等级：
  • 这是 Uniswap v1 和 v2 沿用下来的手续费等级，适用于一些价格波动适中、交易频率也适中的交易对。对于这类交易对，0.30% 的手续费可以在补偿 LP 风险和控制交易者成本之间达到一个相对平衡的状态。例如，一些主流加密货币之间的交易对（如 ETH - BTC），它们的价格波动不像新兴加密货币那么剧烈，但也不像稳定币那样稳定，0.30% 的手续费可以为 LP 提供一定的收益补偿，同时交易者也能够接受这个交易成本。
• 1% 手续费等级：
  • 较高的 1% 手续费等级适合高波动性和高风险的交易对。在这些交易对中，LP 面临着较大的资产价格波动风险、无常损失风险和流动性风险。较高的手续费可以对 LP 承担的这些风险进行补偿。例如，对于一些新兴加密货币与主流加密货币组成的交易对，由于新兴加密货币价格波动大，LP 提供流动性需要承担更多风险，1% 的手续费可以激励 LP 参与其中，同时也筛选出那些对价格不太敏感、更注重交易能够顺利完成的高风险偏好交易者。