Hyperledger Fabric - 介绍

官方文档 给出了 Hyperledger Fabric 的介绍。

本文主要是基于上述文档，并根据自己对区块链的认知从文档中提取关键内容并进行重新组织。

1. 引言

最主流的两条公链 Bitcoin 和 Ethereum，它们的网络都是公开的不需要许可的 (public permissionless)。即它们的网络对任何人公开，同时参与者是匿名进行交互的。

随着区块链技术的普及，更多具有创新性的企业级应用案例也开始尝试使用区块链技术。然而，这里存在几个比较大的障碍。第一个是，公链技术达不到企业级应用案例需要的性能。第二个是，对参与者的身份标识是硬性要求，如在金融交易中必需的 KYC (Know-Your-Customer) 和 AML (Anti-Money- Laundering)。

对于企业级应用，必须考虑如下需求：

• 参与者必须是可标识的
• 网络必须采用许可制 (permissioned)
• 性能上需要很高的交易吞吐率
• 交易确认还需要低延时
• 与商业交易相关的交易和数据需要隐私性和机密性 (privacy and confidentiality)

虽然也有许多早期的区块链平台目前被用于企业级应用，但是 Hyperledger Fabric 从一开始就是为企业级应用而设计的。下面的内容主要介绍 Hyperledger Fabric 本身与其它区块链平台的差别，以及描述部分体系架构的设计动机。

2. Hyperledger Fabric

Hyperledger Fabric 是开源的企业级许可制分布式账本技术 (Distributed Ledger Technology, DLT) 平台，这与其它流行的 DLT 平台或区块链平台有一些关键的不同。

• Hyperledger 是由 Linux Foundation 建立的，Linux Foundation 本身具有非常长和非常成功的开源历史及开源项目。Hyperledger 是由多个技术会员会管理的，Hyperledger Fabric 项目由来自多个组织的人员维护。它的开发者社区包括 35 个组织和将近 200 个开发者。
• Fabric 具有高度的模块化和可配置性的架构，支持对广泛范围企业应用的创新和优化，如：银行、金融、保险、医疗、人力资源、供应链、和数字音乐分发。
• Fabric 是第一个支持采用通用编程语言编写智能合约的 DLT 平台，如 Go, Node.js, Java，而不是限制于领域特定语言 (domain-specific languages, DSL)。这意味着大多数企业已经具备开发智能合约的技能集，而不需要额外的培训来学习一门新的语言。
• Fabric 平台采用的是许可制，意味着与公开无需许可的网络不同的是，参与者已经各自有一定了解，而不是匿名和完全无信任的。这意味着，尽管参与者之间可能不会完全信任对方（例如，他们可能是同一行业的竞争者），但网络可以在治理模型下运行，该治理模型是基于参与者之间确实存在的信任而建立的，例如处理争议的法律协议或框架。
• Fabric 平台最重要的特色之一是它对可插拔共识协议的支持，该协议使平台可以更有效地进行定制，以适应特定的用例和信任模型。例如，当部署在单个企业中或由受信任的机构运营时，完全拜占庭式的容错共识可能被认为是不必要的，并且会严重拖累性能和吞吐量。在这种情况下，崩溃容错 (crash fault-tolerant, CFT) 共识协议可能绰绰有余，而在多方，去中心化的用例中，可能需要更传统的拜占庭容错 (byzantine fault tolerant, BFT) 共识协议。
• Fabric 利用不需要原生加密货币的共识协议来实现代价昂贵的挖矿操作或智能合约的执行。避免使用加密货币会降低一些重大的风险，并且无需进行加密货币挖矿操作就意味着可以以与任何其他分布式系统大致相同的运营成本来部署该平台。

这些差异化设计功能的结合使 Fabric 在交易处理 (transaction processing) 和交易确认延迟 (transaction confirmation latency) 方面成为当今性能最好的平台之一，并实现了交易和智能合约 (在 Fabric 中称为 chaincode) 的隐私和机密性 (privacy and confidentiality)。

