执行引擎

平台支持合约安全、执行高效、编程友好的合约执行沙盒环境，研发了三种合约执行引擎：HVM（HyperVM）、EVM（HyperEVM）、BVM等，分别支持 Java、Solidity、Go等编程语言，提供完善的合约生命周期管理。

HVM

HVM概述

由于当前Java语言的流行以及其强大的生态，使用Java语言编写合约无疑会让合约开发更加便捷且易于推广。HVM为趣链科技首创支持Java语言的智能合约执行引擎，支持符合Java编写规范多种数据结构，内置数据表结构，可以实现业务数据可视化，在保证智能合约执行的安全性、确定性、可终止性的前提下，提供了一系列灵活的应用模式和工具方法集，以满足复杂多样的业务场景需求，为广泛的区块链开发人员提供更便捷、灵活、安全的区块链应用开发模式。

HVM使用

HVM执行机制从外部来看主要负责合约执行的操作。从SDK调用一笔HVM的合约，首先需要共识模块将通过共识的区块交易发送给执行模块，然后执行模块调用HVM暴露出来的合约接口，最后合约执行完成后会将结果返回，将执行结果写入账本中。在架构层面，HVM自上而下主要分为三个部分：合约操作层、库函数层以及虚拟机层。

_images/HVM_Architecture.png
  1. 合约操作层

这一层与用户直接相关联，主要包括合约部署、调用等全生命周期管理，对于合约的操作通过会对链上的合约数据状态产生影响，所以平台采取了灵活的合约管理提案申请-阈值投票-提案执行的策略，通过合约管理员对合约操作进行控制，保证合约管理操作的公平与安全。

  • 合约部署 ：编写Java智能合约，并通过SDK发交易的形式将其部署到区块链上；
  • 合约调用 ： 根据合约地址，调用相应合约中的逻辑。
  • 合约升级 ： 因业务要求或者实现逻辑更新，需要对合约进行升级操作时，需要用新合约来替换掉旧合约，由于升级合约是一个链级操作（改变整个链上的状态），所以需要采用CAF联盟自治框架才可以进行合约升级，保证链上合约的安全控制。
  • 合约冻结/解冻 ：将链上的合约冻结，在合约所有者解冻之前，禁止任何人调用，冻结不同于销毁，其具备一个可逆的过程，可以通过合约解冻的操作重新使用。
  • 合约销毁 ：将链上原来部署的合约进行废止操作，不同于合约冻结，合约销毁是一个不可逆的操作，被销毁的合约不能够被访问，不可以恢复，不允许再进行任何操作，但合约销毁后的数据仍然会存在链的底层账本中，仅用于监管审计。
  1. 库函数层

库函数包括数据结构、账本操作、日志信息以及加解密等功能。

  • 数据结构符合 Java 编写范式：HyperList、HyperMap为平台独立研发，为了方便Java 软件开发者习惯，使其无需感知区块链底层 KV 结构即可编写相应业务逻辑代码。HyperMap 和 HyperList 的使用类似于开发者所熟知的 HashMap 和 ArrayList，但做了原创性地优化，在减少内存使用的同时也提高了更新账本的插入效率。

image1

image3

  • 内置数据表结构：为了满足复杂业务场景下数据类型多样化、业务数据可视化与可分析的需求，智能合约需要支持复杂的表结构数据组织形式。HVM 提供了内置数据结构 HyperTable，支持在合约内部按照表的形式组织业务数据，便于业务数据可视化以及后续的数据分析与价值挖掘。这种结构可以让原Solidity 语言中复杂嵌套的数据操作简单化，同时在性能方面，能有效解决序列化、反序列化造成的性能瓶颈，整体维护成本更低、使用更高效。

