> 死磕以太坊原始碼分析之EVM如何呼叫ABI編碼的外部方法 > > 配合以下程式碼進行閱讀：https://github.com/blockchainGuide/ > > 寫文不易，給個小關注，有什麼問題可以指出，便於大家交流學習。 >  ## 前言 abi是什麼？ 前面我們認識到的是智慧合約直接在EVM上的表示方式，但是，比如我想用java端程式去訪問智慧合約的某個方法，難道讓java開發人員琢磨透彙編和二進位制的表示，再去對接？ 這明顯是不可能的，為此abi產生了。這是一個通用可讀的json格式的資料，任何別的客戶端開發人員或者別的以太坊節點只要指定要呼叫的方法，通過abi將其解析為位元組碼並傳遞給evm，evm來計算處理該位元組碼並返回結果給前端。abi就起到這麼一個作用，類似於傳統的客戶端和伺服器端地址好互動規則，比如json格式的資料，然後進行互動。 在本系列的上一篇文章中我們看到了`Solidity`是如何在EVM儲存器中表示覆雜資料結構的。但是如果無法互動，資料就是沒有意義的。智慧合約就是資料和外界的中間體。 在這篇文章中我們將會看到`Solidity`和`EVM`可以讓外部程式來呼叫合約的方法並改變它的狀態。 “外部程式”不限於`DApp/JavaScript`。任何可以使用`HTTP RPC`與以太坊節點通訊的程式，都可以通過建立一個交易與部署在區塊鏈上的任何合約進行互動。 建立一個交易就像傳送一個`HTTP`請求。`Web`的伺服器會接收你的`HTTP`請求，然後改變資料庫。交易會被網路接收，底層的區塊鏈會擴充套件到包含改變的狀態。 交易對於智慧合約就像`HTTP`請求對於`Web`伺服器。 ## 合約交易 讓我們來看一下將狀態變數設定在`0x1`位置上的交易。我們想要互動的合約有一個對變數`a`的設定者和獲取者： ```go pragma solidity ^0.4.11; contract C { uint256 a; function setA(uint256 _a) { a = _a; } function getA() returns(uint256) { return a; } } ``` 這個合約部署在Rinkeby測試網上。可以隨意使用Etherscan，並搜尋地址 [0x62650ae5…](https://rinkeby.etherscan.io/address/0x62650ae5c5777d1660cc17fcd4f48f6a66b9a4c2#code)進行檢視。 我建立了一個可以呼叫`setA(1)`的交易，可以在地址[0x7db471e5…](https://rinkeby.etherscan.io/tx/0x7db471e5792bbf38dc784a5b983ee6a7bbe3f1db85dd4daede9ee88ed88057a5)上檢視該交易。 交易的輸出資料是： >0xee919d500000000000000000000000000000000000000000000000000000000000000001 對於EVM而言，這只是36位元組的元資料。它對元資料不會進行處理，會直接將元資料作為`calldata`傳遞給智慧合約。如果智慧合約是個Solidity程式，那麼它會將這些輸入位元組解釋為方法呼叫，併為`setA(1)`執行適當的彙編程式碼。 輸入資料可以分成兩個子部分： ```go # 方法選擇器(4位元組) 0xee919d5 #第一個引數(32位元組) 00000000000000000000000000000000000000000000000000000000000000001 ``` 前面的4個位元組是方法選擇器，剩下的輸入資料是方法的引數，32個位元組的塊。在這個例子中，只有一個引數，值是`0x1`。 方法選擇器是方法簽名的 kecccak256 雜湊值。在這個例子中方法的簽名是`setA(uint256)`，也就是方法名稱和引數的型別。 讓我們用Python來計算方法選擇器。首先，雜湊方法簽名： ```go # 安裝pyethereum [https://github.com/ethereum/pyethereum/#installation](https://github.com/ethereum/pyethereum/#installation)> from ethereum.utils import sha3> sha3("setA(uint256)").hex()'ee919d50445cd9f463621849366a537968fe1ce096894b0d0c001528383d4769' ``` 然後獲取雜湊值的前4位元組： ```go > sha3("setA(uint256)")[0:4].hex() 'ee919d50' ``` ## 應用二進位制介面（ABI） 對於EVM而言，交易的輸入資料(`calldata`)只是一個位元組序列。EVM內部不支援呼叫方法。 智慧合約可以選擇通過以結構化的方式處理輸入資料來模擬方法呼叫，就像前面所說的那樣。 如果EVM上的所有語言都同意相同的方式解釋輸入資料，那麼它們就可以很容易進行互動。 [合約應用二進位制介面](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#formal-specification-of-the-encoding)（ABI）指定了一個通用的編碼模式。 我們已經看到了ABI是如何編碼一個簡單的方法呼叫，例如`SetA(1)`。在後面章節中我們將會看到方法呼叫和更復雜的引數是如何編碼的。 ## 呼叫一個獲取者 如果你呼叫的方法改變了狀態，那麼整個網路必須要同意。這就需要有交易，並消耗gas。 一個獲取者如`getA()`不會改變任何東西。我們可以將方法呼叫傳送到本地的以太坊節點，而不用請求整個網路來執行計算。一個`eth_call`RPC請求可以允許你在本地模擬交易。這對於只讀方法或gas使用評估比較有幫助。 一個`eth_call`就像一個快取的HTTP GET請求。 - 它不改變全球的共識狀態 - 本地區塊鏈(“快取”)可能會有點稍微過時 製作一個`eth_call`來呼叫 `getA`方法，通過返回值來獲取狀態`a`。首先，計算方法選擇器： ```go >>> sha3("getA()")[0:4].hex() 'd46300fd' ``` 由於沒有引數，輸入資料就只有方法選擇器了。我們可以傳送一個`eth_call`請求給任意的以太坊節點。對於這個例子，我們依然將請求傳送給 infura.io的公共以太坊節點： ```go $ curl -X POST \-H "Content-Type: application/json" \"[https://rinkeby.infura.io/YOUR_INFURA_TOKEN](https://rinkeby.infura.io/YOUR_INFURA_TOKEN)" \--data '{"jsonrpc": "2.0","id": 1,"method": "eth_call","params": [{"to": "0x62650ae5c5777d1660cc17fcd4f48f6a66b9a4c2","data": "0xd46300fd"},"latest"]}' ``` 根據ABI，該位元組應該會解釋為`0x1`數值。 ## 外部方法呼叫的彙編 現在來看看編譯的合約是如何處理源輸入資料的，並以此來製作一個方法呼叫。思考一個定義了`setA(uint256)`的合約： ```go pragma solidity ^0.4.11; contract C { uint256 a; // 注意: `payable` 讓彙編簡單一點點 function setA(uint256 _a) payable { a = _a; } } ``` 編譯： ```go solc --bin --asm --optimize call.sol ``` 呼叫方法的彙編程式碼在合約內部，在`sub_0`標籤下： ```go sub_0: assembly { mstore(0x40, 0x60) and(div(calldataload(0x0), 0x100000000000000000000000000000000000000000000000000000000), 0xffffffff) 0xee919d50 dup2 eq tag_2 jumpi tag_1: 0x0 dup1 revert tag_2: tag_3 calldataload(0x4) jump(tag_4) tag_3: stop tag_4: /* "call.sol":95:96 a */ 0x0 /* "call.sol":95:101 a = _a */ dup2 swap1 sstore tag_5: pop jump // 跳出 auxdata: 0xa165627a7a7230582016353b5ec133c89560dea787de20e25e96284d67a632e9df74dd981cc4db7a0a0029 } ``` 這裡有兩個樣板程式碼與此討論是無關的，但是僅供參考： - 最上面的`mstore(0x40, 0x60)`為sha3雜湊保留了記憶體中的前64個位元組。不管合約是否需要，這個都會存在的。 - 最下面的`auxdata`用來驗證釋出的原始碼與部署的位元組碼是否相同的。這個是可選擇的，但是嵌入到了編譯器中 將剩下的彙編程式碼分成兩個部分，這樣容易分析一點： - 匹配選擇器並跳掉方法處 - 載入引數、執行方法，並從方法返回 首先，匹配選擇器的註釋彙編程式碼： ```go // 載入前4個位元組作為方法選擇器 and(div(calldataload(0x0), 0x100000000000000000000000000000000000000000000000000000000), 0xffffffff) // 如果選擇器匹配`0xee919d50`, 跳轉到 setA 0xee919d50 dup2 eq tag_2 jumpi // 匹配失敗，返回並還原 tag_1: 0x0 dup1 revert // setA函式 tag_2: ... ``` 除了開始從呼叫資料裡面載入4位元組時的位轉移，其他的都是非常清晰明朗的。為了清晰可見，給出了彙編邏輯的低階虛擬碼： ```go methodSelector = calldata[0:4] if methodSelector == "0xee919d50": goto tag_2 // 跳轉到setA else: // 匹配失敗，返回並還原 revert ``` 實際方法呼叫的註釋彙編程式碼： ```go // setA tag_2: // 方法呼叫之後跳轉的地方 tag_3 // 載入第一個引數(數值0x1). calldataload(0x4) // 執行方法 jump(tag_4) tag_4: // sstore(0x0, 0x1) 0x0 dup2 swap1 sstore tag_5: pop //程式的結尾，將會跳轉到 tag_3並停止 jump tag_3: // 程式結尾 stop ``` 在進入方法體之前，彙編程式碼做了兩件事情： 1. 儲存了一個位置，方法呼叫之後返回此位置 2. 從呼叫資料裡面載入引數到棧中 低階的虛擬碼： ```go // 儲存位置，方法呼叫結束後返回此位置 @returnTo = tag_3 tag_2: // setA // 從呼叫資料裡面載入引數到棧中 @arg1 = calldata[4:4+32] tag_4: // a = _a sstore(0x0, @arg1) tag_5 // 返回 jump(@returnTo) tag_3: stop ``` 將這兩部分組合起來： ```go methodSelector = calldata[0:4] if methodSelector == "0xee919d50": goto tag_2 // goto setA else: // 無匹配方法。失敗 revert @returnTo = tag_3 tag_2: // setA(uint256 _a) @arg1 = calldata[4:36] tag_4: // a = _a sstore(0x0, @arg1) tag_5 // 返回 jump(@returnTo) tag_3: stop ``` > 有趣的小細節：`revert`的操作碼是`fd`。但是在黃皮書中你不會找到它的詳細說明，或者在程式碼中找到它的實現。實際上，`fd`不是確實存在的！這是個無效的操作。當EVM遇到了一個無效的操作，它會放棄並且會有還原狀態的副作用。 ## 處理多個方法 Solidity編譯器是如何為有多個方法的合約產生彙編程式碼的？ ```go pragma solidity ^0.4.11; contract C { uint256 a; uint256 b; function setA(uint256 _a) { a = _a; } function setB(uint256 _b) { b = _b; } } ``` 簡單，只要一些`if-else`分支就可以了： ```go // methodSelector = calldata[0:4] and(div(calldataload(0x0), 0x100000000000000000000000000000000000000000000000000000000), 0xffffffff) // if methodSelector == 0x9cdcf9b 0x9cdcf9b dup2 eq tag_2 // SetB jumpi // elsif methodSelector == 0xee919d50 dup1 0xee919d50 eq tag_3 // SetA jumpi ``` 虛擬碼： ```go methodSelector = calldata[0:4] if methodSelector == "0x9cdcf9b": goto tag_2 elsif methodSelector == "0xee919d50": goto tag_3 else: // Cannot find a matching method. Fail. revert ``` ## ABI為複雜方法呼叫進行編碼 對於一個方法呼叫，交易輸入資料的前4個位元組總是方法選擇器。跟在後面的32位元組塊就是方法引數。 [ABI編碼規範](https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI)顯示了更加複雜的引數型別是如何被編碼的，但是閱讀起來非常的痛苦。 另一個學習ABI編碼的方式是使用 [pyethereum的ABI編碼函式](https://github.com/ethereum/pyethereum/blob/4e945e2a24554ec04eccb160cff689a82eed7e0d/ethereum/abi.py) 來研究不同資料型別是如何編碼的。我們會從簡單的例子開始，然後建立更復雜的型別。 首先，匯出`encode_abi`函式： ```go from ethereum.abi import encode_abi ``` 對於一個有3個`uint256`型別引數的方法（例如`foo(uint256 a, uint256 b, uint256 c)`），編碼引數只是簡單的依次對`uint256`數值進行編碼： ```go # 第一個陣列列出了引數的型別 # 第二個陣列列出了引數的值 > encode_abi(["uint256", "uint256", "uint256"],[1, 2, 3]).hex() 0000000000000000000000000000000000000000000000000000000000000001 0000000000000000000000000000000000000000000000000000000000000002 0000000000000000000000000000000000000000000000000000000000000003 ``` 小於32位元組的型別會被填充到32位元組： ```go > encode_abi(["int8", "uint32", "uint64"],[1, 2, 3]).hex() 0000000000000000000000000000000000000000000000000000000000000001 0000000000000000000000000000000000000000000000000000000000000002 0000000000000000000000000000000000000000000000000000000000000003 ``` 對於定長陣列，元素還是32位元組的塊（如果必要的話會填充0），依次排列： ```go > encode_abi( ["int8[3]", "int256[3]"], [[1, 2, 3], [4, 5, 6]] ).hex() // int8[3]. Zero-padded to 32 bytes. 0000000000000000000000000000000000000000000000000000000000000001 0000000000000000000000000000000000000000000000000000000000000002 0000000000000000000000000000000000000000000000000000000000000003 // int256[3]. 0000000000000000000000000000000000000000000000000000000000000004 0000000000000000000000000000000000000000000000000000000000000005 0000000000000000000000000000000000000000000000000000000000000006 ``` ## ABI為動態陣列編碼 ABI介紹了一種間接的編碼動態陣列的方法，遵循一個叫做[頭尾編碼](https://github.com/ethereum/pyethereum/blob/4e945e2a24554ec04eccb160cff689a82eed7e0d/ethereum/abi.py#L735-L741)的模式。 該模式其實就是動態陣列的元素被打包到交易的呼叫資料尾部，引數(“頭”)會被引用到呼叫資料裡，這裡就是陣列元素。 如果我們呼叫的方法有3個動態陣列，引數的編碼就會像這樣（添加註釋和換行為了更加的清晰）： ```go > encode_abi( ["uint256[]", "uint256[]", "uint256[]"], [[0xa1, 0xa2, 0xa3], [0xb1, 0xb2, 0xb3], [0xc1, 0xc2, 0xc3]] ).hex() /************* HEAD (32*3 bytes) *************/ // 引數1: 陣列資料在0x60位置 0000000000000000000000000000000000000000000000000000000000000060 // 引數2：陣列資料在0xe0位置 00000000000000000000000000000000000000000000000000000000000000e0 // 引數3： 陣列資料在0x160位置 0000000000000000000000000000000000000000000000000000000000000160 /************* TAIL (128**3 bytes) *************/ // 0x60位置。引數1的資料 // 長度後跟這元素 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000a1 00000000000000000000000000000000000000000000000000000000000000a2 00000000000000000000000000000000000000000000000000000000000000a3 // 0xe0位置。引數2的資料 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000b1 00000000000000000000000000000000000000000000000000000000000000b2 00000000000000000000000000000000000000000000000000000000000000b3 //0x160位置。引數3的資料 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000c1 00000000000000000000000000000000000000000000000000000000000000c2 00000000000000000000000000000000000000000000000000000000000000c3 ``` `HEAD`部分有32位元組引數，指出`TAIL`部分的位置，`TAIL`部分包含了3個動態陣列的實際資料。 舉個例子，第一個引數是`0x60`，指出呼叫資料的第96個(`0x60`)位元組。如果你看一下第96個位元組，它是陣列的開始地方。前32位元組是長度，後面跟著的是3個元素。 混合動態和靜態引數是可能的。這裡有個(`static`，`dynamic`，`static`)引數。靜態引數按原樣編碼，而第二個動態陣列的資料放到了尾部： ```go > encode_abi( ["uint256", "uint256[]", "uint256"], [0xaaaa, [0xb1, 0xb2, 0xb3], 0xbbbb] ).hex() /************* HEAD (32*3 bytes) *************/ // 引數1： 0xaaaa 000000000000000000000000000000000000000000000000000000000000aaaa // 引數2：陣列資料在0x60位置 0000000000000000000000000000000000000000000000000000000000000060 // 引數3： 0xbbbb 000000000000000000000000000000000000000000000000000000000000bbbb /************* TAIL (128 bytes) *************/ // 0x60位置。引數2的資料 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000b1 00000000000000000000000000000000000000000000000000000000000000b2 00000000000000000000000000000000000000000000000000000000000000b3 ``` ## 編碼位元組陣列 字串和位元組陣列同樣是頭尾編碼。唯一的區別是位元組陣列會被緊密的打包成一個32位元組的塊，就像： ```go > encode_abi( ["string", "string", "string"], ["aaaa", "bbbb", "cccc"] ).hex() // 引數1： 字串資料在0x60位置 0000000000000000000000000000000000000000000000000000000000000060 // 引數2：字串資料在0xa0位置 00000000000000000000000000000000000000000000000000000000000000a0 // 引數3：字串資料在0xe0位置 00000000000000000000000000000000000000000000000000000000000000e0 // 0x60 (96)。 引數1的資料 0000000000000000000000000000000000000000000000000000000000000004 6161616100000000000000000000000000000000000000000000000000000000 // 0xa0 (160)。引數2的資料 0000000000000000000000000000000000000000000000000000000000000004 6262626200000000000000000000000000000000000000000000000000000000 // 0xe0 (224)。引數3的資料 0000000000000000000000000000000000000000000000000000000000000004 6363636300000000000000000000000000000000000000000000000000000000 ``` 對於每個字串/位元組陣列，前面的32位元組是編碼長度，後面跟著才是字串/位元組陣列的內容。 如果字串大於32位元組，那麼多個32位元組塊就會被使用： ```go // 編碼字串的48位元組 ethereum.abi.encode_abi( ["string"], ["a" * (32+16)] ).hex() 0000000000000000000000000000000000000000000000000000000000000020 //字串的長度為0x30 (48) 0000000000000000000000000000000000000000000000000000000000000030 6161616161616161616161616161616161616161616161616161616161616161 6161616161616161616161616161616100000000000000000000000000000000 ``` ## 巢狀陣列 巢狀陣列中每個巢狀有一個間接定址。 ```go > encode_abi( ["uint256[][]"], [[[0xa1, 0xa2, 0xa3], [0xb1, 0xb2, 0xb3], [0xc1, 0xc2, 0xc3]]] ).hex() //引數1：外層陣列在0x20位置上 0000000000000000000000000000000000000000000000000000000000000020 // 0x20。每個元素都是裡層陣列的位置 0000000000000000000000000000000000000000000000000000000000000003 0000000000000000000000000000000000000000000000000000000000000060 00000000000000000000000000000000000000000000000000000000000000e0 0000000000000000000000000000000000000000000000000000000000000160 // array[0]在0x60位置上 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000a1 00000000000000000000000000000000000000000000000000000000000000a2 00000000000000000000000000000000000000000000000000000000000000a3 // array[1] 在0xe0位置上 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000b1 00000000000000000000000000000000000000000000000000000000000000b2 00000000000000000000000000000000000000000000000000000000000000b3 // array[2]在0x160位置上 0000000000000000000000000000000000000000000000000000000000000003 00000000000000000000000000000000000000000000000000000000000000c1 00000000000000000000000000000000000000000000000000000000000000c2 00000000000000000000000000000000000000000000000000000000000000c3 ``` ## Gas成本和ABI編碼設計 為什麼ABI將方法選擇器截斷到4個位元組？如果我們不使用sha256的整個32位元組，會不會不幸的碰到不同方法發生衝突的情況？ 如果這個截斷是為了節省成本，那麼為什麼在用更多的0來進行填充時，而僅僅只為了節省方法選擇器中的28位元組而截斷呢？ 這種設計看起來互相矛盾……直到我們考慮到一個交易的gas成本。 - 每筆交易需要支付 21000 gas - 每筆交易的0位元組或程式碼需要支付 4 gas - 每筆交易的非0位元組或程式碼需要支付 68 gas 啊哈！0要便宜17倍，0填充現在看起來沒有那麼不合理了。 方法選擇器是一個加密雜湊值，是個偽隨機。一個隨機的字串傾向於擁有很多的非0位元組，因為每個位元組只有0.3%（1/255）的概率是0。 - `0x1`填充到32位元組成本是192 gas 4*31 (0位元組) + 68 (1個非0位元組) - sha256可能有32個非0位元組，成本大概2176 gas 32 * 68 - sha256截斷到4位元組，成本大概272 gas 32*4 ABI展示了另外一個底層設計的奇特例子，通過gas成本結構進行激勵。 > ### 負整數…. 一般使用叫做 [補碼](https://en.wikipedia.org/wiki/Two's_complement)的方式來表達負整數。`int8`型別`-1`的數值編碼會都是1。`1111 1111`。 ABI用1來填充負整數，所以`-1`會被填充為： ```go ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ``` 越大的負整數（`-1`大於`-2`）1越多，會花費相當多的gas。 ## 總結 與智慧合約互動，你需要傳送原始位元組。它會進行一些計算，可能會改變自己的狀態，然後會返回給你原始位元組。方法呼叫實際上不存在，這是ABI創造的集體假象。 ABI被指定為一個低階格式，但是在功能上更像一個跨語言RPC框架的序列化格式。 我們可以在DApp和Web App的架構層面之間進行類比： - 區塊鏈就是一個備份資料庫 - 合約就像web伺服器 - 交易就像請求 - ABI是資料交換格式，就像[Protocol Buffer](https://en.wikipedia.org/wiki/Protocol_Buffers)。 > 翻譯自 https://medium.com/@hayeah/diving-into-the-ethereum-vm-part-2-storage-layout-bc534