6.2.1 架构演进
Fabric架构经历了0.6版本到1.0版本的演进,架构上进行了重大改进,从0.6版本的结构简单演进到可扩展、多通道的设计,在架构上有了质的飞跃;从1.0版本以后,架构未做重大调整,到目前为止,最新发布为1.2版本。
视频教程:https://study.163.com/course/introduction/1210196297.htm
Fabric 0.6版本架构主要是应用、成员管理和Peer的三角形关系,业务逻辑全部集中在Peer节点上,结构过于简单,只能用于一些商业场景的验证。
Fabric 1.0版本在0.6版本的基础上做了重大改进和重构,把承载过多业务的Peer节点进行拆分,将区块链的数据维护和共识服务器进行分离,共识服务从Peer节点中完全分离出来,独立为Orderer节点专门提供共识服务;membership从架构中分离出来形成Fabric-ca单独组件;在架构中加入了多通道(channel)结构,实现更为灵活的业务适应性,支持更强的配置功能和策略管理功能,进一步增强系统的灵活性和适应性。
图:架构演进
6.2.2 总体架构
总体架构核心部分由成员管理(Membership services)、共识服务(Consensus services)和智能合约(Chain-code Services)三部分, 加上安全和加密服务(Security and Crypto Services)贯穿于其他各个组件,应用端通过接口(APIs、Events、SDKs)调用身份(IDENTITY)、账本(LEDGER)、交易(TRANSACTIONS)、智能合约等信息,架构图如下:
图:整体架构
- 成员管理(Membership services):提供成员服务功能,包括注册、登记、申请证书等功能;考虑到商业应用对安全、隐私、监管、审计和性能的要求,节点、成员只有获得证书才能加入到区块链网络中,在1.0版本以后单独由可插拔的Fabric CA组件来处理。
- 共识服务(Consensus services):负责分布式账本的计算和存储(Distrbuted Ledger)、节点间的共识服务(Ordering Service)、背书验证管理(Endorsement Validation)以及节点间的网络传输协议(Network Protocol)功能的实现,是区块链的核⼼心组成部分,为区块链的主体功能提供了底层支撑。
- 智能合约(Chain-code Services):智能合约(SMART CONTRACT)称为链码(chaincode), 是基于标准的一段代码,实现具体业务逻辑。链码和底层账本是解偶的,链码的更新不影响到原有的数据。链码目前可以使用GO、Java、Node.js语言来编写,通过Docker容器来运行chaincode,安装和实例化后通过gRPC与同一通道内的Peer节点进行连接。
- 安全和加密服务(Security and Crypto Services):节点或成员必须被许可才能进入网络,通过证书、加密和签名等手段保证安全,通过多通道隔离功能,保证只有参与交易的节点能访问到数据,其他的节点看不到,真正实现了逻辑与数据的分离。
- 接口(APIs, Events, SDKs):提供API方式给第三方应用调用,方便二次开发,目前已提供Node.js和Java SDK两种语言接口;可以通过SDK或CLI方式进行安装、测试链码,还可以查询交易状态和数据等功能,同时通过Events监听区块链网络中发现的事件,方便第三应用系统调用和处理。
HyperLedger Fabric 1.4 交易流程(6.3)
区块链最主要的特性之一是去中心化,没有了中心机构的集中处理,为了达成数据的一致性,就需要网络中全民参与管理,并以某种方法达成共识,所以区块链的交易流程也就是共识的过程。
视频教程:https://study.163.com/course/introduction/1210196297.htm
在Fabric中,本由一个节点处理的过程,在逻辑上被分解为不同的角色,每个角色承担不同的功能;节点(Peer)分解为背书节点(Endorser peer)和提交节点(Committer peer),为了达到处理的顺序性,提炼出排序(Orderer)角色。
Fabric是应用于联盟链的场景,在处理每一笔交易时,每个环节上需要对交易信息进行权限校验。
Fabric交易流程图如下所示:
图:Fabric交易流程
交易过程详细流程:
1) 应用程序客户端通过SDK调用证书服务(CA)服务,进行注册和登记,并获取身份证书;
2) 应用程序客户端通过SDK向区块链网络发起一个交易提案(Proposal),交易提案把带有本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等信息发送给背书(Endorser)节点。
3) 背书(Endorser)节点收到交易提案(Proposal)后,验证签名并确定提交者是否有权执行操作,同时根据背书策略模拟执行智能合约,并将结果及其各自的CA证书签名发还给应用程序客户端。
4) 应用程序客户端收到背书(Endorser)节点返回的信息后,判断提案结果是否一致,以及是否参照指定的背书策略执行,如果没有足够的背书,则中止处理;否则,应用程序客户端把数据打包到一起组成一个交易并签名,发送给Orderers。
5) Orderers对接收到的交易进行共识排序,然后按照区块生成策略,将一批交易打包到一起,生成新的区块,发送给提交(Committer)节点;
6) 提交(Committer)节点收到区块后,会对区块中的每笔交易进行校验,检查交易依赖的输入输出是否符合当前区块链的状态,完成后将区块追加到本地的区块链,并修改世界状态。