智能合约编写之Solidity运行原理｜FISCO BCOS超话区块链专场（篇6）

引  言

做为一门面向智能合约的语言，Solidity与其余经典语言既有差别也有类似之处。

一方面，服务于区块链的属性使其与其余语言存在差别。例如，合约的部署与调用均要通过区块链网络确认；执行成本须要被严格控制，以防止恶意代码消耗节点资源。

另外一方面，身为编程语言，Solidity的实现并未脱离经典语言，好比Solidity中包含相似栈、堆的设计，采用栈式虚拟机来进行字节码处理。

本系列前几篇文章介绍了如何开发Solidity程序，为了让读者知其然更知其因此然，本文将进一步介绍Solidity的内部运行原理，聚焦于Solidity程序的生命周期和EVM工做机制。

Solidity的生命周期

与其余语言同样，Solidity的代码生命周期离不开编译、部署、执行、销毁这四个阶段。下图整理展示了Solidity程序的完整生命周期：

经编译后，Solidity文件会生成字节码。这是一种相似jvm字节码的代码。部署时，字节码与构造参数会被构建成交易，这笔交易会被打包到区块中，经由网络共识过程，最后在各区块链节点上构建合约，并将合约地址返还用户。

当用户准备调用该合约上的函数时，调用请求一样也会经历交易、区块、共识的过程，最终在各节点上由EVM虚拟机来执行。

下面是一个示例程序，咱们经过remix探索它的生命周期。

pragma solidity ^0.4.25;

contract Demo{
    uint private _state;
    constructor(uint state){
        _state = state;
    }
    function set(uint state) public {
        _state = state;
    }
}

编译

源代码编译完后，能够经过ByteCode按钮获得它的二进制：

608060405234801561001057600080fd5b506040516020806100ed83398101806040528101908080519060200190929190

还能够获得对应的字节码（OpCode）：

PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH2 0x10 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x40 MLOAD PUSH1 0x20 DUP1 PUSH2 0xED DUP4 CODECOPY DUP2 ADD DUP1 PUSH1 0x40 MSTORE DUP2 ADD SWAP1 DUP1 DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 POP POP POP DUP1 PUSH1 0x0 DUP2 SWAP1 SSTORE POP POP PUSH1 0xA4 DUP1 PUSH2 0x49 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH1 0x3F JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0x60FE47B1 EQ PUSH1 0x44 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH1 0x4F JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x6C PUSH1 0x4 DUP1 CALLDATASIZE SUB DUP2 ADD SWAP1 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 POP POP POP PUSH1 0x6E JUMP JUMPDEST STOP JUMPDEST DUP1 PUSH1 0x0 DUP2 SWAP1 SSTORE POP POP JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 0x4e 0xd9 MOD DIFFICULTY 0x4c 0xc4 0xc9 0xaa 0xbd XOR EXTCODECOPY MSTORE 0xb2 0xd4 DUP7 0xdf 0xc5 0xde 0xa9 DUP1 SLT PUSH1 0xC3 CALLDATACOPY XOR 0x5d 0xad KECCAK256 0xe1 0x1f DUP2 SHL STOP 0x29

其中下述指令集为set函数对应的代码，后面会解释set函数如何运行。

JUMPDEST DUP1 PUSH1 0x0 DUP2 SWAP1 SSTORE POP POP JUMP STOP

部署

编译完后，便可在remix上对代码进行部署，构造参数传入0x123:

部署成功后，可获得一条交易回执：

点开input，能够看到具体的交易输入数据：

上面这段数据中，标黄的部分正好是前文中的合约二进制；而标紫的部分，则对应了传入的构造参数0x123。

这些都代表，合约部署以交易做为介质。结合区块链交易知识，咱们能够还原出整个部署过程：

• 客户端将部署请求(合约二进制，构造参数)做为交易的输入数据，以此构造出一笔交易

• 交易通过rlp编码，而后由发送者进行私钥签名

• 已签名的交易被推送到区块链上的节点

• 区块链节点验证交易后，存入交易池

• 轮到该节点出块时，打包交易构建区块，广播给其余节点

• 其余节点验证区块并取得共识。不一样区块链可能采用不一样共识算法，FISCO BCOS中采用PBFT取得共识，这要求经历三阶段提交（pre-prepare，prepare, commit）

• 节点执行交易，结果就是智能合约Demo被建立，状态字段_state的存储空间被分配，并被初始化为0x123

执行

