HyperLeger Fabric开发(六)——HyperLeger Fabric智能合约(链码)

HyperLeger Fabric开发(六)——HyperLeger Fabric智能合约(ChainCode)

一、链码(Chaincode)简介

1、链码简介

在Fabric中,智能合约也称为链码(chaincode),分为用户链码和系统链码。系统链码用来实现系统层面的功能,包括系统的配置,用户链码的部署、升级,用户交易的签名和验证策略等;用户链码用于实现用户的应用功能,开发者编写链码应用程序并将其部署到区块链网络上,终端用户通过与网络节点交互的客户端应用程序调用链码。
链码被编译成一个独立的应用程序,运行于隔离的Docker容器中,在链码部署的时候会自动生成链码的Docker镜像。
链码是访问账本的基本方法,一般是用Go等高级语言编写的、实现规定接口的代码。上层应用可以通过调用链码来初始化和管理账本的状态。只要有适当的权限,链码之间也可以互相调用。
链码(Chaincode)是一段由Go语言编写(支持其它编程语言,如Java,NodeJS)并能实现预定义接口的程序。链码运行在一个受保护的Docker容器当中,与背书节点的运行互相隔离。链码可通过客户端提交的交易对账本状态初始化并进行管理。
链码通常处理由网络中的成员一致认可的业务逻辑。链码创建的(账本)状态是与其它链码互相隔离的,因而不能被其它链码直接访问。如果在相同的Fabric网络中,链码在获取相应许可后可以调用其它链码来访问它的账本。
链码被部署在Fabric网络节点上,运行在Docker容器中,并通过gRPC协议与相应的Peer节点进行交互,以操作分布式账本中的数据。

2、链码的背书策略

背书策略是背书节点如何决策交易是否合法的条件。链码实例化时可指定背书策略,当记账节点接收到交易时,会获知相关链码信息,然后检查链码的背书策略,判断交易是否满足背书策略,若满足则标注交易为合法。
背书策略可分为主体Principal(P)和阈值Threshold(T)两部分,具体如下:
A、Principal指定由哪些成员进行背书。
B、Threshold接受两个输入,分别为阈值T和若干个P的集合n,只要交易中包含了n中t个成员的背书则认为交易合法。
背书策略可以指定某几个组织内的任意成员身份进行背书,或者要求至少有一个管理员身份进行背书等等。
T(1, ‘A’, ‘B’) 则需要A,B中任意成员背书。
T(1, ‘A’, T(2, ‘B’, ‘C’))则需要A成员背书或B,C成员同时背书。
目前客户端已经实现对背书策略的支持,可以通过-P来指定背书策略,结合AND、OR来组合成员,完成成员身份(admin、member)的集合。
-P OR ( ‘Org1.admin‘ , AND (‘Org2.member‘ , ‘Org3.member‘) )
上述背书策略指定要么Org1的admin进行背书,或者Org2和Org3的成员同时进行背书,才满足背书策略。

3、系统链码

系统链码与用户链码有相同的编程模型,但系统链码运行在Peer节点,用户链码则在隔离的容器中运行。因此,系统链码内置为Peer节点的可执行文件中,不遵循用户链码的生命周期,安装、实例化、升级不适用于系统链码。
系统链码用于减少Peer节点与用户链码进行gRPC通信的开销,同时权衡管理的灵活性。系统链码只能通过Peer节点的二进制文件升级,必须通过一组固定的参数进行注册,但不具有背书策略。
?Hyperledger Fabric系统链码实现了一系列系统功能,以便系统集成人员能够根据需求对其进行修改与替换。
常见系统链码如下:
生命周期系统链码(LSCC?):处理生命周期管理。
配置系统链码(CSCC):处理在Peer节点上的通道配置。
查询系统链码(QSCC):提供账本的查询API,例如获取区块以及交易。
背书系统链码(ESCC):通过对交易提案响应进行签名来处理背书过程。
验证系统链码(VSCC):处理交易验证,包括检查背书策略以及多进程并发控制。
在修改或者替换系统链码(LSCC、ESCC、VSCC)时必须注意,因为系统链码在主交易执行的路径中。VSCC在将区块提交至账本前,所有在通道的Peer节点会计算相同的验证以避免账本分歧(不确定性)。如果VSCC被改变或者替换,需要特别小心。

二、链码功能

Peer节点主要功能是调用链码执行交易和记账,其中交易执行由背书节点的链码负责,记账功能由记账节点负责。

