HyperLedger-序列2-Fabric 1.0 架构解析与Transaction处理全流程

从本篇开始,正式进入Fabric的序列。大家如果看过前面以太坊的序列文章,知道以太坊的架构,理解Fabric会很容易。

逻辑架构

竖着来看,3大块:

(1)最左边的,Memship,就是上1篇所讲的联盟链特有的:身份认证相关的内容。比如组织注册,公钥证书发放,交易签名,验证等等。。

(2)中间1块:区块链的基础东西,和比特币、以太坊类似,BlockChain、Transaction、Ledger(分布式账本)、P2P协议。。

(3)最右边1块:智能合约。在以太坊里面,称为Smart Contract,这里换了个名字,叫做ChainCode而已。本质还是同1个东西。

运行架构

下面这张图,展示了Fabric运行时的架构是什么样子(Fabric采用Go语言开发,通常运行在Docker容器里面,每1个Node对应1个Docker容器)

(1)这里的application/SDK,并不是指我们通常的APP的客户端。而是整个Fabric网络的调用端,通常是我们的Web应用服务器。

(2)membership 服务,就是上图中的注册登记、身份认证。在这个地方,你可以认为是一个服务的集群。

(3)peer 就是区块链网络中说的物理上的node。peer呢,有2个角色(对应2个模块),1个叫Endorser,1个叫Commiter(这个后面会详细讲述)。

peer上面存的是Ledger(区块链 + WorldState),存的智能合约ChainCode,然后peer之间、peer和客户端之间,用event通信。

(4)Order-Servce 排序服务。为了Consesus用的,后面会专门来讲述。

总结一下:Fabric相对以太坊,大部分其实很类似(比如peer,peer上面的账本、worldState)。多了2个东西出来,1个是membership(用于注册、身份认证),1个是order service,用于共识算法。

网络节点示意图

下面这张图,示意了整个Fabric运行过程中,网络的节点情况。

有3个组织Org1, Org2, Org3,各自有1堆的Peer(也就是Node),这些Peer呢,既是Endoser角色,又是Commiter角色,所有的Peer组成1个联盟链。通过Ordering Service,所有节点达成共识。

(注:这张图上省去了客户端、Membership服务)

网络运行全过程介绍 - Transaction的深入理解

知道了整个网络的运行架构,接下来看一下整个网络是怎么运作的。

2大流程:

流程1: 写ChainCode,编译,部署。 这个整个的过程,跟前面介绍的,以太坊的Solidity很类似,只是这里用的Go语言。

额外说1句,Fabric的智能合约的编写,比以太坊还简单!!!这得归功于Fabric良好的接口设计。

流程2:客户端注册,向整个网络发送请求。具体来说,

Step1:你要加入这个网络,首先肯定要向Membership服务注册,给你发证书。也就是上图中的步骤0 Enroll

Step2:注册完成,接下来就可以向网络发送交易了。

这里要特别强调一下,Transaction这个词在这里的意思。

我们知道,在比特币网络中,当我们说Transaction,特指买卖双方的转账;到了以太坊中,Transaction这个词有了扩展,不仅指交易,也可以用来部署、调用智能合约;

到了Fabric中,这里Transaction这个词就更加泛化了,其实就是指客户端的发生Request ! 当然,指的是Write Requerst,会改变WorldState,会被加到区块链里面。说的再通俗点,就是请求的日志流水!!!!

对于只读的请求,Query Request,并不改变WorldState,你可以不写入到区块链里面去。当然,你也可以把它当做Transaction,按照Write Request的方式去处理,只是一般没有必要。

再次强调一遍,这里的Transaction,就是我们通常的客户端发出去的请求的日志流水!!!

日志流水 + 状态机的这个模型,我们在前面以太坊的序列中,讲解过;在另1个专门讲Paxos/Raft的分布式一致性算法里面,也讲过。

这个是计算机领域一个个非常非常常见的模型,明白了这个,就会发现Fabric其实很简单。

Transaction Flow -- 一致性如何达到

知道了Transaction就是客户端发的请求,接下来就来看一下,请求进入Fabric的网络中,被怎么写入到所有Peer的。即如何保证所有Peer上面的数据一致性??

下图展示了1个Transaction被处理的详细过程:

Step1:客户端向其中1个Peer提交Transaction。注意,这里的Client是真正的客户端。而这里的submiting peer,你可以认为是fabric网络的客户端(对客户端来说,这个submiting peer是服务器)

Step2:submiting peer把请求给多个endoser模拟执行,然后从每个endoser收集返回结果。也就是图中的步骤 圆圈2,3。

在Fabric里面,把这个“模拟执行”的过程,称为“背书”,endoser。 至所以这么叫,是因为如果模拟执行不通过的话,这个Transaction就直接被拒绝了。模拟执行通过,才有机会进入下面的过程,才有机会被区块链网络接受。

所以,“背书”,通俗点讲,就是“告诉整个区块链网络,这个Transaction被我模拟执行过了,有效的,你们要不也试试看?”

这里有2个关键点:1.发给几个endoser取决于你的endose poclicy怎么配置的,你配置成只有1个endoser也可以。

2.注意这里只是“模拟执行”。endoser并不会把结果直接写到worldState里面。(模拟执行的结果是ReadWriteSet,这个后面单独来讲)

Step3:submiting peer 把这个Transaction + 模拟执行的结果(ReadWriteSet),发给Orderering Service。也就是图中的步骤 圆圈 4

关键点:因为有很多个Client往不同的submit peer发送请求,所以这个Ordering Service会收到1笔笔的Transaction。

Orderering Service呢,会对这些Transaction进行打包,形成Block。

Step4:Ordering Service再把这个Block广播给每个Peer(此时,Peer充当了另外1个角色,不是Endoser,而是Commiter)。所有Commiter接受到这个Block,真正写入:把交易加入区块链,同时更新WorldState,也就是分布式账本(Ledger)

Step5:给Client发送Event,通知其交易已被执行。

依赖问题

(1)为什么按照上面的流程来处理Transaction,就可以保证所有Peer的数据是一致的呢?

换句话说:你所有的Peer都在接收Transaction,所有的Peer都在写入数据,网络又是有延迟的,如何保证所有Peer数据一致??

这就是接下来要讨论的分布式一致性算法问题,这个也是分布式系统的1个典型问题。在Paxos/Raft序列里面,有过探讨。在接下来,会结合Fabric来再次深入讨论这个问题。

(2)写入的时候,多个Transaction改同1个状态(比如多个Transaction同时从同1个账号转钱出去),并发怎么控制?

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180613G0JBYP00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券