根据是否带有修饰符view，咱们可将函数分为两类：调用与交易。因为在编译期就肯定了调用不会引发合约状态的变动，故对于这类函数调用，节点直接提供查询便可，无需与其余区块链节点确认。而因为交易可能引发状态变动，故会在网络间确认。

下面将以用户调用了set(0x10)为假设，看看具体的运行过程。

首先，函数set没有配置view/pure修饰符，这意味着其可能更改合约状态。因此这个调用信息会被放入一笔交易，经由交易编码、交易签名、交易推送、交易池缓存、打包出块、网络共识等过程，最终被交由各节点的EVM执行。

在EVM中，由SSTORE字节码将参数0xa存储到合约字段_state中。该字节码先从栈上拿到状态字段_state的地址与新值0xa，随后完成实际存储。

下图展现了运行过程：

这里仅粗略介绍了set(0xa)是如何运行，下节将进一步展开介绍EVM的工做机制以及数据存储机制。

销毁

因为合约上链后就没法篡改，因此合约生命可持续到底层区块链被完全关停。若要手动销毁合约，可经过字节码selfdestruct。销毁合约也须要进行交易确认，在此很少做赘述。

EVM原理

在前文中，咱们介绍了Solidity程序的运行原理。通过交易确认后，最终由EVM执行字节码。对EVM，上文只是一笔带过，这一节将具体介绍其工做机制。

运行原理

EVM是栈式虚拟机，其核心特征就是全部操做数都会被存储在栈上。下面咱们将经过一段简单的Solidity语句代码看看其运行原理：

uint a = 1;
uint b = 2;
uint c = a + b;

这段代码通过编译后，获得的字节码以下：

PUSH1 0x1
PUSH1 0x2
ADD

为了读者更好了解其概念，这里精简为上述3条语句，但实际的字节码可能更复杂，且会掺杂SWAP和DUP之类的语句。

咱们能够看到，在上述代码中，包含两个指令：PUSH1和ADD，它们的含义以下：

• PUSH1：将数据压入栈顶。

• ADD：POP两个栈顶元素，将它们相加，并压回栈顶。

这里用半动画的方式解释其执行过程。下图中，sp表示栈顶指针，pc表示程序计数器。当执行完push1 0x1后，pc和sp均往下移：

相似地，执行push1 0x2后，pc和sp状态以下：

最后，当add执行完后，栈顶的两个操做数都被弹出做为add指令的输入，二者的和则会被压入栈：

存储探究

在开发过程当中，咱们常会遇到使人迷惑的memory修饰符；阅读开源代码时，也会看到各类直接针对内存进行的assembly操做。不了解存储机制的开发者遇到这些状况就会一头雾水，因此，这节将探究EVM的存储原理。

在前文《智能合约编写之Solidity的基础特性》中咱们介绍过，一段Solidity代码，一般会涉及到局部变量、合约状态变量。

而这些变量的存储方式存在差异，下面代码代表了变量与存储方式之间的关系。

contract Demo{
    //状态存储
    uint private _state;

    function set(uint state) public {
        //栈存储
        uint i = 0;
        //内存存储
        string memory str = "aaa";
    }
}

栈

栈用于存储字节码指令的操做数。在Solidity中，局部变量如果整型、定长字节数组等类型，就会随着指令的运行入栈、出栈。

例如，在下面这条简单的语句中，变量值1会被读出，经过PUSH操做压入栈顶：

uint i = 1;

对于这类变量，没法强行改变它们的存储方式，若是在它们以前放置memory修饰符，编译会报错。

内存

内存相似java中的堆，它用于储存"对象"。在Solidity编程中，若是一个局部变量属于变长字节数组、字符串、结构体等类型，其一般会被memory修饰符修饰，以代表存储在内存中。

本节中，咱们将以字符串为例，分析内存如何存储这些对象。

1. 对象存储结构

下面将用assembly语句对复杂对象的存储方式进行分析。

assembly语句用于调用字节码操做。mload指令将被用于对这些字节码进行调用。mload(p)表示从地址p读取32字节的数据。开发者可将对象变量看做指针直接传入mload。

在下面代码中，通过mload调用，data变量保存了字符串str在内存中的前32字节。

string memory str = "aaa";
bytes32 data;
assembly{
    data := mload(str)
}

掌握mload，便可用此分析string变量是如何存储的。下面的代码将揭示字符串数据的存储方式：

function strStorage() public view returns(bytes32, bytes32){
    string memory str = "你好";
    bytes32 data;
    bytes32 data2;
    assembly{
        data := mload(str)
        data2 := mload(add(str, 0x20))
    }   
    return (data, data2);
}