链码与Peer节点的交互过程如下:
A、链码通过gRPC与Peer节点交互,当Peer节点收到客户端的交易提案请求后,会发送一个链码消息对象(包含交易提案信息、调用者信息)给对应的链码。
B、链码调用Invoke方法,通过发送获取数据(GetState)和写入数据(PutState)消息,向Peer节点获取账本状态信息和发送预提交状态。
C、链码发送模拟执行结果给Peer节点,Peer节点对交易提案和模拟执行结果进行背书签名。

三、链码管理

1、链码生命周期

Fabric提供了 package,install,instantiate和upgrade 4个命令管理链码生命周期。

通过install安装链码,通过instantiate实例化链码,然后可以通过invoke、query调用链码和查询链码。
如果需要升级链码,则需要先install安装新版本的链码,通过upgrade升级链码。
在install安装链码前,可以通过package打包并签名生成打包文件,然后在通过install安装。
链码在成功install以及instantiate后,链码处于运行状态,能够通过Invoke方法来处理交易,后续能够对链码进行升级。
Hyperledger Fabric API允许与区块链网络中的各个节点(Peer,Order,MSP)进行交互,同时也允许在背书节点上package、install、instantiate以及upgrade链码。CLI可以直接访问Hyperledger Fabric API。
Hyperledger Fabric SDK抽象了Hyperledger Fabric API的细节,以辅助应用程序开发,当然也能用于管理链码生命周期。

2、打包链码

链码包由三个部分组成:
A、由ChaincodeDeploymentSpec(CDS)格式定义的链码。CDS根据代码及其它属性(如名称与版本)定义链码包;
B、一个可选的实例化策略,能够被用作背书的策略进行描述;
C、拥有链码的实体的一组签名。
其中,链码的签名主要目的如下:
A、建立链码的所有权;
B、允许验证链码包中的内容;
C、允许检测链码包是否被篡改。
通道上的链码的实例化交易的创建者能够被链码的实例化策略验证。
链码打包的方法由两种,一种是打包被多个所有者所拥有的链码,需要初始化创建一个被签名的链码包(SignedCDS),然后将其按顺序的传递给其它所有者进行签名;一种是打包单个所有者持有的链码。
创建一个被签名的链码包的命令如下:
peer chaincode package -n sacc -p chaincodedev/chaincode/sacc -v 0 -s -S -i "AND(‘OrgA.admin‘)" ccpack.out
-s选项创建一个能被多个所有者签名的链码包,而不是简单的创建一个原始的CDS。一旦-s被指定,如果其它所有者想要签名CDS,则-S选项必须被指定。否则,将会创建一个SignedCDS,除CDS外仅仅包括实例化策略。
-S选项使用被在core.yaml文件中定义的localMspid属性的值标识的MSP对链码包进行签名。
-S选项是可选的。如果创建了一个没有签名的链码包,不能被其它所有者使用signpackage命令进行签名。
-i选项是可选的,允许为链码指定实例化策略。实例化策略与背书策略有相同的格式,指定哪些身份能够实例化链码。本例中仅OrgA的admin能够实例化链码。如果没有实例化策略被指定,将会使用默认的策略,仅允许拥有Peer的MSP的管理员身份实例化链码。

3、签名链码

在创建阶段就被签名的链码包能够交给其它所有者进行检查与签名,支持带外对链码进行签名。
?ChaincodeDeploymentSpec可以选择由所有者集合进行签名,从而创建一个SignedChaincodeDeploymentSpec(SignedCDS)。SignedCDS包括3个部分:
A、CDS包括源代码,链码的名称与版本号;
B、链码的实例化策略,表示为背书策略;
C、链码所有者的列表,由背书策略定义。
当在某些通道上实例化链码时,背书策略是在带外确定的,用于提供合适的MSP主体。如果没指定实例化策略,则默认的策略就是通道的任何MSP管理员。
每一个链码的所有者通过将SignedCDS与链码所有者的身份(例如证书)组合并签署组合结果来背书ChaincodeDeploymentSpec。
一个链码的所有者能够对自己所创建的签名过的链码包进行签名,需要使用如下命令:
peer chaincode signpackage ccpack.out signedccpack.out
ccpack.out、signedccpack.out分别是输入与输出包。signedccpack.out包括一个对链码包附加的签名(通过local msp进行的签名)。

4、安装链码

