主頁 > 軟體設計 > UniswapV2周邊合約學習（三）-- UniswapV2Router02.sol（下）

UniswapV2周邊合約學習（三）-- UniswapV2Router02.sol（下）

2020-10-20 23:01:24 軟體設計

記得朋友圈看到過一句話，如果Defi是以太坊的皇冠，那么Uniswap就是這頂皇冠中的明珠，Uniswap目前已經是V2版本，相對V1，它的功能更加全面優化，然而其合約原始碼卻并不復雜，本文為個人學習UniswapV2原始碼的系列記錄文章，

在序列文章的上一篇我們學習了UniswapV2Router02.sol合約原始碼的上半部分（流動性供給部分），這次我們來學習下半部分，也就是資產交易部分，

建議讀者在開始學習之前閱讀我的另一篇文章：UniswapV2介紹 來對UniswapV2的整體機制有個大致了解；當然也建議閱讀前面的系列文章，特別是核心合約部分，這樣更有助于理解原始碼，

本文接下來內容中，會交替使用資產和ERC20代幣這兩個術語，在涉及到交易對時，它們基本上是等同的，

一、資產交易函式原始碼學習

  1. _swap函式，該函式是一個internal函式，它也是其它資產交易介面的核心，我們先看其原始碼：

    // **** SWAP ****
