区块链大致可分为公有链和联盟链。联盟链是现有中心化商业团体联盟之间进行商业活动的手段和渠道。
HyperledgerFabric是由IBM牵头发起的一个代表性的联盟链项目，于15年底移交给Linux基金会维护，成为开源项目。Hyperledger基金会的成员包括IBM，Intel，思科等。
Fabric架构演变
Fabric的架构目前经历了两个版本的演进，最初的0.6版本只能被用来做商业验证，无法被应用于真实场景中。主要原因就是结构简单，基本所有的功能都集中在peer节点，在扩展性、安全性和隔离性方面有着天然的不足，如图1所示。在后来推出的1.0正式版中，将peer节点的功能进行分拆，把共识服务从peer节点剥离，独立为Orderer节点提供可插拔共识服务。更为重要的一个变化就是加入了多通道功能，可实现多业务隔离，因此在0.6版本的基础上有了质的飞跃。
图1Fabricv0.6架构
概念术语
Auditability：在一定权限和许可下，可以对链上的交易进行审计和检查。
CertificateAuthority：负责身份权限管理，又叫MemberService或IdentityService。
Chaincode：区块链上的应用代码，扩展自“智能合约”的概念，支持Go、Node.js等编程语言，运行在隔离的容器环境中。
Orderer：Fabric1.0架构中的共识服务角色，可以对交易进行排序，批量打包，生成区块，发给Peer节点。一个区块链网络中有多个Orderer节点，它们共同提供排序服务。排序服务可以通过不同的方式实现，从一个中心化的服务,到分布式协议。
Endorser：Fabric1.0架构中的一类peer节点角色，负责检验某个交易是否合法，是否愿意为之签名背书。
Committer：Fabric1.0架构中的另一类peer节点角色，负责对orderer排序后的交易进行检查，选择合法的交易执行并写入存储。
EnrollmentCertificateAuthority：负责成员身份相关证书管理的CA。
TransactionCertificateAuthority：负责维护交易相关证书管理的CA。
WorldState：一个键值数据库，用于存放链码执行过程中涉及到的状态变量。
Fabricv1.0架构
Fabricv1.0的架构如图2所示。
图2Fabricv1.0架构
Fabric联盟链中有两种类型的节点：Peer节点和Orderer节点。Chaincode部署在Peer节点上，它对账本进行读写操作。一个Peer节点可以充当多种角色，如背书者endorser,提交者committer。一个区块链网络中会有多个Peer节点。
Orderer提供了通向客户端和Peer节点的共享通信通道。提供了包含交易的消息广播服务。客户端可以通过这个通道向所有的节点广播消息。通道可以向连接到该通道的节点投递(deliver)消息。
Orderer服务支持多通道。客户端和Peer节点可以连接到一个给定的通道，并通过给定的通道发送和接收消息。多通道使得给定的peer集合接收包含相关交易的区块，从而与其他交易完全隔离，实现数据隔离和保密。如图3所示，peer1,peer2和peerN订阅红色通道，共同维护红色账本;peer1和peerN订阅蓝色通道并维护蓝色账本;peer2和peer订阅黑色通道上，共同维护黑色账本。
图3多通道
链码
链码可以认为是Fabric提供的智能合约，是上层应用与底层区块链平台交互的媒介。
所有的链码都继承两个接口，init和invoke。init接口用于初始化合约，在整个链码的生命周期里，该接口仅仅执行一次。invoke接口是编写业务逻辑的唯一入口，虽然只有一个入口，但是可以根据参数传递的不同自由区分不同业务逻辑。合约接口能获得数据分为三类：合约输入参数；与状态数据库和历史数据库交互；与其他合约的交互。
Fabric1.0交易流程
Fabric上的交易交易分两种：部署交易和调用交易。
部署交易：把Chaincode部署到peer节点上并准备好被调用，当一个部署交易成功执行时，Chaincode就被部署到peer节点上。
调用交易：客户端应用程序通过Fabric提供的API调用先前已部署好的某个chaincode中的函数执行交易，并相应地读取和写入K-V数据库，返回成功或者失败。
如下图所示，开发者创建客户端应用和Chaincode，Chaincode被部署到区块链网络的Peer节点上面。通过Chaincode来操作账本，当调用一个交易时，实际上是在调用Chaincode中的一个函数方法，令它实现业务逻辑，并对账本进行get,put,delete操作。客户端应用提供用户交互界面，并提交交易到区块链网络上。Fabric1.0交易流程如下图所示：
图4交易流程
客户端构造交易提案
客户端应用程序利用任意SDK构造交易提案propose。该提案是一个调用智能合约功能函数的请求，用来确认哪些数据可以读取或写入账本。客户端把交易提案发送给一个或多个Peer节点，交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等。
背书节点模拟执行交易
背书节点endorser收到交易提案后，验证签名并确定提交者是否有权执行操作。背书节点将交易提案的参数作为输入，在当前状态K-V数据库上执行交易，生成包含执行返回值、读操作集合和写操作集合的交易结果，这些值的集合、背书节点的签名和背书结果作为提案的结果返回给客户端SDK，SDK解析这些信息判断是否应用于后续的交易。
客户端把交易发送到共识服务节点
应用程序验证背书节点签名，并比较各节点返回的提案结果，判断提案结果是否一致以及是否参照指定的背书策略执行。客户端收到各个背书节点的应答后，打包到一起组成一个交易并签名，发送给Orderers。
共识排序，生成新区块，提交交易
Orderers对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，调用deliverAPI投递消息，发送给提交节点。Committer收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改K-V状态数据库。
补充说明
超级账本V1.0将执行链码的节点与决定出块顺序的节点相分离。每个peer维护分布式账本的一个copy，orderers则仅提供共识排序服务，而不必维护账本的copy。
clients首先要将交易提交给peers的一个子集执行chaincode。必须有足够多的endorsers背书一致后，clients才将更新后的状态以及背书签名等提交给orderers。orderers通过共识协议输出block的排序。最后，所有的peers再对背书进行验证。从而：链码的执行可以在共识排序前完成；不需要所有的peers都执行所有的链码。
clients判断提案结果是否一致主要是为了消除非确定性的影响。这主要是因为交易的执行可能因为种种原因而分叉，如果client发现大多数endorsers的执行结果不一致时，它就会认为该交易的结果是非确定性的，这笔交易也就作废了。
Fabric的优势
Fabric采用模块化架构把交易处理划分为3个阶段：通过Chaincode进行分布式业务逻辑处理和协商；交易排序(orderders)；交易的验证和提交(committers)。这样划分带来的好处：不同的阶段由不同的节点参与，不需要全网的节点都参与。网络的性能和扩展性得到优化。Peer节点和Orderder节点可以独立扩展，并可以动态增加。此外，Fabric提供可插拔架构，其共识机制和加密算法均是可插拔的，可以根据实际情况选择替换。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。