fabric智能合约

1.智能合约整体介绍

1)fabric架构

fabric架构分为两个部分,应用层区块链底层

对于应用层来说,fabric提供了基于GRPC协议的API来于区块链进行通讯,并且在API的基础上封装了支持go语言、Java语言、node.js等SDK,方便客户端的调用。由于区块链是分布式的账本,并且交易需要进行共识之后才能够进行上链,那么这样一笔交易从开始到结束,耗时就会很长,客户端很可能没接收到响应就已经超时了,因此传统的同步方式就显得很不合适。

fabric提供提供了一套异步的处理的事件机制来解决这个问题。其实不止fabric,国内许多框架像Facebook、BCOS也有事件监听这一机制。在fabric中,客户端通过注册一个事件,当这个事件完成之后,就会通知客户端完成的结果,客户端此时再进行相应的结果处理,这样就解决同步超时的问题。

fabric底层框架分为三个部分。成员服务(Membership services)。区块链服务(Blockchain services)和链码服务(Chaincode services)。成员服务包括三个组件,登录、注册、身份认证、管理和审计。在一个无权限的区块链中,每个节点都是对等的,都可以随意提交交易到链上。fabric的成员服务通过PKI体系和分布式的技术,把fabric变成了一个带权限的区块链。成员服务一共包含三种证书。分别是用于登录注册的用户证书,交易签名验签的交易证书和加密传输的TLS证书。每笔交易在区块链中都会进行签名认证,只有认证过的交易才能够继续进行下一个流程。

链码服务包含两个组件,安全容器和安全注册组件。fabric提供了一套独立于节点的沙盒机制chaincode容器,方便开发不同语言的链码。chaincode容器和peer容器之间是通过gRPC协议进行通讯的。fabric智能合约是和其他的区块链底层框架不同,其他大多数的区块链底层框架都使用了EVM就是solidity语言,但是fabric现在支持通用语言进行编写智能合约。这一点对于开发者来说降低了很大的学习成本,不用单独去学习solid语言,可以直接使用现有的技能来开发智能合约,然后进行链上的操作。

区块链服务提供了一个分布式账本的平台,包含共识管理、分布式账本、点对点网络和分类存储。fabric的共识机制是可插拔的。fabric共识机制包含Kafka、etcdraft等共识。fabric在1.0版本之前,有用过拜占庭共识,但是在后来的版本中去掉了。官方,是有说在以后的版本中还会推出拜占庭共识。fabric框架与其他区块链框架共识方面不同的地方在于,fabric中的区块是通过独立于节点记账节点的orderer节点来产生的

fabric的链上数据分为两个部分,Blockchain和StateBlockchain就是账本文件,是一系列串联起来的区块,以文件的形式存储在节点中的。这个文件记录了历史区块的交易,不同通道账本存储在不同的文件中。所以它是以物理的方式隔离在不同的文件夹中的,一般都存在于节点的production下目录下。State就是世界状态,记录了账本的最新状态,是以key-value的形式来存储的数据库

fabric中支持levelDB和couchDB这2种非关系型数据库。区块账本文件占用的空间大小是会不断上涨的,因为它记录了区块的历史。但是世界状态就不一定了,世界状态中的数据是可以进行CRUD操作的,就是我们平时操作关系型数据库MySQL里边的创建(Create)、读取(Read)、更新(Update) 和删除(Delete)的操作。那么这也就解释了一个问题,为什么在fabric链码中会有删除的交易,因为它删除的是状态数据库中的数据,而节点账本中的区块是会不断累加的。BSN最近发布了一个商用版本,大家会发现计费中有存储容量这一项,那么BSN是怎么进行应用容量计算的呢?DSN中记录的存储是节点的账本文件所占的磁盘容量和状态数据库DB所占的磁盘容量之和。

接下来我们看一下这个p2p协议。fabric中有两种网络通讯协议,一种是gossip,一种是gRPC。gossip是在一个组织内部通过这个协议来进行报文交流的。在排序节点和锚节点,也就是主节点之间,是通过gRPC来进行通讯的

2)交易流程

接着看一下交易(Transactions)。交易分为两个部分,一部分是部署,一部分是调用。我们可以通过客户端或者SDK来实现交易的发送,部署的交易包含链码安装,链码实例化和链码升级等操作。这幅图展示了fabric的交易流程。一笔交易从产生到记录到区块和账本中,一共分为九个步骤。