image2

  • 内置嵌套Map数据结构：HyperList、HyperMap数据结构都无法满足复杂数据组织结构的需求；HyperTable的表结构拥有严格的层级格式（表-行-列簇-列-值），缺乏在复杂结构下的灵活性（例如：不可只有列，没有列簇）。针对上述问题，HVM推出新型的数据结构——NestedMap，支持用户按需进行灵活的数据组织，并且实现对多层映射数据更高的读写性能。
  1. 虚拟机层

虚拟机层主要是在合约执行过程中，对于合约解析执行的内部操作。为了提高整体的执行效率，HVM设计定制类加载器，类加载缓存提供合约地址到合约类加载器的映射，一个合约类加载器保存合约的字节码和合约类实例，采用最近最少使用淘汰策略（LRU）减少类重复加载带来的开销；指令解析从开始的每次对指令进行解析到将指令做成单例，并进行栈帧复用，大量节省指令执行时间，提高整体执行效率。

HVM优势

  • 支持多级日志

日志在应用开发过程中的作用至关重要，能帮助开发者快速定位和发现问题。由于 EVM 未对出现的异常进行详细定位，给编译调试造成极大的难度。而 HVM 通过内置日志工具类，支持六种日志级别：critical、error、warning、notice、info、debug。可以为每种常见的错误进行合理的提示，方便使用者 对合作操作过程中产生的异常进行debug，方便开发和运维快速定位问题。

  • 分层调用模式

HVM采取分层调用的模式，可以有效降低合约升级的成本。其实现方法主要通过InvokeBean的方式在业务调用层在不更新合约的情况下定义丰富的业务逻辑， 合约层只实现最核心、最基本的原子操作。以转账场景为例，合约层只有增加余额和减少余额的方法，在InvokeBean调用层定义转账的逻辑：如余额是否充足、 减少转让方余额和增加接收方余额。

  • 支持加解密工具

一些业务场景需要在智能合约中进行签名验签逻辑处理，从而进行身份认证，便于进行权限判断或者后续业务的开展。因此 HVM 设计了基于 TEE的加解密工具， 支持在合约中调用存储于 TEE 的公私钥完成签名、验签操作，并支持 ECDSA国标系列、SM 国密系列等多种加解密算法，具有方便友好安全的特性。

  • 支持合约访问控制

合约编码者可以通过智能合约和访问控制策略来限制访问数据的角色和用户，在合约中针对节点、角色、用户定制不同的合约函数访问权限。合约编码者可以在 合约中为一些高权限的函数设置权限控制，使得该函数只能被固定地址的调用者调用，从而实现访问权限控制。

  • 支持合约并行执行

在区块链在并行执行HVM交易时，若采用创建多个HVM实例的方式实现HVM合约并行，将导致多个HVM实例占用大量的内存、每个HVM实例都维护一份合约类加载器缓存，造成资源浪费。对此，我们对HVM进行了优化设计，支持多个合约调用协程在单个HVM实例中并行执行。

EVM

EVM概述

Hyper EVM在合约执行方面，优化执行的内部细节，包括跳转表的初始化逻辑优化、EVM初始化上下文流程优化，减少了内存的频繁分配和对象的创建过程，加快 了EVM初始化速度。同时，HyperEVM会跟随以太坊EVM版本迭代更新，适配最新的以太坊EVM特性。

BVM

BVM概述

BVM全称是 Built-in Virtual Machine ，是用于处理内置合约的虚拟机类型。BVM的出现让开发者自主定义一些内置合约（即是合约代码由开发人员预先写好，在平台启动时直接创建对象加载，无需用户手动部署），提供用户所需的专属功能。具有性能优良、无需（额外）部署、权限灵活等特性。

BVM支持内置的合约

