fabric社区发展概况

前言

官网：https://github.com/hyperledger/fabric
fabric作为联盟链底层的基础设施已经发展几年，也陆续在一些场景中落地。在发展过程中，也在不断完善。从最早fabric0.6版本到现在1.4，1.X版本后面会停止更新，会切换到2.0版本。本文就从fabric发展历程，把几个版本主要的特性做一下总结，也可从中发现商业落地对社区发展的一些推动。

fabric主要版本特点

fabric0.6

fabric0.6算是最早的一个release版本，peer节点承担记账和共识功能，peer节点压力比较大，系统性能和扩展性不好，难以商业落地。其共识算法采用的是PBFT算法。PBFT算法的最大容错节点数量是(n-1)/3, pbft 算法支持容错故障节点之外，还需要支持容错作恶节点。另外，其他各个模块的耦合性也比较大。在商业落地应用时，特别是互联网环境，网络环境恶劣情况下，容易出现区块不同步的问题，后面1.0版本进行了拆分，节点拆分成peer+orderer节点，peer主要负责验证，记账功能，orderer节点负责共识功能，共识算法改成zk+kafka，提高了交易性能。

fabric1.0

• 节点拆分:peer+orderer
  系统更加模块化，扩展性，性能均有提高，提高了商业落地的可能性。

• 共识：zookeeper+kafka

fabric1.0采用了松耦合模块化的方式，解耦了peer，orderer节点，共识算法也改成了zookeeper+kafka。共识这一块就只支持容错误节点，不支持容作恶节点，其最大容错节点为:(n-1)/2.在引入zk+kafka后系统复杂度上会增加，另外网络连接规模也增大，在一些场景中也比较容易出现区块不同步问题，后来发现基本上是因为网络问题，以及orderer与kafka之前共识问题。在商业落地中需要解决这些问题。

fabric 1.2

• private data

支持同一channel内只对指定的collection中的subset可见。
具体地，chaincode进行模拟执行，模拟执行的结果分为公开部分和私密部分，peer对其中的公开部分进行签名并返回给客户端，其中公开部分指公开的读写集以及私密数据读写集hash。 对于模拟执行过程中的私密数据部分，模拟执行完毕后得到的私密数据，gossip模块一方面对这些数据按照之前制定的共享规则进行分发。另一方面将这些数据提交到transient store中。接收到该私密数据的节点同样将该私密数据提交到transient store中。
客户端将返回结果发送给orderer做共识。可以发现在交易过程中只对模拟执行的公开部分进行处理的话。模拟执行的私密数据部分是不会放在链上的,上链的是私密数据的hash值，作为记录和监管。

fabric1.4

• raft共识

  1.4主要的改变就是加入了raft共识，这个共识是从etcd上引入进来的，这样的好处是降低了系统的复杂度，维护更加方便，共识效率上也会更高。到目前为止fabric支持Solo, Kafka, Raft共识，这个可以通过配置文件来进行配置。

• Fabric operations service
  peer、orderer开放一些接口。来实现节点的健康检查、日志等级的改变、go routine stack获取、grpc info输出等。

• private data 共享给新加入collection的peer

• private data client access control

• peer 区块回滚
  提供peer回滚区块功能，在数据冲突时需要回滚到之前的区块。私有数据会保持不变，因为私有数据不能从Orderer上或者其他peer上拉取。

• specify orderer endpoint at orgnization level

• bug fix
  bug的修复。这个版本也将社区长期支持的发布版本。

fabric2.0

• chaincode lifecycle

  多个组织指定policy,而不是由一个组织就可决定。
  升级policy也要满足指定的组织数，而不是由一个组织就可决定。
  更简单的升级，不必重新安装chaincode
  更简便的操作

• fabric token
  支持在channel上代表资产的token.采用 Unspent Transaction Output (UTXO) 模型来进行相关操作。这个模型也是比特币所采用的模型。

后语

从fabric的发展看，基本上是从可用性到后面的全场景的覆盖这样的一个过程，用起来也是越来越方便，场景覆盖也是越来越全面。