下面我们将更详细地探讨这些差异化功能。

3. 高度模块化

Hyperledger Fabric 专门设计为具有模块化的体系结构。无论是可插拔共识，可插拔身份管理协议 (例如 LDAP 或 OpenID Connect)，密钥管理协议还是密码库，该平台将可配置性作为它的设计核心，这样可以满足企业应用需求的多样性。

在较高的层次上，Fabric 由以下模块化组件组成：

• ordering service: 可插拔订单服务在交易顺序上达成共识，然后将区块广播给对端节点。可以简单地类比于比特币中的挖矿模块和 P2P 模块。
• membership service provider: 可插拔成员资格服务提供者负责将网络中的实体与加密身份相关联。可以简单地认为是 Fabric 中特有的网络许可模块。
• peer-to-peer gossip service: 可选的点对点传输服务通过向其他对等节点订购服务来分发输出区块。可以简单地类比于比特币中的 P2P 模块。
• chaincode: 智能合约 ("chaincode") 在容器环境 (例如 Docker) 中运行以进行隔离。它们可以用通用编程语言编写，但不能直接访问帐本状态。(?)
• 账本可以配置为支持各种 DBMS。
• endorsement and validation policy enforcement: 可插拔的认可和验证策略实施，可以针对每个应用程序进行独立配置。可以简单地类比于比特币的矿工，但是这里更像是联盟链中的各个组织，而且单个组织可以只和特定的逻辑挂钩，可以简单类比于以太坊 2.0 中的分片技术。

业界普遍认为，没有一个区块链可以全部统治。可以通过多种方式配置 Hyperledger Fabric，以满足多种行业用例的不同解决方案要求。

4. 许可制区块链 VS 无需许可制区块链

在无需许可的区块链中，几乎任何人都可以参与，且每个参与者都是匿名的。在这种情况下，除了一定高度之前的区块链状态是不可变的之外，别无其他信任。为了解决这种缺乏信任的场景，无需许可的区块链采用工作量证明 (Proof Of Work, POW) 共识机制，并提供原生的加密货币作为激励。

在许可制区块链中，参与者是具有身份标识的，且大多数还经过了审核，因此整个网络是在具有一定程度信任的治理模型下运行的。许可制区块链提供了一种方法来保护一组具有共同目标但可能不会完全相互信任的实体之间的交互。通过依赖参与者的身份，许可制区块链可以使用更传统的崩溃容错 (CFT) 或拜占庭容错 (BFT) 共识协议，这些协议不需要昂贵挖矿成本。

在这种许可制的情况下，参与者通过智能合约有意引入恶意代码的风险得以降低。首先，参与者是相互了解的，并且遵循针对网络和相关交易类型建立的认可政策，所有活动 (无论是提交应用程序交易，修改网络配置还是部署智能合约) 都记录在区块链上。与完全匿名不同的，这可以根据治理模型的条款轻松地确定有罪的一方并处理恶意事件。

5. 智能合约

智能合约，或者在 Fabric 中称为 "chaincode"，是一种受信任的分布式应用程序，可从区块链和对等节点之间的共识机制中获得安全性/信任。用以实现区块链应用程序的业务逻辑。

应用智能合约的三个要点，尤其是将其应用于平台时：

• 网络中能够同时运行许多智能合约
• 它们可以动态部署 (在许多情况下，任何人都可以部署)
• 应用程序代码应被视为不受信任，甚至可能是恶意的

现有的大多数具有智能合约功能的区块链平台都遵循一种订单执行 (order-execute) 架构，其中的共识协议为：

• order: 验证并订购交易，然后将其传播到所有对等节点
• execute: 然后，每个对等节点依次执行交易

order-execute 架构实际上可以在所有现有的区块链系统中找到，从以太坊等公共/非许可平台 (基于 PoW 的共识) 到 Tendermint，Chain 和 Quorum 等许可平台。

