Uniswap Crypto

代码出处：

• UniswapV3Pool.sol：initialize
• v3-sdk：encodeSqrtRatioX96（TypeScript）

在合约中有一个sqrtPriceX96的值，它的意思是 价格的平方根 * 2^96 ，首先我们要定义一下原始的单位价格，原始的 Price 是 amount1/amount0 ，那sqrtPriceX96=sqrt(Price) * 2^96 ，为什么这样定义，因为合约没有浮点数，并且这样做可以让计算简单一些，提高gas的效率。， 我们一般会使用encodeSqrtRatioX96(amount1Raw, amount0Raw) 来获取它的价格，amount1Raw代表的是他的最小单位，比如usdt是6位，但是weth就要18位。

Price 永远都只是两个标地的相对价格而已，而描述中P代表的是token0用token1计价的价格，因为是（amount1/amount0）。

那么 tick 是怎么算的呢？ 我们在上面说过，价格的表现在合约中表现是 sqrtPriceX96，代表的是 sqrt(amount1/amount0) * 2^96。 而tick是一个乘法刻度，将价格分为很多个格子， tick每增加一格，价格就乘以 1.0001 ,也就是上涨 0.01% ,协议把价格1 定位第0格的tick ， 我们上文的例子中如果老板开门时候 价格是 0.9 。

那么在0.9附近 就有 -1054，-1053 这两条tick .

代码出处：

• TickMath.sol：getSqrtRatioAtTick / getTickAtSqrtRatio
• TickBitmap.sol：flipTick / nextInitializedTickWithinOneWord

在solidity 中有一个TickMath.sol 就是负责来做这些换算的，getSqrtRatioAtTick getTickAtSqrtRatio 你可以随意的将sqrtpricex96 和 tick 互相转换,需要显示价格就再price = (sqrtPriceX96 / 2^96)^2 。 tick就是这样计算的，在合约中它是使用bitmap存储的，一长串的二进制来存储足够多的tick 1代表这个tick有被设置， 0 代表没有有流动性的仓位以它作为边界。 。

代码出处：

• UniswapV3Pool.sol：swap 入口与参数检查
• SwapRouter.sol：回调数据与多池 exactInput
• Path.sol：路径布局与逐池解码

function swap(
    address recipient,
    bool zeroForOne,
    int256 amountSpecified,
    uint160 sqrtPriceLimitX96,
    bytes calldata data
) external override noDelegateCall returns (int256 amount0, int256 amount1)

其中ZeroForOne 的意思是 从token0到token1 那么就传true，这个就可以决定币种的方向，付什么，收到什么。 amountSpecified 是来指定数量的，正数代表指定投入的币种数量，负数代表指定想收到的币种的数量。sqrtPriceLimitX96 就是当价格到达此位置的时候就停止，比如开始的价格HKD：RMB是0.9，你不断的买入，港币价格一直上涨，你可以设定最多走到0.91的时候，我就不买了。

那你就可以填入sqrt(0.91) × 2^96 。 data 的参数是一个bytes .在周边合约（v3-periphery）里面多个池子的兑换就是使用data 来做的。想想一下你想使用 RMB 换 USD , 但是在uniswap的池子中有两个方式，一个是直接使用RMB 换 USD ,一个是使用RMB 换 HKD 再由HKD 换 USD ，周边合约就会将这个路径（path） 编码成bytes 。

abi.encodePacked(RMB,fee,HKD,fee,USD)

. 因为v3 区分fee , 两个地址和fee 就可以有唯一的一个池子。 所以币种中间的fee 就是池子的费率。 这个data 还有其他的用法， 比如授权其他用户付款，闪电贷等，闪电贷后面我们应该要讲一下，也是一个很好玩的用法。

代码出处：

• UniswapV3Pool.sol：swap 循环、寻找边界与剩余数量

在下单后，订单到底是如何成交的呢？ 价格是如何推进的呢？ 前文说过 swap 有固定输入数量，固定输出数量的区别，他们都使用了相同的逻辑就是看指定的量有没有被消耗完， 代码中使用 state.amountSpecifiedRemaining 来判断，当一笔常见的兑换会在指定输入，或者指定输出凑齐的 时候停止，没有消耗完就会继续循环，如果在兑换的图中价格到达限制也会提前停止。为什么要循环不一次兑换完呢？ 因为在用户添加流动性的时候会选tick , 你的兑换跨越tick 后，不同的tick之间的流动性总量（L）会不同。

