Hyperledger Fabric基础之Peer节点

Hyperledger Fabric基础之Peer节点

参考

https://hyperledger-fabric.readthedocs.io/en/release-1.2/peers/peers.html

http://www.javatree.cn/news/5129ebda1ada4e93ab2fcc393fc79184

先复习下区块链网络关于peer节点的内容, 每个通道有一个账本, 每个通道有若干个peer节点, 通道节点都有通道的账本的副本, peer节点可安装链码和初始化链码实例。

 

参考下图, peer可是区块链网络的基石，包含了账本和链码，应用程序或管理员都得通过节点去管理网络的资源。

 

节点,账本和链码

通道对应账本，一个peer节点可以接入到多个通道， 所以一个节点可以有多个账本副本。

每个账本可安装0个或多个链码，实际上每个账本都有默认的一些系统链码。

 

节点与应用

应用可使用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生成的区块是不可以更改的，它在账本中的记录的位置是不变的。

 

阶段3 - 验证

节点收到orderer分发的新区块，会去验证交易是否根据对应链码的背书策略被所需的组织背书签发。

如果验证通过，节点会做账本状态的一致性检查，即使背书验证通，但由于此时可能另外的交易已更新对应资源的状态，这个交易也是无效的。

节点更新账本的时候，失败的交易还是会被保存用于审计之用，还是与orderer收到的区块一致，只是有保存标记位标记交易是否合法。

 

注意到，阶段3是不需要执行链码的，这意味着链码只需要安装在背书节点，可保持背书组织和链码的机密性。

 

最后，每个区块追加到记账本都会有一个消息通知。应用可以注册监听这些通知消息，

Orderer和共识

以上说明的整个流程共识，因为每个节点对交易的顺序和内容都达成了一致。

 

歇口气， 最后的基础只是主要介绍下记账本的结构， 私有数据就自行阅读了。

更多请关注