Uniswap core源码学习

uniswap的core代码分为两部分，Factory和Pair，其中Factory是工厂合约，主要用来创建交易对，而Pair就是交易对合约，控制LP的mint和burn，以及用户的swap交易。
Factory

首先来看一下Factory合约，定义了四个变量：

1.   address public feeTo;
2.     address public feeToSetter;
4.     mapping(address => mapping(address => address)) public getPair;
5.     address[] public allPairs;
6.    
7.     constructor(address _feeToSetter) public {
8.             feeToSetter = _feeToSetter;
9.           }

复制代码

feeTo和feeToSetter负责协议手续费的去向控制，构造合约的时候需要设置feeToSetter，做好权限控制。
getPair和allPairs用于记录所有的流动性交易对以及映射关系。

1.   function setFeeTo(address _feeTo) external {
2.       require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
3.       feeTo = _feeTo;
4.   }
6.   function setFeeToSetter(address _feeToSetter) external {
7.       require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN');
8.       feeToSetter = _feeToSetter;
9.   }
10. }

复制代码

提供了两个可以用来修改手续费setter和to地址的方法。
最重要的核心就是下面的createPair，用于创建交易对。

1.   function createPair(address tokenA, address tokenB) external returns (address pair) {
2.       require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
3.       (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
4.       require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
5.       require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); // single check is sufficient
6.       bytes memory bytecode = type(UniswapV2Pair).creationCode;
7.       bytes32 salt = keccak256(abi.encodePacked(token0, token1));
8.       assembly {
9.           pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
10.       }
11.       IUniswapV2Pair(pair).initialize(token0, token1);
12.       getPair[token0][token1] = pair;
13.       getPair[token1][token0] = pair; // populate mapping in the reverse direction
14.       allPairs.push(pair);
15.       emit PairCreated(token0, token1, pair, allPairs.length);
16.   }

复制代码

权限控制

第一部分的代码写了三个require：

• 交易对两端token不可相同
  
• 交易对token不可为零地址
  
• 交易对还未创建
  

可以看到这里对tokenA和tokenB做了一个排序，这是为了保证唯一性，不论传入什么样顺序的交易对，都能输出一样的结果。
因为token0小于token1，所以在检查零地址的时候只需要检查一个即可。
部署合约

此处部署了新交易对的合约，使用了内联assembly，create2是创建合约的方法，它有一个特性就是创建得到的地址可预测：

1. address = keccak256(
2.     0xff,                    // 固定前缀
3.     deployer,                // 部署者地址（Factory）
4.     salt,                    // 盐值
5.     keccak256(bytecode)      // 字节码哈希
6. )

复制代码

这里的salt是用交易对中两个token的地址生成的，这也就意味着对于任意一对token，最终生成的合约地址是唯一且可预测的，即使合约没部署也可以通过计算提前知道合约地址。
初始化

部署好合约后，调用了initialize()对合约进行了初始化，并在map里登记了交易对互相之间的映射关系，然后发出一条event，标志着交易对创建完成。

为什么使用initialize调用进行初始化，而不是在create创建合约的时候通过构造函数初始化呢？

这是因为如果定义了构造函数，那在create的时候传入的字节码里就需要带上参数类型并且传入实参，导致最终得到的hash都不相同。
特别是外部合约或者其他代码中计算pair address时，只需要传入一个固定的常量creationCodeHash即可（直接由uniswap分享出来），而不需要试图去获取uniswap的creationCode（得不到）。
Pair

Pair合约是uniswap core代码里面最复杂的部分，负责交易对的相关内容。
首先从变量定义开始：

1. uint public constant MINIMUM_LIQUIDITY = 10**3;
2. bytes4 private constant SELECTOR = bytes4(keccak256(bytes('transfer(address,uint256)')));

复制代码