第一步是提交交易提案。在提交交易提案之前,我们应该有一个类似enroll的过程,完成之后我们才能对一笔交易进行签名,签名完成之后再把提案发送给背书。背书节点验证完签名并且在本地模拟交易成功以后,会把背书的结果返回给客户端。客户端在收集到足够的背书结果之后,可以把交易发送给order节点进行排序打块儿。出块之后会把出块的结果通过gRPC的协议发送给主节点。主节点验证完交易之后,会把结果记录到本地的账本中,并且在同一组织内向其他节点分发区块,其他节点验证交易完成之后,也会把结果存储到本地的账本中。****。

3)chaincode

  • 简介
  1. Fabric中智能合约又称链码(chaincode),是用计算机语言描述合约条款、交易的条件、交易的业务逻辑等,通过调用链码实现交易的自动执行和对账本数据的操作,是应用程序与底层交互的媒介。换句话说,是一段对业务的描述和一种对数据的约束

  2. 链码在一个独立于peer节点的docker容器中执行,通过grpc与背书节点进行通讯

  3. 一个chaincode的账本是与其他chaincode相互隔离的,不能直接访问,只有在相同网络中的chaincode获取相应的许可以后才能调用其他chaincode来访问其他账本。

  4. 链码支持多种语言编写,包括golang、java、node.js。

chaincode分为两个部分,一部分是chaincode开发,另一部分是chaincode操作开发就是我们要需要编写代码,操作则是部署相关的,像安装链码、实例化链码、升级链码等

  • chaincode开发

chaincode开发可进一步分为系统链码用户链码两种。系统链码是不以单独的docker来运行的,它运行在节点进程中。在1.2以后的版本中,系统链码有三个,LSCC、CSCC和QSCC。LSCC是用来处理生命周期相关的功能,我们部署合约的时候,会有一些链码的操作,像链码安装、链码实例化和链码升级等就是通过调用LSCC来实现的,这个链码和chaincode的部署操作息息相关。CSCC负责处理peer侧chaincode的配置QSCC能够提供账本查询的API,能够通过QSCC来实现区块的查询和交易查询的功能。在1.2版本之前,还有两种系统链码叫ESCC和VSCC。一种是背书系统链码,一种是验证系统链码。

Chaincode包括两种链码(系统链码和用户链码)。

系统链码运行在节点进程中,不以单独的docker运行,包括LSCC、CSCC、QSCC。

  • LSCC:生命周期系统链码(life cycle chaincode),处理生命周期相关的功能
  • CSCC:配置系统链码(configuration system chaincode),处理peer侧channel的配置
  • QSCC:查询系统链码(query system chaincode),提供账本查询API,比如获取区块及交易等

系统链码不用我们用户进行开发,它是fabric需要的一种机制,我们要开发的是用户链码

用户链码都必须实现chaincode接口,链码包含:Init,Invoke两个方法。其中Init方法会在chaincode接收到instantiate或者upgrade交易时被调用,使chaincode执行必要的初始化操作,包括初始化应用的状态。

Invoke方法接收和处理链下业务系统调用事务处理提案,其参数包含调用的链码程序中函数的名称和具体业务处理数据参数,即在Invoke中根据不同的方法参数调用其他分支处理响应的业务,可以简单理解为链码方法的入口

  • chaincode操作

chaincode的操作就是chaincode部署。当chaincode开发完成或者需要升级时,需要进行chaincode部署。chaincode操作贯穿chaincode的整个生命周期,包含打包(package)、安装(install)、实例化(instantiate)、更新(upgrade)、停止和启动(stop and start)。在安装并实例化成功chaincode之后,就可以调用chaincode中的方法与账本进行交互。

官方并没有实现停止和启动这两个生命周期,那我们的停止操作需要怎么做呢?官方建议是,我们可以通过移除chaincode容器和每个背书节点,删除安装包来停止容器。具体的操作就是通过docker的命令来删除所有主机或者虚拟机上peer节点进行启动的chaincode容器,随后从每个背书节点删除掉安装包就可以了。

2.智能合约开发

1)使用Java开发智能合约

