5_2.md

EVM体系结构

当了解EVM的体系结构和掌握Solidity汇编后，就可以更加深入的对EVM进行探究，汇编和操作码解决了EVM在运行时如何操作数据，但是并没有解决EVM运行时如何对这些数据进行管理。

可以看到code和storage里存储的数据是非易失的，而stack，args，memory里存储的数据是易失的，其中code的数据是智能合约的二进制源码，是非易失的很好理解，部署合约的时候data字段也就是合约内容会存储在EVM的code中。

存储分类

接下来看一下EVM中定义的几种数据的存储空间以及各个存储位置的含义；

Stack

基于栈的虚拟机实现简单，移植性好，这也是以太坊选择基于栈的虚拟机的重要原因，前文的逆波兰表达法已经展示了如何采用栈来完成基本的运算，但是在EVM中的栈实现要复杂一些，EVM中的栈采用了32字节（256bit）的字长，最多可以容纳1024个字，字为最小的操作单位，EVM的栈结构如下所示；

stack可以免费使用，没有gas消耗，用来保存函数的局部变量，数量被限制在了16个，当在合约里中声明的局部变量超过16个时，再编译合约就会遇到Stack too deep, try removing local variables错误。

介绍几个EVM操作栈的指令，在后面分析合约的时候会用到；

• Pop指令（操作码0x50）用来从栈顶弹出一个元素；
• PushX指令用来把紧跟在后面的1-32字节元素推入栈顶，Push指令一共32条，从Push1（0x60）到Push32（0x7F），因为栈的一个字是256bit，一个字节8bit，所以Push指令最多可以把其后32字节的元素放入栈中而不溢出。
• DupX指令用来复制从栈顶开始的第1-16个元素，复制后把元素在推入栈顶，Dup指令一共16条，从Dup1（0x80）到Dup16（0x8F）。
• SwapX指令把栈顶元素和从栈顶开始数的第1-16个元素进行交换，Swap指令一共16条，从Swap1（0x90）一直到Swap16（0x9F）。

Calldata

calldata也叫args，是一段只读的可寻址的保存函数调用参数的空间，与栈不同的地方的是，如果要使用calldata里面的数据，必须手动指定偏移量和读取的字节数。

EVM提供的用于操作calldata的指令有三个：

• calldatasize返回calldata的大小;
• calldataload从calldata中加载32bytes到stack中;
• calldatacopy拷贝一些字节到内存中;

通过一个合约来看一下如何使用calldata，假如我们要写一个合约，合约有一个add的方法，用来把传入的两个参数相加，通常会这样写。

pragma solidity ^0.5.1;

contract Calldata {
  function add(uint256 a, uint256 b) public view returns (uint256) {
      return a + b;
  }
}

当然我们也可以用内联汇编的形式这样写。

contract Calldata {
  function add(uint256 a, uint256 b) public view returns (uint256) {
    assembly {
      let a := mload(0x40)
      let b := add(a, 32)
      calldatacopy(a, 4, 32)
      calldatacopy(b, add(4, 32), 32)
      result := add(mload(a), mload(b))
    }
  }
}

首先我们我们加载了0x40这个地址，这个地址EVM存储空闲memory的指针，然后我们用a重命名了这个地址，接着我们用b重命名了a偏移32字节以后的空余地址，到目前为止这个地址所指向的内容还是空的。

calldatacopy(a, 4, 32)这行代码把calldata的从第4字节到第36字节的数据拷贝到了a中，同样calldatacopy(b, add(4, 32), 32)把36到68字节的数据拷贝到了b中，接着add(mload(a), mload(b))把栈中的a，b加载到内存中相加。最后的结果等价于第一个合约。

而为什么calldatacopy(a, 4, 32)的偏移要从4开始呢？在EVM中，前四位是存储函数指纹的，计算公式是bytes4(keccak256("add(uint256, uint256)"))，从第四位开始才是args。

Memory

Memory是一个易失性的可以读写修改的空间，主要是在运行期间存储数据，将参数传递给内部函数。内存可以在字节级别寻址，一次可以读取32字节。所有的数据在Memory中都表现为字节数组。

EVM提供的用于操作memory的指令有三个：

• Mload加载一个字从stack到内存；
• Mstore存储一个值到指定的内存地址，格式mstore（p，v），存储v到地址p；
• Mstore8存储一个byte到指定地址 ；

当我们操作内存的时候，总是需要加载0x40，因为这个地址保存了空闲内存的指针，避免了覆盖已有的数据。

Storage

Storage是一个可以读写修改的持久存储的空间，也是每个合约持久化存储数据的地方。需要注意的是Storage中存储位置（除了映射，变长数组以外的所有类型）都是依次连续从位置0开始排列的。Storage是一个巨大的map，一共2^256个插槽，一个插糟有32byte。每次存储状态变量的时候都会被转换为键值对进行存储，键就是这个状态变量的位置。

