核心基础服务

对Fabric的主体模块及流程有一定认识后，我们在继续深究里面的细节功能，为了让整个框架能运作起来当然需要用到更多的技术手段，这里主要讲几个相对核心的功能点。

• Gossip Protocol

回顾上述的交易流程图中，Orderer将交易数据排序打包后分发给各个Peer节点，若假设有成百上千甚至更多的Peer节点都由Orderer节点进行分发那么首先单点的压力是否能承受，其次如果出现失败的情况又该如何同步等问题。在Fabric的实现当中，采用的是让Peer节点之间相互同步而非Orderer节点来分发消息，每个Peer节点都会维护其他Peer节点的信息，随机的与部分其他Peer节点进行通信互换区块信息，传输时利用Peer-to-Peer的技术去加快数据的传输，而Orderer节点仅是将打包好的区块发送至特定的Leader Peer（可手动指定也可由Orderer自行选取），然后Peer节点之间在通过Gossip协议相互交换数据达到最终一致性。

• Eventhub

那么根据上面描述的Gossip协议，可见每个Peer节点写入区块的时间可能是不一致的，那么client端进行业务逻辑判断（如事务逻辑）如何获知特定交易数据是否已经写入Peer节点内呢？实际上每个Peer都会和client端保持一个Eventhub的连接，在Peer节点完成交易后，如将区块写入账本后便会发送消息通知各个client，但是也要注意，回调总是不可信的，存在消息丢失的可能性，Fabric也并没有保证消息的最终到达。

• Read-Write Set

在Peer节点将一个区块写入账本前，如上所述会进行背书策略的校验，以防止恶意节点的入侵，达到有权重划分，可实名制交易的联盟链。除去验证各节点签名验证，当然还要比对个节点输出的结果是否一致，那如何去衡量结果是否一致呢？这里提出了读写集合的概念，一段程序我们化做为IO，如果使用相同Input得出一致的Output，那么我们便可以认同在这一特定情况下函数性质是相同的。在这里我们并不关心Input，只要写入/修改的数据一致便可认为达成了共识，所以Write Set是用于保存最终需要写入/修改的数据集，这个是用来比对各节点的结果集是否一致，而Read Set中存着各节点执行合约中读取了哪些数据，并会把这个数据的当前版本记录在Read Set中，在Peer节点写入区块前也会校验Read Set中读取的数据版本是否和当前数据环境中的版本一致，以防止交易并发带来的错乱。

认证体系

刚接触区块链的同学可能会有一个概念，区块链应该保证公平公正公开，所以形成了“公有链”的一个概念，例如比特币，全员可参与，对所有人透明。但是区块链并不仅局限于“公有链”，对于大多数业务场景来说，应该属于“联盟链”，即由特定成员参与、有权重分配的业务，例如银行间的对账环节，A、B、C银行互相的交易中，A、B银行间的交易当然不愿意透露给C银行，而A、B、C银行的所有交易或许都要上报给央行，可见此处“公有链”是不可取的。那如何去保证公平公正公开呢？首先代码必须对成员开源，所有服务可由自身搭建，利益相关成员共同审核“智能合约”，全员共识的背书策略，相互授权或由可信第三方认证中心授权。那么最基础的一道认证体系便显得尤为重要了，我们在来看看Fabric是如何去实现他的认证体系的。

首先有几个概念需要明确，Fabric的CA认证中心是基于PKI体系打造的，相关资料可参考如下。

• PKI(Public Key Infrastructure)

• X.509 证书

Membership Service Providers(MSP)

在划分成员结构的时候Fabric用MSP来定义一个成员，在最佳实例推荐中，一个企业或者机构可以是一个单独的MSP，例如上述说到的供应链的案例，由例图来说明，核心企业便是一个MSP，银行和供应商各代表一个MSP，那么在一个MSP下可以有多个Peer节点，而不同的授权便有不同的功能，MSP具体应用场景主要如下。

• 在部署智能合约或者初始化时需要拥有对应CA赋权的证书才可执行（默认为PeerAdmin用户）。

• 为新节点或用户注册证书时，需要CA对该操作证书赋予权限（一般为Admin用户）。

• 在背书策略中可通过MSP来代表背书成员，可设定单个Peer节点代表其MSP达成协议（也可以要求全部Peer节点通过才达成协议）。

• 在跨MSP间的Peer节点通信，先通过各MSP内指定的Anchor Peer收集MSP内的Peer列表，然后通过各MSP下的Anchor Peer交互其Peer列表，将其他MSP下的Peer列表同步到内部Peer后，便通过Gossip协议Peer节点间随机通信。

• 每个MSP都有自己独立的CA节点，为其提供所有的证书需求，各MSP共享其CA节点的ROOT证书达到互相认证。

• 匿名交易。在一笔交易中，包含着每一个参与背书的用户证书，这可以认为是公开实名制的交易，所有链内成员都可以看见每一笔交易是由谁参与的，但是如果我们希望匿名交易该如何实现呢？在Fabric 0.6版本内有Ecert和Tcert的概念，Ecert即为用户的证书，而Tcert则是用于匿名交易，用户可以通过向CA申请一批Tcert用于交易，而该Tcert不包含用户的信息，当需要验证查验信息时可通过CA来认证该用户的身份。（此功能在1.0版本尚未实现）

• Revoke，废除证书。在PKI体系中，其最大的优势便是Off line的，即在证书颁发后，不需要CA节点的存在也可以在本地进行认证，而遇到很大的问题是类似于废除证书时如果希望能即是将废除证书的消息通知到各个节点，目前的做法是需要CA节点保持在线并与各节点保持通信。（获取Tcert也需要CA节点在线）

在每个区块链中其相关的配置信息也包含了MSP的划分，阐述相对复杂这里便不描述，有兴趣可以参考官方文档 ：）

难点及待解决的问题

上述篇幅主要是给读者对Fabric的整体框架有基本的认识，仍有许多细微的问题无法一一讨论。当然，在区块链尚未大规模能应用于市场下其技术也是不完善的，在Fabric中也有许多需要解决的难点问题。

在官方推荐的实践当中，划分数据的隔离是通过账本的粒度进行隔离，不关联的交易便在不同的账本中了，但是实际业务当中，总有需要在单账本内进行数据隔离的场景，早前已经看到有相关的设计文档出稿了，不过距离正式发布该功能就不确定合适能完成了，目前只能自行在业务逻辑中对数据进行加密隔离。

当两个数据通过账本隔离后需要交互的场景目前来看是比较难实现的，及跨账本调用，首要解决的问题便是认证模型如何去进行融合。

目前想要接入区块链的成本仍然是很高的，即便Fabric项目大部分功能都无法通过可视化的配置，需要了解更多的底层细节才能正确搭建环境及配置。