由于比特币的流行，以太坊和一些别的衍生技术成长起来，对一些有创新力的企业开始关注区块链底层技术，分布式账本和分布式应用平台。然而，许多企业需要更高的性能，这是那些无须许可的区块链技术无法达到的。另外，在许多场景下，参与者的身份认证是一个核心诉求，例如金融领域
对于企业使用，有如下比较需求：
基于此，Hyperledger Fabric应运而生。Hyperledger Fabric 是一个开源的企业级需要许可的分布式账本技术平台。Fabric是一个高度模块化和可配置架构。同时，Fabric的智能合约是第一个支持所有通用编程语言，例如Java, Go and Node.js。
Hyperledger Fabric还支持可插拔的共识协议，用户可以根据自己的用例和模型进行选择。
可采用不同的共识机制，目前支持Kafka，BFT-SMaRt和Solo。Kafka是基于ZooKeeper的Paxos实现，可以实现50%的CFT，不能容忍不诚实的节点；BFT-SMaRt则是PBFT的实现，可以实现33%的BFT；Solo是单order节点的ordering，主要用于开发测试。
大部分区块链（也包括公链）所采用的流程是：将transactions排序打包然后同步到每个节点（通常采用广播的方式），每个节点再按顺序执行（或者称之为验证）这些交易。在论文中，这种架构被称之为“order-execute architecture”，即先“order”再“execute”。
这样的架构存在一些问题，
首先所有节点按照顺序执行交易会限制性能（例如TPS），通常将不相关的操作并发执行可以提升性能，但是对智能合约很难做到并发，因为代码之间的依赖关系很难确定。此外，order-execute最大的限制是，所有节点所执行的交易必须满足确定性（must be deterministic）。类似以太坊这样采用Solidity这样的编程语言可以一定程度上保证代码确定性，但对于更流行的语言（例如Go，Java，C/C++），则很难保证确定性（比如Go中的map iterator就无法保证确定性）。
在联盟链中，一种可行的做法是，仅让部分节点运行代码，然后同步最终状态（state）至全网。这样子一方面通过选择运行代码的节点从而保证代码运行的一致性，并且减少了验证节点数也提升了性能。
在上述架构中，智能合约这种分布式应用包括了两个部分：
chaincode：即原来的smart contract code，在execute阶段可以运行，值得注意的是，还有一种特殊的system chaincodes，这类chaincodes定义了整个链的底层设置，包括validation system chaincode和endorsement system chaincode
endorsement policy：可以理解为独立于共识模块的一种验证或者背书机制。传统consensus包括了验证节点是否作恶以及交易本身是否正确两个任务，而在Fabric中，将后者抽离成为endorsement policy。实际上这个模块也是可以替换的，比如“五个endorser节点中只要有三个执行结果一致则完成验证”这种策略完全可以换成“只需要XXX endorser节点完成执行则通过验证”。
client发起交易，首先将交易信息（propose message）发给定义好的若干endorsers，注意此处的endorsers是由交易本身的chaincode和其中的 endorsement policy共同决定；此处propose message包括信息如下：
tx=<clientID, chaincodeID, txPayload, timestamp, clientSig>
clientID:提交交易的client的ID
chaincodeID：交易所属的chaincode的ID
txPayload：交易本体信息
timestamp：时间戳
clientSig：client签名
endorser收到message后，用client公钥验证clientSig，然后运行交易并验证输出结果。如果该endorser被选择为背书节点，则把结果发回给提交的client；
该client收集每个endorser返回的信息，当满足endorsement policy后，则进入ordering阶段，反之该交易失败；
client将通过endorsement的交易广播至所有orderers（表示为broadcast(tx)），后者通过某种共识机制对所有通过endorsement的交易进行排序，保证所有节点的数据满足时序一致性；
orderers再将排序后的交易广播至其他peers（包括了endorsing peers和non-endorsing peers），这里广播的实际上就是一个包含了若干交易的block和一个sequence number；
所有peers验证block之后，更新自身的ledger，即完成上链。
当然上述流程中有一些较强的假设，比如对于P2P传输而言，需要满足liveness，即broadcast(tx)操作在有限的时间内一定可以到达所有其他节点。
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所