两个常量MINIMUM_LIQUIDITY和SELECTOR。
其中MINIMUM_LIQUIDITY是对最小流动性的要求，在初次添加流动性的时候会有MINIMUM_LIQUIDITY数量的LP token被永久锁定，即使所有的LP都赎回，也保证了池子不会被抽干，LP计算公式永远有效。
而SELECTOR的预定义是solidity中节约gas的方法，提前计算selector的字节码在合约编译的时候写入，后续调用的时候就无需花费gas重复计算。

1. uint112 private reserve0;           // uses single storage slot, accessible via getReserves
2. uint112 private reserve1;           // uses single storage slot, accessible via getReserves
3. uint32  private blockTimestampLast; // uses single storage slot, accessible via getReserves

复制代码

reserve是流动性池中代币的存量，但是和单纯的balance不同，因为合约是支持接收转账的，所以balance的数量可能因为其他的行为而发生改变，但reserve的值是统计所有符合Pair逻辑的行为之后得到的流动性池中合法的代币存量。
所以reserve并不是一个实时量，而是需要依赖更新操作，因此还需要一个时间变量blockTimestampLast来记录上次的更新时间。
在数据类型的设计上，reserve用了uint112而不是uint256之类常见的int长度，这是因为blockTimestampLast需要32位存储，对于一个uint256来说，还剩下224位，正好分给两个reserve，112位已经能够满足单个代币的供应量。
这种设计可以将三个变量放在一个slot中，节约存储空间，减少gas的使用。

在solidity中支持任意8的倍数的int类型，如uint16，uint32都是可以的

1. address public factory;
2. address public token0;
3. address public token1;

复制代码

定义了最基本的三个元素：

• factory，创建工厂的地址，避免非法调用
  
• token0和token1：交易对的两侧
  

1. uint public price0CumulativeLast;
2. uint public price1CumulativeLast;
3. uint public kLast;

复制代码

priceCumulativeLast代表了代币价格的累积值，用于计算代币的时间加权平均价格（TWAP），可以提供给外部作为预言机使用。
kLast是上次k值（x与y的乘积常量）变动时存储的值，使用场景在协议手续费的计算中。

1. event Mint(address indexed sender, uint amount0, uint amount1);
2. event Burn(address indexed sender, uint amount0, uint amount1, address indexed to);
3. event Swap(
4.     address indexed sender,
5.     uint amount0In,
6.     uint amount1In,
7.     uint amount0Out,
8.     uint amount1Out,
9.     address indexed to
10. );
11. event Sync(uint112 reserve0, uint112 reserve1);

复制代码

Pair里面有四个事件，分别代表着LP的添加和减少，代币的swap，还有流动性池数量的更新。
mint

