【翻译】Hyperledger Fabric v1.1 中的系统链码
2020/4/26 15:33:40
本文主要是介绍【翻译】Hyperledger Fabric v1.1 中的系统链码,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
Hyperledger Fabric 交易流
Hyperledger Fabric v1.1提供了几个特殊的链码来执行某些特殊的任务,这些链码被称为系统链码 (System Chaincode)。本文的目的是简述这些链码的实现、功能和用法。与用户链码类似,系统链码也实现了 Init() 和 Invoke() 方法。Fabric中一共有五种合约:
下面,将对每个系统链码的功能以及使用进行阐述。值得注意的是,因为我们可能需要传输golang结构体的序列化的protobuf bytes,用命令行(CLI)进行简单的invoke/query可能不能使用系统链码的提供的全部功能。因此,推荐使用SDK进行执行这些功能。在本文中,仅通过CLI执行invoke/query操作演示系统链码的部分功能。
1. Configuration System Chaincode (CSCC)
CSCC 管理peer上通道相关的信息以及执行通道配置交易。它提供五个方法:(i) JoinChain, (ii) GetConfigBlock, (iii) GetConfigTree, (iv) SimulateConfigTreeUpdate, (v) GetChannels。
下面将介绍这些功能的使用。所有的命令都是在sample network (参考setup)中的指向peer0的客户端中执行的。为了运行CSCC相关的命令,我们需要在CLI命令中使用peer channel和peer chaincode。
JoinChain 方法用来使一个peer加入通道。它需要一个参数,即通道配置区块的序列化的protobuf bytes,其中通道配置区块作为peer channel create命令的返回从orderer获取。下面的CLI命令使peer加入名为ch1的通道。在调用CSCC时,peer channel join命令负责读取ch1.block并把它以bytes的形式传入。但是,如果我们直接使用peer chaincode invoke来调用JoinChain方法,将ch1.block的内容放入CLI请求是比较困难的。
$ peer channel join -b ch1.block
GetConfigBlock 方法用于获取给定通道的当前的配置区块。它需要一个参数,即通道名字的byte形式。如下的两条CLI命令都可以用于获取通道mychannel的配置区块。
$ peer chaincode query -C "mychannel" -n cscc -c '{"Args":["GetConfigBlock", "mychannel"]}'
或
peer channel fetch -o orderer0:7050 config -c mychannel
GetChannels方法用于获取peer目前所加入的通道。如下的两条CLI命令都可以用于获取所有的通道。
$ peer chaincode query -C "" -n cscc -c '{"Args":["GetChannels"]}'
或
$ peer channel list
GetConfigTree和SimulateConfigTreeUpdate用于获取config结构和模拟执行config结构更新。如果要从一个通道添加或移除组织,必须获取config tree来进行修改,并在调用SimulateConfigTree方法时,必须获取CSCC的背书。
2. Life Cycle System Chaincode (LSCC)
LSCC 用于管理链码的生命周期——在peer上安装、在通道上部署和升级、用户从运行中的链码获取信息。它提供了八个方法:(i) install, (ii) deploy, (iii) upgrade, (iv) getid, (v) getdepspec, (vi) getccdata, (vii) getchaincodes, (viii) getinstalledchaincodes。
install方法用于存储chaincode程序到peer的文件系统(/var/hyperledger/production/chaincodes)。它需要一个参数,即chaincode deployment spec (core/common/ccprovider/cdspackage.go)的序列化protobuf bytes。尽管我们可以通过传入整个chaincode的内容来直接调用LSCC,但更好的做法是使用peer chaincode install命令,这个命令在其将通过读取chaincode的内容对LSCC进行调用。
$ peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
deploy方法用于在给定的通道上实例化合约。它可以接受五个参数,前两个参数——通道的名字和chaincode deployment spec是必须的,其他是那个参数——背书策略、背书系统合约的名字和验证系统合约的名字是可选的。
$ peer chaincode instantiate -o orderer0:7050 -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR ('Org1MSP', 'Org2MSP')"
getdepspec方法用于获取安装在peer上的合约的chaincode deployment spec。下面的CLI命令将从通道mychannel中获取mycc合约的deployment spec。
$ peer chaincode query -C mychannel -n lscc -c '{"Args":["getdepspec", "mychannel", "mychannel"]}'
getchaincodes方法用于获取在部署在通道上的合约的列表。如下CLI命令从通道mychannel上获取实例化的合约列表。
$ peer chaincode query -C mychannel -n lscc -c '{"Args":["getchaincodes"]}'
getinstalledchaincodes方法用于获取在peer上安装的合约的列表。
$ peer chaincode query -C "" -n lscc -c '{"Args":["getinstalledchaincodes"]}'
upgrade方法用于升级合约。
$ peer chaincode upgrade -o orderer0:7050 -C mychannel -n mycc -v 2.0 -c '{"Args":["reinit"]}' -P "OR ('Org1MSP', 'Org2MSP')"
getid用于获取合约的id
$ peer chaincode query -C mychannel -n lscc -c '{"Args":["getid","mychannel","mycc"]}'
getccdata用于获取合约的数据。
$ peer chaincode query -C mychannel -n lscc -c '{"Args":["getccdata","mychannel","mycc"]}'
3. Query System Chaincode (QSCC)
QSCC 将特定的方法暴露给用户,使得用户可以查询在block storage中存储的区块和交易。它提供五个方法:(i) GetChainInfo, (ii) GetBlockByNumber, (iii) GetBlockByHash, (iv) GetTransactionByID, (v) GetBlockByTxID。
GetBlockByNumber方法用于获取序列化的区块。下面的CLI命令从通道mychannel中获取序号为3的区块。
$ peer chaincode query -C mychannel -n qscc -c '{"Args":["GetBlockByNumber", "mychannel", "3"]}'
其他方法类似。
4. Endorser System Chaincode (ESCC)
ESCC 被背书节点(core/endorser/endorser.go)调用。背书节点在执行交易之后,将它的前面放在transaction response message中。其中,transaction response message也包括交集执行的结果,如交易状态、合约事件和read/write set等。一个调用功能可以包含5-7个参数,即Header、ChaincodeProposalPayload、ChaincodeID、Response、simulation result、events、payload visibility。
作者:John_Xuxu
链接:https://www.jianshu.com/p/92e92dae8a73
这篇关于【翻译】Hyperledger Fabric v1.1 中的系统链码的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-11-25我们抛弃了Kubernetes!来看看为什么以及我们现在用什么
- 2024-11-25使用Kubernetes部署.NET微服务:产品与订单服务的策略探讨
- 2024-11-25亚马逊EKS集群的ETCD监控与告警设置——利用Container Insights
- 2024-11-25Kustomize与Helm大比拼:哪个更适合你的Kubernetes部署?
- 2024-11-16轻巧的Kubernetes与WebAssembly的完美搭档
- 2024-11-16基于AWS的Java应用持续集成与持续部署全流程指南:从构建到部署在Amazon EKS上运行
- 2024-11-15为什么我在Kubernetes集群里需要一个API网关?
- 2024-11-15亚马逊EKS的未来发展趋势
- 2024-11-15使用Kubernetes简化分布式Spring Boot应用中的定时任务管理
- 2024-11-15教你轻松几步升级Hetzner上超划算的Kubernetes集群