基于Qtum-x86智能合约的创建过程解析

Qtum-x86智能合约创建过程

Qtum-x86虚拟机与以太坊EVM最大的区别之一就是智能合约实现过程。一般来说，智能合约开发人员会使用Remix，甚至用solc来进行开发工作，以便将合约编译成字节码。在EVM合约中，发送到区块链的字节码就是从“0”处开始执行。当矿工（或质押人）构建区块并将合约交易完成上链时，字节开始执行。底层的执行过程基本概括如下：

1. 交易字节码被发送到区块链节点

2. 矿工/质押人开始构建一个新区块，并开始完成包含交易的字节码

3. 字节码从“0”处开始执行

4. 执行为智能合约构造函数生成的solidity字节码

5.“持久的（persistent）”字节码被复制到内存中（即所需的全部数据和字节码，通常不包括构造函数）

6.构造函数修改后的“常量”在内存中更改，以匹配要部署的最终版本

7.合约执行结束，同时指定了应该持久化到区块链的内存范围

8. 区块链将数据保存到以太坊的Global State Trie，通过“code”字段将要持久化的字节码与地址关联起来

再次调用合约时，会执行以下过程：

1. 当调用合约时，执行从已持久化的合约字节码的“0”处开始（不包括构造函数）

2. Solidity自动生成的合约代码解析ABI数据，指定应对哪些函数和参数值执行操作

3. 执行函数

4. 函数返回的数据被复制到内存中，并在合约退出执行时指定地址（开始地址和结束地址）

正是因为Solidity编写可能存在相关漏洞，Qtum-x86就要求大多数智能合约开发人员需要更加细心。近期，许多智能合约编写者都知道智能合约返回的数据大小是有固定限制的，EVM可通过一些专门的操作码允许返回长度可变的数据，当然Solidity会在需要时使用这些操作码。

x86合约的处理过程有着明显的不同，在许多方面更为复杂，但同时也更加灵活。其中部分原因在于它继承了所使用的现有编程语言（例如，C或Rust）的差异，而没有使用抽象了所有细节的专门构建的语言。首先，编写合约的过程尽管更透明，但也更复杂：

1. 创建一个“SimpleABI”文件，该文件指定了可以从外部调用合约的接口

2. SimpleABI程序与生成“分派”代码的ABI文件，以及其他必需的内容一起运行，这样智能合约开发人员就可以不用关心解析和创建ABI数据的底层细节

3.然后，开发人员为指定的所有接口函数（当然还有其他所需的非接口函数）编写代码-；如果没有实现接口函数，则会导致链接器错误

4.然后代码被编译成单独的对象文件，这些对象文件会链成一个内聚的ELF文件（Linux和其他一些unix操作系统的标准二进制格式）

5. 然后，ELF文件被载入一个自定义的Qtum程序，该程序将提取出感兴趣的数据并将其编译成一个Qtum-x86字节码格式的文件

在大多数情况下，使用Makefiles之类的工具进行设置之后，这种过程可以自动执行，Qtum当然也会提供可以更改和修改的模板项目，以避免复杂的设置过程。

Qtum-x86字节码格式不像Solidity那样“扁平”。它有一个头部区域，指定有关字节码的一些信息，以及3个独立的部分。头部包含的数据有：

· 选项部分大小

· 代码段大小

· 数据段大小

·“保留”（即尚未使用）

包含的三个部分是：

1. 选项 – 诸如选择禁用或选择启用某些Qtum-x86功能的标志（例如禁用字节码升级）或更丰富的数据（如依赖关系图和元数据）之类的东西

2. 代码 – 合约的实际可执行数据。该部分数据存储为只读和可执行文件

3. 数据 – 在合约执行期间使用和/或修改的明文数据。该部分数据以读写方式存储，且不可执行

与EVM不同，x86所有内存都被认为既是数据，也是代码。存在一些保护机制，但它要求代码和数据能清晰地区分开来，并存储在单独的内存区域中。这种保护机制是为了防止一些潜在的安全问题。尽管本身不会有安全问题，但如果代码设计不当，就可能因为覆盖了保护区代码或执行了调用方可控制的数据，将小错误“放大”为更大的错误。因此，这就需要对Qtum-x86的字节码格式进行结构化处理。

当然，ELF能够指定所有这些内容，此外还能提供其他更多的功能，那么为什么不使用ELF作为字节码格式呢？最大的原因是为了简化共识模型。无论使用什么样的字节码格式，每个节点都必须完全一致地解析和理解这些字节码是“共识关键”所在。ELF明显更为复杂，而过去那些简单的解析器又有几个安全漏洞。因此，一种只保留我们所需内容的大大精简过的格式才是最佳的选择。这也允许编译器的其他可能的中间输出格式，例如PE格式（用于Windows.exe文件的格式）。

既然知道了最终的字节码，就可以将其广播到区块链上。Qtum-x86中执行合约和持久化合约的方法是类似的，但二者也有足够的差异，由此可能会影响智能合约的开发人员：

1. 包含交易的字节码被发送到区块链节点

2. 矿工/质押人开始构建一个新的区块，并开始完成包含交易的字节码

3. 解析字节码格式，并将每个部分被映射到VM的内存中

4. 字节码从“代码”内存的第0个位置开始执行

5. 执行由编译器/链接器插入的“crt0”代码，以初始化堆栈并准备执行

6. 系统调用目的是使合约意识到正在被构建（因此不应期望出现合约调用）

7. 执行智能合约构造函数代码

8. 代码退出并结束执行

9. 区块链持久化存储了整个合约字节码格式文件。字节码作为地址的“bytecode”数据字段保存到DeltaDB中。一个表示构造、执行和字节码的“delta”会被插入到区块头中的Merkle哈希树中

再次调用合约时，将执行以下过程：

1. 调用合约时，执行从“代码”部分的“0”开始，与创建合约时的执行方式相同。

2. 执行由编译器/链接器插入的“crt0”代码，以初始化堆栈并准备执行

3. 系统调用目的是使合约意识到正在被构建（因此不应期望出现合约调用）

4. 执行SimpleABI生成的代码并解析发送给合约的ABI数据。

5. SimpleABI代码从“共享的合约通信堆栈”中获取ABI数据，并将其复制到参数堆栈中，并执行用户实现的接口函数。

6. 执行用户实现的功能和逻辑

7. 将逻辑的返回数据放入参数堆栈中并退出函数

8. SimpleABI生成的代码获取返回数据并将其推送到合约通信堆栈上

9. 退出合约