家蛙树

Hyperledger Fabric基础之Peer节点

Zealot
区块链
2018-08-24

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

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

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

t_9469f6cd37af4909af36bffe143a06ce.png

节点,账本和链码
通道对应账本,一个peer节点可以接入到多个通道, 所以一个节点可以有多个账本副本。
每个账本可安装0个或多个链码,实际上每个账本都有默认的一些系统链码。

t_1ccda6d24909470a8c1bcced9b835eeb.png

t_7b90516f6be3403cbe6d46608ffd8cfe.png

节点与应用

t_658bc828b18649f7929d0aae6ef97262.png

应用可使用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节点和应用,通道的概念很关键,主要用于管理和隔离节点。

t_9befa8fe22f845659ef477f15c595a23.png

节点与组织
区块链网络由一个或多个组织管理,peer节点则是网络中这些组织的连接点。

t_2149490acc214c65b08d3083a9b47682.png

每个组织可以通过自己开发不同的应用,接入各自的接入点,为网络对应的通道提供资源和数据,没有中心化的资源。

节点和身份

t_3e6e6385a3a341919e2fa9fabef385cf.png

组织管理员会为其下peer节点分配数字证书,peer节点连接到通道的时候数字证书就可以标记身份, 标记节点归属哪个组织,这个在通道的MSP中有定义。

Peer节点和Orderer排序节点
多个Peer节点账本数据要一致,需要与Orderer排序节点交互协作。
如上所述,应用接入peer去更新记账本和查询的步骤有不少区别, 有三个阶段处理。

阶段1 - 提议
应用需要提交一个交易提议到对应的背书(endorsing)节点, 背书节点模拟执行对应链码生成修改提议的结果响应,但实际不修改背书节点的账本数据。当应用收到足够多的被签名的提议响应之后, 第一阶段就处理完成了。

t_06de43f03ed84df3ad473eabddf3eee1.png

常问的一个问题是, 应用怎么知道这些背书节点,需要多少个背书节点签名? 是需要发送到所有节点?
官方的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版本升级可能代码有些差异

t_b3449a40cf10470e9eb574e1f256b014.png

阶段2 - 打包

Orderer节点是主角, 它会收到阶段1中交易提议响应的内容, 把批量的交易打包到区块,当生成的区块到了一定大小或者一定的时间内,orderer分发到连接它的所有Peer节点。
交易的排序是严格的,orderer生成的区块是不可以更改的,它在账本中的记录的位置是不变的。

t_c509bb293d0c46d598ed24ee1e4239ac.png

阶段3 - 验证
节点收到orderer分发的新区块,会去验证交易是否根据对应链码的背书策略被所需的组织背书签发。
如果验证通过,节点会做账本状态的一致性检查,即使背书验证通,但由于此时可能另外的交易已更新对应资源的状态,这个交易也是无效的。
节点更新账本的时候,失败的交易还是会被保存用于审计之用,还是与orderer收到的区块一致,只是有保存标记位标记交易是否合法。

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

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

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

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

点赞 0
0条评论
其他心得
1.Kafka排序服务原理 官方文档在google doc上, 参考翻译 https://www.jianshu.com/p/db006359133d 2. kafka 排序服务安装 所有的代码已分享在https://github.com/zealzeng/kafka-orderer-demo 2.1 安装环境 官方文档有一些简单的描述 https://hyperledger-fabric.readthedocs.io/en/release-1.4/kafka.h
Zealot · 16天前 
1.Andorid串口开发包一般使用google多年前提供的android-serialport-api, 提供自用分支 https://github.com/zealzeng/android-serialport-api 2.Android设备一般需要root, 保证设备串口文件如/dev/ttyS0, /dev/ttyUSB0等可读可写, 如果无权限, 则需要切到su执行chmod 666。需要注意的是有些设备su路径是/system/bin/su, 有些是/system
2.3 拜占庭问题 The Byzantine Generals Problem拜占庭将军问题是Lesilie Lamport等人 1982年发表的论文, 具体PDF链接, http://lamport.azurewebsites.net/pubs/byz.pdf 拜占庭问题假设一个场景,拜占庭的多个军队围攻地方的一个城市,军队的将军通过信使交换信息,在观察敌军的情况后将军们必须达成统一的作战计划。但是将军中可能有叛徒,会阻止其它将军达成一致决定。 将军们就需要一个算法保证所有忠诚的将军达
编写过一些链码的人可能会觉得是在操作一个简单的key-value数据库, 就是GetState和PutState去操作键值对,而对复杂些的一对多,多对多等实体关系和数据模型不知怎么设计。我们先从官方的例子入手一起探讨下。 1.简单转账例子 /fabric-samples/chaincode/chaincode_example02/go/chaincode_example02.go 假设链码调用peer chaincode invoke … -c ‘{“Args”:[“invoke”,”a
Zealot · 53天前 
区块链的真实数据依赖于物联网和智能设备,记一次折腾的android无线调试经历。 Android 4.2.2定制版智能硬件, USB口能插鼠标键盘, 但是不能USB调试。供应商两个方案, 要么开壳找到USB OTG排座, USB口自己接线, 但是开壳会导致硬件功能无法使用; 要么手工打包apk安装到硬件慢慢的toast。 摸索出第三条路。 搜索android无线调试, 基本都需要第一次USB调试线, adb tcpip 5555开启android设备端口监听, 之后adb connect ip