Java语言的链码需要两部分内容,一部分是构建工具,另一部分就是我们写的业务链代码

Java链码支持两种构建工具gradle和maven。两种构建工具都需要如下三个步骤:

  • 添加插件:遮蔽方式的FatJar
  • 指定mainClass路径
  • 添加fabric-chaincode相关依赖

添加的插件叫FatJar,是把所有的依赖包都打包到一个jar中。 FatJar有三种打包方式,分别是非遮蔽方式(Unshaded)、遮蔽方式(Shaded)和嵌套方式(Jar of Jars)。非遮蔽方式对于是相对于遮蔽方式来说的,非遮蔽方法会把所有的包里的文件都加到一个目录里,然后再打包到同一个jar包中,但是这种情况对于复杂应用可能会碰到同名类相互嵌套的问题。嵌套方法就是在jar包里嵌套其他的jar包,这个方法可以避免同名包名覆盖的问题,但是这个方法不被JVM来支持,原生不支持,因为JDK提供的class loader仅支持装载嵌套包嵌套包的class文件。遮蔽方法会把依赖包中的类路径修改到某个组路径下,这样就可以在一定程度上避免同名类相互遮蔽、相互覆盖的问题,最终发布的jar也不会带入依赖冲突问题给下游

添加完这个依赖后,在chaincode的实例化或者更新的过程中,会将这个chaincode打包为一个包含所有依赖的jar。然后fabric通过这个all in one的jar来启动一个独立于peer之外的容器。刚刚我们提到过fabric用户链码是独立于peer存在的,然后系统链码是运行在节点进程中的。

Java chaincode常用方法

2)使用go语言开发智能合约

  • 依赖包
  • “github.com/hyperledger/fabric/core/chaincode/shim”
  • “github.com/hyperledger/fabric/protos/peer”

shim 包为链码提供了 API 用来访问/操作数据状态、事务上下文和调用其他链代码;

peer 包提供了链码执行后的响应信息;

shim.ChaincodeStubInterface提供的方法来读取和修改账本的状态;

peer.Response:封装的响应信息

  • chaicode接口
  1. 参数解析:将传过来的一些参数信息进行一些解析
  2. 链码互操作:调用不同的智能合约
  3. 状态操作:提供了一些对数据库状态的操作,比如增加、删除、修改、查询
  4. 链码事件:提供了一些事件的注册
  5. 交易信息:交易信息获取,比如获取chainID
  6. 其他

go chaincode常用方法

3.开发建议

链码的执行是一个分布式的系统,在多个节点隔离执行,也就是说同一笔交易在整个区块链网络中,会对该交易执行很多次,执行的次数取决于背书的策略的选择,比如说选择这条链上的所有节点都要执行,也可以选择某一个组织的某一个节点上执行。这样有一个结果就是,不管选用哪种方式,它最终执行的结果都必须是相同的。因为客户端会去比较,从不同节点去做模拟交易的结果如果不一样的话,这笔交易就不会给排序节点发送,这样的话,这笔交易就算失败。

那哪些情况会导致这种执行结果不一致呢?一是不稳定的外部依赖,二是随机函数,三是系统的时间。就比如说你要用到外部的一些第三方依赖,可能它不太稳定,或者说这个节点它就不能和外网进行联通,这样的话就会有一些问题,它就是执行不成功。随机函数就更好理解了,如果你选择的是在这条链上的所有节点都要达成共识的话,它在每一个节点上执行的时候,它的随机函数产生的结果肯定都不会不一致,这样的话也是不行的。还有一个就是系统的时间,各个节点,如果节点多的话,它的时间有可能就会存在一些差别,这样的话它提交交易的时候也是不会成功的。

链码编写禁忌:

  • 不稳定的外部依赖
  • 随机函数
  • 系统时间

下面就是介绍一下我们在开发过程中的一些建议。一是必须要校验所有链码方法的参数信息,你比如说要校验参数的个数,另外一个比如说要含一个用户信息,比如说用户的名称,用户名,比如说他对应的一些性别啊,这些信息做一些必要校验,比如说有些是可以为空的话,就无需校验,但是有些它的类型数据是否为空,这些都需要做一些校验。二是不要在init方法中做大量的数据化初始操作,因为在链码的实例化或者升级的过程中只调用一次它,如果初始化大量的数据的话,可能会超时或者失败,直接就提交不成功。三是引用了第三方包的话,需要使用vendor管理第三方引用的一些包,如果不使用这个管理,把这些包也打上去的话,在去合约部署的时候,可能会要去下载这些第三方包,这样的话可能下载不下来,或者是什么原因也会导致他部署失败。四是必须在根目录打成zip包。