比如在0.8到0.9 价格附近 张三添加了流动性， 0.8到 1.0 之间 李四添加了流动性， 当一笔兑换的几个到达0.9以上的时候，区间流动性总量就要将张三的删除了，张三也收不到0.9以上兑换的手续费了。

代码出处：

• TickBitmap.sol：flipTick / nextInitializedTickWithinOneWord
• SqrtPriceMath.sol：getAmount0Delta / getAmount1Delta
• SqrtPriceMath.sol：getNextSqrtPriceFromInput / Output

具体到代码中，每轮会先查tick的 bitmap ，

代码出处：

• UniswapV3Pool.sol：nextInitializedTickWithinOneWord 调用

(step.tickNext, step.initialized) = tickBitmap.nextInitializedTickWithinOneWord(
    state.tick,
    tickSpacing,
    zeroForOne
);

。每次只搜索bitmap的一个块，所以这个函数的最后WithinOneWord 。 他的意思是 如果流动性在tick 600 . 我们从0 开始前进， 0 会到 255， 再从256 到 511 ，然后才能找到600的tick 。step.initialized 如果返回false 则没有找到真正的仓位边界。 再计算一下走到这个边界的需要多少token 。然后判断这一轮能不能到达，

代码出处：

• SqrtPriceMath.sol：getAmount1Delta 的取整分支

return
    roundUp
        ? FullMath.mulDivRoundingUp(liquidity, sqrtRatioBX96 - sqrtRatioAX96, FixedPoint96.Q96)
        : FullMath.mulDiv(liquidity, sqrtRatioBX96 - sqrtRatioAX96, FixedPoint96.Q96);

简单的来说就是当前价格和目标价格 以及流动性来计算需要输入/能够输出的token ，忽略取整 这段就是。getAmount1Delta（getAmount0Delta） → L × 两个平方根价格（倒数）的差 。 在有数量后判断能不能达到分支目标 要 区分开看了，

代码出处：

• SwapMath.sol：computeSwapStep 的固定输入 / 固定输出分支

if (exactIn) {
    uint256 amountRemainingLessFee = FullMath.mulDiv(uint256(amountRemaining), 1e6 - feePips, 1e6);
    amountIn = zeroForOne
        ? SqrtPriceMath.getAmount0Delta(sqrtRatioTargetX96, sqrtRatioCurrentX96, liquidity, true)
        : SqrtPriceMath.getAmount1Delta(sqrtRatioCurrentX96, sqrtRatioTargetX96, liquidity, true);
    if (amountRemainingLessFee >= amountIn) sqrtRatioNextX96 = sqrtRatioTargetX96;
    else
        sqrtRatioNextX96 = SqrtPriceMath.getNextSqrtPriceFromInput(
            sqrtRatioCurrentX96,
            liquidity,
            amountRemainingLessFee,
            zeroForOne
        );
} else {
    amountOut = zeroForOne
        ? SqrtPriceMath.getAmount1Delta(sqrtRatioTargetX96, sqrtRatioCurrentX96, liquidity, false)
        : SqrtPriceMath.getAmount0Delta(sqrtRatioCurrentX96, sqrtRatioTargetX96, liquidity, false);
    if (uint256(-amountRemaining) >= amountOut) sqrtRatioNextX96 = sqrtRatioTargetX96;
    else
        sqrtRatioNextX96 = SqrtPriceMath.getNextSqrtPriceFromOutput(
            sqrtRatioCurrentX96,
            liquidity,
            uint256(-amountRemaining),
            zeroForOne
        );
}

固定输入意思是 我们指定投入多少输入币，输出多少由合约计算，需要计算的是这些token 会把价格推到那里，是否可以跨越当前边界，不能够跨越tick那价格会停在那里。 举个例子， 输入 token1、输出 token0，价格上涨， 当前的价格是1 ， 目标价格是1.1 (这个目标价格可能有多个来源，用户的价格限制， tick的边界，或者bitmap的边缘tick) 区间内流动性 L = 1000 ，那么走到目标价格需要的token 就是1000*(sqrt(1.1) - sqrt(1)) . 剩余净预算不足，就在边界前结束；预算足够，就先走到本轮边界。