安装交易将链码的源代码打包成ChaincodeDeploymentSpec(CDS)的规定的格式,然后安装到通道中的背书节点上。
当安装的链码包只包含一个ChaincodeDeploymentSpec时,将使用默认初始化策略并包括一个空的所有者列表。
链码应该仅仅被安装在链码所有者成员的背书节点上,用于实现链码对于网络中其它成员在逻辑上是隔离的。没有链码的Peer节点,不能成为链码交易的背书者,不能执行链码,但作为记账节点仍然能够验证与提交交易到账本上。
安装链码会发送一个SignedProposal到生命周期系统链码(LSCC) 。
使用CLI安装sacc链码的命令如下:
peer chaincode install -n sacc -v 1.0 -p sacc
-n选项指定链码实例名称
-v选项指定链码的版本
-p选项指定链码所在路径,必须在GOPATH路径下
CLI内部创建sacc的SignedChaincodeDeploymentSpec,然后将其发送给本地Peer节点,Peer节点会调用LSCC上的安装方法。为了在Peer节点上安装链码,SignedProposal的签名必须来自于Peer节点的本地MSP管理员之一。

5、实例化链码

实例化调用生命周期系统链码(LSCC)用于创建及初始化通道上的链码。链码能够被绑定到任意数量的通道,以及在每个通道上单独的操作。无论链码安装及实例化到多少个通道上,每个通道的状态都是隔离的。
实例化的创建者必须满足包含在SignedCDS内链码的实例化策略,而且还必须是通道的写入器(作为通道创建的一部分被配置)。可以防止部署链码的流氓实体或者欺骗者在未被绑定的通道上执行链码。
默认的实例化策略是任意的通道MSP的管理员,因此链码实例化交易的创建者必须是通道管理员之一。当交易提案到达背书节点后,背书节点会根据实例化策略验证创建者的签名。在提交实例化交易到账本前,在交易验证时再一次完成该操作。
实例化交易同样设置了通道上的链码的背书策略 。背书策略描述了交易被通道上成员接受的认证要求。
使用CLI去实例化sacc的链码并初始化状态为user1与0,命令如下:
peer chaincode instantiate -n sacc -v 1.0 -c ‘{"Args":["user1","0"]}‘ -P "OR (‘Org1.member‘,‘Org2.member‘)"
-n选项指定链码实例名称
-v选项指定链码的版本
-c 选项指定链码的调用参数
-P选项指定链码的背书策略
背书策略表示,org1.member或者org2.member必须对调用使用sacc的交易进行签名,以保障交易是有效的。在成功实例化后,通道的链码进入激活状态,可以处理任意的交易提案。交易到达背书节点时,会同时被处理。

6、调用链码

调用链码:
peer chaincode invoke -o orderer.example.com:7050 --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA -C mychannel -n sacc -c ‘{"Args":["invoke","user1","user2","10"]}‘
查询链码
peer chaincode query -C mychannel -n sacc -c ‘{"Args":["query","user1"]}‘

7、升级链码

链码的升级通过改变其版本号(作为SignedCDS的一部分)。SignedCDS另外的部分,如所有者及实例化策略都是可选的。然而,链码的名称必须是一致的,否则会被当做另外一个新的链码。
在升级前,必须将新版本的链码安装到有需求的背书节点上。升级也是一种交易,会把新版本的链码绑定到通道中。升级只能在一个时间点对一个通道产生影响,其它通道仍然运行旧版本的链码。
由于可能存在多个版本的链码同时存在,升级过程不会自动删除老版本俩马,用户必须手动操作删除过程。
升级与实例化transaction有一点不同的是:通过现有的chaincode实例化策略检查升级transaction,而不是用新的策略检查。这是为了确保只有当前实例化策略中指定的成员能够升级chaincode。
在升级期间,链码的Init函数也会被调用,执行有关升级的数据或者使用数据重新进行初始化,在升级链码的期间避免对状态进行重置。
安装新版本的链码
peer chaincode install -n sacc -v 1 -p path/to/my/chaincode/v1
upgrade升级链码
peer chaincode upgrade -n sacc -v 1 -c ‘{"Args":["d", "e", "f"]}‘ -C mychannel

原文地址:http://blog.51cto.com/9291927/2318325

时间: 2024-11-06 07:29:44

HyperLeger Fabric开发(六)——HyperLeger Fabric智能合约(链码)的相关文章

fabric 环境搭建 和 部署 智能合约 - (实习第二天)

首先安装docker,安装的时候有坑,坑就是资料没找对. 这篇博客的意义就是没有坑安装好,部署好. 我用的是 Ubuntu 18.04 安装Docker-ce,这下面的安装方式就是菜鸟教程的,可以去哪看. 1.更换国内软件源,推荐中国科技大学的源,稳定速度快(可选) sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak sudo sed -i 's/archive.ubuntu.com/mirrors.ustc.edu.cn/g' /et

solidity编程开发语言——以太坊智能合约利器

