家蛙树

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 · 38天前 
对于Fabric的权限和MSP配置这块,可能大家实际部署会给一堆msp目录绕晕,我们回过头来梳理一下。 1.Peer节点如何控制用户的采访权限?我们以first-network为例, 先看下peer0的启动配置docker-compose-cli.yaml。 引用到base/docker-compose-base.yaml peer0.org1.example.com: container_name: peer0.org1.example.com extends: fi
Fabric在半天前发布1.3版本,参考 https://github.com/hyperledger/fabric/releases 介绍下1.3的新特性,参考 https://hyperledger-fabric.readthedocs.io/en/release-1.3/whatsnew.html 1.MSP新实现方式,使用身份混合器/Identify Mixer 通过使用零知识证明(zero-knowledge proofs), 可实现身份的匿名和不可连接。 开发环境提供了
Zealot · 88天前 
Hyperledger Fabric当前最新版本为1.2, 自行参考官方安装文档 https://hyperledger-fabric.readthedocs.io/en/release-1.2/prereqs.html 以Centos7安装为例, 简单说明注意事项。 1.安装或更新curl yum install curlyum update curl保证尽量新的版本, 后面步骤安装脚本使用curl下载文件 2.docker安装 (1)Docker CE安装参考官
Zealot · 52天前 
1.基于Hyperledger Cello Cello的定位是为Fabric提供一个BaaS平台,使用Web UI方便的管理区块链网络,节点和链码。 理想丰满,希望兼容K8s,swarm等多容器,提供了安装网络,简单监控,安装链码,调用等基本功能,可惜bugs一堆,又得兼顾Fabric快速迭代的版本。还有一点,以docker为例,实际Work Node使用remote docker访问模式,需要在Master的管理平台手工输入所有的worker node ip和端口,有些维护
1.Consistency 一致性 一致性是分布式系统需要解决的基础问题,一致性是对外呈现的一致的状态或结果,一致性为什么很重要,举个扫码支付的例子。 小明到商场想玩夹娃娃机,他爸爸扫码支付了10元,娃娃取币机正常情况下需要弹出10个币,假设取币机出了问题,没接收到支付成功的通知,没弹出币就让人抓狂了。两个系统中订单状态不一致了,支付系统认为是支付成功,娃娃取币机认为订单待支付。 1.1一致性模型 一致性的模型定义,只列出一些常见的,一起学习研究。(1)Strict Consist