另一个交易方向下 固定输出固定数量的token1 ，这句话可以描述为我为了得到40个token1的情况下，我要输入多少个token0 。 结束平方根价格为 1 - 40/1000 = 0.96，对应的普通价格为 0.96² = 0.9216 ，那我需要输入的就是 1000 * (1/0.96 - 1)

一个小诀窍，计算amount1 的时候都是直接√P 就好了， amount0 都需要1/ √P 倒数一下。所以在已知开始价格 和结束价格的时候，这一段对应多少币呢？

Δtoken1 = L × |√(P_(结束))-√(P_(开始))|
Δtoken0 = L × |1 / √(P_(结束))- 1 / √(P_(开始))|

能不能走到边界呢？

就是这样的方式 。走完一轮循环后，整笔订单可能还没有完成， 合约会记录指定的剩余数量（amountSpecifiedRemaining），以及目标的累计兑换数量（amountCalculated）, 然后来进行下一个循环将整个兑换结束。 设想一下刚刚的例子，张三在0.8 到 0.9 之间提供 1000 的流动性， 李四在 0.8 到 1.0 之间提供 2000 L 。 当价格位于两人的重叠区间时，有效 L 是 3000 。

这个L 在添加流动性的时候计算， 流动性在合约内大概可以有3种描述， 第一种 是 仓位的L ，张三添加一次流动性，这个仓位有多少L 。 第二种 是池子的L ，当前参与交易的L 一共有多少， 第三种 tick 的变化导致L的变化(liquidityNet),价格跨越这里，总L的变化有多少 ，更加详细的等到添加流动性部分再细说。 当价格向上跨过 0.9 的时候，合约就会把当前的 L 从 3000 调整到 2000，接下来的兑换继续用李四的流动性来计算。

代码出处：

• Tick.sol：update，维护 liquidityGross 与 liquidityNet
• UniswapV3Pool.sol：跨 tick 后更新有效 L

这里并不需要把所有 LP 找出来重新加一遍。张三添加流动性时，合约已经在他的下边界记了 +1000，在上边界记了 -1000；李四也一样，下边界记 +2000，上边界记 -2000。所以两个人都添加完之后，边界上保存的是这样的结果： 0.8 对应的 tick：liquidityNet = +3000 0.9 就是 -1000 1.0 就是 -2000 向上跨过 0.9，就加上 -1000；向下跨回来，就反过来加上 1000。

跨边界本身不会把价格重新设一遍，价格还在那里，下一轮只是换了一个 L。张三的仓位也没有被删除，等价格回来，他的资金会重新参与兑换 。

代码出处：

• UniswapV3Pool.sol：保存状态、转账与 swap 回调检查

uniswap 中有很多精妙的设计。对于智能合约而言，代码的优雅性 和 数据结构算法的使用，对于问题的解决方案真的很棒。等到指定数量完成，或者价格碰到了限制，循环就结束了。池子保存新的价格、tick 和有效 L，再处理实际的代币转账，在v3 内，它会先把你应该收到的币转出去，然后再用callback让支付方将需要支付的币补进来 ，池子会检查余额 ，不够的话就会revert ， 不过你已经消耗的gas 依旧要支付。

代码出处：

• UniswapV3Factory.sol：费率、getPool 与 createPool
• TickBitmap.sol：flipTick / nextInitializedTickWithinOneWord

在实际的操作中，仓位的边界会有 tickSpacing 的约束， 比如间隔是 60,那么 tick 设定 就要能被60 整除， 比如tick 的 某一段就是 60 120 180 ... 600 这样子。 设置更大的间隔，是在“LP 选区间的精细程度”和“交易执行成本”之间做取舍，价格经过普通刻度时，不需要改变有效 L；但经过一个已初始化的仓位边界，合约需要做我们上面讲的那些边界的处理，对于gas 的消耗会变多，假设一笔交易把 tick 从 0 推到 600 ，如果按1 的间隔，那么就要处理600次跨界，而如果是60 的间隔，只需要处理10次， 像 USDC/USDT 这样的稳定币交易对，更需要细密的仓位边界，因此常见于 tickSpacing 较小的低费率池。