这篇关于Solidity教程的博客展示了很多Solidity特性.本教程假定你对以太坊虚拟机和编程有一定的了解. 以太坊,"世界计算机"提供了一个非常强大的全球共享基础设施,使用名为Solidity的编程语言构建去中心化应用程序. 让我们开始我们的Solidity教程,介绍Solidity. 什么是Solidity? 以太坊Solidity是一种面向智能合约的高级语言,其语法与JavaScript类似.solidity是用于生成在EVM上执行的机器级代码的工具.solidity编译器获

win7下以太坊基于truffle+ganache开发环境搭建以及智能合约的部署调用

上一篇介绍的是以太坊下基于geth+remix-ide智能合约环境的搭建和部署运行,本篇介绍的是基于truffle+ganache. ganache相当于是geth的图形化操作界面,相对于纯指令操作的geth较为简单易上手,并且运行交易和生成区块的过程一目了然. [前期准备] 1.Node.js安装(这一点在上一篇文章中提到过,所以此处不做展示) 2.指令输入: npm install -g solc(安装智能合约) npm install -g ganache-cli (安装ganache开发

以太坊智能合约开发工具 Truffle 最佳入门指导1

Truffle是以太坊(Ethereum)智能合约开发的瑞士军刀,小巧好用,上手简单. 本篇文章主要展示如何用Truffle 开发第一个Ethereum智能合约. 1.准备工作:(本人针对window环境,如果是mac 或linux可以自行搜索其他教程) a.安装git bash :http://gitforwindows.org/ b.安装npm:https://jingyan.baidu.com/article/a17d528506d7f58098c8f2b0.html 2.安装Truffl

什么是以太坊?什么是智能合约?

以太坊是一个分布式的计算平台.它会生成一个名为Ether的加密货币.程序员可以在以太坊区块链上写下"智能合约",这些以太坊智能合约会根据代码自动执行. 以太坊是什么? 以太坊经常与比特币相提并论,但情况却有所不同.比特币是一种加密货币和分布式支付网络,允许比特币在用户之间转移. 相关:什么是比特币?它是如何工作的? 以太坊项目有更大的目标.正如Ethereum网站所说,"以太坊是一个运行智能合约的分布式平台".这些智能合约运行在"以太坊虚拟机"上

第一行代码:以太坊(3)-使用更多的工具编写和测试智能合约

<第一行代码:以太坊>开始连载了 在上文中已经使用了Remix环境运行和测试了本书编写的第一个智能合约程序,不过编写和测试智能合约的测试方式很多,例如,在testrpc环境测试:在Intellij IDEA集成开发环境中用Solidity语言编写智能合约:在纯Web环境中测试智能合约:使用AJAX方式测试智能合约等.本文将详细介绍这些用于编写和测试智能合约的方法. 1.安装本地remix环境(Windows.Mac OS X和Linux) 在本节使用Remix环境运行和测试了Calc智能合约,

HyperLeger Fabric开发(一)——HyperLeger简介

HyperLeger Fabric开发(一)--HyperLeger简介 一.HyperLeger简介 1.HyperLeger简介 Hyperledger(超级账本)是Linux基金会于2015年发起的推进区块链数字技术和交易验证的开源项目,目标是让成员共同合作,共建开放平台,满足来自多个不同行业各种用户案例,并简化业务流程.由于点对点网络的特性,分布式账本技术是完全共享.透明和去中心化的,故非常适合于在金融行业的应用,以及其它的例如制造.银行.保险.物联网等行业.通过创建分布式账本的公开标准

HyperLeger Fabric开发(三)——HyperLeger Fabric架构

HyperLeger Fabric开发(三)--HyperLeger Fabric架构 一.HyperLeger Fabric架构简介 1.通道简介 商业应用的一个重要的需求是私密×××易,为此Fabric设计了通道(Channel)来提供成员之间的隐私保护.通道是部分网络成员之间拥有独立的通信渠道,在通道中发送的交易只有属于通道的成员才可见,因此通道可以看作是Fabric的网络中部分成员的私有通信子网.通道由排序服务管理.在创建通道的时候,需要定义通道的成员和组织.锚节点(anchor pee

HyperLeger Fabric开发(五)——HyperLeger Fabric账本存储

HyperLeger Fabric开发(五)--HyperLeger Fabric账本存储 一.HyperLeger Fabric账本简介 Fabric里的数据以分布式账本的形式存储.账本由一系列有顺序和防篡改的记录组成,记录包含着数据的全部状态改变.账本中的数据项以键值对的形式存放,账本中所有的键值对构成了账本的状态,也称为世界状态(World State).?每个通道中有唯一的账本,由通道中所有成员共同维护着账本,每个记账节点上都保存了所属通道的账本的一个副本,因而是分布式账本.对账本的访问