EVM

体系结构

存储层

一般的客户端采用 LevelDB 数据库，而 OpenEthereum 采用了 RocksDB。LevelDB 是 Key-Value 的、基于 Log-Structured Merge Tree 的非关系数据库。例如 geth 的所有区块数据都是存储在 LevelDB 中，而 LevelDB 的实现在源代码的 ethdb 包内。

数据层

以太坊的数据层主要定义了数据结构、数据模型、哈希函数、签名算法等。以太坊采用独特的数据结构保护区块头和区块体，区块头含有交易的 Merkle 根哈希值，还有账户状态的 Merkle 根哈希值、日志的 Merkle 根哈希值。以太坊中Merkle 根哈希值是采用 Merkle Patricia Tree 计算的。哈希函数使用 keccak256，数字签名采用 ECDSA。

网络层

以太坊节点通信采用的 p2p 协议是 DEVp2p，包含了 RLPx、Discv4 等子协议。RLPx 是安全的数据传输协议，采用 ECIES([Elliptic Curve Integrated Encryption Scheme](https://cryptopp.com/wiki/Elliptic_Curve_Integrated_Encryption_Scheme)) 生成公私钥，传输用于加密数据的共享的对称密钥。Discv4 是节点发现协议，通过计算节点的举例实现节点发现。

共识层

Eth1.0 采用 Ethash PoW 共识算法，Eth2.0 现采用 Ethash PoW 和 Casper FFG 混合共识算法，其中主链采用 Ethash PoW，信标链采用 Casper FFG，在未来将完全采用 Pos 协议。

Eth1.0 的挖矿规则采用 GHOST(Greedy Heaviest-Observed Sub-Tree) 协议，未来 Eth2.0 将采用 LMD-GOHST(Latest Messafe Driven GOHST) 协议。

关于 Ethash PoW 算法的细节，可以看这篇博客。

激励层

以太坊通过以太币激励矿工，挖矿奖励。详细奖励机制可见这篇文章，可能规则有所更改，但是大体思想不变。

合约层

我自身是研究合约的，因此较为关注这一层。这一层主要关注交易和合约。交易是用户与以太坊交互的唯一途径，包含了许多的对象。合约部署前会编译生成 ABI 和字节码，字节码部署上链，ABI 规定 JSON-RPC 调用的规范。

应用层

应用层主要是采用合约的各种各样的应用，例如 DApp、钱包、链游等等。DApp 的数据交互大部分依赖于合约。

EVM 存储空间

在以太坊中，EVM 是无寄存器、基于栈的虚拟机，是合约的执行环境，任何人都可以将合约的字节码部署到 EVM，然后 EVM 作为沙盒，负责解释执行。操作系统上安装 geth 之类的区块链节点客户端，客户端维互 EVM, EVM 维护着可信的执行环境。而每台运行着客户端的计算机都算作节点，因此 EVM 可视为许多计算机构成的分布式的系统。

EVM 的存储空间有三类，stack、memory、storage。

• stack 和 memory 都是临时存储，在智能合约运行时有效，当运行结束后回收。memory 主要是临时存储数组、字符串等较大的交易时的数据，按 256 位读取，按 8 位或者 256 位读取，更加灵活；，
• 栈最多容纳 1024 个元素，以32字节为一组（也就是每个变量用 uint256 类型储存，以太坊是 256 位的虚拟机），这样可以方便地应用 256 位 Keccak 哈希计算和椭圆曲线计算。对栈的访问并不是完全严格按照 FILI（先进后出），而是一种寄存器栈，允许将顶端的16个元素种的某一个复制或者交换到栈顶。每次操作只能取栈顶的若干元素，把结果压栈。当然也能够把栈顶元素放到 memory 或者 storage 区域保存。
• storage 是永久性存储，采用映射的形式存储 uint256 的 Key 和 uint256 的 Value，因此它的操作更消耗计算资源，gas 也高得多。这样的储存空间分类，同样在 Solidity 中有所体现。

全局变量的存储方式

一般的静态类型

全局变量紧凑地存储在 storage，这样多个变量可能存储在同一个 slot (一个 solt 32 个字节) 里面。除了动态数组和映射类型，数据都是从 slot[0] 开始，连续地（如果不够32字节也不会扩充 0）存储在 slots 里。每个变量所需的字节由变量类型确定。多个变量打包在一个 slot 的规则如下：

• 这些变量所占空间之和不超过 32 字节。
• 大端存储，也就是第一个变量的存储位置在 slot 地址中最小的部分。
• 如果当前 slot 剩余空间无法容纳下一个变量，则下一个变量将存储在下一个 slot
• 结构体和数组总是分配新的 slot 给它们，其中的成员紧凑存储。
• 结构体或者数组的下一个全局变量，也往往不会与结构体或者数组在同一个 slot，而是在下一个 slot 中。
• 如果合约由继承关系，那么全局变量的存储的先后，遵循 C3 线性化顺序规则

设计思路说明：

EVM 是 32字节 为基础操作单位的虚拟机，如果元素不够 32 个字节，EVM 需要执行额外的操作，去读写这个元素，因此小于 32 个字节的元素消耗的 gas 可能会比 32 个字节的元素更多。为了优化这个问题，编译器会将多个小于 32 字节的元素，尽可能地紧凑存储在一个 slot。原本需要每个变量读取一次，变成了多个变量一起读取，即使只操作其中一个变量，也不会影响同一个 slot 的其他变量。

因此可知，全局变量的声明顺序也应当注意，uint128, uint128, uint256 的顺序会比 uint128, uint256, uint128 更好。

映射和动态数组的存储

映射和动态数组所需的空间是无法预计的，因此它们不是整个的放在某个位置，而是首先按照上面的规则占用 32 字节，然后将具体的值存储在其他的 slot，通过 keccak256 哈希来查找。（很难产生冲突的情况）

例如，假设映射类型或者动态数组占用了 slot[p]，对于动态数组，slot[p] 存储元数个数（除了特殊的 byte[] 和 string）；对于映射，slot[p] 为空。动态数组元素的位置将从 keccak256(p) 开始，按照上述规则排列。

对于动态数组的元素 x[i][j]，假设 x 的类型是 uint24[][]，那么存储它的 slot 的位置应该是 keccak256(keccak256(p)+i)+floor(j/floor(256/24)) ，也就是说递归的定义，二维动态数组先找到一维动态数组的位置，然后再哈希，找到起始元素的位置。最后，通过这个 slot 的数据 v，找到元素所在的片段 *`(v >> ((j % floor(256 / 24)) 24)) & type(uint24).max`**

对于映射类型，如果 Key 是k，那么存储值的 slot 为 keecak256(h(k)+p)，其中 K 表示把 h(k) 和 p 组合成一个字符串。**h() 的定义如下

• 对于值类型，h(k) 通过填充 0 的方式，将 k 填充为 32 字节。
• 对于字节或者字符串类型，h(k) 直接计算 k 的 keccak256 哈希。

对于嵌套映射，按照递归定义的方式确定。详情可见文档。

bytes 和 string 的存储

bytes 和 string 是比较特殊的数组类型，它们的存储方式相同。因为它们的每个元素相当于 uint8，占用 8 位，也相当于 bytes1，因此可以把它们当作 bytes1[] 处理。

但是如果数组的元素比较少，那么就把数组元素和数组元素的个数存储在同一个 slot。例如，bytes 只有 31 字节，元素按照小端序存储，地址最小的 8 位存储length*2。

如果数组元素总共所占大小达到或者超过 32 字节，那么会在 slot[p] 存储 *`length2 + 1**，然后数据类似地存放在位置位 **keccak256(p)`** 的位置。

storage 存储结构的 JSON 表示

对于每个元素，都有个 JSON 片段表示，例如合约

contract A { uint x; }

对应的 JSON 表示如下：

{
    "astId": 2,
    "contract": "fileA:A",
    "label": "x",
    "offset": 0,
    "slot": "0",
    "type": "t_uint256"
}

• astId 是全局变量声明的 AST(abstract syntax tree) 节点的id。
• contract 是合约的名称，包括其路径作为前缀。
• label 是全局变量的名称。
• offset 是根据编码在存储槽内以字节为单位的偏移量。
• slot 是全局变量所在或开始的存储槽。这个数字可能非常大，被表示为一个字符串。
• type 是一个类型标识符，来自types。

对于 types 中的每个类型 type，都包括如下属性

{
    "encoding": "inplace",
    "label": "uint256",
    "numberOfBytes": "32",
}

• encoding 表示数据在存储中的编码方式：
  • inplace: 数据在存储中连续排列.
  • mapping: Keccak-256 基于映射类型的哈希的方法 .
  • dynamic_array: Keccak-256 基于动态数组类型的哈希的方法
  • bytes: 单槽或基于Keccak-256 bytes 类型的哈希的方法，取决于数据大小 .
• label 是规范的类型名称 (比如别称 uint 要写成规范名称 uint256) 。
• numberOfBytes 是使用的字节数(十进制字符串)。 如果 numberOfBytes>32 意味着使用了一个以上的 slot。

对于下面这个合约：

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.0 <0.9.0;
contract A {
    struct S {
        uint128 a;
        uint128 b;
        uint[2] staticArray;
        uint[] dynArray;
    }
​
    uint x;
    uint y;
    S s;
    address addr;
    mapping (uint => mapping (address => bool)) map;
    uint[] array;
    string s1;
    bytes b1;
}

JSON 格式的存储结构说明：

​
"storageLayout": {
  "storage": [
    {
      "astId": 14,
      "contract": "fileA:A",
      "label": "x",
      "offset": 0,
      "slot": "0",
      "type": "t_uint256"
    },
    {
      "astId": 16,
      "contract": "fileA:A",
      "label": "y",
      "offset": 0,
      "slot": "1",
      "type": "t_uint256"
    },
    {
      "astId": 18,
      "contract": "fileA:A",
      "label": "s",
      "offset": 0,
      "slot": "2",
      "type": "t_struct(S)12_storage"
    },
    {
      "astId": 20,
      "contract": "fileA:A",
      "label": "addr",
      "offset": 0,
      "slot": "6",
      "type": "t_address"
    },
    {
      "astId": 26,
      "contract": "fileA:A",
      "label": "map",
      "offset": 0,
      "slot": "7",
      "type": "t_mapping(t_uint256,t_mapping(t_address,t_bool))"
    },
    {
      "astId": 29,
      "contract": "fileA:A",
      "label": "array",
      "offset": 0,
      "slot": "8",
      "type": "t_array(t_uint256)dyn_storage"
    },
    {
      "astId": 31,
      "contract": "fileA:A",
      "label": "s1",
      "offset": 0,
      "slot": "9",
      "type": "t_string_storage"
    },
    {
      "astId": 33,
      "contract": "fileA:A",
      "label": "b1",
      "offset": 0,
      "slot": "10",
      "type": "t_bytes_storage"
    }
  ],
  "types": {
    "t_address": {
      "encoding": "inplace",
      "label": "address",
      "numberOfBytes": "20"
    },
    "t_array(t_uint256)2_storage": {
      "base": "t_uint256",
      "encoding": "inplace",
      "label": "uint256[2]",
      "numberOfBytes": "64"
    },
    "t_array(t_uint256)dyn_storage": {
      "base": "t_uint256",
      "encoding": "dynamic_array",
      "label": "uint256[]",
      "numberOfBytes": "32"
    },
    "t_bool": {
      "encoding": "inplace",
      "label": "bool",
      "numberOfBytes": "1"
    },
    "t_bytes_storage": {
      "encoding": "bytes",
      "label": "bytes",
      "numberOfBytes": "32"
    },
    "t_mapping(t_address,t_bool)": {
      "encoding": "mapping",
      "key": "t_address",
      "label": "mapping(address => bool)",
      "numberOfBytes": "32",
      "value": "t_bool"
    },
    "t_mapping(t_uint256,t_mapping(t_address,t_bool))": {
      "encoding": "mapping",
      "key": "t_uint256",
      "label": "mapping(uint256 => mapping(address => bool))",
      "numberOfBytes": "32",
      "value": "t_mapping(t_address,t_bool)"
    },
    "t_string_storage": {
      "encoding": "bytes",
      "label": "string",
      "numberOfBytes": "32"
    },
    "t_struct(S)12_storage": {
      "encoding": "inplace",
      "label": "struct A.S",
      "members": [
        {
          "astId": 2,
          "contract": "fileA:A",
          "label": "a",
          "offset": 0,
          "slot": "0",
          "type": "t_uint128"
        },
        {
          "astId": 4,
          "contract": "fileA:A",
          "label": "b",
          "offset": 16,
          "slot": "0",
          "type": "t_uint128"
        },
        {
          "astId": 8,
          "contract": "fileA:A",
          "label": "staticArray",
          "offset": 0,
          "slot": "1",
          "type": "t_array(t_uint256)2_storage"
        },
        {
          "astId": 11,
          "contract": "fileA:A",
          "label": "dynArray",
          "offset": 0,
          "slot": "3",
          "type": "t_array(t_uint256)dyn_storage"
        }
      ],
      "numberOfBytes": "128"
    },
    "t_uint128": {
      "encoding": "inplace",
      "label": "uint128",
      "numberOfBytes": "16"
    },
    "t_uint256": {
      "encoding": "inplace",
      "label": "uint256",
      "numberOfBytes": "32"
    }
  }
}

memory 的存储方式

Solidity保留了前 4 个特殊用途的32字节的 slot，内部二进制的序列的范围不同，代表的功能也不同：

• 0x00 - 0x3f (前面64 字节，占用 2 个slot): 计算哈希时临时存储数据的空间，在语句之间使用。
• 0x40 - 0x5f (32 字节，占用 1 个 slot): 当前分配的内存大小 ，或者说是内存指针所在位置（因为可以通过内存空间大小计算内存指针位置）。
• 0x60 - 0x7f (32 字节，占用 1 个 slot): slot[0]，正式内存，用于保存动态 memory 数组的初始值，而且只读。然后下一个位置 0x80 是开始写入的位置。

注意：

1. 执行期间，内存永远不会释放，新的将写入的对象会放在空闲内存指针上。
2. memory 数组中的元素始终占据32字节的倍数（特殊的 bytes 和 string 除外）。
3. 对于多维 memory 数组，它的名字实际上也是代表指向内存数组的指针。
4. 对于动态数组，存储它的第一个 slot 里是它的长度，然后数组元素按顺序排列。
5. 如果需要临时存储的操作需要大于 64 字节的空间，那么不会放入 0x00-0x3f 的暂存空间，又考虑到临时存储的生命周期很短，因此直接在当前内存指针的下一个位置写入，但是内存指针不变，0x40-0x5f 记录的内存大小也不变，然后继续写入内存时直接覆盖。因此，在直接操作未使用的内存时，这块内存可能不是初始值。

memory 的存储方式和 storage 比较相似，但是有一些区别。例如下面的表达式，在 storage 中会紧密排列，只占 1 个 slot，而 memory 中不会紧密排列，占用 4 个 slot

uint8[4] a;

calldata 的存储方式

按照 ABI 的方式编码，值得提出来的是构造函数部署时才给参数，因此它的参数的编码在最后面附上去，仍然按照 ABI 的方式编码。

清洗和优化

当一个变量类型不够占用256位时（如 uint8），而 EVM 往往是 32 字节一组读取，因此除了变量占的空间外的其它位，可能需要清洗，防止这些多余数据造成的未知的影响。

例如，在将一个变量写入 storage 时，storage 中的这一串序列可能用于计算哈希值或作为消息调用的数据，那么多余的数据可能会造成异常。

注意：

• 通过内联汇编访问变量，并不保证这一串序列已被清洗。
• 如果多余的位并不直接影响下一个操作，那么将不会进行变量的清洗。
• 压栈的时候，编译器会默认执行变量清洗。

变量清洗的规则如下：

EVM 运行机制

EVM 只能接受外部账户发送的调用请求（统称交易）或者合约账户发送的消息。结果是修改后的状态数据库和日志。日志将以 MPT 的形式组织成交易的收据树，然后将收据树的树根的哈希值记录在区块头上。

实际上，外部账户或者合约账户的操作，都将转化成 Message 对象传入 EVM，EVM 根据 Message 生成 Contract 对象。如果只是普通转账，直接修改状态数据库种的账户余额即可。如果 Message 的 data 成员不为空，那么将会根据 data 中的 ABI 编码后的序列，部署合约或者调用合约中的函数。调用合约时，EVM 将根据 Contract 对象中的 CodeAddr 获取地址，当调用合约代码的某个函数时，就会通过函数签名匹配入口和参数。，从状态数据库中加载对应字节码（包含函数选择器和函数入口），解释器根据合约字节码中的操作码执行。

EVM 的操作码占用 1 字节，最多有 256 个操作码（目前可能还没全部用上）。在解释器中，首先根据函数签名选择被被调用的函数，然后获取操作码，从 (跳转表) JumpTable 中检索对应的操作，具体调用过程由合约决定。

Gas 机制始终贯穿整个运行过程中，如果 Gas 不足，将随时执行 execute()，按照要求回滚。如果 gas 有剩余，则返还这部分给调用者。

EVM 操作码

EVM通过一组指令来执行特定任务，这组指令被称为操作码，每个操作码只占一个字节，因此目前的操作码如下：

每个数字都是十六进制表示，蓝色标出的为正在使用的操作码，灰色横杠表示未被使用。具体功能可以浏览这里。每个操作码的作用都是将栈顶元素出栈，然后将结果入栈。

操作码主要分为以下：

• 栈操作相关的字节码（POP, PUSH, DUP, SWAP）
• 运算/比较/位操作相关的字节码（ADD， SUB， GT, LT, AND, OR）
• 环境相关的字节码（CALLER, CALLERVALUE， NUMBER）
• 内存操作字节码（MLOAD, MSTORE, MSTORE8, MSIZE）
• 存储操作字节码（SLOAD, SSTORE）
• 程序计数器相关的字节码（JUMP, JUMPI, PC, JUMPDEST）
• 终止相关的字节码（STOP， RETURN, REVERT, INVALID, SELFDESTRUCT）

EVM 字节码

操作码以字节码的形式存储，一串字节码会被解释为多个字节。例如 0x6001600101 会根据操作码的编码解释称如下操作:

先将两个值压栈，然后加起来，结果压栈。由于一个字节的二进制范围是 [0, 127]，所以操作码的范围是 [0x00,0x7f]

GAS 开销的精确计算

这是官网文档总结的 gas 开销，其中带链接的 gas 表示动态开销，计算较为复杂。我将在下面解释一些不是那么容易理解的部分。更详细的说明见这里。(表格较长，可以按住 SHIFT 滚动鼠标转轮，横向)

实际计算的话，这个工具很好用.