相对价格波动较大的交易对，则常见于间隔更大的较高费率池 。

代码出处：

• LiquidityAmounts.sol：getLiquidityForAmount0 / Amount1 / Amounts

那么流动性数量是如何计算的呢？ 前面说过 token0 和 token1 的计算

Δtoken1 = L × |√(P_(结束))-√(P_(开始))|
Δtoken0 = L × |1 / √(P_(结束))- 1 / √(P_(开始))|

所以反过来，现在知道token 数量，

L0 = amount0 / |1 / √(P_(结束))- 1 / √(P_(开始))|
L1 = amount1 / |√(P_(结束))-√(P_(开始))|

那本次添加的流动性就是 min(L0,L1 ) 两个里面取最小， 比如你准备了很多港币，但人民币只够支持 1000 L，那么这次就只能添加这么多，没用上的港币不需要硬塞进仓位。两种币应该放多少， 取决于当前价格和你选的区间，并没有一条必须各放一半价值的规定。如果当前价格低于整个区间，只需要 token0；高于整个区间，只需要 token1。

代码出处：

• UniswapV3Pool.sol：更新仓位、有效 L、边界与 bitmap

添加成功后，合约会更新这个仓位的 L，以及上下两个边界的记录 如果仓位当前就在价格范围内，池子的有效总 L 也会立即增加。哪怕一个仓位横跨几千个 tick，也不需要把中间每个 tick 都写一遍，只更新两个端点就够了。

代码出处：

• Tick.sol：update，维护 liquidityGross 与 liquidityNet
• UniswapV3Pool.sol：更新仓位、有效 L、边界与 bitmap

除了 liquidityNet，每个边界还有一个 liquidityGross，记录以这里为边界的仓位一共挂着多少 L。比如一个人正好在这里退出 1000 L，另一个人进入 1000 L，净变化虽然是 0，但这个边界还被两份仓位使用，手续费的区间记账仍然需要它。只有这些仓位都撤走了，边界才可以从 bitmap 里清掉。

代码出处：

• Position.sol：owner、tickLower、tickUpper 对应的仓位键

那合约怎么知道其中多少是你的？core合约内使用一个 mapping，

keccak256(abi.encodePacked(owner, tickLower, tickUpper))

同一个池子里，同一个 owner 在同一个区间继续添加，L 就累加到这条记录上 。

从v3 开始 流动性是用NFT 表示的， 这个的owner 是NFT 管理合约地址， 并不是每个用户的唯一，而是 每次上下边界一样的时候，对于core 合约而言都是一样的。 在NFT管理合约内，管理合约用不同 NFT，分别记录两个人的份额，

代码出处：

• NonfungiblePositionManager.sol：Position 与 _positions
• NonfungiblePositionManager.sol：mint

mapping(uint256 => Position) private _positions;

nft 是另外一种token的方式，你可以把它想象成银行卡，每个人的卡都是唯一的。 V2 的 LP 份额可以用同一种 ERC20 代币表示，大家按比例持有同一个全区间池子。到了 V3，每个人选择的区间可能不同，同样的本金也可能对应不同的 L，所以常见的管理方式变成了一份仓位一个 NFT。同一个人也可以持有很多份，分别做不同区间的生意。 这张 NFT 是可以转走的。假设你把自己的仓位 NFT 转给李四，他就可以领取这份仓位尚未领取的手续费，也可以撤出剩余本金，连转移前已经赚到但还没领取的部分也一起归他控制。

代码出处：

• UniswapV3Pool.sol：feeGrowthGlobal、ticks、tickBitmap、positions
• Tick.sol：Tick.Info
• Position.sol：Position.Info 与 Last 快照

这部分要如何优雅的在代码中实现呢？ 首先有3个字段需要留意 全局账 ：

uint256 public override feeGrowthGlobal0X128;
uint256 public override feeGrowthGlobal1X128;

