Hyperledger Fabric 2.0 使用教程

简介

区块链是一个由分布式网络中的节点维护的不可篡改的账本。

Hyperledger Fabric 是一个开源的企业级许可分布式账本技术（Distributed Ledger Technology，DLT）平台，专为在企业环境中使用而设计。

模块化

Fabric 由以下模块化的组件组成：

• 可插拔的排序服务对交易顺序建立共识，然后向节点广播区块；
• 可插拔的成员服务提供者负责将网络中的实体与加密身份相关联；
• 可选的P2P gossip 服务通过排序服务将区块发送到其他节点；
• 智能合约（“链码”）隔离运行在容器环境（例如 Docker）中。它们可以用标准编程语言编写，但不能直接访问账本状态；
• 账本可以通过配置支持多种 DBMS；
• 可插拔的背书和验证策略，每个应用程序可以独立配置。

许可区块链

在一组已知的、已识别的且经常经过审查的参与者中操作区块链，这些参与者在产生一定程度信任的治理模型下运作。

通过依赖参与者的身份，许可区块链可以使用更传统的崩溃容错（CFT）或拜占庭容错（BFT）共识协议，而不需要昂贵的挖掘。

在许可的情况下，降低了参与者故意通过智能合约引入恶意代码的风险。

链码

三个关键点适用于智能合约，尤其是应用于平台时：

• 多个智能合约在网络中同时运行，
• 它们可以动态部署（很多情况下任何人都可以部署），
• 应用代码应视为不被信任的，甚至可能是恶意的。

顺序执行架构，其中共识协议：

• 验证并将交易排序，然后将它们传播到所有的节点，
• 每个节点按顺序执行交易。

结果一定是确定的。

执行-排序-验证架构，它将交易流分为三个步骤：

• 执行一个交易并检查其正确性，从而给它背书，
• 通过（可插拔的）共识协议将交易排序，
• 提交交易到账本前先根据特定应用程序的背书策略验证交易

在交易顺序达成最终一致前执行交易。每个交易只需要由满足交易的背书策略所必需的节点的子集来执行（背书）。这样可以并行执行，从而提高系统的整体性能和规模。第一阶段也消除了任何非确定性，因为在排序之前可以过滤掉不一致的结果。

隐私和保密

在一个公共的、非许可的区块链网络中，利用 PoW 作为其共识模型，交易在每个节点上执行。这意味着合约本身和他们处理的交易数据都不保密。每个交易以及实现它的代码，对于网络中的每个节点都是可见的。

Hyperledger Fabric 是一个许可平台，通过其通道架构和 私有数据特性实现保密。

在通道方面，参与到通道的节点才有权访问智能合约（链码）和交易数据，以此保证了隐私性和保密性。

私有数据通过在通道中的成员间使用集合，实现了和通道相同的隐私能力并且不用创建和维护独立的通道。

可插拔共识

Fabric 目前提供了一种基于etcd 库 中 Raft 协议 的 CFT 排序服务的实现。

一个 Fabric 网络中可以有多种排序服务以支持不同的应用或应用需求。

性能和可扩展

一个区块链平台的性能可能会受到许多因素的影响，例如交易大小、区块大小、网络大小以及硬件限制等。

Hyperledger Caliper的基准测试框架。

将 Fabric 扩展到 20000 笔交易每秒（Scaled Fabric to 20,000 transactions per second）。

更新说明

智能合约的去中心化治理

新的 Fabric 链码生命周期支持多个组织在链码和账本交互之前协商链码的参数，例如链码背书策略。

新的模式有几个改进:

• 多个组织必须认同链码参数。去中心化的模型要求在链码在通道上变为活动状态之前，要有足够数量的组织就背书策略和其他细节达成一致意见。
• 更周密的链码升级过程。只有在足够数量的组织批准升级后才能升级链码。
• 更简单的背书策略和私有数据集合更新 。支持在不重新打包或重新安装链码的情况下，更改背书策略或私有数据集合配置。
• 可查验的链码包 Fabric 生命周期将链码封装在可读性更强的 tar 文件中。
• 使用一个包在通道上启动多个链码。
• 通道成员之间的链码包不需要为同一个。

使用新的链码生命周期

私有数据增强

私有数据模式：

• 共享和验证私有数据
• 集合级别的背书策略
• 每个组织的隐式集合