链码编写规范:

  • 校验所有链码方法参数信息
  • 不要在Init方法中大量初始化数据
  • 需要使用govendor管理引用第三方包
  • 发布服务时,链码包打包时进入项目根目录进行打包,格式为.zip

然后还有一些就是在那个合约的开发过程中需要的一些注意的地方,K值的定义就是。所有的业务系统里边的数据都存在一个数据库中,并且以KY6的形式存储,可能存在就是说不同业务的K值是相同的情况,这样的话就是后者去提交,会把前者的信息给覆盖掉。然后是有一个什么解决方案,就是用不同的业务。来给他加个前缀,然后来作为他的一些K。你比如说用户信息和角色信息,这个是很常用的一些信息,然后它的标识可能会存在是相同的。如果直接用他的标识来存,用作为他的K来存储的话,就会有一些,比如说你用户叫001。然后角色K对应的K值也是001,这样的话它就会存储角色的,角色的话它会把用户信息给覆盖掉。这样的话就是在不同的业务上加上它对应的一些标识,作为他的前缀。比如说用户。就叫USER001,然后角色就叫肉001,这样的话就会避免这些问题。还有一个就是根据配置进行模糊查询的时候。这个跟咱们那个传统数据库里边的那些查询是一样的。比如说这两个。表达式就是执行的查询的语句。前者。这个就是查询的,就是包含了所有K中包含user的一些数据。然后以及前面加个监控号,这种的话,它就是只查询已优的开头的数据。还有一些是需要注意的,就是一些特殊符号需要去做一些转译,比如说英文的小括号。中括号,大括号点,还有那种斜杠,反斜杠都要去做一些转移。第三个呢,说一下那个关于索引的创建。传统的话就是合约的话就是创建数据库,创建索引的话有四种方式,第一种就是命令行,然后直接敲命令,然后去执行,去创建。第二个就是CDB中的话,就是在数据库的这个页面上去做一些。页面上可以看到的一些操作添加。然后还有就是通过HTTP发送,方法为get或者body为杰森格式的包文。然后第四个就是放置在合约中链

链码开发的注意事项:

  • 关于key的定义

    • 描述:所有业务数据都存在与一个数据库中,并存储方式是以key-value的形式存储,可能存在不同业务的key值相同的情况,后者保存会覆盖前者信息。
    • 解决方案:在不同的业务key值添加前缀
    • 示例:用户和角色他们的标识相同,如果以标识作为key存储时,后者保存会覆盖前者信息;但是如果用户:user_用户标识,角色:role_角色标识,这样存储就会避免这个问题
  • 关于根据key值模糊查询

    • 描述:根据key查询同一个业务数据时

    • 解决方案:查询语句使用正则表达式进行查询的

      {“_id”:{“$regex”:“user_.*”}检索key中只要含有"user"的数据

      {“id":{“$regex”:"^user.*”}检索key以"user"开头的数据

    • 注意:
      正则表达式:特殊符号转义

  • 关于浮点数计算

  • 关于链码索引

    • 创建索引的4种方式

      • 命令行

      • couchdb web交互页面点击"All Documents"右边的加号

      • http发送方法为get、body为json格式的报文

      • 放置在链码中在链码安装更新的时候创建

    • 在main.go的同级目录下创建文件META-INFstatedbcouchdbindexes在该indexes目录下创建.json文件,文件名随便定,文件个数没有限制。

      编辑该json文件,格式如下:
      {“index”:{“fields”:[“fileld”]},“ddoc”:“fileldodex”,“name”:“fileld-json-index”,type":“json”}

    • 在fabric环境中安装链码。此时couchdb数据库中已经添加了刚刚的索引区块,可以成功执行排序语句

  • 关于跨链调用(InvokeChaincode)

    • 由于链码名称和channel名称事先未知,跨链调用时尽量将这些作为函数参数传入链码
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>