feeGrowth就是手续费累计增长，Global 整个池子共用 ， 0 和 1 就是分别代码token0 和 token1 。 X128就是数值 乘以 2^128 。 合约中记的是每单位 L 累计赚了多少手续费，比如 30 / 3000 = 0.01 ， 这样的好处是，如果记录单个用户的话 张三：30 * 1000/3000 = 10 元 。 李四：30 * 2000/3000 = 20 元 。

但是在合约中池子只记录了单位L的手续费。张三就可以直接 1000 * 0.01 = 10 ,李四也是一样的。 类似的意思是如果未来又有一次兑换，假设第二段的单位L的手续费是0.2 ， 那么这个累计就是 0.3 。 . 0 和 1 两个字段的意思是因为一笔流动性，会有两个币种的手续费需要记录 。

仓位的边界信息，

mapping(int24 => Tick.Info) public override ticks;

这个的key是 tick .所以是多人公用的，没有分用户。比如张三选 [-120, 120)，李四选 [-120, 240)，两人共用 ticks[-120] 这条边界记录。 Tick.Info 中相关的字段 liquidityGross的意思就是 该tick的L总和， liquidityNet 这个在前面swap ，和流动性添加的时候说了，当价格跨越这个tick的时候，有效的L 要增加或者减少多少。

feeGrowthOutside0/1X128 这个用来区分边界两侧手续费增长的累计账本 。 第三个需要留意的 就是 到用户了， 用户的流动性仓位边界，

mapping(bytes32 => Position.Info) public override positions;

。 其中 key 是用owner 和 tickLower tickUpper 算hash 来定位的。 在用户的仓位记录内 会记下 上次已经结算到那个读数了， feeGrowthInside0LastX128 / feeGrowthInside1LastX128 .Last 表示上次结算时，该区间累计表的读数。 ，如果用口语描述整个的运行逻辑 简单而言就是 张三上次结算时，人民币区间累计值：0.05 现在人民币区间累计值：0.08，那它新增的人民币手续费：0.03 * 1000 = 30 。

代码出处：

• Tick.sol：getFeeGrowthInside
• Tick.sol：cross，翻转 feeGrowthOutside

feeGrowthInside 是用这些记录现算出来的， 在价格在当前区间内的话，

区间内累计值
  = 全局累计值
  - 下边界以下的累计值
  - 上边界以上的累计值

假设全局累计值 G

它是怎么判断 用户不再区间内提供流动性，从而不给他奖励的呢？ 假设全局的累计值是 0.01 下/上边界 outside = 0 。 那么Inside = 0.01 - 0 - 0 = 0.01 。 当价格上涨跨出仓位的时候， 新的 upper.outside = G - 旧的 upper.outside = 0.01 - 0 。出区间后，其他的lp 赚了手续费 全局 的累计手续费变成0.03， 上边界 outside 仍为 0.01 因为当前价格已经在上边界之上，计算“上边界以上的增长”要用， 上方增长 = G - upper.outside = = 0.03 - 0.01 。

所以这个仓位的区间内累计值依旧是 Inside = 全局 - 下方 - 上方 = 0.03 - 0 - 0.02 = 0.01 全局增长了，但这个仓位的 Inside 没增长。 这样，区间外产生的手续费就不会分给它

代码出处：

• Position.sol：update，结算手续费并更新快照

总结一下整个流程就是 交易产生手续费 （feeGrowthGlobal0/1X128，全池每段的单位 L 手续费增长） 结合仓位上下边界，算出 feeGrowthInside0/1X128，减去仓位的 Last 快照 * L 除以 2^128 就是新增收益，记入 tokensOwed0/1 。 这样就算中间发生了很多次兑换，价格进进出出，结算一个仓位时也只需要读它的快照、两个边界和全局状态。

用户增加或者减少 L 时， 会先用原来的 L 结算已经发生的手续费，再记录新的 L，后来加进来的钱就不会分走前面赚到的部分。 V3 的手续费也不会自动变成新的L。它单独累计，结算后记入待领取金额，你想复投，需要领取后重新添加；看到某些产品会自动复投， 是外面又包了一层策略。

