1.Peers

Peers是网络的基本元素，持有账本和智能合约（链码），代表信息及其对应的处理方式。

如图所示，P1、P2、P3每个Peer都保存一份账本的副本和智能合约的副本，这样提供了一种冗余机制，避免了单点失效，事实上，每个Peer可以持有多个账本和链码。而应用和管理员等想要访问某些资源，必须通过peer来实现，所以其是非常基本且重要的。

一个链码可以有1个或者1个以上的账本，每个账本可以有对应的0个或0个以上个链码，图中账本L1对应链码S1,L2对应S1与S2,虽然一个账本没有对应的链码是完全可以的，但是这种情况极为罕见，大多数情况下都应该至少有一个链码。

应用和peer的查询交互操作包括三个简单的步骤，而更新交互包含额外的两步。

应用在需要访问账本和链码时使用Fabric SDKAPI来调用链码、生成交易，验证、提交交易到账本中，最终在整个过程完成后交易会收到消息提示。

应用A连接到peer P1
应用A向P1发起提议

2.1. peer使用提议的参数调用链码S1，来查询或者更新账本L1

2.2. 链码S1生成查询或者更新提议的回复
返回提议回复到应用A，如果是一个查询操作，到这里就已经结束了
应用A从所有回复中构建交易到order O1节点

4.1. O1节点收集网络中的各种交易，将其打包到区块里面，然后发送区块到所有peer节点，包括P1

4.2. P1首先对块内交易进行验证，然后用其来更新账本L1
在L1被更新之后，P1生成事件，返回应用A，告知其整个过程已经完成

对于查询操作，一般只需要一个Peer节点就可以完成了，应用也可以通过连接多个Peer节点来获得更加实时的信息等。而更新操作会包含额外的步骤，在第3步中回复的并不是更新成功的通知，而是表示该节点同意节点的更新，具体更新还需要等待其他节点通过共识过程同意更新之后再执行，即4、5步的内容。

每个channel可以包含多个peer，每个peer也可以加入多个channel，可以将channel类比为通讯工具中的群组，channel中除了peer以外，还有order与application，P1与P2可以使用通道C直接进行交流。channel是由若干物理上存在的peer所形成的逻辑结构，peer为通道的访问、管理等提供访问点。

区块链网络由多个组织所形成与管理，peer是这些组织的连接点，被各个组织所拥有，每个组织可以有多个peer节点。而网络的形成也是由各组织提供资源才能形成，会随着组织提供资源的多少而进行规模的伸缩，只要有组织存在，网络就会存在，不管中间是否有新的网络加入或者之前的网络离开，因此也能看出网络的去中心化的特性。网络中必须要有peer，但是不一定要有application，application由组织具体的业务逻辑等确认。对于查询操作，application通常只连接组织自己的peer就足够了，但是对于更新操作，就需要连接多个peer来满足背书策略。

网络中的每一个peer都有其所属组织的管理员颁发的证书。当一个peer链接到通道时，会通过channel MSP来由其电子证书确定其所属组织。在物理上，peer可以位于云端、位于本地机器上等，但是其所属组织情况是由其身份(Identify)决定的，而不是由其物理所在决定的。

应用对账本的更新过程共分为三个阶段。

application从背书策略要求的peer上收集账本更新提议的背书，但此时peer并未完成真正的账本更新。
将背书收集在一起作为一个交易打包成区块，收集过程由application完成，而打包由order完成。
将区块发放给各个peer，将其验证之后，对账本进行实际更新操作。验证失败的交易会被扣留下来用于审计等工作，不会用于更新账本。

整个工作流过程被称为共识,共识过程之后,所有的peer都在交易的顺序和内容上达成了一致，共识是个多步的过程，应用只有在这个过程全部结束之后才会受到完成提示，在不同的peer上这个时间可能各不相同。

2.ledger

账本存的是业务逻辑相关的重要事实，包括当前值以及引起当前值的交易历史，可以类比为存折银行账户余额以及其交易流水，它本身不存钱，但是却代表了存折持有者的财富，账户余额是可变的，但是交易流水是不可变的，而区块链则保证了这种不可变性。

账本有两个相关的组件组成—世界状态和区块链。世界状态是一个持有当前值的数据库，方便数据的获取，状态默认是一个键值对，可以容易的CURD。区块链则是一个交易日志，记录了到当前的世界状态的所有改变，交易存储在块内，数据结构与世界状态大不相同，因为要保证可变性。

可以逻辑上认为网络中有一份账本，而事实上有很多账本的副本，这些副本会通过共识保持一致，这也是分布式账本技术(DLT)的应用。

2.1.世界状态

应用程序可以使用简单的账本API来增删读状态，状态值可以是简单的字符串(Audi)或者一种复合结构({type:BMW…})。