1. function mint(address to) external lock returns (uint liquidity) {
2.     (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
3.     uint balance0 = IERC20(token0).balanceOf(address(this));
4.     uint balance1 = IERC20(token1).balanceOf(address(this));
5.     uint amount0 = balance0.sub(_reserve0);
6.     uint amount1 = balance1.sub(_reserve1);
8.     bool feeOn = _mintFee(_reserve0, _reserve1);
9.     uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
10.     if (_totalSupply == 0) {
11.         liquidity = Math.sqrt(amount0.mul(amount1)).sub(MINIMUM_LIQUIDITY);
12.        _mint(address(0), MINIMUM_LIQUIDITY); // permanently lock the first MINIMUM_LIQUIDITY tokens
13.     } else {
14.         liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);
15.     }
16.     require(liquidity > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_MINTED');
17.     _mint(to, liquidity);
19.     _update(balance0, balance1, _reserve0, _reserve1);
20.     if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
21.     emit Mint(msg.sender, amount0, amount1);
22. }

复制代码

mint是Pair里面的关键方法之一，调用时间在合约转入流动性池资产之后，根据转入的数量会给对应的用户mint出LP token。
首先通过reserve和balance的差值计算出amount，也就是用户转入作为lp的代币数量。
feeOn是uniswap中手续费的设计，不影响主流程，放到最后再讲。
在_mintFee之后，读取了当前lp token的总供应量，这里有两个注意的点：

• 顺序问题，_mintFee中会影响supply的数量，所以必须在其之后读取
  
• gas优化问题，在方法如果要读取合约的成员变量，应当使用一个临时变量去做记录，方法内变量的使用gas要低于读取合约的变量。
  

根据totalSupply分成两种逻辑：

• 初次添加流动性，计算公式为$\sqrt {x*y}$，额外还需要减去MINIMUM_LIQUIDITY，这也是上面提到过的锁定流动性，然后这部分流动性会被打到零地址去。
  
• 正常有池子的情况下流动性的计算公式是$\frac{totalSupply}{reserve}*amount$，也就是保证totalSupply和reserve比值不变的情况下增加amount的数量，
  
  
  
  • 如果在添加单个代币流动性的情况下，直接这么计算就可以，用户得到的LP token价值与当前流动性池子内的LP token价值是相等的。
    
  • 如果是双代币添加，那么就要取两个值中的较小值。
    
  
  

1. function _update(uint balance0, uint balance1, uint112 _reserve0, uint112 _reserve1) private {
2.     require(balance0 <= uint112(-1) && balance1 <= uint112(-1), 'UniswapV2: OVERFLOW');
3.     uint32 blockTimestamp = uint32(block.timestamp % 2**32);
4.     uint32 timeElapsed = blockTimestamp - blockTimestampLast; // overflow is desired
5.     if (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) {
6.         // * never overflows, and + overflow is desired
7.         price0CumulativeLast += uint(UQ112x112.encode(_reserve1).uqdiv(_reserve0)) * timeElapsed;
8.         price1CumulativeLast += uint(UQ112x112.encode(_reserve0).uqdiv(_reserve1)) * timeElapsed;
9.     }
10.     reserve0 = uint112(balance0);
11.     reserve1 = uint112(balance1);
12.     blockTimestampLast = blockTimestamp;
13.     emit Sync(reserve0, reserve1);
14. }

复制代码

在mint中，可以看到计算提取出代币数量amount的时候，基数用的是balance/totalSupply而不是reserve，这是因为reserve的更新有滞后性，并且uniswap认为Pair中的所有资产都是属于LP的，即使是不通过合约方法存入的部分，都可以根据lp token获得分成。
其他部分与mint基本类似，就不重复说明了。
swap

1. function burn(address to) external lock returns (uint amount0, uint amount1) {
2.     (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
3.     address _token0 = token0;                                // gas savings
4.     address _token1 = token1;                                // gas savings
5.     uint balance0 = IERC20(_token0).balanceOf(address(this));
6.     uint balance1 = IERC20(_token1).balanceOf(address(this));
7.     uint liquidity = balanceOf[address(this)];
9.     bool feeOn = _mintFee(_reserve0, _reserve1);
10.     uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
11.     amount0 = liquidity.mul(balance0) / _totalSupply; // using balances ensures pro-rata distribution
12.     amount1 = liquidity.mul(balance1) / _totalSupply; // using balances ensures pro-rata distribution
13.     require(amount0 > 0 && amount1 > 0, 'UniswapV2: INSUFFICIENT_LIQUIDITY_BURNED');
14.     _burn(address(this), liquidity);
15.     _safeTransfer(_token0, to, amount0);
16.     _safeTransfer(_token1, to, amount1);
17.     balance0 = IERC20(_token0).balanceOf(address(this));
18.     balance1 = IERC20(_token1).balanceOf(address(this));
20.     _update(balance0, balance1, _reserve0, _reserve1);
21.     if (feeOn) kLast = uint(reserve0).mul(reserve1); // reserve0 and reserve1 are up-to-date
22.     emit Burn(msg.sender, amount0, amount1, to);
23. }

复制代码

可以看到swap方法的参数中只有amountOut的值，而没有amountIn，说明在swap中amountIn是依赖于amountOut计算出来的，并且在实现中是先转出out资产，再去判断in是否满足，这种设计有以下的原因：

• 支持闪电贷功能，因为闪电贷的功能依赖于转出资产套利后再补回，用户先要得到out资产才可以
  
• 保证balance的正确性，因为swap中的流动性池需要满足常数k条件，必须用新的balance参与计算得到另一个token的balance
  

进入具体方法里面，首先是对数值有效性的判断，然后就直接将amountOut通过_safeTransfer转给了to地址，这也是我们前面提到的先out再in。
转账之后做了一个data长度的判断，此处就是对闪电贷支持的实现，借贷的对象需要实现IUniswapV2Callee中的uniswapV2Call方法供uniswap调用，并在其中实现套利-还款的逻辑，保证最终的amountIn与out的资产相匹配。
amountIn的计算公式是：balance - (_reserve - amountOut)，虽然通常在dex中都是单边输入单边输出，但swap的底层实现其实是支持双输出和双输入的，只要保证最后的余额满足常数k的约束即可。
uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));是uniswap计算手续费的公式，首先mul(1000)是为了用整数的精度计算，其实等价于为balance-(amountIn*0.003)，即收取amountIn 0.3%的手续费。 而require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'UniswapV2: K');规定了收取手续费之后的balance的常数k需要不小于流动性池现有存储的常数k。那么再加上手续费，流动性池的k值其实是上升的，意外着LP能够兑换的资产也变多了，所有的LP都能够通过手续费受益。
对于uniswap来说，用户发起swap后会马上用户转出out资产，但在最后结算时，合约中必须新增满足条件的in资产，即扣减手续费之后流动性池的常数k值不能减少，至于中间发生了什么，合约并不关心。
协议费