data变量表示str的0~31字节，data2表示str的32~63字节。运行strStorage函数的结果以下：

0: bytes32: 0x0000000000000000000000000000000000000000000000000000000000000006
1: bytes32: 0xe4bda0e5a5bd0000000000000000000000000000000000000000000000000000

能够看到，第一个数据字获得的值为6，正好是字符串"你好"经UTF-8编码后的字节数。第二个数据字则保存的是"你好"自己的UTF-8编码。

熟练掌握了字符串的存储格式以后，咱们就能够运用assembly修改、拷贝、拼接字符串。读者可搜索Solidity的字符串库，了解如何实现string的concat。

2. 内存分配方式

既然内存用于存储对象，就必然涉及到内存分配方式。

memory的分配方式很是简单，就是顺序分配。下面咱们将分配两个对象，并查看它们的地址：

function memAlloc() public view returns(bytes32, bytes32){
    string memory str = "aaa";
    string memory str2 = "bbb";
    bytes32 p1;
    bytes32 p2;
    assembly{
        p1 := str
        p2 := str2
    }   
    return (p1, p2);
}

运行此函数后，返回结果将包含两个数据字：

0: bytes32: 0x0000000000000000000000000000000000000000000000000000000000000080
1: bytes32: 0x00000000000000000000000000000000000000000000000000000000000000c0

这说明，第一个字符串str1的起始地址是0x80，第二个字符串str2的起始地址是0xc0，之间64字节，正好是str1自己占据的空间。此时的内存布局以下，其中一格表示32字节（一个数据字，EVM采用32字节做为一个数据字，而非4字节）：

• 0x40~0x60：空闲指针，保存可用地址，本例中是0x100，说明新的对象将从0x100处分配。能够用mload(0x40)获取到新对象的分配地址。

• 0x80~0xc0：对象分配的起始地址。这里分配了字符串aaa

• 0xc0~0x100：分配了字符串bbb

• 0x100~...：由于是顺序分配，新的对象将会分配到这里。

状态存储

顾名思义，状态存储用于存储合约的状态字段。

从模型而言，存储由多个32字节的存储槽构成。在前文中，咱们介绍了Demo合约的set函数，里面0x0表示的是状态变量_state的存储槽。全部固定长度变量会依序放到这组存储槽中。

对于mapping和数组，存储会更复杂，其自身会占据1槽，所包含数据则会按相应规则占据其余槽，好比mapping中，数据项的存储槽位由键值k、mapping自身槽位p经keccak计算得来。

从实现而言，不一样的链可能采用不一样实现，比较经典的是以太坊所采用的MPT树。因为MPT树性能、扩展性等问题，FISCO BCOS放弃了这一结构，而采用了分布式存储，经过rocksdb或mysql来存储状态数据，使存储的性能、可扩展性获得提升。

结  语

本文介绍了Solidity的运行原理，运行原理总结以下。

首先，Solidity源码会被编译为字节码，部署时，字节码会以交易为载体在网络间确认，并在节点上造成合约；合约函数调用，若是是交易类型，会通过网络确认，最终由EVM执行。

EVM是栈式虚拟机，它会读取合约的字节码并执行。

在执行过程当中，会与栈、内存、合约存储进行交互。其中，栈用于存储普通的局部变量，这些局部变量就是字节码的操做数；内存用于存储对象，采用length+body进行存储，顺序分配方式进行内存分配；状态存储用于存储状态变量。

理解Solidity的运行方式及其背后原理，是成为Solidity编程高手必经之路。

咱们鼓励机构成员、开发者等社区伙伴参与开源共建事业，有你在一块儿，会更了不得。多样参与方式：

一、进入微信社群，随时随地与圈内最活跃、最顶尖的团队畅聊技术话题（进群请添加小助手微信，

微信ID：FISCOBCOS010）；

二、订阅咱们的公众号：“FISCO BCOS开源社区”，咱们为你准备了开发资料库、最新FISCO BCOS动态、活动、大赛等信息；

三、来Meetup与开发团队面对面交流，FISCO BCOS正在全国举办巡回Meetup，深圳、北京、上海、成都……欢迎您公众号在菜单栏【找活动】中找到附近的Meetup，前往结识技术大咖，畅聊硬核技术；

四、参与代码贡献，您能够在Github提交Issue进行问题交流，欢迎向FISCO BCOS提交Pull Request，包括但不限于文档修改、修复发现的bug、提交新的功能特性。

代码贡献指引：

https://github.com/FISCO-BCOS/FISCO-BCOS/blob/master/docs/CONTRIBUTING_CN.md