先复习下区块链网络关于peer节点的内容, 每个通道有一个账本, 每个通道有若干个peer节点, 通道节点都有通道的账本的副本, peer节点可安装链码和初始化链码实例。
参考下图, peer可是区块链网络的基石,包含了账本和链码,应用程序或管理员都得通过节点去管理网络的资源。
![](actionImg/Publoadimg.do?id=4028813e711a7c39017177b045ef4458&type=max)
节点,账本和链码
通道对应账本,一个peer节点可以接入到多个通道, 所以一个节点可以有多个账本副本。
每个账本可安装0个或多个链码,实际上每个账本都有默认的一些系统链码。
![](actionImg/Publoadimg.do?id=4028813e711a7c39017177b1bf1d446f&type=max)
![](actionImg/Publoadimg.do?id=4028813e711a7c39017177b1ce414470&type=max)
节点与应用
应用可使用Hyperledfer Fabric SDK采访节点的账本,可以进行查询和更新操作。
蛮多开发语言的SDK都有了, Node.js, Java, Go, Python, REST, 不过就Node.js和Java是release版本, 其它的都还是
测试版, Node.js文档配套好些, Java的基本只能看TestCase代码, 所以说Hyperledger Fabric也属于成长完善阶段。
参考上图, 查询和更新前三步是必须的, 应用连接到peer, 调用链码,peer返回响应结果。
前三步查询的区别是, 返回的响应结果可以直接从peer的账本副本直接返回, 当然应用也可以连接其它peer查询比较
哪个结果最新。
前三步更新的区别是, 因为涉及到共识和数据一致性,实际上应用需要发送更新提议到其它背书(endorsing)节点, 背书节点会模拟执行但不修改各自的账本,背书完成后返回响应给应用。
更新的第四步应用需要收集所有的背书响应,最后打包请求到orderer排序节点,排序节点发送到网络中的其它节点, 这些节点会验证打包信息,通过后更新本地账本拷贝,最后异步通知应用。
节点与通道
我们可以认为通道是逻辑上的一个结构,用于隔离一组物理上的peer节点和应用,通道的概念很关键,主要用于管理和隔离节点。
节点与组织
区块链网络由一个或多个组织管理,peer节点则是网络中这些组织的连接点。
每个组织可以通过自己开发不同的应用,接入各自的接入点,为网络对应的通道提供资源和数据,没有中心化的资源。
节点和身份
组织管理员会为其下peer节点分配数字证书,peer节点连接到通道的时候数字证书就可以标记身份, 标记节点归属哪个组织,这个在通道的MSP中有定义。
Peer节点和Orderer排序节点
多个Peer节点账本数据要一致,需要与Orderer排序节点交互协作。
如上所述,应用接入peer去更新记账本和查询的步骤有不少区别, 有三个阶段处理。
阶段1 - 提议
应用需要提交一个交易提议到对应的背书(endorsing)节点, 背书节点模拟执行对应链码生成修改提议的结果响应,但实际不修改背书节点的账本数据。当应用收到足够多的被签名的提议响应之后, 第一阶段就处理完成了。
常问的一个问题是, 应用怎么知道这些背书节点,需要多少个背书节点签名? 是需要发送到所有节点?
官方的FAQ回答是背书策略是由链码部署的时候声明, BYFN例子
peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"
-P这里定义了调用链码实例的策略,必须Org1MSP和Org2MSP下的peer节点签名。
Java SDK的一些例子, 1.2版本升级可能代码有些差异
阶段2 - 打包
Orderer节点是主角, 它会收到阶段1中交易提议响应的内容, 把批量的交易打包到区块,当生成的区块到了一定大小或者一定的时间内,orderer分发到连接它的所有Peer节点。
交易的排序是严格的,orderer生成的区块是不可以更改的,它在账本中的记录的位置是不变的。
![](actionImg/Publoadimg.do?id=4028813e711a7c39017177ba978a44d0&type=max)
阶段3 - 验证
节点收到orderer分发的新区块,会去验证交易是否根据对应链码的背书策略被所需的组织背书签发。
如果验证通过,节点会做账本状态的一致性检查,即使背书验证通,但由于此时可能另外的交易已更新对应资源的状态,这个交易也是无效的。
节点更新账本的时候,失败的交易还是会被保存用于审计之用,还是与orderer收到的区块一致,只是有保存标记位标记交易是否合法。
注意到,阶段3是不需要执行链码的,这意味着链码只需要安装在背书节点,可保持背书组织和链码的机密性。
最后,每个区块追加到记账本都会有一个消息通知。应用可以注册监听这些通知消息,
Orderer和共识
以上说明的整个流程共识,因为每个节点对交易的顺序和内容都达成了一致。
————————————————
版权声明:本文为CSDN博主「zealVampire」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/zealVampire/article/details/81839627?ops_request_misc