验证引擎设计理念简明解析

在BitXHub跨链体系中，验证引擎是跨链交易中不可缺少的一个重要组成部分。验证引擎主要提供了对跨链交易背书规则合约部署执行，对跨链交易背书验证和内容验证的功能。

本文主要从验证引擎的设计、部署执行流程以及验证规则编写等方面进行介绍。

一、整体设计

验证引擎的整体架构设计如下图所示：

验证引擎的设计采用了验证器的插拔式设计，即对于不同的跨链交易所采用不同的验证规则策略，验证引擎会根据规则地址来判断采用不同的验证器进行验证。现阶段的验证引擎支持Go内置验证器和WASM虚拟机验证器。

第一种验证器是Go内置验证器。这个验证器是为一些常见的区块链和默认规则提供的方便调用的验证器。原生的集成在了BitXHub的中继链中，例如对于常见的Fabric区块链，BitXHub的中继链提供了一个默认的规则地址，用户只要通过注册这个地址的规则就能直接调用默认的Fabric验证规则对跨链交易进行验证了。

第二种验证器是WASM验证器。这个验证器是使用了wasm虚拟机使用这种验证器可以允许用户使用不同类型的语言编写验证规则，比如C，rust或者Go等。同时，wasm本身的运行性能也要高于很多区块链的合约虚拟机，例如evm。用户只需要用自己喜欢的语言编写好验证规则，编译成wasm的字节码就可以部署到中继链上了。

二、部署执行流程

从整体设计我们可以看到验证引擎主要分为两部分，一部分是验证器模块，另一部分是规则管理模块。只有通过规则管理模块部署了验证规则的应用链发送的跨链交易才能够通过验证引擎的验证。

规则管理模块同时也提供了对应用链验证规则的热更新和删除，当用户发现自己应用链的验证规则合约有错误或者应用链的背书规则有升级或者改变时，可以通过规则管理模块向中继链发送系统交易修改验证规则，规则的更新是实时动态的，不会影响中继链的运行。

BitXHub的中继链内置了规则管理的合约，跨链网关通过调用内置合约就可以将自己对应的应用链的验证规则注册到中继链上。如果验证规则调用的是GO内置的验证规则，用户只需要将对应的内置规则的地址注册到中继链即可。如果用户想要定制自己的验证规则，可以先将wasm的字节码部署到中继链上，再将合约地址做一个关联即可让验证引擎在验证阶段对验证规则进行调用了。

验证引擎的另一个部分则是验证器模块的执行层，也是验证引擎最主要的部分。在一笔跨链交易到达中继链之后，验证引擎会先检查交易的顺序是否是正确的，然后通过IBTP的From字段获取来源链的ID，通过这个ID在规则管理模块中得知验证引擎需要哪种类型的验证器来对交易进行校验。如果需要的是WASM验证器，那么验证引擎就会将对应的WASM字节码加载到WASM虚拟机中。

当验证器初始化完毕以后，验证引擎就会将对应应用链的验证者信息和需要验证的交易的IBTP的proof字段和payload字段传入到验证器中。为了防止恶意者进行非法的跨链交易，验证器会对proof字段的背书信息进行签名校验。如果背书的签名信息与事先注册在中继链的应用链的验证者信息相匹配，那么表示背书验证通过，验证引擎会继续进行跨链交易的内容验证，将IBTP的payload字段和proof字段里的内容进行比对。如果两者一致则表示验证通过，那么跨链交易就会被传入到中继链的执行引擎中继续执行并完成跨链交易。如果背书验证或者内容验证有一项不匹配，验证引擎就会返回验证不通过的错误，跨链交易就不会继续执行，并将错误返回给来源链的跨链网关。

三、编写验证规则

下面我们以Fabric1.4为例介绍一下验证规则的逻辑和如何用rust编写WASM验证规则合约。

我们知道Fabric对于智能合约的执行是在背书节点上进行的，每一个背书节点都会模拟执行chaincode，在模拟执行完chaincode之后，背书节点会对模拟的结果和抛出的事件进行封装，之后再进行签名背书。最后将背书结果发送给客户端。客户端在对比模拟执行的结果之后将背书结果发给orderer节点进行排序，最后在提交阶段会抛出chaincode的事件。

在fabric区块链中，对于每一个chaincode都可以指定不同的背书策略，所以对于fabric的验证规则也需要满足复杂背书的要求。所以在应用链注册时上传的验证者信息需要包含背书节点的mspid和对应的证书，需要包含chaincode的id和背书策略的字节码。

那么下面我们来介绍验证规则又是如何使用上述信息对fabric的跨链交易进行的验证的。当跨链交易在fabric这一段上链以后，跨链网关就会将该上链的