外部链码启动器

• 消除 Docker 守护进程依赖

• 容器的替代品 不再要求链码在 Docker 容器中运行，可以在运营者选择的环境（包括容器）中执行。

• 可执行的外部构建器 操作员可以提供一组可执行的外部构建器，以覆盖 Peer 节点构建和启动链码方式。

• 作为外部服务的链码

提高状态数据库缓存

• 在使用外部 CouchDB 状态数据库时，背书和验证阶段的读取延迟历来是性能瓶颈。
• 在 Fabric v2.0 中，用快速的本地缓存读取取代了 Peer 节点中那些耗费资源的查找操作。可以使用 core.yaml 文件中的属性 cachesize 来配置缓存大小。

关键概念

1.账本

一个状态（您的银行余额）和一组促成该状态的有序交易（收入和支出）。

呈现一组账本状态的当前值，同时记录下促成了以上账本状态的交易的历史。

Hyperledger Fabric 中的账本由“世界状态“和”区块链“这两部分组成，它们彼此不同但却相互关联。

世界状态是一个数据库，它存储了一组账本状态的当前值。（余额）

通过世界状态，程序可以直接访问一个账本状态的当前值，不需要遍历整个交易日志来计算当前值。

可以创建、更新和删除状态，所以世界状态能够频繁更改。

区块链是交易日志，它记录了促成当前世界状态的所有改变。

一旦把数据写入区块链，就无法修改，它是不可篡改的。

从世界状态中可以直接获取当前值。世界状态被作为数据库来实现。这一点很有意义，因为数据库为有效存储和状态检索提供了充分的算子。

所有被提交的交易，无论有效与否，都会被收进区块链。

关键设计在于，只有那些受到相关背书组织签名的交易才会更新世界状态。

每当更新状态时，都会检查该状态的版本，以确保当前状态与背书时的版本相匹配。这就确保了世界状态是按照预期进行更新的，没有发生并发更新。

区块链记录了每个账本状态之前的所有版本以及状态是如何被更改的。

区块链的结构是一群相互链接的区块的序列化日志，其中每个区块都包含一系列交易，各项交易代表了一个对世界状态进行的查询或更新操作。

区块链总是以文件实现，而与之相反的是，世界状态以数据库实现。

创世区块包含了一个配置交易，该交易含有网络配置（未显示）的初始状态。

世界状态数据库选项

LevelDB 是世界状态数据库的默认选项，当账本状态是简单的键值对时，使用 LevelDB 非常合适。LevelDB 数据库与 peer 节点位于相同位置，它被嵌入与 peer 节点相同的操作系统进程中。

当账本状态结构为 JSON 文档时，以 CouchDB 来实现世界状态非常合适，这是因为业务交易涉及的数据类型通常十分丰富，而 CouchDB 可支持对这些数据类型进行各种形式的查询和更新。在实现方面，CouchDB 是在单独的操作系统进程中运行的，但是节点和 CouchDB 实例之间仍然存在1:1的关系。

命名空间

每个链码都有自己的世界状态，并且与所有其他链码的世界状态分离。世界状态位于一个命名空间中，因此只有位于同一链码中的智能合约才能访问一个给定的命名空间。

每个通道都有一个完全独立的账本。这意味着完全独立的区块链和完全独立的世界状态，包括命名空间。

2.通道功能（capabilities）

支持不同的版本 才使得Fabric节点能够滚动升级。

capabilities在每个通道的配置中定义， 通过定义行为会产生一致结果的版本，确保了确定性。

capabilities使运行在不同版本的节点能够 以兼容和一致的方式在给定特定区块高度的通道配置下运行。

• 每次发布版本不一定都有一个新的capability level。
• 在通道中，节点版本必须不能低于特定的capability版本。

3.策略

策略是一组规则，用来定义如何做出决策和实现特定结果。

Fabric 策略表示成员如何同意或者拒绝网络、通道或者智能合约的变更。策略是基础设施的管理机制。

策略决定了那些组织可以访问或者更新 Fabric 网络，并且提供了强制执行这些决策的机制。

系统通道配置

排序系统通道配置区块中的策略治理着排序服务使用的共识，并定义了新区块如何被创建。系统通道也治理着联盟中的哪些成员可以创建新通道。