EVM提供的用于操作Storage的指令有两个：

• Sload用于加载一个字到stack中；
• Sstore用于存储一个字到storage中；

Solidity将定义的状态变量，映射到插糟内，对于静态大小的变量从0开始连续布局，对于动态数组和map则采用了其他方法。

ABI编码

智能合约会被编译成字节码然后在EVM上执行，其中合约有存储在不同位置的变量和函数。

状态变量

Storage初始化的时候是空白的，默认位置是0。值类型的声明会占用存储位置，当合约初始化时就EVM就会为其分配位置。

pragma solidity ^0.5.1;
contract C {
    uint256 a;
    uint256 b;
    uint256 c;
    uint256 d;
    uint256 e;
    uint256 f;
    function test() public {
      f = 0xc0fefe;
    }
}

用solc --bin --asm --optimize test.sol编译合约，可以看到；

    tag_5:
        /* "test.sol":167:175 0xc0fefe */
      0xc0fefe
        /* "test.sol":163:164 f */
      0x5
        /* "test.sol":163:175 f = 0xc0fefe */
      sstore

这段汇编执行的是sstore(0x5, 0xc0fefe)，把0xc0fefe存储到0x5这个位置，0x5这个位置的变量就是f，在EVM中声明变量不需要成本，EVM会在编译的时候保留位置，但是不会初始化。

当通过指令sload读取一个未初始化的变量的时候， 不会报错，只会读取到零值0x0。

结构体

引用类型结构体的初始化和之前的状态变量就有不同；

pragma solidity ^0.5.1;
contract C {
    struct Empty {
      uint256 a;
      uint256 b;
    }
    struct Tuple {
      uint256 a;
      uint256 b;
      uint256 c;
      uint256 d;
      uint256 e;
      uint256 f;
    }
    Tuple t;
    function test() public {
      t.f = 0xC0FEFE;
    }
}

编译后得到；

    tag_5:
        /* "test.sol":219:227 0xC0FEFE */
      0xc0fefe
        /* "test.sol":213:216 t.f */
      0x5
        /* "test.sol":213:227 t.f = 0xC0FEFE */
      sstore
        /* "test.sol":182:234 function test() public {... */

编译后得到的结果和状态变量的行为是一致的都是在0x5的位置存储了数据，但是引用类型的声明并不会占用实际位置，只有在初始化的时候才会为其分配位置，Empty结构体虽然有两个状态变量但是并没有初始化，也没有为其分配位置。

布尔类型

布尔类型存储的时候仍然是采用

pragma solidity ^0.5.1;

contract C {
    bool b;
    function test() public {
      b = true;
    }
}

编译后得到；

/* "test.sol":85:86  b */
  0x0
    /* "test.sol":85:93  b = true */
  dup1
  sload
  not(0xff)
  and
    /* "test.sol":89:93  true */
  0x1
    /* "test.sol":85:93  b = true */
  or
  swap1
  sstore
/* "test.sol":54:100  function test() public {... */

最终是把0x1存储在位置0了，但是这里的过程还进行了一些位运算，下面的分析展示了这个汇编执行的过程；

假设栈的长度为三位，不足时全部补0。

0x0   栈为 000
dup1  栈为 000 000
sload加载 not(0xff) 到栈顶

0xff 为 111
not(0xff) 为 000

此时栈变为 000 000 000

and(000, 000) 栈为 000 000

0x1 栈为 000 000 001

or(001, 000) 栈为 000 001

swap1 栈为 001 000

sstore(000，001) 在位置0存储变量001

布尔值true是1，false是0，但是对于EVM来说是无法确定值的类型，也就是说EVM无法判断这个值是数值1还是布尔true，这个时候就需要ABI的描述，这个描述就是之前提到的ABI的Json描述。

定长数组

定长数组EVM很容易知道类型和长度，所以可以依次排列，就像存储状态变量一样。

pragma solidity ^0.5.1;
contract C {
    uint256[6] numbers;
    function test() public {
      numbers[5] = 0xC0FEFE;
    }
}

编译合约，可以看到一样的汇编。

    tag_5:
        /* "test.sol":110:118 0xC0FEFE */
      0xc0fefe
        /* "test.sol":105:106 5 */
      0x5
        /* "test.sol":97:118 numbers[5] = 0xC0FEFE */
      sstore

但是使用定长数组就会有越界的问题，EVM会在赋值的时候生成汇编检查，后文进行讨论。