在以 order-execute 架构运行的区块链中执行的智能合约必须具有确定性。否则，可能永远无法达成共识。为了解决非确定性问题，许多平台要求以非标准或特领域的语言 (例如 Solidity) 编写智能合约，以便消除非确定性操作。这阻碍了广泛采用，因为它要求开发人员编写智能合约来学习一种新语言，并可能导致编程错误。

此外，由于所有交易由所有节点顺序执行，因此性能和规模受到限制。智能合约代码在系统中的每个节点上执行的事实要求采取复杂的措施来保护整个系统免受潜在的恶意合约的侵害，以确保整个系统的弹性。

6. Fabric 提供全新的方法来执行智能合约

Fabric 为交易引入了一种新的架构，称之为 execute-order-validate。它通过将交易流分为三个步骤来解决 order-execute 模型面临的弹性、灵活性、可伸缩性、性能和机密性挑战：(?)

• execute: 执行交易并检查其正确性，从而认可 (endorsing) 该交易
• order: 通过 (可插拔) 共识协议 order 交易
• validate: 在将交易提交到账本之前，根据特定于应用程序的背书策略 (endorsement policy) 验证交易

这种设计与 order-execute 范式完全不同，Fabric 在达成交易的最终协议之前执行交易。

在 Fabric 中，特定于应用程序的背书策略指定需要其中的哪些对端节点保证给定智能合约的正确执行。因此，每笔交易只需要由满足交易认可策略所需的对端节点的子集执行 (认可) 即可。这允许并行执行，从而提高了系统的整体性能和规模。第一阶段还消除了任何不确定性，因为不一致的结果可以在 order 前滤除。

因为消除了不确定性，所以 Fabric 是第一个启用通用编程语言使用的区块链技术。在 1.4.3 版本中，可以使用 Go、Node.js、Java 编写智能合约。

注释

这里尝试对 execute-order-validate 进行类比以加深理解，这里与以太坊 2.0 进行类比。以太坊 2.0 包含分片节点和中继节点，各分片节点之间可以执行不同的合约，各分片内部维护片内本身的共识，再由中继节点维护各分片之间的共识，从而维护以太坊网络的整体共识。那么，这里把 order 服务类比于中继节点，execute 的节点为分片节点，根据业务逻辑划分成不同的分片节点，即联盟链的组织节点。之间，通过 channel 进行连接。

7. 隐私性和机密性

正如前面已经讨论的那样，在一个利用 POW 作为共识模型的公共无许可的区块链网络中，交易在每个节点上执行。这意味着合约本身和其所处理的交易数据都不会保密。每个交易及其实现的代码对于网络中的每个节点都是可见的。在这种情况下，我们已经将合约和数据的机密性换成了 POW 交付的拜占庭容错共识。

对于许多企业级应用而言，缺乏机密性可能会成为问题。例如，在供应链合作伙伴网络中，可能会为某些消费者提供优惠价格，以巩固关系或促进额外销售。如果每个参与者都能看到每份合约和交易，那么就不可能在完全透明的网络中维持这种业务关系–每个人都希望获得优惠的价格！

再举一个例子，考虑证券行业，在该行业中，建立仓位 (或出售仓位) 的交易者不希望竞争对手知道这一点，否则他们将寻求参与竞争，从而削弱了交易者的竞争能力。

为了解决企业级应用对隐私和机密性的需求，区块链平台采用了多种方法。所有的平台都有其取舍。

加密数据是提供机密性的一种方法。但是，在利用 POW 达成共识的无许可网络中，加密数据位于每个节点上。如果有足够的时间和计算资源，则可能会破坏加密。对于许多企业级应用而言，其信息可能遭到破坏的风险是无法接受的。