uniswap中协议费是可以手动控制开启关闭的，协议费的来源就是手续费，开启feeOn的情况下，uniswap可以从手续费中得到协议分成。

1. function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
2.     require(amount0Out > 0 || amount1Out > 0, 'UniswapV2: INSUFFICIENT_OUTPUT_AMOUNT');
3.     (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
4.     require(amount0Out < _reserve0 && amount1Out < _reserve1, 'UniswapV2: INSUFFICIENT_LIQUIDITY');
6.     uint balance0;
7.     uint balance1;
8.     { // scope for _token{0,1}, avoids stack too deep errors
9.     address _token0 = token0;
10.     address _token1 = token1;
11.     require(to != _token0 && to != _token1, 'UniswapV2: INVALID_TO');
12.     if (amount0Out > 0) _safeTransfer(_token0, to, amount0Out); // optimistically transfer tokens
13.     if (amount1Out > 0) _safeTransfer(_token1, to, amount1Out); // optimistically transfer tokens
14.     if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data);
15.     balance0 = IERC20(_token0).balanceOf(address(this));
16.     balance1 = IERC20(_token1).balanceOf(address(this));
17.     }
18.     uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
19.     uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
20.     require(amount0In > 0 || amount1In > 0, 'UniswapV2: INSUFFICIENT_INPUT_AMOUNT');
21.     { // scope for reserve{0,1}Adjusted, avoids stack too deep errors
22.     uint balance0Adjusted = balance0.mul(1000).sub(amount0In.mul(3));
23.     uint balance1Adjusted = balance1.mul(1000).sub(amount1In.mul(3));
24.     require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'UniswapV2: K');
25.     }
27.     _update(balance0, balance1, _reserve0, _reserve1);
28.     emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
29. }

复制代码

协议费的公式可以写作：协议费LP代币 = S × (rootK - rootKLast) / (5 × rootK + rootKLast)，其中S为totalSupply，这个公式是由[S × (rootK - rootKLast)/rootKLast] × (1/6)得到的，也就是要分成从上次kLast到这次k中间新增LP数量的1/6。
kLast只有在swap的过程中才会变更，并且保证了k缓慢增长的时候，协议能够根据这些额外增长的k去mint出LP token，再根据LP token来获取分成受益。
如果池子里：

• 纯粹的 mint/burn 操作（不涉及 swap）
  
• 没有交易活动的静态池子
  
• 刚刚收取过协议费的池子（此时 kLast 会被更新）
  

那么也就无法计算出协议费，因为k未改变。

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除