存证类内置合约 描述
存证类内置合约 “SetHash”场景，表示存证场景下文件哈希的存储形式。HashContract中只有两个操作：存和取，对应Set方法和Get方法。
提案类内置合约 包括更改配置和权限管理等事件，如新增节点投票。提案合约提供创建提案、取消提案、提案投票以及执行提案的操作，分别对应Create、Cancel、Vote、Execute方法。 根据提案内容划分可分为配置类、权限类、节点类、合约命名类、合约生命周期管理类和ca模式管理类等。
零知识证明内置合约 用于演示零知识证明+同态隐藏机制下的隐私转账功能，提供的接口包括创建账户、查询余额、隐私转账等。该演示功能限于AMD64平台，请使用GOSDK提供的方法调用相关功能。
账户生命周期管理类内置合约 即证书账户生命周期管理，包含注册证书账户以及弃用证书账户。
证书管理类内置合约 用于保存和节点准入相关的证书和ca证书、以及证书吊销黑名单。对外接口主要提供查询证书是否吊销（CheckCert）、节点证书替换功能（VPCertReplace）、SDK证书冻结（CertFreeze）等。
DID类内置合约 可以设置链的ChainID，当需要使用DID功能之前需要由平台的admin账户对ChainID进行设置，注册的DID账户中的ChainID必须与平台的ChainID一致。
Mpc类内置合约 该功能和可验证计算有关，用于通过MPC方法生成多方共同完成可信设置。
NFT类内置合约 可以派发账户余额，可以由平台的admin账户对任一账户进行账户余额的派发，当平台开启了gas扣费的情况下，每笔交易都需要从交易发起者账户中扣除交易执行所需要的手续费。

BVM优势

  • 性能优良：由于嵌入系统中，所以可以接近原生代码执行速度。
  • 无需部署：无需用户额外部署，可以理解为平台刚启动就被 “部署”在某个固定地址上。
  • 权限灵活：系统安全，不属于任何用户，任何用户都不可以对该合约进行升级或冻结、解冻的相关操作。

Gas机制

gas主要作用是一种合约交易中用来度量执行合约逻辑复杂度的值，并通过限制复杂度大小来进行合约执行环境的停机和提供计费参考。每一笔交易都会包含两个与gas相关的关键信息，分别是gas上限和gas单价，gas上限决定了当前这笔交易所能消耗的gas数量，gas单价指定了当前这笔交易每消耗了一个单位的gas所需要支付的”价格”，即一笔交易所需要支付的交易gas价值 = 交易消耗的gas数量 * gas单价。消耗的gas将被用于激励联盟链的组织者。

每一笔交易需要消耗的gas由智能合约执行时按照占用的CPU、内存和存储资源来动态计算得出。CPU资源体现在虚拟机执行每一个合约逻辑都需要进行指令调用，以操作数栈的形式对数据进行处理；内存资源体现在临时存储数据的局部变量表上的内存大小占用；存储资源则是对于合约状态数据存入账本的磁盘空间占用的消耗。当交易指定的gas上限低于交易执行所消耗的gas时，则将停止当前交易的执行，无论成功与否，交易发起者都需要为交易支付所消耗的gas费。

gas单价决定了当前这笔交易消耗的每一个单位的gas所需要支付的费用，由交易发起者来进行指定。当前区块链将有一个由CAF联盟投票决定的一个最低gas价格标准值，若交易中指定的gas价格低于这个标准值，则将拒绝执行交易。同时在交易打包时，将高gas价格的交易进行优先打包，优先打包的交易将有优先执行权。能力无法凭空产生，gas需由联盟链组织者为普通用户的区块链地址来进行增发，同时规定了对于gas转移的权限，只能由联盟链CAF组织成员来进行gas的增发，普通用户在购买gas后只能用于交易的手续费，无法进行流转。

结合实际场景，如某应用方对接了平台的链服务，用户在该应用上使用了相关链服务（如上链存证、部署合约、NFT购买等），则需要向应用方支付对应的上链服务费（即gas），以完成交易的打包确权（任何一次链上的操作都可理解为一笔交易行为）。而支付的gas则会进入到gas池，应用方可根据相关的激励策略按一定周期分配给联盟节点，共享联盟生态价值，推动联盟更加正向健康发展。