欢迎来到电子游戏英语!

一文读懂验证引擎的设计理念 | BTC

财富热线+86 0000 8888
一文读懂验证引擎的设计理念 | BTC
浏览:193 发布日期:2020-06-27

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

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

 

  一、整体设计  

 

 

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

对于WASM规则,我们可以通过rust来编写验证规则,中继链中的WASM虚拟机要求规则的字节码符合wasi标准,所以BitXHub提供了rust编写WASM合约规则的模板。验证的入口函数为start_verify,而对于比较麻烦的wasm的输入输出BitXHub已经提供了一套读写方案,用户只需要在contract.rs文件中编写自己所想要验证的内容即可,非常便捷易用。

验证引擎的另一个部分是验证器模块的执行层,也是验证引擎最主要的部分,下图是验证引擎执行的主要流程图:

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

从整体设计我们可以看到验证引擎主要分为两部分,一部分是验证器模块,另一部分是规则管理模块。只有通过规则管理模块部署了验证规则的应用链发送的跨链交易才能够通过验证引擎的验证。如果没有部署验证规则,电子游戏英语代理那么当一笔跨链交易传入中继链并进入到验证引擎后,验证引擎会因为无法找到对应的验证规则而返回验证失败。所以整个流程的第一步就是对验证规则的部署。

BitXHub跨链体系中,验证引擎是跨链交易中不可缺少的一个重要组成部分。验证引擎主要提供了对跨链交易背书规则合约部署执行,对跨链交易背书验证和内容验证的功能。本文主要从验证引擎的设计、部署执行流程以及验证规则编写等方面进行介绍。

BitXHub验证引擎解决了在跨链场景中一直所被关心的跨链交易如何保证内容的正确性和交易的有效性问题,而可定制插拔的验证规则机制也使得不同类型的区块链交易内容和有效性的验证成为了可能。

  三、编写验证规则  

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

本文作者:趣链科技数据网格实验室

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

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

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

  二、 部署执行流程  

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

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

那么下面我们来介绍验证规则又是如何使用上述信息对fabric的跨链交易进行的验证的。当跨链交易在fabric这一段上链以后,跨链网关就会将该上链的信息封装成IBTP协议发送到中继链,此时封装在IBTP的proof字段已经包含了fabric交易中的ChaincodeActionPayload信息。当交易进入到验证引擎时,验证引擎会初始化wasm验证器,同时将IBTP的proof字段和payload字段连同验证者信息传入到验证器中。验证器开始进行验证。首先会查看交易信息中的chaincode的ID和验证者信息中预留的是否一致,以防有恶意者伪造假的chaincode进行交易,然后开始通过预留的复杂背书策略的字节码初始化fabric中的策略验证器,策略验证其可以将交易信息中的背书数组和预留的背书节点信息进行关联验证,查看背书数组签名的正确性和是否符合策略。当背书数组被确定是正确的以后,验证引擎还会对交易的具体内容进行比对,防止恶意者修改了IBTP中payload的信息。当各个步骤的验证通过后,验证引擎就能够确认该笔fabric的跨链交易是有效的。

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