固定大小的变量都是尽可能打包成32字节的块然后依次存储的，而一些类型是可以动态扩容的，这个时候就需要更加灵活的存储方式了，这些类型有映射（map），数组（array），字节数组（Byte arrays），字符串(string)。

映射（map）

通过一个简单的合约学习map的存储方式；

pragma solidity ^0.5.1;

contract Test {
  mapping(uint256 => uint256) items;

  function test() public {
      items[0x01] = 0x42;
  }
}

这个合约很简单，就是创建了一个key和value都是uint256类型的map，并且在用0x01作为key存储了0x42，用solc --bin --asm --optimize test.sol编译合约，得到如下汇编。

 tag_5:
        /* "test.sol":119:123 0x01 */
      0x1
        /* "test.sol":113:118 items */
      0x0
        /* "test.sol":113:124 items[0x01] */
      swap1
      dup2
      mstore
      0x20
      mstore
        /* "test.sol":127:131 0x42 */
      0x42
        /* "test.sol":113:124 items[0x01] */
      0xada5013122d395ba3c54772283fb069b10426056ef8ca54750cb9bb552a59e7d
        /* "test.sol":113:131 items[0x01] = 0x42 */
      sstore
        /* "test.sol":82:136 function test() public {... */
      jump // out

分析一些这段汇编就会发现0x42并不是存储在key是0x01的位置，取而代之的是0xada5013122d395ba3c54772283fb069b10426056ef8ca54750cb9bb552a59e7d这样一段地址，这段地址是通过keccak256( bytes32(0x01) + bytes32(0x00) )计算得到的，0x01就是key，而0x00表示这个合约存储的第一个storage类型变量。所以key的计算公式就是keccak256(bytes32(key) + bytes32(position))

当有合约中存在多个map的时候其映射规则也是一致的。如下所示是多个map时的存储位置分析：

pragma solidity ^0.5.1;

contract Test {
  mapping(uint256 => uint256) itemsA;
  mapping(uint256 => uint256) itemsB;

  function test() public {
    itemsA[0xAAAA] = 0xAAAA;
    itemsB[0xBBBB] = 0xBBBB;
  }
}

编译得到

tag_5:
        /* "test.sol":166:172 0xAAAA */
      0xaaaa
        /* "test.sol":149:163 itemsA[0xAAAA] */
      0x839613f731613c3a2f728362760f939c8004b5d9066154aab51d6dadf74733f3
        /* "test.sol":149:172 itemsA[0xAAAA] = 0xAAAA */
      sstore
        /* "test.sol":195:201 0xBBBB */
      0xbbbb
        /* "test.sol":149:155 itemsA */
      0x0
        /* "test.sol":178:192 itemsB[0xBBBB] */
      dup2
      swap1
      mstore
        /* "test.sol":178:184 itemsB */
      0x1
        /* "test.sol":149:163 itemsA[0xAAAA] */
      0x20
        /* "test.sol":178:192 itemsB[0xBBBB] */
      mstore
      0x34cb23340a4263c995af18b23d9f53b67ff379ccaa3a91b75007b010c489d395
        /* "test.sol":178:201 itemsB[0xBBBB] = 0xBBBB */
      sstore
        /* "test.sol":120:206 function test() public {... */
      jump // out

itemsA的位置是0，key是0xAAAA:

# key = 0xAAAA, position = 0
keccak256(bytes32(0xAAAA) + bytes32(0))
'839613f731613c3a2f728362760f939c8004b5d9066154aab51d6dadf74733f3'

itemsB的位置是1，key是0xBBBB:

# key = 0xBBBB, position = 1
keccak256(bytes32(0xBBBB) + bytes32(1))
'34cb23340a4263c995af18b23d9f53b67ff379ccaa3a91b75007b010c489d395'

用solc --bin --asm --optimize test.sol编译合约，得到如下汇编。

    /* "test.sol":166:172 0xAAAA */
      0xaaaa
        /* "test.sol":149:163 itemsA[0xAAAA] */
      0x839613f731613c3a2f728362760f939c8004b5d9066154aab51d6dadf74733f3
        /* "test.sol":149:172 itemsA[0xAAAA] = 0xAAAA */
      sstore
        /* "test.sol":195:201 0xBBBB */
      0xbbbb
        /* "test.sol":149:155 itemsA */
      0x0
        /* "test.sol":178:192 itemsB[0xBBBB] */
      dup2
      swap1
      mstore
        /* "test.sol":178:184 itemsB */
      0x1
        /* "test.sol":149:163 itemsA[0xAAAA] */
      0x20
        /* "test.sol":178:192 itemsB[0xBBBB] */
      mstore
      0x34cb23340a4263c995af18b23d9f53b67ff379ccaa3a91b75007b010c489d395
        /* "test.sol":178:201 itemsB[0xBBBB] = 0xBBBB */
      sstore
        /* "test.sol":120:206 function test() public {... */
      jump // out

