Fabric的区块链协议调研报告
关于Fabric的基本介绍这里就不赘述，报告主要从Fabric设计的整体逻辑架构开始，重点讲述涉及区块链服务设计的核心内容。下面是Fabric的逻辑架构：
可以看到Fabric主要由成员服务（Membership Services）、区块链服务（Blockchain Services)、和链码服务（Chaincode Services）三个服务板块组成。Fabric有着突出的四大功能：身份管理、隐私与保密、高效处理、链码功能，这其中身份管理就是很重要的一个特色，也就是成员服务（Membership Services）这一板块，它通过对参与者进行身份的审核，进而确保平台的安全性和权限管理，但是这一块与链的关系不是很直接，我们放到最后作为补充；同时链码功能（Chaincode Services）与智能合约几乎等价，我们也是放到最后再讲，重点放到中间的这一层区块链服务（Blockchain Services）。
区块链服务
区块链服务（Blockchain Services）负责了节点的共识管理、账本的分布式计算、账本的存储以及节点间的P2P协议功能实现。下面先从节点开始，进而深入探究Fabric的交易流程以及共识机制：
节点：
在Fabric中，出现得最多的就是对等节点（peer node），它是链的基本元素，类似于其他区块链上的普通节点，下面是它的基本结构图：
每一个对等节点都可以存放账本和链码（这里的链码与我们所说的智能合约基本是一样的），当然每一个节点可以存放多个账本，也可以存放多个链码，节点可以创建也可以删除。对于最简单的交互访问账本模型可以从下面的结构图分析：
查询操作：
A是作为应用程序对节点进行各种操作（如访问查询等），在上面的这一个结构流程图是表示了应用程序A连接到对等节点，通过调用对等节点的链码S1进行查询或者更新它的账本L1，对于更新账本这个操作，我们后面会进行更进一步的分析，因为更新账本一般不是一个对等节点自己就可以决定的事情，我们假设这是一个查询操作，（因为查询不需要咨询其他节点），对等节点把查询到的结果返回给应用程序，经过这个流程，这是有另外一种节点，我们叫做排序节点，来对事件进行打包成块，发送给所有网络节点，P1在处理好这个交易后产生一个相应事件给应用程序A。
更新操作：
上述是不用其他节点共识的简单查询，如果是要更新事务，单个节点不能私自更新账本，需要征求其他节点的验证的，就涉及到共识机制，这里涉及三个流程：
提案
对于应用程序A1想要提出一个交易提案，需要对等节点P1和P2进行执行并确认，它首先发起分别对于这两个节点的交易提议，节点对收到的事务生成响应并且带上确认，例如对于节点P1，它通过执行链码生成R1响应并且带上自己的E1确认。PS：在这里面，账单更新选中的节点是由政策定义的链码决定的，在这个例子中该交易需要P1和P2进行操作确认。这个阶段在应用程序收到足够多的签名响应时结束。接下来就是进行打包；
打包
在链上的节点除了对等节点，还有排序节点，这些节点的作用就是打包更新账本提案，例如对于刚才上面所说的程序A1接收到的两个节点P1和P2返回的验证事务，就是需要提交给排序节点O1，排序节点把这个事务按照一定的顺序与其他类似的交易事务打包进区块，至于顺序不一定是按照时间先后，但是这个顺序是固定的，不管用什么方式，这使得事务一旦被写到数据块上，那么永远都不会改变，也就是不会发生账本分叉。这个过程就是简单的收集打包，没有任何的验证，它不需要对交易价值进行判断，只是机械地不可逆打包。
验证
在上面打包得到的块需要发布到对等节点，如下：
排序节点把打包后的区块发布给了P1、P2，节点通过处理这个区块进行自己账本的更新，并且会通知其他节点这个交易已经处理。当然这个处理是有一定认可政策的，例如这个提案交易需要多少人同意认可才是有效，如果验证成功，对等节点的账本将更新，而失败的验证交易将不会更新于账本。最终节点也会返回响应事件给应用程序作为响应。
整体来看，所有的对等节点在排序节点的协同下，达成了交易顺序以及内容的一致性，而对于节点的类型，大家可能有疑问，主要分为：提交节点、背书节点、领导节点、锚节点。其实每一个对等节点都是一个提交节点，可以接受交易区块并更新，也都可以有智能合约，可以执行并验证，成为背书节点，当然还有排序节点对交易进行打包成块，而领导节点可以对打包好的交易分发给组织中的其他节点。锚节点则是作为一个节点与其他组织节点通信的节点。因此交易流程一般分为：应用程序发布提案给背书节点进行验证，背书节点执行并签名，应用程序收集交易并发送给排序节点，排序节点打包并广播，接收到的节点验证并写入账本。
共识服务
刚刚谈到的排序节点，这些节点就是整个系统共识机制的维护者，它相当于提供了一个交付保证的通信组织，为客户端以及对等节点之间提供了一个共享的通信通道，同时提供广播服务。在Fabric中，这样的共识服务是可插拔模块，目前有主要三种模式，Solo、Kafka、BFT。Solo是一种部署在单个节点的时序服务，只能支持单链；而Kafka能够容忍部分节点宕机失效，但是不能容忍恶意节点，BFT则是我们很熟悉的拜占庭，n>=3f+1则有效。
分布式账本结构
在区块链上，账本存储了所有历史交易和状态改变记录，在Fabric中，每一个通道中都有一个共享账本，账本的结构如下：
可以看到每一个节点维护的账本以文件系统的形式存储于本地，主要是四个数据库，包括账本索引库（快速查询账本）、区块索引库（快速查询区块和交易）、状态数据库、历史数据库，状态数据记录的是交易执行的结果，记录的是所有变量键值的最新值，也叫作“世界状态”；历史数据记录了每一个状态数据的历史信息，可以用于区块提交的回复。一般的交易记录分为，保存到账本数据中、更新状态数据、更新历史信息数据。
网络模型
对于Fabric的网络环境可以参考下面：
对于这个网络，我们可以看到有四个企业R1、R2、R3、R4被写入一个网络协议中，R4是这个网络的发起者，它也没有任何打算与企业进行交易，整个网络间，R1与R2有私自联系的需求，R2和R3也是，企业R1有一个客户端应用可以通过通道C1进行交易，R2则可以在通道C1和C2进行交易，R3与R2类似。对于节点1维持了一个账本L1的副本与通道C1联系起来，节点2维持了一个账本L1与C1联系、一个L2与C2联系。有一个订购服务O4为节点提供服务并且利用系统的通道，用于将块分发。
通道
在上面提到的通道是Fabric的一个特色，它是在两个或者多个成员之间专门为私人的和机密的交易为目的而建立的私有“子网”，正如上面我们所说到的每一个交易都在一个指定的通道中执行，在通道中交易必须通过通道中的每部分认证和授权，要加入一个通道都必须有成员服务提供商获得的身份标识，用于鉴定节点在通道中是什么节点与服务。
PS：
成员服务
成员服务是为了对身份进行授权，这一块涉及了PKI以及MSP，PKI包含了数字证书、公钥私钥、证书颁发机构、废弃证书列表。这一部分相对是密码学的东西，不过还是比较简单，这里不多说，总之就是对于信任的机构开出的身份认证证书进行验证，实现一个身份识别的作用，但是仅有PKI是不够的，就像有很多支付方式：支付宝、银联、微信，但是这个平台支持什么支付方式是有限制的，MSP就是这个功能，MSP支持了本地以及频道MSP：频道就是我们所说的通道，对于每一个通道应该是私密的，因此这一部分的验证是有必要的，而本地MSP则是对对等节点进行验证，例如组织成员的身份验证。这基本都是密码学的验证系统，这里不多述。
链码服务
这里也不多述，简单介绍一下执行流程：客户端提交提案，包含了链码函数以及调用函数，以proto消息发送到背书节点，背书节点调用SHIM包创建链码仿真执行内容，然后初始化内容，调用参数，基于读取和写入的Key生成读写操作集，背书集群节点模拟提案执行（读写等操作），如果执行结果返回成功，就执行背书，如果失败，返回错误码，背书节点对交易结果签名，返回客户端，如下图：