世界状态以数据库的方式来实现，这样使得存储与读取都更加有效率，Fabric也可以通过配置来使用不同的数据库来更加适配应用，目前包括LevelDB和CouchDB，前者适合与存储简单的键值对，后者则适合JSON结构的文档，会支持更复杂的查询与更新。

应用几乎不能调用智能合约，当交易被包含在区块链中之后才会收到通知，所以应用不能直接更新世界状态，世界状态是由被足够背书节点签署后的交易更新的。这样将应用和世界状态进行了隔离。

除了数据本身，世界状态还有版本号，每次更新世界状态都会使得版本号增加，每次更新状态时都会检查版本号来确保防止并发更新的情况出现，确保按序更新。

账本刚创建的时候世界状态是空的，随着后面的交易增加才会增加世界状态，而且任何时候，世界状态都可以根据区块链重建，当peer创建时，也是通过这种方式来同步世界状态的，而且当peer出现异常失效时，也可以通过这种方式来重建世界状态。

2.2.区块链

区块链存储了账本状态的之前版本与变成当前状态的方式。区块链是由一系列相连的区块构成的，每个区块包含一系列交易，每个交易都代表一条对世界状态的查询或者更新。区块顺序或者交易顺序都由排序服务(ordering service)实现。

每个区块头都包含整个区块的交易和上一个区块头的哈希，通过密码学方式让所有交易链接起来，形成区块链，给账本带来安全性，因为修改交易就必须处理之前的交易。第一块是创世块，作为账本起点，里面没有任何用户交易，而是包含初始网络通道状态的配置交易(channel configuration)。

区块链通常以文件的方式实现，因为区块链的操作基本上就是添加，而很少查询，所以用文件方式实现很好。

2.2.1.区块

区块由三个部分组成

区块头

区块号：从0(创世块)开始，每增加一个区块，其区块号就加一。
当前块哈希：当前区块所有交易的哈希。
前一个区块头哈希：前一个区块头的哈希，用于形成一条链。

块数据

按顺序排列的所有交易，在排序服务创建时写入区块。

块元数据

包含区块创建者的证书和签名，用于网络各节点对其进行验证。随后，块提交者将每个事务的有效/无效指示器添加到位图中，该位图以及累积状态更新的哈希值也驻留在块元数据中，以便检测状态分叉。

这部分不会用于计算块哈希。

2.2.2.交易

交易存在于区块的块数据节中。

一个交易主要由五部分组成，其他的一些对于理解账本的数据结构就并不那么重要了。

交易头(H4)

交易头存储交易必须的元数据，比如相关的链码名称以及他的版本。

签名(S4)

包含一个客户端应用程序创建的签名，该签名由客户端私钥创建，用于检查交易细节没有被篡改。

提议(P4)

这部分将应用程序提供的用于账本更新的参数输入进行编码存储，这部分也将用于账本更新时的参数输入。

回应(R4)

该部分获取了世界状态更新前后的值，作为一个读写集(RW-set)。也是智能合约的输出，如果交易被成功验证，将会用其去更新账本。

背书(E4)

这是一个来自背书策略所要求的组织的签署的交易响应列表。

在真实的区块链环境中，每一个链码都会有自己对应的世界状态，因此有命名空间的说法，相同的命名空间的智能合约才能访问对应的世界状态，因此世界状态是有命名空间的属性。而区块链则没有命名空间属性，它里面含有来自多个含有不同命名空间的智能合约的交易。

而在Fabric中，每个通道都有一个隔离的账本，也就是一个完全隔离的区块链和世界状态，包括命名空间，而应用可以通过连接不同的通道来使得不同通道之间的账本进行访问。

3.排序服务

比特币和以太坊基于概率的共识算法进行共识，保证账本最终一致，但是可能出现分叉的情况，这与Fabric不同。Fabric有一个特殊的节点，叫做orderder(也称为排序节点)来进行交易排序，多个排序节点一同提供排序服务。因为fabric的设计依赖于确定性的共识算法，因此每次验证都需要保证最终一致和正确性，不能引起分叉，而不仅仅是最终一致。

除了最终一致，分离链码执行和背书也给了Fabric在性能和可扩展性上的优势，消除了执行和排序服务都在同一个节点时可能带来的瓶颈。

Orders也有访问控制，限制了谁可以读写和修改他们。这些是在通道建立时写在配置文件中的。和peer一样，order节点也是属于一个组织的，这个组织也应当有自己的CA。

orderers的交易处理流：

阶段一：提议

在这一阶段，客户端应用程序会发送交易提议到可以调用智能合约来产生账本更新提议并进行背书的peers的子集。背书节点并不会立即把这个账本更新提议应用到自己的账本副本去，而是返回这个账本更新提议到客户端去。

阶段二：排序并打包交易到区块

第一阶段完成后，客户端应该会受到来自各peer的背书的交易提议回应。

