Hyperledger Fabric 整理体系:
区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构。
账本在FileSystem中保存,世界状态保存在LevelDB中。
Fabric核心概念
- chaincode:链码/智能合约,对外提供调用指令。分为系统链码、用户链码
- 系统链码
负责fabric节点自身的处理逻辑,包括系统配置、背书、校验等工作。系统链码仅支持go语言,在Peer节点启动时会自动完成注册和部署。
系统链码共有五种类型:- 配置系统链码(CSCC):Configuration System Chaincode,负责处理Peer端的channel配置
- 生命周期系统链码(LSCC):Lifecycle System Chaincode,负责对用户链码生命周期进行管理
- 查询系统链码(QSCC):Query System Chaincode,提供账本查询API。如获取区块和交易等信息。
- 背书管理系统链码(ESCC):Endorsement System Chaincode,负责背书(签名)过程,并可以支持对背书策略进行管理。
对提交的交易提案的模拟运行结果进行签名,之后创建响应消息返回给客户端 - 验证系统链码(VSCC):Validation System Chaincode,处理交易的验证,包括检查背书策略已经多版本并发控制。
- 用户链码
根据不同场景需求及成员指定的相关规则,操作区块链分布式账本的状态的业务处理逻辑代码,运行在链码容器中,通过fabric提供的接口与账本状态进行交互。在整个程序中处于重要位置,下可对账本数据进行操作,上可以对企业级应用程序提供调用接口。
- 系统链码
- transaction:tx 交易,每条指令都是一次交易
- world state:世界状态,
- endorse:背书,在共识机制的投票环节,背书意味着参与投票
- endorsement policy:背书策略,
- peer:组织中的节点;peer节点以区块的形式从orderer排序服务节点接收有序状态更新,维护状态和账本。fabric中Peer节点可划分如下:
- Endorsing Peer:根据指定的策略调用智能合约,对结果进行背书,返回提案相应到客户端
- Committing Peer:验证数据并保存到账本中
- Anchor Peer:跨组织通讯
- Leading Peer:做为组织内所有节点的代表连接到Orderer排序服务节点,将从排序服务节点接收到的批量区块广播给组织内的其他节点
- channel:通道提供了一种通讯机制,将peers和orderer连接在一起,形成一个具有保密性的通讯链路;将一个大网络分割成不同私有子网,进行数据隔离
- KPI:public key infrastructure,一种遵循标准的利用公钥加密技术为电子上午的开展提供一套安全基础平台的技术和规范
- MSP:Membership Service Provider,联盟链证书管理,保存可信任RCA、ICA
- org:orginazation,管理合作企业的组织
Fabric分层
fabric大致分为底层网络层、权限管理模块、区块链应用模块。通过SDK和CLI对应该开发者提供服务。
fabric 模块分层
与此相对应的人员分为三类:
- 底层:系统运维,负责系统的部署和服务
- 组织骨干力人员:负责证书,MSP权限管理,共识机制等
-
业务开发人员:编写chaincode,创建/维护channel,执行transaction等
fabric技术人员分层
开发流程主要包括编写智能合约、通过SDK调用智能合约、及订阅各类事件。
开发环节
MSP
每个管理协作企业的ORG组织都可以拥有自己的MSP,如图所示:
ORG - MSG
MSP出现在两个地方
- 全局MSP:存在channel上,逻辑上认为是配置在系统上的,实际每一个参与者上拷贝一份
-
局部MSP:每个peer,orderer,client等角色都维护,只保存全局MSP的子集,内容保存在本地文件系统上
MSP分类
MSP结构包含RCA根证书、ICA中间证书、OU组织单位、管理员证书、RCL吊销证书列表、节点上的具体证书、存储私钥的keystore、TLS的根证书与中间证书
MSP结构
fabric交易流程
1. peer结点的部署
peer结点上保存有账本ledger和chaincode
channel是一个逻辑概念,可以管理多个peer
channel - peer
当有多方参与者时
channel - org - peer
加入MSP时,可以通过MSP隔离全网不同组织的参与者
channel - MSP - org - peer
2. 交易执行流程
去中心化的设计,必须需要通过投票(多数大于少数)来维持数据一致性,fabric具体操作如下:
- 由client端的CLI或者SDK进行proposal议案提出。client会依据chaincode中的endorsement policy决定把proposal发往哪些endorse peer;背书节点进行投票,client汇总背书节点结果
- client将获得多数同意的proposal,连同各节点的背书及结果提交到orderring service;orderer汇总各client递交过来的请求后,不需要检查交易中的具体数据,只是把接收的所有通道交易,按时间顺序进行排序,并创建交易区块。
-
orderer将交易打包成区块block,然后广播给同一通道内所有组织的Leader节点;各节点各自验证结果,最后将block记录到自己的ledger中。
交易流程 - 原理
交易流程 - 编程
从编程的角度来看,流程更清晰,A是应用程序
- A首先连接到peer
- A调用chaincode发起proposal;与此同时,P1收到后先模拟执行,产生结果放回给A
- A收到各peer返回的结果
- A向O1发起交易;与此同时,O1产生block后会通知peer,而peer会更新其账本
-
最后通过调阅事件A收到了结果。
交易流程 - 节点
2.1 proposal议案阶段
A1发出<T1, P>,收到了<T1, R1, E1> <T1, R2, E2>两个结果
2.2 package打包阶段
O1会在channal上收到很多transaction,将tx排序,在达到block的最大大小(一般应配1M一下,否则性能下降严重)或者达到超时事件后,达成block P2
2.3 验证阶段
O1将含有多条tx打包成区块的B2发往各peer,而P1和P2将B2加到自己的账本中。
资料整理
网友评论