零知识证明 (Zero knowledge proofs, ZKP) 是为解决此问题而正在探索的另一个研究领域，这里的权衡是，目前计算 ZKP 需要大量时间和计算资源。因此，在这种情况下的权衡是为了保密。

的利用可替代共识机制的许可制上下文中，人们可能会探索一些将机密信息仅分配给授权节点的方法。

Hyperledger Fabric 是采用许可制的平台，可通过其通道 (channel) 架构实现机密性。本质上，Fabric 网络上的参与者可以在参与者的子集之间建立一个“通道”，该通道应被授予特定交易集的可见性。将此视为网络覆盖。因此，只有那些参与通道的节点才能访问智能合约 (链码, chaincode) 和交易的数据，从而保留了两者的隐私和机密性。

为了改善其隐私和机密性功能，Fabric 增加了对私有数据 (private data) 的支持，并在未来开发可用的零知识证明 (ZKP)。随着它的可用，将对此进行更多介绍。

8. 可插拔的共识机制

交易的顺序被委托给模块化组件以实现共识，该组件在逻辑上与执行交易并维护帐本的对端节点分离。具体来说就是订购 (ordering) 服务。由于共识是模块化的，因此可以根据特定部署或解决方案的信任假设量身定制其实现。这种模块化体系结构允许平台依赖完善的工具包来进行 CFT (崩溃容错) 或 BFT (拜占庭容错) 排序。

Fabric 当前提供两种 CFT 订购服务 (ordering service) 实现。第一个基于 Raft 协议 的 etcd 库。另一个是 Kafka (内部使用 Zookeeper)。有关当前可用订购服务 (ordering service) 的信息，请查看有关订购的概念性文档。

还要注意，它们不是互斥的。Fabric 网络可以具有支持不同应用程序或应用程序需求的多种订购服务。

注释

共识机制在与对端节点独立的模块组件中实现。

9. 性能和可扩展性

区块链平台的性能可能会受到许多变量的影响，例如交易大小，区块大小，网络规模，以及硬件限制等。Hyperledger 社区目前正在性能和规模工作组内制定 一套措施草案。以及称为 Hyperledger Caliper 的基准测试框架的相应实现。

尽管这项工作仍在继续发展，应被视为衡量区块链平台性能和规模特征的权威，但 IBM Research 的一个团队发表了一篇 同行评审论文，评估了 Hyperledger Fabric 的体系结构和性能。本文提供了关于 Fabric 架构的深入讨论，然后使用 Hyperledger Fabric v1.1 的预发行版报告了团队对该平台的性能评估。

研究团队所做的基准测试工作为 Fabric v1.1.0 发行版带来了许多性能改进，使平台的整体性能比 v1.0.0 发行版提高了一倍以上。

10. 结论

任何对区块链平台的认真评估都应在其短名单中包括 Hyperledger Fabric。

结合起来，Fabric 的差异化功能使其成为用于许可制区块链的高度可扩展系统，支持灵活的信任假设，使该平台能够支持从政府，金融，供应链物流，医疗保健等广泛的行业用例。

更重要的是，Hyperledger Fabric 是 (当前) 十个 Hyperledger 项目中最活跃的。该平台周围的社区正在稳步增长，并且每个后续版本提供的创新远远超过了其他任何企业区块链平台。

Reference

• Introduction, https://hyperledger-fabric.readthedocs.io/en/latest/whatis.html

• Introduction, https://hyperledger-fabric.readthedocs.io/en/release-1.4/whatis.html

• Tendermint, https://tendermint.com/

• Chain, http://chain.com/

• Quorum, https://www.goquorum.com/

• Raft 协议, https://raft.github.io/raft.pdf

• etcd 库, https://etcd.io/

• Kafka, https://kafka.apache.org/

• Zookeeper, https://zookeeper.apache.org/

项目源代码

项目源代码会逐步上传到 Github，地址为 https://github.com/windstamp。

Contributor

1. Windstamp, https://github.com/windstamp