在这一阶段，客户端提交包含包含交易回应的交易到排序服务节点。排序服务会在同一时间收到来自各个应用程序的交易。排序服务可能由多个节点构成，他们协作来提供排序服务。他们的工作就是将收到的交易进行排序，然后打包成块，这些块会变成最终区块链中的区块。

区块中的交易数取决于通道配置中的值以及设定的出块时间参数(BatchSize和BatchTimeout)。区块之后会被保存在orderer的账本中，然后分发到channel中的各peers中，orderer账本中的这些区块也可以在peer重新连接或者新加入的情况下，在连接排序服务时发送给peer进行同步。

需要注意的是，排序服务的规则并不是交易到达orderer的时间顺序，而是和peer保持相同定义的一个顺序，peer稍候也会使用这个顺序来对块进行验证。因为排序服务可能有很多节点，交易到每个节点的时间可能并不一样，所以时间顺序也很难实现。

阶段三：验证提交

阶段三中，首先orderer会把区块分发给所有连接到他的peer，并不是所有的peer都需要连接到order中，因为peer也可以通过gossip协议把区块发给其他的peer。每一个peer会独立的验证区块，具体来说，会验证区块中的每一个交易，确保其被足够的peer签名背书。

对于排序服务，order有不同的实现。

Raft(目前推荐的方式)

Raft是一个CFT(crash fault tolerant)排序服务，即任何节点发生崩溃都可以进行动态的恢复，从而保持了高可用性，从order群中选举出领导者之后，剩下的节点都称为追随者，领导者做什么，追随者都会照做。Raft排序服务会比Kafka排序服务更加容易设立(不需要设立zookeeper，没有版本问题)以及管理，而且Kafka并不是一个完全去中心化的方案。

每一个通道都有一个单独的Raft协议实例，实例内部可以自己选举主节点。选举之类的操作对peer和客户端是透明的。

fabric2.0 概念， peer、账本和排序服务相关推荐

(Fabric 学习六)Fabric2.0 私有数据使用marbles官方示例
私有数据从v1.2开始,Fabric 提供了创建私有数据集合的功能,它允许在通道上定义的组织子集能够背书.提交或查询私有数据,而无需创建单独的通道. 产生的原因:一个通道上的一组组织需要对该通道上的 ...
(九)Fabric2.0 通道实践-更新通道配置(修改区块交易数量)
总目录: (0) 如何利用区块链保护知识产权 (一)HyperLedger Fabric 2.0-release测试网络部署 (二)Fabric2.0 first-network 生成配置说明 (三) ...
Fabric2.0部署学习进阶教程系列博文
Fabric2.0部署学习系列文章目录 1.<在本机上安装VMWare详细图文过程> https://blog.csdn.net/weixin_44750512/article/detai ...
Hyperledger Fabric 排序服务核心原理和工作过程
Hyperledger 源码分析之 Fabric 排序服务在超级账本 Fabric 网络中起到十分核心的作用.所有交易在发送给 Committer 进行验证接受之前,需要先经过排序服务进行全局排序. ...
WCF4.0新特性体验(6):路由服务Routing Service（下）
紧接前文WCF4.0新特性体验(5):路由服务Routing Service(上).今天我们介绍WCF4.0消息路由的实现机制,然后会讲解路由服务的实现过程. [4]WCF与路由服务: 其实在介绍WC ...
Dubbo 3.0 前瞻之对接 Kubernetes 原生服务
Kubernetes 是当前全球最流行的容器服务平台,在 Kubernetes 集群中,Dubbo 应用的部署方式往往需要借助第三方注册中心实现服务发现.Dubbo 与 Kubernetes 的调度体 ...
区块链教程Fabric1.0源代码分析流言算法Gossip服务端二
区块链教程Fabric1.0源代码分析流言算法Gossip服务端二 Fabric 1.0源代码笔记之 gossip(流言算法) #GossipServer(Gossip服务端) 5.2.commIm ...
上海亚商投顾：A股缩量调整 AIGC、Web3.0概念抢眼
上海亚商投顾前言:无惧大盘大跌,解密龙虎榜资金,跟踪一线游资和机构资金动向,识别短期热点和强势个股. 市场情绪三大指数今日震荡调整,深成指.创业板指午后均跌超1%,黄白二线有所分化,科创50指数跌近 ...
(七)Fabric2.0智能合约实践-设置背书策略
总目录: (0) 如何利用区块链保护知识产权 (一)HyperLedger Fabric 2.0-release测试网络部署 (二)Fabric2.0 first-network 生成配置说明 (三) ...
gossip 区块链_区块链教程Fabric1.0源代码分析流言算法Gossip服务端一兄弟连区块链教程-阿里云开发者社区...
区块链教程Fabric1.0源代码分析流言算法Gossip服务端一,2018年下半年,区块链行业正逐渐褪去发展之初的浮躁.回归理性,表面上看相关人才需求与身价似乎正在回落.但事实上,正是初期泡沫的渐退 ...

fabric2.0 概念， peer、账本和排序服务