简介
由于比特币的流行，以太坊和一些别的衍生技术成长起来，对一些有创新力的企业开始关注区块链底层技术，分布式账本和分布式应用平台。然而，许多企业需要更高的性能，这是那些无须许可的区块链技术无法达到的。另外，在许多场景下，参与者的身份认证是一个核心诉求，例如金融领域
对于企业使用，有如下比较需求：
- 参与者的身份是明确的，可识别的
- 进入网络是必须被许可的
- 较高的性能，并发
- 事务确认的低延迟
- 适用于商业场景私有的和保密的事务
基于此，Hyperledger Fabric应运而生。Hyperledger Fabric 是一个开源的企业级需要许可的分布式账本技术平台。Fabric是一个高度模块化和可配置架构。同时，Fabric的智能合约是第一个支持所有通用编程语言，例如Java, Go and Node.js。
Hyperledger Fabric还支持可插拔的共识协议，用户可以根据自己的用例和模型进行选择。
模块化
- ordering 可插拔建立共识的服务，将多个不同的事务以确定的顺序打包成一个区块，然后广播这个区块到其他peers。
可采用不同的共识机制，目前支持Kafka，BFT-SMaRt和Solo。Kafka是基于ZooKeeper的Paxos实现，可以实现50%的CFT，不能容忍不诚实的节点；BFT-SMaRt则是PBFT的实现，可以实现33%的BFT；Solo是单order节点的ordering，主要用于开发测试。
- CA 单独的服务，用于用户身份识别
- Smart contracts (“chaincode”) 运行在隔离的容器环境中(Docker),可以使用不同的通用语言编写，但是不能直接访问账本状态
- endorse peer 可以单独的为每个应用程序配置不同的验证策略
- Committer：负责维护区块链和账本结构（包括状态DB、历史DB、索引DB等）。该节点会定期地从Orderer获取排序后的批量交易区块结构，对这些交易进行落盘前的最终检查（包括交易消息结构、签名完整性、是否重复、读写集合版本是否匹配等）
order-execute architecture
大部分区块链（也包括公链）所采用的流程是：将transactions排序打包然后同步到每个节点（通常采用广播的方式），每个节点再按顺序执行（或者称之为验证）这些交易。在论文中，这种架构被称之为“order-execute architecture”，即先“order”再“execute”。
这样的架构存在一些问题，
首先所有节点按照顺序执行交易会限制性能（例如TPS），通常将不相关的操作并发执行可以提升性能，但是对智能合约很难做到并发，因为代码之间的依赖关系很难确定。此外，order-execute最大的限制是，所有节点所执行的交易必须满足确定性（must be deterministic）。类似以太坊这样采用Solidity这样的编程语言可以一定程度上保证代码确定性，但对于更流行的语言（例如Go，Java，C/C++），则很难保证确定性（比如Go中的map iterator就无法保证确定性）。
在联盟链中，一种可行的做法是，仅让部分节点运行代码，然后同步最终状态（state）至全网。这样子一方面通过选择运行代码的节点从而保证代码运行的一致性，并且减少了验证节点数也提升了性能。
Execute-order-validate architecture
- 执行一个事务，然后校验正确性, 从而为它背书
- 通过可插拔的共识协议来背书
- 在提交到账本之前，根据应用程序指定的背书策略来校验事务
在上述架构中，智能合约这种分布式应用包括了两个部分：
chaincode：即原来的smart contract code，在execute阶段可以运行，值得注意的是，还有一种特殊的system chaincodes，这类chaincodes定义了整个链的底层设置，包括validation system chaincode和endorsement system chaincode
endorsement policy：可以理解为独立于共识模块的一种验证或者背书机制。传统consensus包括了验证节点是否作恶以及交易本身是否正确两个任务，而在Fabric中，将后者抽离成为endorsement policy。实际上这个模块也是可以替换的，比如“五个endorser节点中只要有三个执行结果一致则完成验证”这种策略完全可以换成“只需要XXX endorser节点完成执行则通过验证”。
Hyperledger Fabric是目前主流的开源联盟链产品之一，自2016年5月12日开辟代码仓库之日起，已有快3年的时间了，产品趋于稳定，功能也越来越完善，正在适配不同业务场景下的需求。纵观Fabric的发布历程，在v0.6.1-preview版本至v1.0.0的版本迁移过程中架构发生了明显的变化，在v1.0.0之后每个小版本中加入了一些新的feature，来支持不同的业务场景以及完善相应的功能。
应用程序和节点（Applications and Peers）
https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
对等节点和排序节点一起工作来确保账本在每个节点中都保持最新。在这个例子中，应用程序 A 连接到 P1 并调用 chaincode S1 来查询或更新账单 L1。 P1 调用 S1 来生成包含查询结果或建议账本更新的提案响应。应用程序 A 收到提案响应，对于查询，过程现在已完成。 O1 将整个网络中的交易收集到块中，并将这些交易分发给所有节点，包括P1。P1 在处理 L1 之前会先验证交易。一旦 L1 被更新， P1 产生一个由 A 接收的事件来表示完成。
节点可以立即将查询结果返回给应用程序，因为满足查询所需的所有信息都位于节点的账单本地副本中。节点不会咨询其他节点，以便将查询返回给应用程序。但是，应用程序可以连接到一个或多个节点来发出查询 —— 例如以证实多个对等节点之间的结果，或者如果怀疑信息可能过期，则从不同的节点检索更新结果。在图中，您可以看到分类账查询是一个简单的三步过程。
更新事务与查询事务比较相似，但有两个额外的步骤。虽然账本更新应用程序也连接到节点以调用 chaincode，与账单查询应用程序不同，单个节点无法执行账单更新，因为其他节点必须首先同意这种操作 —— 这就是共识的过程。因此，节点向应用程序返回更新提议 —— 这个节点将先获得其他节点的同意。第一个额外的步骤 —— 也即第四步 —— 要求应用程序发送一组适当的更新提议到整个节点网络中，该交易需要被整个网络节点所同意。这是通过应用程序使用 排序节点将事务打包进区块 来实现的，并将它们分发到节点的整个网络，以便在应用到每个节点的账本副本之前，可以对其进行验证。由于整个共识处理需要一些时间才能完成（秒），因此应用程序会异步通知，如步骤5所
