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条评论
其他心得
Zealot · 271天前 
1.简介 Fabric CA基于开源项目CFSSL开发, 主要为fabric网络提供PKI证书服务,是MSP生成的基础。可能有人会问, 官方不是有cryptogen工具批量生成MSP吗? cryptogen实际是辅助测试工具,默认不同orderer,org都有不同的CA, 如果一个org要追加个peer或user, cryptogen就不管用了。生产环境我们建议使用fabric ca全面管理证书, 如果想简单来而区块链组织,节点和用户基本不会变, cryptogen也没问题。 2.
Zealot · 168天前 
去年得知蚂蚁金服放出SOFA的部分开源项目, RPC部分号称源于阿里内部的HSF, HSF当年可是把dubbo 1.x踢出局的, 只是没想到京东改造dubbo为JSF, 当当改为dubbox。国内蛮多电商公司实施服务化就直接上dubbo 1.x或dubbox。这应该是阿里没想到的, 所以现在dubbo 2.x又回笼为apache的顶级项目, 把dubbox合并还继续完善。 朋友说他们公司花了千万买了SOFA的商业版, 那么值钱的东西今天抽空过了一下开源部分的SOFAStack和dubbo2.x文档
Zealot · 177天前 
Fabric 1.4.1引入Raft排序服务, 运维界比较出名的etcd实现的orderer服务。后生可畏, etcd是中国一个年轻人的作品, 实现了raft协议, 在k8s等容器化, 虚拟化, 集群化有官方应用。etcd也是go语言编写, fabric开窍了, 直接把etcd和orderer整合了, 相比kafka/zookeeper的排序服务,搭建简单多了,也比kafka这些省了很多资源(kafka默认开的堆是2GB..), 所以个人是强烈推荐使用,尽量出来不久,但在1.4LTS维护,
Luoying web framework Luoying web framework contains a bundle of components to accelerate J2EE development Github地址 https://github.com/zealzeng/luoying-web Maven地址 <dependency> <groupId>com.whlylc</groupId> <artifac
Zealot · 185天前 
Hyperledger Fabric v2.0 Alpha引入两大新功能,新的Fabric链码生命周期和FabToken. 新的链码生命周期 2.0支持链码的去中心化的治理,引入新的流程在节点上安装链码,在通道上启动实例。新的链码生命周期允许多个组织对链码的参数协同达成一致,例如链码的背书策略。新的模型的改进点如下: (1) 多个组织必须确认同意链码的参数 1.x版本里,一个组织拥有修改链码参数的能力,例如修改背书策略,通道的其它成员也被同步而更改。新的链码生命周期更灵活一些,它兼容支