// requires the initial amount to have already been sent to the first pair
function _swap(uint[] memory amounts, address[] memory path, address _to) internal virtual {
    for (uint i; i < path.length - 1; i++) {
        (address input, address output) = (path[i], path[i + 1]);
        (address token0,) = UniswapV2Library.sortTokens(input, output);
        uint amountOut = amounts[i + 1];
        (uint amount0Out, uint amount1Out) = input == token0 ? (uint(0), amountOut) : (amountOut, uint(0));
        address to = i < path.length - 2 ? UniswapV2Library.pairFor(factory, output, path[i + 2]) : _to;
        IUniswapV2Pair(UniswapV2Library.pairFor(factory, input, output)).swap(
            amount0Out, amount1Out, to, new bytes(0)
        );
    }
}

    它把交易資產的核心邏輯抽象出來獨立為一個內部函式，方便各個資產交易外部介面呼叫（代碼復用），此函式為內部函式，用戶無法直接呼叫，從注釋中我們可以知道，需要事先將初始數量的代幣發送到第一個交易對（ 這是UniswapV2的先轉移后交易特性決定的），

    可以看到它有兩個輸入引數 amounts和path，分別為uint及地址陣列，那么它們代表什么含義呢？

    在系列文章的周邊合約工具庫學習時已經提到，UniswapV2支持交易鏈模式，也就假定有A/B 和B/C 這兩個交易對（但不是存在A/C交易對），我們可以在一個交易內先將A總換成B，然后再將B兌換成C，這樣就相當于A兌換成了C，整個交換流程為：A => B => C ，順序涉及的三種代幣為A,B,C，path顧名思義就指這條路徑的，它的內容是交易鏈中依次出現的各代幣地址，因此，path的內容為[addressA,addressB,addressC]，amounts代表什么呢，它代表整個交易程序中交易鏈依次涉及的代幣數量，在A => B => C 交易鏈中，amounts的內容為：[amountA,amountB,amountC]，因為初始資產只能賣出，所以amounts[0]代表賣出的初始資產數量，在本例中為amountA，而最終得到的資產只能買進，所以amounts陣列的最后一個元素代表買進的最終資產數量，例如amountC，陣列中間的元素代表涉及到的中間代幣的數量，例如amountB，它們是前一個交易對（A/B交易對）的買進值，同時也是下一個交易對（B/C交易對）的賣出值，

    下面的解釋仍然以 A => B => C 交易鏈為例（假定當前沒有直接A到C的交易對），

    函式體是一個for回圈，雖然我們的path長度為3，但是交易對數量只有2個，為什么呢，其實很簡單，大家想一想五線譜中的間與線的數量關系是什么？是五線四間，而這里是三個地址兩個交易對，這里面的關系圖是不是一樣的? 😉😉😉😊😊😊，所以回圈的判定條件不是通常的i < path.length，而要少一次，為i < path.length - 1，

    • 回圈內的第一行用來獲取當前交易對中的兩種代幣地址，以i = 0來講，input就是A，output就是B，

    • 回圈內的第二行用來獲取較小的代幣地址，因為交易對內的代幣地址及對應的代幣數量是排序過的（按地址大小從小到大排列），

    • 回圈內的第三行用來從amounts中獲取當前交易對的買進值（同時也是下一交易對的賣出值，如果還有交易對的話），

    • 回圈內的第四行用來判斷如果input（A）是較小值（交易對排過序后的較小地址為A），那么當前交易對買進的兩種代幣數量分別為（0，amountOut），也就是賣出A，得到amountOut數量的B；如果output（B）是較小值（交易對排過序后的較小地址為B），當前交易對買進的兩種代幣數量分別為（amountOut，0），同樣也為賣出A，得到amountOut數量的B，

      這么做的原因是在UniswapV2中，交易對合約的swap函式的前兩個引數對應的代幣地址是從小到大排序的，詳情見核心合約學習三中對swap函式的額外說明，

    • 回圈內的第五行用來計算當前交易對的接收地址，因為UniswapV2是一個交易代幣先行轉入系統，所以下一個交易對就直接是前一個交易對的接收地址了（如果還有下一個交易對），這里如果i回圈到最后一次i == path.length - 2,那么后面沒有交易對了，其接收地址為用戶指定的接收者地址；如果未到最后一次（后面還有交易對），那么接收地址就是通過工具庫計算的下一個交易對的地址，

    • 回圈內的最后一行代碼先是計算了當前交易對的地址，然后呼叫了該地址交易對合約的swap介面，將指定買進的代幣數量和接收地址及空負載（不執行回呼）作為引數傳給該函式，

    理解了_swap函式這個核心，再學習資產交易部分的其它外部介面（被用戶直接呼叫的函式）就很簡單了，因為它們基本上都是對本函式的呼叫，

  2. swapExactTokensForTokens函式，從函式名稱可以看出它是指定賣出固定數量的某種資產，買進另一種資產，該值由計算得來，同時支持交易對鏈（也就是上面講到的 A => B => C模式)，函式代碼為：

    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);
}

    其引數分別為賣出的初始資產數量，買進的另一種資產的最小值，交易對鏈，接收者地址和最遲交易時間，回傳值amounts的含義見_swap函式，

    • 函式代碼的第一行用來計算當前該交易的amounts，注意它使用了自定義工具庫的getAmountsOut函式進行鏈上實時計算的，所以得出的值是準確的最新值，amounts[0]就是賣出的初始資產數量，也就是amountIn，

    • 函式的第二行用來驗證最終買進的代幣數量不能小于用戶限定的最小值（防止價格波動較大，超出用戶的預期），

    • 函式的第三行將擬賣出的初始資產轉移到第一個交易對中去，這正好映證了_swap函式的注釋，必須先轉移賣出資產到交易對，

    • 函式的第四行呼叫_swap函式進行交易操作，

    • 該函式將用戶欲賣出的資產轉移到了第一個交易對合約中，該資產是一種ERC20代幣，因此必須先得到用戶的授權，

      那么這里可不可以采用移除流動性的permit方式實行線下簽名訊息授權呢？答案是不能，因為采用這種方式授權時permit函式必須包含在ERC20代幣的合約代碼中，在UniswapV2中，交易對本身就是ERC20代幣合約(本交易對流動性代幣的合約)，它里面是包含了permit函式的，但是交易對里面的兩種資產（ERC20代幣）卻是外部的ERC20代幣合約，基本上沒有這個permit函式，

  3. swapTokensForExactTokens函式，從函式名稱可以看出它是指定交易時買進的資產數量，而賣出的資產數量則不指定，該值可以通過計算得來，結合函式2我們可以看到，函式介面可以分為指定買進（本函式）和指定賣出（函式2）兩種型別，那么為什么會有這兩種方式呢？因為Uniswap交易對采用了恒定乘積演算法，它的價格是個曲線，不是線性的，因此指定買進和指定賣出計算的方式是不一樣的，于是這里便有了這兩種介面（函式），然而它們的底層實作卻是統一的邏輯（_swap函式），本函式代碼為：

    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);
}

    函式的引數同函式2類似，只不過前兩個引數變成了擬買進的資產的數量和指定賣入資產的最大值（保護用戶，防止價格波動過大從而使賣出資產數量大大超過用戶預期），回傳值amounts的含義和前面一樣，這里不再重復闡述了，

    • 函式的第一行呼叫庫函式來計算回傳值amounts，因為它是同一個交易里合約實時計算，所以不必擔心時效性問題，總是交易時的最新值，
    • 第二行驗證計算得到的賣出的初始資產數量要小于用戶限定的最大值，
    • 第三行將初始資產轉入第一個交易對中，轉移數量在第一行中計算得到，
    • 最后一行呼叫_swap函式進行交易操作，
    • 該函式也需要事先得到用戶授權以轉移初始賣出資產到交易對合約，

  4. swapExactETHForTokens函式，同swapExactTokensForTokens類似，只不過將初始賣出的Token換成了ETH，在上一篇文章學習流動性供給時已經介紹了ETH/WETH的相互兌換，這里就不再闡述了，注意這里函式引數不再有amountInMax，因為隨方法發送的ETH數量就是用戶指定的最大值（WETH與ETH是等額1:1兌換的），如果計算的結果超了則ETH會不足，拋出錯誤重置整個交易，

    function swapExactETHForTokens(uint amountOutMin, address[] calldata path, address to, uint deadline)
    external
    virtual
    override
    payable
    ensure(deadline)
    returns (uint[] memory amounts)
{
    require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
    amounts = UniswapV2Library.getAmountsOut(factory, msg.value, path);
    require(amounts[amounts.length - 1] >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
    IWETH(WETH).deposit{value: amounts[0]}();
    assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]));
    _swap(amounts, path, to);
}
    • 函式的第一行驗證第一個代幣地址必須為WETH地址，因為Uniswap交易對為ERC20/ERC20交易對，賣出ETH之前會自動轉換成為等額WETH（一種ERC20代幣），第一個交易對實質上是WETH/ERC20交易對，需要在此賣出WETH，所以第一個地址（賣出的初始資產地址）必須為WETH，
    • 第二行用來計算amounts，
    • 第三行，驗證最終買進的資產數量必須大于用戶指定的值，防止價格波動太大，
    • 第四行，將ETH兌換成WETH
    • 第五行，將WETH轉移到第一個交易對合約中，WETH代幣合約原始碼已經公開了，該合約的資產轉移函式transfer會回傳一個bool值，所以不需要再呼叫自定義庫中的safeTransferFrom函式，直接使用assert函式來斷言該值必須為true即可，
    • 第六行呼叫_swap函式進行交易操作，
    • 本函式沒有轉移用戶的ERC20代幣，所以沒有授權操作，ETH兌換后的WETH就在本合約里，是合約自己的資產，所以呼叫了WETH合約的transfer方法而不是transferFrom方法，

  5. swapTokensForExactETH函式，同swapTokensForExactTokens類似，只不過指定買進的不是Token（ERC20代幣），而是ETH，所以交易鏈的最后一個代幣地址必須為WETH，這樣才會買進WETH，然后再將它兌換成等額ETH，

    function swapTokensForExactETH(uint amountOut, uint amountInMax, address[] calldata path, address to, uint deadline)
    external
    virtual
    override
    ensure(deadline)
    returns (uint[] memory amounts)
{
    require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
    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, address(this));
    IWETH(WETH).withdraw(amounts[amounts.length - 1]);
    TransferHelper.safeTransferETH(to, amounts[amounts.length - 1]);
}
    • 函式的第一行驗證path中最后一個必須是WETH地址，
    • 第二行通過庫函式計算amounts，含義同上，
    • 第三行驗證計算得到的賣出資產數量必須小于用戶限定的最大值，價格保護，
    • 第四行，將欲賣出的資產轉移到第一個交易對中，
    • 第五行，呼叫_swap函式進行交易操作，注意接收者地址為本合約地址，因為從最后一個交易對得到的是WETH，并不是用戶想要的ETH，
    • 第六行，將本合約接收的WETH轉成ETH，
    • 第七行，將兌換好的ETH發送給用戶指定的接收者to，
    • 此函式在轉移賣出資產到第一個交易對時也需要事先授權，

  6. swapExactTokensForETH函式，同``swapExactTokensForTokens函式類似，只不過將最后獲取的ERC20代幣改成ETH了，因此，交易鏈的最后一個代幣地址必須為WETH，這樣才能賣進WETH然后再兌換成等額ETH，該函式同上一個函式swapTokensForExactETH`也類似，只不過一個是指定買進多少ETH，另一個是指定賣出多少資產，函式代碼為:

    function swapExactTokensForETH(uint amountIn, uint amountOutMin, address[] calldata path, address to, uint deadline)
    external
    virtual
    override
    ensure(deadline)
    returns (uint[] memory amounts)
{
    require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
    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, address(this));
    IWETH(WETH).withdraw(amounts[amounts.length - 1]);
    TransferHelper.safeTransferETH(to, amounts[amounts.length - 1]);
}
    • 第一行驗證path中的最后一個代幣地址為WETH地址，
    • 第二行通過庫函式計算amounts，含義同上，
    • 第三行驗證交易鏈最終買進的的WETH數量（會兌換成等額ETH）不能小于用戶的限定值，
    • 第四行將用戶擬賣出的資產轉入到第一個交易對中，
    • 第七行呼叫_swap進行交易操作，注意接收者地址為本合約地址，因為最后從交易對得到的是WETH，并不是用戶想要的ETH，
    • 第八行，將本合約接收的WETH轉成ETH，
    • 第九行，將兌換好的ETH發送給用戶指定的接收者to，
    • 此函式在轉移賣出資產到第一個交易對時也需要事先授權，

  7. swapETHForExactTokens函式，賣出一定數量的ETH，買進指定數量的資產（TOKEN），因為前面已經學習了好幾個類似的函式，再學習這個函式就很簡單了，這里可以直接列出該函式的大致邏輯：

    要賣出ETH，所以第一個地址必定為WETH地址，因為是指定買進資產，肯定是利用工具庫函式反向遍歷來計算amounts，又因為第一個交易對是包含WETH的交易對，所以交易前必須將擬賣出的ETH兌換成WETH到本合約，然后將WETH從合約發送到第一個交易對，接著會呼叫_swap函式進行交易，最后將多余的ETH退回給呼叫者，大家可以對照一下該函式的代碼看是不是這樣：

    function swapETHForExactTokens(uint amountOut, address[] calldata path, address to, uint deadline)
    external
    virtual
    override
    payable
    ensure(deadline)
    returns (uint[] memory amounts)
{
    require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
    amounts = UniswapV2Library.getAmountsIn(factory, amountOut, path);
    require(amounts[0] <= msg.value, 'UniswapV2Router: EXCESSIVE_INPUT_AMOUNT');
    IWETH(WETH).deposit{value: amounts[0]}();
    assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amounts[0]));
    _swap(amounts, path, to);
    // refund dust eth, if any
    if (msg.value > amounts[0]) TransferHelper.safeTransferETH(msg.sender, msg.value - amounts[0]);
}

    通過對照可以發現猜想的邏輯只是少了一個驗證計算得到的賣出ETH數量，雖然不驗證時，如果amounts[0] > msg.value的話，在兌換WETH時會因為ETH不足而出錯重置，但萬一由于某種原因導致合約本身的ETH數量不為0，那么此時就有可能通過了（相當于用合約已有的ETH幫你支付），所以這里還是需要驗證amounts[0] <= msg.value，

  8. _swapSupportingFeeOnTransferTokens函式，這個函式從名稱上看，和_swap函式的區別是支持使用轉移的代幣支付手續費，在上一篇文章流動性供給時已經提到了使用轉移代幣支付手續費，筆者以此也不熟悉，現實中也未接觸或者使用過，但是可以簡單認為此類代幣（拓展的ERC20代幣）在資產轉移時可能會有損耗（部分資產轉移到一個協議地址來支付手續費），轉移的數量未必就是最后接收的數量，這是筆者的個人理解，未必正確，請大家見諒，也請大家留言指出使用轉移的代幣支付手續費的正確理解方式，此函式的代碼為：

    // **** SWAP (supporting fee-on-transfer tokens) ****
// requires the initial amount to have already been sent to the first pair
function _swapSupportingFeeOnTransferTokens(address[] memory path, address _to) internal virtual {
    for (uint i; i < path.length - 1; i++) {
        (address input, address output) = (path[i], path[i + 1]);
        (address token0,) = UniswapV2Library.sortTokens(input, output);
        IUniswapV2Pair pair = IUniswapV2Pair(UniswapV2Library.pairFor(factory, input, output));
        uint amountInput;
        uint amountOutput;
        { // scope to avoid stack too deep errors
        (uint reserve0, uint reserve1,) = pair.getReserves();
        (uint reserveInput, uint reserveOutput) = input == token0 ? (reserve0, reserve1) : (reserve1, reserve0);
        amountInput = IERC20(input).balanceOf(address(pair)).sub(reserveInput);
        amountOutput = UniswapV2Library.getAmountOut(amountInput, reserveInput, reserveOutput);
        }
        (uint amount0Out, uint amount1Out) = input == token0 ? (uint(0), amountOutput) : (amountOutput, uint(0));
        address to = i < path.length - 2 ? UniswapV2Library.pairFor(factory, output, path[i + 2]) : _to;
        pair.swap(amount0Out, amount1Out, to, new bytes(0));
    }
}

    相比_swap函式，從輸入引數來看，少了一個amounts，也就是涉及到的此類資產數量不能再由自定義的工具庫函式計算得到了，函式體內同樣是一個for回圈，用來遍歷每個交易對進行交易，

    • 回圈體內的第一行獲取當前交易對的兩種代幣地址，

    • 回圈體內的第二行將這兩種代幣地址進行排序（排序的作用在_swap函式中已經講過)，

    • 回圈體內的第三行用來得到當前交易對合約的實體，

    • 回圈體內的第4-5行定義兩個臨時變數，一個代表賣出資產數量，一個代表買進資產的數量，使用Input和Output便于閱讀，

    • 回圈體內的第6行和第11行是使用一對{}將變數進行scope，防止堆疊過深問題，相關的內容在序列文章核心合約學習（三）中已經介紹過了，

    • 回圈體內的第7行用來獲取交易對資產池中兩種資產的值（用于恒定乘積計算的），注意這兩個值是按代幣地址（不是按代幣數量）從小到大排過序的，

    • 回圈體內的第8行用來將交易對資產池中兩種資產的值和第一行中獲取的兩個代幣地址對應起來，并保存在兩個帶有input和output的臨時reserve變數中，含義更加明顯，便于閱讀，

    • 回圈體內的第9行用來計算當前交易對賣出資產的數量（交易對地址的代幣余額減去交易對資產池中的值）

    • 回圈體內的第10行根據恒定乘積演算法來計算當前交易對買進的資產值 ，為什么要計算得買進的資產值呢？因為交易對合約的swap函式的輸入引數為買進的兩種代幣資產值而不是賣出的兩種代幣資產值，（這么做個人認為第一方面是因為UniswapV2是先行轉入賣出資產系統，賣出的數量通過比較合約地址的代幣余額與合約資產池中的相應值可以得到；第二方面是交易對合約的swap函式是個先借后還系統，函式引數為買進的資產數量可以方便的先借出相應資產），

    • 回圈體內的第12行將計算得到的買進資產值和零值按代幣地址從小到大的順序排序，這樣就會和交易對中swap函式的輸入引數順序保持一致，另一個為什么是零值呢？很顯然，在交易鏈模式中，每個交易對只會賣出其中一種資產來買進另一種資產，而不會兩種資產全買進，

    • 回圈體內的第13行是計算接收地址，計算程序同_swap函式，

    • 回圈體內的最后一行呼叫交易對合約的swap函式進行實際交易，

    • 該函式和本合約的_swap主要區別就是交易鏈交易程序中轉移的資產數量不再提前使用工具庫函式計算好，而是在函式內部根據實際數值計算，

      因為資產在實際轉移程序可能會有部分損耗來支付交易費用，到底損耗多少是未知的，每種資產也是不一樣的，所以無法提前通過統一庫函式來計算得到，

      實際計算賣出資產的數量的方法為：在交易對中賣出的資產數量等于交易對合約地址的資產余額減去交易對合約資產池中相應的數值，假設該方法叫M，

      買進的資產數量由恒定乘積演算法算出，然而該值未必就是下一個交易對的資產賣出數量，因為此類資產在從當前交易對轉移到下一個交易對的程序中，可能存在損耗，所以下一個交易對的賣進資產也是通過方法M計算（在for的下一個回圈里），

      剛才說了一大堆估計大家都有點暈😂😂😂😂，讓我們簡單一點吧🤩🤩🤩🤩：

      1. 在不支持代幣支付交易手續費的交易中，前一個交易對的買進資產數量就是后一個交易對的賣出資產數量（或者接收數量）；第一個交易對的賣出資產數量就是用戶直接轉移的資產數量.
      2. 在支持代幣支付交易手續費的交易中，因為資產轉移程序中可能有損耗，所以每一個交易對的賣出資產數量必須由方法M計算得到，包含第一個交易對的賣出資產數量，

  9. swapExactTokensForTokensSupportingFeeOnTransferTokens，有了上面的_swapSupportingFeeOnTransferTokens函式做鋪墊，這個函式就比較好理解了，從名稱上看，它和swapExactTokensForTokens函式相同，只不過多了支持FeeOnTransferTokens，函式代碼為：

    function swapExactTokensForTokensSupportingFeeOnTransferTokens(
    uint amountIn,
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint deadline
) external virtual override ensure(deadline) {
    TransferHelper.safeTransferFrom(
        path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn
    );
    uint balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
    _swapSupportingFeeOnTransferTokens(path, to);
    require(
        IERC20(path[path.length - 1]).balanceOf(to).sub(balanceBefore) >= amountOutMin,
        'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'
    );
}

    • 第一行將用戶欲賣出的資產轉入到第一個交易對中，

    • 第四行用來記錄接收者地址在交易鏈最后一個代幣合約中的余額，假定 A => B => C，就是C代幣的余額，

    • 第五行呼叫可復用的內部函式（函式8）進行實際交易，

    • 最后的require函式用來驗證接收者買進的資產數量不能小于指定的最小值，

      前面已經講過，由于此類代幣在轉移程序中可能有損耗，所以最終接收者買進的資產數量不再等于恒定乘積公式計算出來的值，必須使用當前余額減去交易前余額來得到實際接收值，

    • 轉移賣出資產時需要提前授權，這個接下來不再重復提及了，

  10. swapExactETHForTokensSupportingFeeOnTransferTokens函式，同函式9類似，只不過將賣出的TOKEN改成了ETH，既然賣出ETH，它就又和函式swapExactETHForTokens類似，因此，邏輯上也很好理解，和普通TOKEN => TOKEN介面相比，多了一個計算并驗證買進的資產數量并和WETH/ETH的相互兌換，函式代碼為：

    function swapExactETHForTokensSupportingFeeOnTransferTokens(
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint deadline
)
    external
    virtual
    override
    payable
    ensure(deadline)
{
    require(path[0] == WETH, 'UniswapV2Router: INVALID_PATH');
    uint amountIn = msg.value;
    IWETH(WETH).deposit{value: amountIn}();
    assert(IWETH(WETH).transfer(UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn));
    uint balanceBefore = IERC20(path[path.length - 1]).balanceOf(to);
    _swapSupportingFeeOnTransferTokens(path, to);
    require(
        IERC20(path[path.length - 1]).balanceOf(to).sub(balanceBefore) >= amountOutMin,
        'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT'
    );
}
    • 函式的第一行用來驗證交易鏈第一個代幣地址為WETH地址，原因前面已經講過了，
    • 第二行：隨函式發送的ETH就是欲賣出的資產，ETH需要兌換成WETH，
    • 第三行，將ETH兌換成WETH，
    • 第四行，將WETH發送到第一個交易對，因為這里是發送本合約的WETH，所以無需授權交易，
    • 第五行以后，同函式9，用來呼叫函式8進行交易操作，同時記錄接收者地址交易前后最后一種代幣的余額，從而計算出實際買進的數量，來驗證它不能小于用戶指定的最小值，
    • WETH這里不用考慮也不會有損耗，為什么呢？因為它是開源的，它是不支持轉移代幣支付手續費的，

  11. swapExactTokensForETHSupportingFeeOnTransferTokens函式，有了前面的學習，這個函式也很簡單了，就是賣出指定數量的初始TOKEN，最后得到一定數量的ETH，同時支持使用轉移的代幣支付手續費，函式代碼為：

    function swapExactTokensForETHSupportingFeeOnTransferTokens(
    uint amountIn,
    uint amountOutMin,
    address[] calldata path,
    address to,
    uint deadline
)
    external
    virtual
    override
    ensure(deadline)
{
    require(path[path.length - 1] == WETH, 'UniswapV2Router: INVALID_PATH');
    TransferHelper.safeTransferFrom(
        path[0], msg.sender, UniswapV2Library.pairFor(factory, path[0], path[1]), amountIn
    );
    _swapSupportingFeeOnTransferTokens(path, address(this));
    uint amountOut = IERC20(WETH).balanceOf(address(this));
    require(amountOut >= amountOutMin, 'UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT');
    IWETH(WETH).withdraw(amountOut);
    TransferHelper.safeTransferETH(to, amountOut);
}
    • 函式的第一行用來驗證交易鏈最后一個地址為WETH地址，原因不再重復了，
    • 第2-4行用來將初始資產發送給第一個交易對，注意這里需要提前授權，
    • 第5行呼叫內部函式8進行交易操作，注意，此時的接收地址為本合約地址，因為用戶買進的的是ETH，而這里得到的是WETH，不能直接讓用戶接收，需要轉換成ETH，
    • 第6行用來獲取交易鏈中買進的資產（WETH）數量，因為周邊合約本身不存有任何資產（交易前WETH余額為0），所以本合約地址當前WETH余額就是買進的WETH數量，
    • 第7行驗證買進的WETH數量要大于用戶指定的最小值，
    • 第8-9行，將WETH兌換成等額ETH并發送給接收者，
    • WETH并不會有損耗，原因同上，

  12. quote函式，注釋中可以看到，從該函式起，主要就是庫函式功能了，它們都是直接呼叫庫函式做一些計算，因為庫函式一般是無狀態的，所以它們基本上也都是pure型別的（和對應的庫函式一致），工具庫函式的說明也可以參照序列文章中的周邊合約學習（一）–工具庫的學習，

    // **** LIBRARY FUNCTIONS ****
function quote(uint amountA, uint reserveA, uint reserveB) public pure virtual override returns (uint amountB) {
    return UniswapV2Library.quote(amountA, reserveA, reserveB);
}

    該函式及接下來的幾個函式都未在本合約使用，它們主要是直接包裝了工具庫函式提供給外部合約使用，為什么這么做呢？個人猜想是因為外部合約很大可能 不會使用UniswapV2這個自定義的工具庫UniswapV2Library，所以周邊合約提供了相應的介面方便外部合約使用這些庫函式功能（當然也可以是鏈下呼叫而非合約呼叫），

    該函式的功能為根據交易對中兩種資產比例，給出一種代幣數值，計算另一種代幣數值，本合約在流動性供給計算時直接使用了相同功能的工具庫函式，

  13. getAmountOut函式，根據恒定乘積演算法，指定賣出資產的數量，計算買進資產的數量，計算時考慮了手續費，僅適用于單個交易對，

  14. getAmountIn函式，根據恒定乘積演算法，指定買進資產的數量，計算賣出資產的數量，計算時考慮了手續費，僅適用于單個交易對，

    這里有一點需要提一下，其函式代碼為（超級簡單）：

    function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut)
    public
    pure
    virtual
    override
    returns (uint amountIn)
{
    return UniswapV2Library.getAmountIn(amountOut, reserveIn, reserveOut);
}

    注意：在上一篇文章介紹Router時，官方檔案提到Router1合約有一個低風險的Bug，就是指這個函式，那么到底是什么Bug呢？我們來對照一下Router1合約中相應的代碼：

    function getAmountIn(uint amountOut, uint reserveIn, uint reserveOut) public pure override returns (uint amountIn) {
    return UniswapV2Library.getAmountOut(amountOut, reserveIn, reserveOut);
}

    😄😄😄，該bug是一處筆誤，將UniswapV2Library.getAmountIn寫成了UniswapV2Library.getAmountOut，然而該函式周邊合約本身并未呼叫，只是作為介面提供給外部使用，因此為低風險的，但是由于合約部署之后無法更改，所以只能等到Router2來更改過來了，

  15. getAmountsOut函式，多了一個s，代表多個，意味著它用于交易鏈的計算中，指定賣出資產數量，計算涉及到的每種資產數量并順序保存在一個陣列中，

  16. getAmountsIn函式，多了一個s，代表多個，意味著它用于交易鏈的計算中，指定買進資產數量，反向推導計算出涉及到的每種資產數量并順序保存在一個陣列中，

二、資產交易函式分類

上面這么多swap函式，大家肯定看得眼花繚亂了👻👻👻，下面我們根據交易資產的種類和指定的是賣出資產數量/買進資產數量，對它們做一個簡單的分類：

2.1、 TOKEN => TOKEN

就是兩種ERC20代幣交易，可分為：

  1. 指定賣出代幣數量，得到另一種代幣，函式為swapExactTokensForTokens，
  2. 指定買進代幣數量，賣出另一種代幣，函式為swapTokensForExactTokens，

2.2、ETH => TOKEN

ETH兌換成ERC20代幣，也分為兩種：

  1. 指定賣出ETH數量，得到另一種ERC20代幣，函式為swapExactETHForTokens，
  2. 指定買進ERC20代幣數量，賣出ETH，函式為swapETHForExactTokens，

2.3、TOKEN => ETH

ERC20代幣兌換成ETH，等等，有人會說這不是和 ETH => TOKEN 一樣的么，既然能通過交易鏈實作 ETH => TOKEN，那么必能反向通過該交易鏈實作 TOKEN => ETH，

是這樣的沒錯，但是因為不能直接交易ETH，所以會涉及到一個ETH和WETH的相兌換（轉換發生在不同方向的交易鏈的不同階段），因此實作邏輯還是不同的，所以這里提供了另外兩個介面，

  1. 指定賣出ERC20代幣數量，得到ETH，函式為swapExactTokensForETH，
  2. 指定買進ETH數量，賣出另一種ERC20代幣，函式為swapTokensForExactETH，

2.4、支持FeeOnTransferTokens函式

此外還有三個支持FeeOnTransferTokens函式，分別為函式9、函式10，函式11，注意它們的函式名稱，均表示指定賣出資產數量，也就是說它們只能用于交易鏈中指定賣出資產數量這種場景，不支持指定買進資產的場景中進行的反向交易鏈數值計算，因此只有3個該類函式，

為什么會這樣呢？

個人認為是因為此類資產在轉移程序中可能會有損耗，但損耗到底多少是無法知曉的，因此指定買進資產數量反推賣出資產數量的話，是無法得到的，因為該值為計算得到的值加上損耗值，如果指定賣出資產數量的話，每個交易對的實際賣出資產數量和最終接收的買進資產數量均可以通過比較相應地址交易前后的資產余額來計算出，因此此種交易場景是可行的，

因此2.1-2.3三種交易型別每種型別只有一個支持FeeOnTransferTokens函式，分別為：

  1. TOKEN => TOKEN 為 swapExactTokensForTokensSupportingFeeOnTransferTokens函式，
  2. ETH => TOKEN 為swapExactETHForTokensSupportingFeeOnTransferTokens函式，
  3. TOKEN => ETH 為swapExactTokensForETHSupportingFeeOnTransferTokens函式，

綜合得到Router2合約用于資產交易的對外介面共分四類9個介面，

三、總結

從前面的學習中可以看出，雖然資產交易對外提供了四類共9個介面，但來回就是對兩個核心_swap函式的呼叫，其中支持使用轉移的代幣支付手續費的介面中，轉移資產的實際數量不再等于根據恒定乘積計算出來的結果值，而需要根據相應地址的兩次資產余額相減計算出來，交易鏈中如果有涉及到ETH交易的，需要在交易鏈的對應階段（開始或者結束階段）進行ETH/WETH的兌換，因為UniswapV2交易對全部為ERC20/ERC20交易對，因此交易鏈中間流程不可能有ETH出現，

至此，UniswapV2Router02.sol合約原始碼學習（下）就到此結束了，計劃下一次進行周邊合約中的UniswapV2Migrator.sol的原始碼學習，

由于個人能力有限，難免有理解錯誤或者不正確的地方，還請大家多多留言指正，

在UniswapV2合約的原始碼學習程序中，UniswapV2Router02.sol合約篇幅最長，也比較復雜，因此本合約的學習記錄（上/下篇）的撰寫也比較耗時，更新時間較久，

如果本文能給大家帶來一點幫助，請大家手留余香，點個贊，借用CSDN的一句話：你們的支持是筆者寫下去的最大動力，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/182943.html

標籤：其他

上一篇：Circles UBI全面決議與參與方式

下一篇：python-利用Tushare金融大資料社區的資料就行回測

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季，第二季，第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說，對作業的節奏也差不多掌握了，作業做起來的效率也更高了。雖然和之前的作業一樣，作業中都要用到新的知識，但是相比之前，更加懂得了如何利用工具以及資料。雖然之間卡過殼，但總體而言，這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元，此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO（2020）第四單元博客作業暨課程總結博客

    北航OO（2020）第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中，由于UML圖具有比較清晰的樹形結構，因此我對其中需要進行查詢操作的元素進行了包裝，在樹的父節點中存盤所有孩子的參考。考慮到性能問題，我采用了快取機制，一次查詢后盡可能快取已經遍歷過的資訊，以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目：第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖，順序圖，狀態圖分析器 MyUmlInteraction，實際上我們要建立一個有向圖模型，UML中的物件（元素）可能與同級元素連接，也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false，將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元：StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中，圖的節點包括類、介面、屬性，子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖，第一遍遍歷建點，第二、三次遍歷設定屬性、連邊，實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素：封裝、繼承、多型。 封裝和繼承，這兩個比較好理解，但要理解多型的話，可就稍微有點難度了。今天，我們就來講講多型的理解。 我們應該經常會看到面試題目：請談談對多型的理解。 其實呢，多型非常簡單，就一句話：呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具：DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest，同時又想使用資料驅動，那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料：http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下： 1.什么是xlrd模塊？ 2.為什么使用xlrd模塊？ 3.怎樣使用xlrd模塊？ 1.什么是xlrd模塊？ ?python操作excel主要用到xlrd和xlwt這兩個庫，即xlrd是讀excel，xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時，底層到底做了什么？

    jdk1.7中的底層實作程序（底層基于陣列+鏈表） 在我們new HashMap()時，底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候： 首先，呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式，它可以用來減少類之間的直接依賴關系，
    * 將物件之間的通信封裝到一個中介者物件中，從而使得各個物件之間的關系更加松散。
    * 在中介者模式中，物件之間不再直接相互互動，而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點，專案投資大概1億，包括了礦山的各方面的內容，顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃，有很多煤礦行業專家的加持，他們的描述是非常完美，但是去年底應該上線的平臺，現在還沒有看到影子。他們確實有很多場景需求，但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序，開始編碼、測驗、除錯之前進行需求分析和架構設計，才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式，它可以用來減少類之間的直接依賴關系，
    * 將物件之間的通信封裝到一個中介者物件中，從而使得各個物件之間的關系更加松散。
    * 在中介者模式中，物件之間不再直接相互互動，而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點，專案投資大概1億，包括了礦山的各方面的內容，顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃，有很多煤礦行業專家的加持，他們的描述是非常完美，但是去年底應該上線的平臺，現在還沒有看到影子。他們確實有很多場景需求，但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序，開始編碼、測驗、除錯之前進行需求分析和架構設計，才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師，不僅僅要緊跟行業技術趨勢，還要結合研發團隊現狀及痛點，探索新的交付方案。在日常中，你是否遇到如下問題 “ 業務需求排期長研發是瓶頸；非研發角色感受不到研發技改提效的變化；引入ISV 團隊又擔心質量和安全，培訓周期長“等等，基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有，只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理：沒有銀彈，架構分層模型更是如此，每一種都有各自優缺點，所以請根據不同的業務場景，并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more

Copyright © 2010-2020 有解無憂