我们详细的来看看这部分在合约内是如何流转的 。 可以把它理解为3个动作， 减少营业资金、领取已结算的钱、销毁空仓位凭证 。 他们对应的函数分别是 decreaseLiquidity ， collect ， burn(tokenId) 。 首先 decreaseLiquidity：告诉合约“我要减少多少 L” ,接口的定义在 INonfungiblePositionManager.sol

代码出处：

• INonfungiblePositionManager.sol：DecreaseLiquidityParams 与接口
• NonfungiblePositionManager.sol：decreaseLiquidity

struct DecreaseLiquidityParams {
    uint256 tokenId;    // 操作哪一份 NFT 仓位
    uint128 liquidity;  // 本次减少多少 L，不是减少后剩多少
    uint256 amount0Min; // 本次减少 L，至少应记账多少 token0 本金，交易发出后，价格可能变化，对应的两种币数量也会变化；如果算出的本金低于 这些下限，就回滚。
    uint256 amount1Min; // 本次减少 L，至少应记账多少 token1 本金
    uint256 deadline;   // 交易执行期限，Unix 时间戳，单位为秒
}

function decreaseLiquidity(
    DecreaseLiquidityParams calldata params
) external payable returns (
    uint256 amount0, // 本次减少 L 对应的 token0 本金
    uint256 amount1  // 本次减少 L 对应的 token1 本金
);

张三这次的请求就是

tokenId   = 101
liquidity = 200

这部分是和管理合约交互, 所以大概的流程就是

张三操作 NFT #101
    ↓
管理合约读取 #101 的池子、上下 tick
    ↓
管理合约调用 Core 的 pool.burn(lower, upper, 200)

Core合约 看到的调用者是管理合约，用户在管理合约内区分， Core 的 burn：把减少 L 表示成负的变化量

代码出处：

• IUniswapV3PoolActions.sol：burn 接口
• UniswapV3Pool.sol：burn，以负 liquidityDelta 减少 L

function burn(
    int24 tickLower, // 仓位下边界
    int24 tickUpper, // 仓位上边界
    uint128 amount  // 本次减少的 L；传 0 可用于刷新已有仓位的手续费
) external returns (
    uint256 amount0,
    uint256 amount1
);

代码中关键是：

代码出处：

• UniswapV3Pool.sol：burn，以负 liquidityDelta 减少 L

liquidityDelta: -int256(amount).toInt128()

这部分我觉得需要举一个例子来讲一下， 假设 我们有 5000 USDC 和 2.5 ETH. 当前 ETH 的价格是 2000 USD .

我们常会听到 “无常损失” 。 在这里呢看图中，把一份资产放进 LP 后，因为自动兑换改变了持仓，导致它的价值低于“原样拿着这份资产不动”的价值 。 上涨时候会不断卖出ETH , 下跌的时候会不断买入 ETH . “无常”指的是：这个差额可能随着相对价格回归而缩小，甚至消失。 如果价格继续远离初始价格，差距还可能扩大。尤其区间 LP 越界后会变成单一资产，风险也不会自动停止。所以不要因为名字里有“无常”两个字，就把它当成暂时不用管的损失。

而且调区间也有成本。假设跌出范围后，你的人民币已经换成了港币，此时要把区间重新放到当前价格两侧，通常得先卖掉一部分港币， 换回人民币，再重新添加。每次追着价格调整，都可能发生兑换、手续费和 gas 支出。窄区间确实能让同样的资金在附近提供更多深度， 但也会更快把仓位从一种币换成另一种币。

在最开始找换店的例子中，我们一直让找换店只看自己的库存，那它怎么跟外面的价格保持一致？ ？靠的是有人来做套利。假设外面一港币能换 0.95 元人民币， 你店里还按接近 0.9 的价格卖，就会有人从你这里买港币，拿到外面卖。买的人多了，你的港币库存减少，报价被推高，直到价差不足以覆盖手续费、gas 和其他执行成本。

在能观察和安排交易顺序的环境里，别人还可能抢在你前面买入，把你的成交价格推差，再在你后面卖出，这就是常说的夹子交易。它给你造成的损失也不会作为一笔普通 LP 手续费显示出来。大滑点给这类交易留下的空间会更多，算一单到底花了多少，最终还是要对比自己的实际投入和实际到账。