本文作者:HiBlock区块链技术布道群-AmyWu
原文发布于简书
1
Peer Nodes 节点
在任何区块链网络里面,节点都是构成整个网络必不可少的组成部分。在Hyperledger Fabric的网络里面,在节点上,我们可以实现和定制 chaincode,当然还有与之附随的 chaincode 的 Blockchain Ledger。
节点是 chaincode, Blockchain Ledger的载体。每个节点上都有一份 chaincode 的 Blockchain Ledger 的拷贝。
每个节点都可以被:创建, 开始, 停止, 重新设定, 删除。
一个节点上,可以有多个 chaincode 和 Blockchain Ledger, 而一个 Blockchain Ledger为多个chaincode提供服务。
每个节点上都有一个默认的 system chaincodes。
2
Multiple Ledgers and Chaincodes
多账本 多智能合约
一个节点里面,有一个 chaincode 的 Blockchain Ledger 是很常见的。在Hyperledger Fabric的网络里面,一个节点上有多个 Blockchain Ledger,而基于每个 Blockchain Ledger,又有多个 chaincode,也是很常见的。而每个节点上都有一个默认的 system chaincodes。
3
Applications and Peers 应用与节点
what’s most important to understand is the difference in application-peer interactions for ledger-query compared to ledger-update transaction styles.
一个外部应用,比如安卓上的一个应用,可以通过 Hyperledger Fabric Software Development Kit (SDK) 里面提供的 APIs 来连接节点,触发 chaincode,生成交易,通过 ordered(排队,排序) 之后,被广播到网络其他节点上。
从一个应用的角度:
通过API链接节点
尝试激活智能合约
收到节点的回复(在回复之前,节点会激活请求的智能合约,智能合约生产指令,更新回复)
把收到的回复,提交给排序节点(排序节点会做相关确认,然后把这次交易的信息排队到广播队列中)
收到节点以及更新的回复
从一个节点的角度:
是有能力在确认相关信息之后,独立执行智能合约的。因为所需要的信息在这个节点的本地都有备份。
虽然可以独立执行智能合约,但是不能独立的把执行结果广播出去。
4
一次交易的旅程
4.1 参与方
A :收购萝卜
B :出售萝卜
peerA:代表A
peerB:代表B
4.2 假设
我们的联盟网络已经建成,而且参与方已经通过相关资格认证机构,注册,并且有相关材料证明其身份。
The application user has registered and enrolled with the organization’s certificate authority (CA) and received back necessary cryptographic material, which is used to authenticate to the network.
包含了代表萝卜市场的一对key和value的智能合约已经在联盟网络里配置好了。
智能合约的逻辑里面,包含了交易的步骤以及一个萝卜的价格。并且在背书协议里面,包含了必须双方提出背书。
4.3 交易步骤
A想发出购买萝卜的请求。因为需要双方背书,所以A同应用,把这请求同时发给了,peerA和peerB。
SDK生成请求。这个请求可以执行一个智能合约,从而可以读写(比如加入一对新的代表萝卜市场的key和value)账本。
SDK将交易打包为正确的格式,并用用户的加密凭证为此交易提议生成唯一的签名。
背书节点,如果签名验证成功,就执行请求
主要验证:
・请求的格式是否正确
・这个请求在之前已经被执行过
・签名是否有效
・请求提出者,在权限上是否符合此次请求的内容。
背书节点,执行请求,生成结果。此时账本还没有做任何的更新。和背书节点的签名一起,返回给请求者。
--- 线上课程推荐---
领取专属 10元无门槛券
私享最新 技术干货