可以看到，存储的地址和使用公式计算的结果一样。

动态数组

在其他语言中，数组只是连续存储在内存中的一系列相同类型的元素，取值的时候都是采用首地址+偏移量的形式，但是在solidity中，数组是一种映射。数组在存储器中是这样存储的；

0x290d...e563
0x290d...e564
0x290d...e565
0x290d...e566

虽然看起来像是连续存储的，但实际上访问的时候是通过映射来查找的。增加了数组类型的意义在于多了一些数组的方法，便于我们更好的理解和编写代码，增加的特性有；

• length表示数组的长度，一共有多少元素；
• 边界检查，当读取或者写入时索引值大于length就会报错；
• 比映射更加复杂的存储打包行为；
• 当数组变小时，自动清除未使用的空间；
• bytes和string的特殊优化让短数组（小于32字节）存储更加高效；

编译合约

pragma solidity ^0.5.1;
contract C {
    uint256[] chunks;
    function test() public {
      chunks.push(0xAA);
      chunks.push(0xBB);
      chunks.push(0xCC);
    }
}

使用remix调试合约可以看到storage部分的存储内容；

因为动态数组在编译期间无法知道数组的长度，提前预留存储空间，所以solidity就用chunks变量的位置存储了动态数组的长度，而具体的数据地址通过计算keccak256(bytes32(0))算得数组首地址，再加数组长度偏移量获得具体的元素。

这里的 0 表示的是chunks变量的位置哦

动态数据打包

数组与映射相比，有更加优化的打包行为，编译合约；

pragma solidity ^0.5.1;
contract C {
    uint128[] s;
    function test() public {
        s.length = 4;
        s[0] = 0xAA;
        s[1] = 0xBB;
        s[2] = 0xCC;
        s[3] = 0xDD;
    }
}

使用remix调试合约可以看到storage部分的存储内容；

可以发现4个元素并没有占据4个插槽，而只有两个，solidity一个插糟的大小是256bit，s的类型是uint128，编译器做了一个优化，对数据进行了更优化的打包策略，可以最大限度的节约Gas。

看一些各项操作所花费Gas的表格；

其中数据的持久化操作sstore是消耗Gas最多的操作，在合适的场景下使用数组可以利用编译器优化节约大量的Gas。

字节数组和字符串

bytes和string是EVM特殊优化的类型；

pragma solidity ^0.5.1;
contract C {
    bytes s;
    function test() public {
        s.push(0xAA);
        s.push(0xBB);
        s.push(0xCC);
    }
}

最后用remix编译得到;

key: 0x0000000000000000000000000000000000000000000000000000000000000000
value: 0xaabbcc0000000000000000000000000000000000000000000000000000000006

当bytes和string的长度小于31字节的时候可以这样放到一个插槽里，但是当大于31字节的时候，就采用存储动态数组的方式。

EVM的存储器就是一个无歧义的键值数据库，对于同一个数据只有一种存储方式，一旦存储就意味着数据的二进制不会发生改变了，除非数据本身发生了变化。这样做主要是为了保证世界状态的根哈希无歧义，对一个合约的所有状态计算得到的默克尔树的根哈希就可以标识这个合约当前的状态集合，状态细小的改变都会在根默克尔根哈希的比较中被发现。

函数选择器和参数编码

除了上面所介绍的数据类型的编码，在Solidity中还有很重要的一个组成部分就是函数调用。同样，函数调用也是在EVM虚拟机上执行的，这个时候就会面临一些问题，如何选择函数，如何给函数传递参数。

举个例子：

function cmp(uint32 x, uint32 y) returns (bool r) {
  r = x > y;
}

对于函数cmp来说，为了确定在EVM中标识一个函数会为它生产函数签名，生成方式是bytes4(keccak256("cmp(uint32,uint32)"))得到0x726b4eb8。在EVM中栈的字长为32字节，如果不采用签名的方式当遇到有大量参数的函数就会出现无法存储的问题。

当有函数名后就需要为函数传递参数，假设调用cmp函数传递的参数分别是69和5，那么第一个参数，uint32位的值69，并补位到32字节。

0x0000000000000000000000000000000000000000000000000000000000000045。

第二个参数，uint32位的值5。补位到32字节。

0x0000000000000000000000000000000000000000000000000000000000000005。

所以最终拼接得到的字节码为：

0x726b4eb8000000000000000000000000000000000000000000000000000000000000000450000000000000000000000000000000000000000000000000000000000000005

返回结果是一个bool值，在这里，返回的是true。所以输出就是一个bool。

0x0000000000000000000000000000000000000000000000000000000000000001