Uniswap core源码学习
uniswap的core代码分为两部分，Factory和Pair，其中Factory是工厂合约，主要用来创建交易对，而Pair就是交易对合约，控制LP的mint和burn，以及用户的swap交易。Factory
首先来看一下Factory合约，定义了四个变量：
address public feeTo;
address public feeToSetter;
mapping(address => mapping(address => address)) public getPair;
address[] public allPairs;
constructor(address _feeToSetter) public {
feeToSetter = _feeToSetter;
}feeTo和feeToSetter负责协议手续费的去向控制，构造合约的时候需要设置feeToSetter，做好权限控制。
getPair和allPairs用于记录所有的流动性交易对以及映射关系。
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;
}
}提供了两个可以用来修改手续费setter和to地址的方法。
最重要的核心就是下面的createPair，用于创建交易对。
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 == address(0), 'UniswapV2: PAIR_EXISTS'); // single check is sufficient
bytes memory bytecode = type(UniswapV2Pair).creationCode;
bytes32 salt = keccak256(abi.encodePacked(token0, token1));
assembly {
pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
}
IUniswapV2Pair(pair).initialize(token0, token1);
getPair = pair;
getPair = pair; // populate mapping in the reverse direction
allPairs.push(pair);
emit PairCreated(token0, token1, pair, allPairs.length);
}权限控制
第一部分的代码写了三个require：
[*]交易对两端token不可相同
[*]交易对token不可为零地址
[*]交易对还未创建
可以看到这里对tokenA和tokenB做了一个排序，这是为了保证唯一性，不论传入什么样顺序的交易对，都能输出一样的结果。
因为token0小于token1，所以在检查零地址的时候只需要检查一个即可。
部署合约
此处部署了新交易对的合约，使用了内联assembly，create2是创建合约的方法，它有一个特性就是创建得到的地址可预测：
address = keccak256(
0xff, // 固定前缀
deployer, // 部署者地址（Factory）
salt, // 盐值
keccak256(bytecode) // 字节码哈希
)这里的salt是用交易对中两个token的地址生成的，这也就意味着对于任意一对token，最终生成的合约地址是唯一且可预测的，即使合约没部署也可以通过计算提前知道合约地址。
初始化
部署好合约后，调用了initialize()对合约进行了初始化，并在map里登记了交易对互相之间的映射关系，然后发出一条event，标志着交易对创建完成。
为什么使用initialize调用进行初始化，而不是在create创建合约的时候通过构造函数初始化呢？
这是因为如果定义了构造函数，那在create的时候传入的字节码里就需要带上参数类型并且传入实参，导致最终得到的hash都不相同。
特别是外部合约或者其他代码中计算pair address时，只需要传入一个固定的常量creationCodeHash即可（直接由uniswap分享出来），而不需要试图去获取uniswap的creationCode（得不到）。
Pair
Pair合约是uniswap core代码里面最复杂的部分，负责交易对的相关内容。
首先从变量定义开始：
uint public constant MINIMUM_LIQUIDITY = 10**3;
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重复计算。
uint112 private reserve0; // uses single storage slot, accessible via getReserves
uint112 private reserve1; // uses single storage slot, accessible via getReserves
uint32private blockTimestampLast; // uses single storage slot, accessible via getReservesreserve是流动性池中代币的存量，但是和单纯的balance不同，因为合约是支持接收转账的，所以balance的数量可能因为其他的行为而发生改变，但reserve的值是统计所有符合Pair逻辑的行为之后得到的流动性池中合法的代币存量。
所以reserve并不是一个实时量，而是需要依赖更新操作，因此还需要一个时间变量blockTimestampLast来记录上次的更新时间。
在数据类型的设计上，reserve用了uint112而不是uint256之类常见的int长度，这是因为blockTimestampLast需要32位存储，对于一个uint256来说，还剩下224位，正好分给两个reserve，112位已经能够满足单个代币的供应量。
这种设计可以将三个变量放在一个slot中，节约存储空间，减少gas的使用。
在solidity中支持任意8的倍数的int类型，如uint16，uint32都是可以的
address public factory;
address public token0;
address public token1;定义了最基本的三个元素：
[*]factory，创建工厂的地址，避免非法调用
[*]token0和token1：交易对的两侧
uint public price0CumulativeLast;
uint public price1CumulativeLast;
uint public kLast;priceCumulativeLast代表了代币价格的累积值，用于计算代币的时间加权平均价格（TWAP），可以提供给外部作为预言机使用。
kLast是上次k值（x与y的乘积常量）变动时存储的值，使用场景在协议手续费的计算中。
event Mint(address indexed sender, uint amount0, uint amount1);
event Burn(address indexed sender, uint amount0, uint amount1, address indexed to);
event Swap(
address indexed sender,
uint amount0In,
uint amount1In,
uint amount0Out,
uint amount1Out,
address indexed to
);
event Sync(uint112 reserve0, uint112 reserve1);Pair里面有四个事件，分别代表着LP的添加和减少，代币的swap，还有流动性池数量的更新。
mint
function mint(address to) external lock returns (uint liquidity) {
(uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
uint balance0 = IERC20(token0).balanceOf(address(this));
uint balance1 = IERC20(token1).balanceOf(address(this));
uint amount0 = balance0.sub(_reserve0);
uint amount1 = balance1.sub(_reserve1);
bool feeOn = _mintFee(_reserve0, _reserve1);
uint _totalSupply = totalSupply; // gas savings, must be defined here since totalSupply can update in _mintFee
if (_totalSupply == 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);
_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);
}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价值是相等的。
[*]如果是双代币添加，那么就要取两个值中的较小值。
function _update(uint balance0, uint balance1, uint112 _reserve0, uint112 _reserve1) private {
require(balance0 <= uint112(-1) && balance1 <= uint112(-1), 'UniswapV2: OVERFLOW');
uint32 blockTimestamp = uint32(block.timestamp % 2**32);
uint32 timeElapsed = blockTimestamp - blockTimestampLast; // overflow is desired
if (timeElapsed > 0 && _reserve0 != 0 && _reserve1 != 0) {
// * never overflows, and + overflow is desired
price0CumulativeLast += uint(UQ112x112.encode(_reserve1).uqdiv(_reserve0)) * timeElapsed;
price1CumulativeLast += uint(UQ112x112.encode(_reserve0).uqdiv(_reserve1)) * timeElapsed;
}
reserve0 = uint112(balance0);
reserve1 = uint112(balance1);
blockTimestampLast = blockTimestamp;
emit Sync(reserve0, reserve1);
}在mint中，可以看到计算提取出代币数量amount的时候，基数用的是balance/totalSupply而不是reserve，这是因为reserve的更新有滞后性，并且uniswap认为Pair中的所有资产都是属于LP的，即使是不通过合约方法存入的部分，都可以根据lp token获得分成。
其他部分与mint基本类似，就不重复说明了。
swap
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;
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);
}可以看到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可以从手续费中得到协议分成。
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 (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
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');
}
_update(balance0, balance1, _reserve0, _reserve1);
emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
}协议费的公式可以写作：协议费LP代币 = S × (rootK - rootKLast) / (5 × rootK + rootKLast)，其中S为totalSupply，这个公式是由 × (1/6)得到的，也就是要分成从上次kLast到这次k中间新增LP数量的1/6。
kLast只有在swap的过程中才会变更，并且保证了k缓慢增长的时候，协议能够根据这些额外增长的k去mint出LP token，再根据LP token来获取分成受益。
如果池子里：
[*]纯粹的 mint/burn 操作（不涉及 swap）
[*]没有交易活动的静态池子
[*]刚刚收取过协议费的池子（此时 kLast 会被更新）
那么也就无法计算出协议费，因为k未改变。
来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除
页:
[1]