跳转至

深入探究超分类帐结构

许可区块链已经发展到在一组已知的(不一定可信的)但可识别的参与者中解决采纳区块链教的需要。这些参与者首先需要被明确地接纳到区块链网络中。在这里，了解(识别)参与者比完全信任那些已知的参与者更重要。这些参与者可能彼此不信任，但是他们是已知的、可识别的，并且他们被一个共同的目标联系在一起。Hyperledger Fabric(HLF)(一个被允许的区块链)使用拜占庭容错 ( BFT )变种实用 BFT ( PBFT )，而不是 工作 ( PoW )的 pr oof 作为共识协议。HLF 为许可的区块链提供了改进的功能性质量，如保密性和一致性，同时还提供了改进和增强的非功能性质量，如性能和可伸缩性。

本章着重于 HLF 的基本原理。这将使您能够理解业务逻辑是如何在 HLF 中实现的，并了解有助于对分布式分类帐进行读写操作的各种事务类型。Linux 基金会与各种领先的公司和一些最聪明的开发人员合作，正在努力解决 IT 世界面临的一些最复杂的挑战，并且还在促进开源技术的商业应用。这是世界上最大的开源软件项目。Linux 基金会是各种开源项目的总括项目。对于大数据和分析，它支持 R 以及财团项目。对于网络，它为ONAP(开放网络自动化平台的简称)、OpenDaylight 等提供动力。对于云计算，它支持诸如 Cloud Foundry 和 cloud native computing 等项目。同样，对于区块链来说，Linux 基金会负责 Hyperledger 项目。

超级账本项目一瞥

Hyperledger 项目于 2015 年 12 月启动，由 Linux 基金会主持，旨在创建先进的跨行业分布式账本技术 ( DLT )和区块链技术。它托管区块链框架并支持许多工具。它是开源项目的保护伞，其中一些项目是 DLT 框架，包括 Iroha、锯齿和 Fabric。

由 Hyperledger 托管的框架

以下是 Hyperledger 托管的框架。这些分类如下:

  • 超级分类帐 Burrow
  • 超分类帐结构
  • 印度超级分类帐
  • 超级分类帐 iro
  • 超分类帐锯齿

超分类帐 Burrow :

  • 投稿人:最初由 Monax 投稿，英特尔协办。
  • 主要特性 : Burrow 是一个轻量级、快速、高效的许可链码机器。它利用 Tendermint 协议达成共识。陋居最重要的特点是区块链的速度。三维在区块链实现速度。首先是代码库的事务吞吐量。第二个是数据块在网络中的传播速度。第三个也是最后一个维度是块最终确定的时间(也称为块的最终确定性)。陋居是一个非分叉的区块链，事务的终结性是有保证的。终结性提高了系统的整体速度，因为应用程序和系统可以立即依赖区块链网络上的信息。
  • 目标:为模块化的区块链客户端提供一个被授权的智能合同解释器，该解释器部分开发为以太坊虚拟机 ( EVM )的规范。这是一个许可的智能合同机，它为模块化区块链客户端提供了一个许可的智能合同解释器，部分符合 EVM 的规范。
  • 共识协议 : Tendermint。

超帐结构(HLF) :

  • 出资方:最初由数字资产和 IBM 出资
  • 主要特点:模块化和可插拔架构，并获得高度隐私和保密许可
  • 目标:作为开发具有模块化架构的许可企业应用程序或解决方案的基础
  • 共识协议:阿帕奇卡夫卡

超分类帐印第:

  • 投稿人:索夫林基金会。
  • 关键特性:专为去中心化身份打造。它管理密钥、证明和其他相关信息，使各方之间能够进行可信的对等交互。
  • 目标:提供工具、库和可重用组件来创建和使用独立的身份，以实现跨应用程序的互操作。
  • 共识协议 : PBFT。

超分类帐 Iroha :

  • 供稿人:Soramitsu、日立、NTT Data、Colu 供稿
  • 主要特性:允许操控账户和数字资产
  • 目标 : Hyperledger Iroha 强调使用 Android 和 iOS 客户端库进行移动应用程序开发，从而将其与其他 Hyperledger 框架区分开来
  • 语言 : C++
  • 共识协议 : 又一个共识 ( YAC )

总账锯齿:

  • 投稿人:英特尔。
  • 主要特性:DLT 应用的模块化平台。
  • 目标:锯齿创造了一个数字平台，在一个不可信的世界里实现物理可追溯性。这是一个区块链框架，利用模块化平台来构建、部署和运行分布式分类帐。它支持有权限和无权限部署。
  • 共识协议 : 经过时间证明 ( 诗人)共识。

前面列出的 Hyperledger 框架用于构建 DLT 和区块链应用程序，以及一系列模块(也称为工具),这些模块有助于部署和维护区块链应用程序、分析分类帐数据以及管理区块链网络。

Hyperledger 托管的工具

以下模块，也称为工具，由 Hyperledger 托管:

  • 超大型卡尺
  • 超级分类帐大提琴
  • 超级分类帐编辑器
  • 总帐被套
  • Hyperledger Explorer
  • URSA 超级分类帐

大钩卡尺:

  • 贡献者:甲骨文、华为等
  • 目标:能够衡量特定区块链实施的绩效
  • 主要特性:可以生成各种性能指标的报告，如资源利用率、每秒交易量、交易延迟等

超分类帐大提琴:

  • 贡献者 : IBM，华为，其他。
  • 目标:让商家拥有区块链 - 作为 - a - 服务 ( BaaS )，实现企业快速区块链解决方案。它降低了复杂性，并最大限度地减少了创建、终止和管理区块链所需的工作。
  • 主要特点:除了各种基础设施外，还提供多租户服务，如裸机 金属，虚拟机。它通过一个简化的控制面板实现了区块链的创建和管理，允许区块链实例立即可用。

超级账本作者:

  • 贡献者:来自 IBM 和 Ox-chains 的贡献者是维护者社区，然而，我们鼓励每个人都来参与和贡献。
  • 目标:开发一套协作工具，方便快捷地建立区块链商业网络，使开发者能够快速创建链码和应用。
  • 关键特性:使用 JavaScript 和包括 Node.js、npm、CLI 等工具构建。它的模块化语言简化了资产定义、参与者定义和事务定义。这三个部分构成了区块链网络。它允许更快更容易地开发区块链应用程序。

总账被套:T3】

  • 贡献者 : NTT 数据和纹波。
  • 目标:通过实现 Interledger 协议 ( ILP )实现总账系统之间的互操作性。ILP 是一种支付协议，旨在跨分布式和非分布式分类帐转移价值。
  • 主要特性:它允许分类帐(甚至是非区块链或分布式分类帐)之间的原子交换，以及每个分类帐中帐户的单一帐户名称空间。

超分类帐浏览器:

  • 贡献者 : IBM、DTCC 和英特尔。
  • 目的 : 允许授权参与者探索 DLT 项目。它还允许区块链运营的可视化，使企业能够从数据中提取价值。
  • 主要特性 : Explorer 可以查看、调用、部署或查询块、交易和相关数据、网络信息(名称、状态和节点列表)、链码和交易系列，以及存储在分类帐中的任何其他相关信息。

超分类帐 Ursa :

  • 贡献者:Ursa 贡献者包括 Hyperledger Indy、Sawtooth 和 Fabric 开发人员，他们致力于这些模块的安全方面。此外，为了确保所有的加密算法都符合标准，还需要几个密码学家的参与。
  • 关键特性:模块化、灵活的加密库，旨在供 Hyperledger 中的其他项目使用，但不限于此。
  • 目标:确保其他 Hyperledger 项目能够安全、方便地访问可信的加密库。它的模块化库将帮助区块链开发者在简单配置的帮助下切换或改变加密方案。
  • 语言:铁锈。

HLF–特性和限定符

除了 Linux 基金会，各种公司，如富士通和 IBM，正在 HLF 项目上进行合作。HLF 是一个被许可的区块链框架，它被设计和构建来开发模块化的应用程序。

以下是 Hyperledger 框架的主要功能:

  • HLF 由来自不同组织的优秀、多样化的技术指导委员会管理。
  • HLF 是模块化和可配置的，这使得它适用于各种用例，从银行、金融和供应链到教育和医疗保健。
  • 这是一个 DLT，其中链码是用通用编程语言编写的，如 Java、Go 和 Node.js，而不是用 DSL ( 特定领域语言)编程。这也使 HLF 更接近那些已经构建了应用程序和资源并熟练使用这些语言的企业。
  • HLF 是一个 DLT，是一个开源的、企业级的、许可的 DLT。
  • HLF 遵循基于组件的模块化方法和易于使用的 API。
  • 由于 HLF 是许可的，它在治理模式下运行以处理争议。
  • HLF 支持可插拔的共识协议，区块链网络可以选择共识协议来解决他们的用例。单一企业区块链解决方案的例子，崩溃容错 ( CFT )共识可能比 BFT 更有吸引力，因为 BFT 更适合多企业区块链网络。
  • 成员服务(HLF 的关键组件)是即插即用的。
  • HLF 还有可插拔的身份管理协议，比如轻量级目录访问协议 ( LDAP )和 OpenID Connect。这也使得 HLF 对拥有多样化身份解决方案的企业很有吸引力。
  • 在 HLF 中，智能合同(也称为链码)在容器(例如 Docker)中执行，因此与分类帐状态相隔离。
  • 在 HLF 中，可以配置分类帐来支持各种数据库管理系统。
  • HLF 不需要加密货币，这显著降低了区块链存在对加密货币的依赖，并降低了攻击风险。
  • HLF 服务图显示了 HLF 的各种组件。它们通过 API 和 SDK 进行集成、组装和交互。主要组件如下:
    • 身份
    • 分类帐
    • 处理
    • 共识；一致
    • 智能合同
    • 安全和加密服务

为什么是 Hyperledger？

我们在第一章、探索区块链和 BaaS、和第二章、解释分布式账本技术和区块链中介绍了 DLT 和区块链。此外，我们还学习了各种网络拓扑，如集中式、分布式和分散式系统。我们也熟悉了区块链的结构、交易和其他各种区块链概念。我们对允许和不允许的区块链进行了详细的分析和讨论。以太坊和比特币等无许可区块链是开放的区块链，任何人都可以参与其中。另一方面，许可区块链允许有限组的参与者管理区块链网络，而只有授权和认证组的参与者能够访问它。

无权限的区块链有很多优点，同样，使用有权限的区块链也有很多优点。许可区块链具有成本效益，并且交易开销低。由于交易验证和确认更快，交易成本非常低，交易时间也更快。选择区块链网络的决策完全取决于用例以及消息和事务的可见性。然而，在我看来，与企业有很好共鸣的关键区别是决定谁将加入区块链商业网络，谁被授权在商业网络上进行交易；另一个原因是能够加强生产者和消费者之间的直接关系，减少或消除对中间方或第三方(中间人)的依赖。

我们处在一个去中介化的时代。它由优步、亚马逊、Airbnb 和其他公司开创，它们没有车辆，没有真实库存，也没有房间库存，但它们允许生产者和消费者联系和交易。区块链和 DLT 进一步赋予生产者和消费者权力，导致第三方和中介从等式中去中介化。许可区块链通过许可访问区块链网络和引导参与者之间的交易来进一步允许区块链网络上的数据隔离，从而实现数据的隐私和机密性，从而增强了隐私。与区块链一样，DLT 完全有潜力颠覆高度依赖中介的行业，如保险、医疗、运输、零售、物流、房地产和教育。

在高层次上，关于企业，区块链提供以下内容:

  • 它检查恶意节点在传输时篡改数据的风险，以确保防篡改数据传输。这是通过保护事务树以及获得能力的复杂性来确保的。恶意用户无法在不重新计算 PoW 哈希的情况下更改/篡改数据，这是一项巨大的任务，需要极高的计算能力。
  • 由于 HLF 区块链是许可的，区块链网络在已知的参与者中运行，这提供了对区块链网络本身的高度信任。
  • 使用 HLF 的渠道，参与者群体之间的交易可以得到进一步的保护。
  • 它消除了对单一中心故障点的依赖。
  • 通过遵循协议，采用相同的验证和块布局规则来确保一致性。
  • 所有节点将遵循最长的链，这确保了跨地理区域协议的建立。
  • 区块链降低了不确定性，增强了各方之间的信任，从而实现更快、更安全的交易。
  • 由企业选择的许可区块链允许企业通过提供不变性(防篡改，其中区块链代表真相)、隐私和机密性(授权的敏感数据的安全交换)、可伸缩性、可靠性、可用性(支持任务关键型应用程序)和可审计性(管理、跟踪、追踪、验证和监控)来为参与者定义成员规则。

在无许可区块链中，事务在每个节点上执行(假设共识是 PoW)。这意味着缺乏保密性，因为数据和智能合约以及交易数据在网络上的每个节点上都是可用的。机密性和交易数据可见性对于企业来说非常重要。在 B2B 交易的情况下，企业不希望一个合作伙伴以特殊费率获得的数据被另一个合作伙伴获得，尽管在无许可网络中通过加密数据解决了保密性问题。然而，使用 PoW 的无许可区块链网络将导致数据在每个节点上都可用，这突出了给定时间解密它的可能性，以及节点上数据的本地可用性。在 HLF 中，随着参与者的识别和加密，信道提供了最高级别的保密性。在这里，只有参与节点可以访问链代码和事务数据，这也是由访问控制进一步控制的。这为区块链网络带来了高度的私密性和保密性。

无许可与有许可的区块链:

当我们开始讨论为什么是 Hyperledger？，快速了解未经许可的区块链和经许可的区块链(如 HLF)之间的差异是有意义的。让我们从执行风格、确定性和保密性的角度来分析 DLT 的这些变体:

  • 执行方式:
    • 一个无权限的区块链，比如以太坊，观察事务的顺序执行，它们遵守顺序 - 执行架构。所有对等体执行 oorder-execute风格的事务，这导致了性能和可伸缩性的限制。这里，吞吐量与事务中的延迟成反比。然而，未经许可的区块链试图通过精心策划一种加密货币来解决这一问题。这确保了燃料/气体包括在每个交易中。因此，通过智能合同为交易执行的每一步支付汽油。然而，这种吞噬加密货币的机制可能不适合许可的区块链。
    • 像 HLF 的架构一样，许可的区块链支持可伸缩性、性能和信任。HLF 的架构是基于执行-命令-验证 ( E-O-V )架构，在这种架构下，甚至在达成共识之前就执行事务。事务的执行( execute )将确保一个事务的正确性(背书)，而一个模块化的可插拔共识协议将产生一个排序( order )事务。此外，就在提交交易之前，由特定于应用程序的背书策略对其进行验证( validate )。E-O-V 解决了无许可区块链的订单和执行架构所面临的灵活性、可伸缩性、性能和机密性问题。HLF 允许对等体的子集并行执行事务。有趣的是，chaincode 将背书的工作委托给某些指定的同行；因此，不同的链代码可以指定不同的对等体作为签署者，这支持并行执行。请注意，Fabric 甚至会在订购之前执行事务。
  • 决定论:
    • 共识确保节点在事务上达成一致，因此，智能契约应该确定性地执行事务。如果没有，建立共识就没有意义。此外，这种非决定论将导致共识无效，这将导致分叉。因此，智能合约语言和编译器应该确保智能合约的执行是确定的。因此，各种区块链选择 DSL。这就迫使开发者学习新的语言，只是为了保证智能合约的确定性。
    • HLF 的 E-O-V 架构确保交易由特定于应用程序的认可策略进行验证。这意味着特定于应用程序的策略将确保多少对等节点以及哪些对等节点将验证并确保链代码的确定性执行。因此，对等体的子集将执行(签署)交易以满足签署策略。这将过滤掉不一致的结果，甚至在排序之前，从而消除任何不确定性。因为消除了不确定性，HLF 支持使用标准编程语言。可以用 Go、Node.js、Java 写 chaincode。
  • 用于确定性的混合复制驱动程序:
    • HLF 遵循被动和主动复制。被动复制是通过对等体的子集执行(认可)事务来实现的，这提供了确定性和并行执行。它还通过仅在达成共识后将事务提交到分类帐来实现主动复制。因此，HLF 遵循混合复制策略。同样，共识的选择特定于用例，或与用例相关的部署，因为 Hyperledger 支持模块化共识机制。这允许实现者选择任何协议来达成共识，例如 BFT 或 CFT。
  • 保密:
    • 利用 power 的无权限区块链在每个节点上执行事务。因此，每个交易和智能合约对每个节点都是可见的，这清楚地表明了对于 PoW 提供的 BFT 增益的机密性的损失。机密性的丧失对于企业客户及其使用情形来说是一个挑战。例如，如果一个企业希望与一些供应商建立特定的费率，而与非高级供应商建立不同的费率，他们将不能保持这种优选费率的保密性。如果所有供应商都在同一个区块链网络上并访问同一个智能合同，则不可能与不同的供应商保持不同的贸易关系(费率)。无许可区块链提供了两种解决方案:
      • 它会加密这些首选信息。但是，每个节点上都有数据和智能合约。加密可能会被破坏，并且总是存在丢失信息的风险。
      • 零知识证明 ( ZKP )可以处理失密。然而，ZKP 的计算增加了延迟并消耗了资源。这意味着 ZKP 可以解决保密问题，即使这将导致性能问题。
  • 像 HLF 一样，经过许可的区块链提供渠道和私人数据收集 ( PDC )来解决保密问题。

去/不去——选择区块链解决方案

现在，每个企业都需要一个区块链解决方案，同时，每个企业都需要一个基于用例的区块链解决方案。因此，确定企业是否需要区块链解决方案的核心是基于它试图解决的用例。

现在，让我们列出一个企业在评估区块链之前应该考虑的因素:

  • 是否需要一个公共共享数据库？
  • 对于一个业务流程，参与各方是否缺乏信任？
  • 提交数据库时涉及到多方吗？
  • 第三方或中间商是否参与了业务流程？
  • 业务流程数据是否存在于多个数据库中？
  • 是否需要数据的不变性或事务的日志/历史？
  • 交易频率是否在每秒 10，000 次交易的范围内？
  • 交易规则是否很少改变？(在区块链创作的规则是预设的，一旦部署和启动，chaincode 将不会基于新规则改变路线)。由于区块链的一切都是确定的，改变规则的应用程序通常不适合区块链。
  • 流程不是存储了很多静态数据吗？
  • 流程没有很多数据吗？(随着数据的复制，将大量数据复制到所有节点对于区块链来说并不是一个高效的使用案例)。
  • 是否不需要从外部来源检索数据？

如果前面任何一个问题的答案是是，那么区块链就是企业用例的解决方案。此外，如果需要公开事务，那么企业用例需要一个无许可的区块链解决方案，或者需要一个有许可的区块链解决方案，比如 HLF。

建筑——概念视图

在我们进入 HLF 体系结构及其组件之前，让我们首先浏览一个概念性的视图，并学习一些重要的术语。阅读本节，通过一个例子掌握一些基本知识，在阅读了架构和组件之后，再次阅读本节，进一步确认您对 HLF 的理解。

KonsensusChain 组织决定创建一个产品链(一个名为 product chain 的区块链商业网络),使生产商和零售商能够达成交易。此外，它还允许监管机构验证产品的合法性。组织 KonsensusChain 将作为创始人组织，不参与任何交易。然而，它将建立区块链网络，开发用户界面，链接代码应用程序，并将进一步维护和经营商业网络(财团)。这是一个创始人发起的区块链网络模型，以 HLF 为基础，参与组织创建了一个联合体。在这个例子中，dApp 并不是完全由创始人提供的。dApps 由组织单独构建。但是，他们使用 SDK、REST APIs 和其他集成方法来连接业务区块链网络并执行事务。

以下是打算加入区块链网络的不同组织:

  • 生产者组织:标识为组织 1 ( O1 ，这是一个生产某种产品并销售给零售商的组织。监管机构进一步核实这些产品的合法性。制作机构 O1 的 c 认证机构 ( CA )为 CA 01 。
  • 零售商组织:标识为组织 2 ( O2 )，这是一个从生产商组织 O1 购买产品并销售给其消费者的组织。零售商组织 O2 的 CA 是 CA O2 。
  • 零售商组织:标识为组织 1 ( O3 )，这是一个从生产者组织 O1 购买产品并销售给其消费者的组织。零售商组织 O3 的 CA 是 CA O3 。
  • 监管机构:认定为监管机构(【O4】，该监管机构对产品进行验证，并对生产的合法性进行盖章。
  • 创始机构:【KonsensusChain.com】T2 为创始机构，标识为机构 5 ( O5 )。所有的零售商和生产商都同意雇佣 O5 作为产品链区块链网络(区块链网络的虚构名称)的创始人组织。

以下是这个位于区块链的商业网络(ProductChain)的要求:

  • 需求一:生产商组织( O1 )希望与零售商组织( O2 )进行私下交易和沟通，因为他们已经就某些产品的特定费率达成一致，并且希望拥有交易隐私
  • 要求二:同样，生产商组织( O1 )希望与零售商组织( O3 )进行私下交易和沟通，因为他们已经就某些折扣和支付条款达成一致，他们希望对此保密

以下是本节将提到的业务网络的概念图:

建筑:概念视图

建设区块链网络

本节讨论业务网络的构建模块，并涵盖形成业务网络所涉及的步骤。所有条款都基于 HLF。以下是建立企业网络所需的步骤:

第一步 : 启动区块链网络:组建网络的第一步是启动订货商。在示例中(参考前面的架构 : 概念视图图)，节点 O5 归组织 O5 所有，也被定义为订购方。创始人组织( O5 )使用网络配置， NC05 ，为区块链网络配置订购服务( Ord05 )。该设置通过区块链网络(ProductChain)向创始人组织( O5 )提供完全的管理权限。组织 O5 的 CA 为CAT24】O5。CA 向发起组织的网络节点的管理员颁发证书( O5 ):

  • 本质上，订餐服务由 O5 托管在创始人机构( O5 )或云平台管理员上，并由 O5 进一步管理和执行。网络配置文件( NC05 )定义了组织 O5 在业务网络上的权利和特权信息。
  • CAs 是 HLF 的核心。HLF 提供了一个内置的 Fabric CA 来快速启动。但是，组织可以使用自己的 ca。不同的参与者使用证书在区块链网络上标识自己。在这个虚构的区块链网络(ProductChain)中，我们将定义五个 ca，每个组织一个。
  • 网络配置( NC05 )使用一种称为成员资格服务提供者 ( MSP )的结构，将 CA05 颁发的证书映射到 O5 组织的证书持有者。此外， NC05 在策略中使用 MSP 名称，以授予来自创始人组织( O5 )的参与者通过区块链网络资源的访问权。举个例子，从 O5 中确定一个参与者，他作为区块链网络的管理员，可以进一步向区块链网络添加新的成员组织。

创始人正在添加的其他管理员:创始人组织( O5 )通过更新网络配置( NC05 )添加一个制作人组织( O1 )作为管理员。该修改进一步将 O1 定义为区块链网络的管理员。生产者组织使用其资源(节点)作为区块链网络的附加订购者( O1 )。

第二步 : 定义联合体实现交易的分离和安全:其次，我们来看定义联合体。它是两个或两个以上组织的联合，参与实现一个共同的目标。在联合体中，每个参与组织都有自己的法律地位，并通过商定的合同联系在一起。这个联合体的形成不同于第二章、中定义的解释分布式账本技术和区块链的联合体。在第二章、解析分布式账本技术和区块链中，创始人组织本身定义并拥有联合体，也参与交易。在这里，创始人负责建立、维护和操作区块链网络的基础设施。它还提供了一个解决方案，各种组织可以合并并形成一个联盟和渠道，并可以进入交易。这种配置可以允许云平台提供商管理业务网络，而无需参与其中。毕竟，联盟是志同道合的组织团体，致力于解决一个共同的问题。在这个过程中，他们利用商业网络中的资源。在这个示例中，创始人组织使用了它的基础设施，还使用了一些节点作为订购者。在该联合体中，以下内容适用:

** 创建者组织正在使用其基础设施，并且还使用节点 P5 ( Ord O5 )作为订购者节点 * 生产者组织 O1 (也被定义为网络管理员)定义了一个联合体-X1 ，有两个成员——组织 O1 和组织 O2 * 联合体定义存储在网络配置( NC05 )文件中

第三步 : 定义渠道:第三，我们将创建一个渠道，让财团成员能够安全地进行交易。通常，这样的信道被称为应用信道:

  • 频道配置 CCon1 管辖频道-C1 。频道-C1 是为联合体-X1 打造的。 O1 和 O2 都可以管理通道配置， CCon1 ，并且拥有同等的权限。
  • 通道配置( CCon1 )与网络配置( NC05 )完全分离，因此组织 O5 对通道配置( CCon1 )没有控制权。然而，频道- C1 连接到订购服务( Ord 05 )。
  • 渠道配置( CCon1 )包含定义组织( O1 和 O2 )通过渠道-C1 进行交易的权利的策略。其他组织如 O3 和 O5 不能影响其上的交易。

向通道添加对等节点:

  • 向频道、组织 1 :对等 P1 通过生产者组织( O1 )加入商业网络。这是可能的，因为组织拥有对等体( O1 拥有 P1 )。图中的对等方 P1 也托管分类帐 1 的副本( L1 )。很明显， P1 和 O5 (对等和订购服务)可以通过通道-C1 相互通信。
  • 向渠道、组织 2 添加对等点:类似地，对等点 P2 通过零售商组织( O2 )加入渠道，零售商组织拥有对等点 P2 。对等方 P2 也托管总账 1 的副本( L1 )。显然， P2 和 O5 (对等和订购服务)可以通过通道-C1 相互通信。

以下是我们可以从这种配置中吸取的经验教训:

  • 关联同行与组织:可以根据证书确认同行 P1 与组织( O1 )的关联。在此示例中，组织 O1 的 CA ( CA O1 )已经向对等方( P1 )发布了 X.509 身份，因此， P1 与 O1 相关联。类似地，可以基于证书来确认同行( P2 )与组织( O2 )的关联。在这个例子中，组织 O2 的 CA ( CA O2 )向对等方( P2 )发布了 X.509 身份，因此 P2 与 O2 相关联。
  • 关联对等体与台账:对等体 1 ( P1 )和对等体 2 ( P2 )托管台账 1 ( L1 )的副本。因此，分类账 1 ( L1 )在物理上与 P1 和 P2 关联，而在逻辑上与渠道( C1 )关联。
  • 功能:启动时，peer ( P1 )向 order(Ord O5)发送请求。来自对等方( P1 )的请求由订购方( Ord O5 )通过参考通道配置( CCon1 )进行验证。该验证解锁关于P1对频道 C1 的许可(访问控制)的信息。它有助于确定对等方( P1 )可以对分类帐 1 ( L1 )执行的操作(读/写)。同样的道理也适用于 P2 和 T21。

添加链码并允许应用程序访问分类帐:在这个例子中，dApp 并不完全由创始人提供。dApps 由组织单独构建。

但是，他们使用 SDK、REST APIs 和其他集成方法来连接业务区块链网络并执行事务:

  • 生产者组织( O1 )拥有应用( O1App1 )，零售商组织( O2 )拥有应用( O2App2 )。这些应用程序与 chaincode(一个智能合约)集成在一起，在图中定义为 chaincode ( SC1 )。Chaincode ( SC1 )部署在对端 1 ( P1 )和对端 2 ( P2 )上，允许 dApp ( O1App1 和 O1App2 )访问总账 1 ( L1 )。所有参与实体，例如应用程序( O1App1 和 O2App2 )、对等方( P1 和 P2 )以及订购服务( O5 )使用通道-C1 进行通信(事务)。
  • dApps ( O1App1 和 O2App2 )也被称为客户端应用。他们也有与组织相关联的身份( O1 和 O2 )。Chaincode ( SC1 )定义操作，dApps(应用)可以与 Chaincode 集成，执行允许访问总账的交易( L1 )。应用程序( O1App1 和 O2App2 )对分类帐( L1 )的访问完全由链码( SC1 )操作控制。
    • Chaincode 由一个组织的( O1 )开发团队开发，并由联合体团队( X1 的成员，如 O1 和 O2 )评审同意。然而，在被部署到对等体之前，联盟需要对链码达成共识。

链码及其阶段

链码有四个阶段——安装、初始化、定义背书者和允许交易。下面是对这些阶段的详细分析。您也可以将它们与示例联系起来:

  • Installed :在对链码(开发和测试)达成一致的情况下，组织的( O1 )管理员可以在对等节点( P1 和 P2 )上部署(安装)链码。尽管安装了 chaincode 的对等体可以完全访问并了解 chaincode，但客户端应用程序(dApps)仅限于调用事务。有趣的是，仅仅在通道上安装 chaincode 并不能使客户端应用程序( O1App1 和 O2App2 )针对 chaincode ( SC1 )发出事务。这只能在启动链码时发生。
  • Initiated :目前为止，chaincode 只安装在同行上( P1 和 P2 )。因此，除了同行( P1 和 P2 )之外，其他渠道参与者对此一无所知。制片人组织( O1 )将在频道( C1 )上发起链码( SC1 )。一旦在通道上启动链码，其他通道参与者，如 dApps ( O1App1 和 O2App2 )可以调用链码( SC1 )。此外，只有对等体(安装了 chaincode)可以访问 chaincode 逻辑。但是，其他组件仍然无法访问链代码逻辑，但是可以在链代码上调用操作。
  • 背书:参照前面的架构 : 概念图图，可以明确机构( O1 和 O2 )是联合体-X1 的一部分。他们定义了信道( C1 )，信道由信道配置( CCon1 )控制。说到这里，一个代言政策( EP #1 )也是渠道配置的一部分， CCon1 。当链码启动时，认可政策( EP #1 )被附加到渠道配置( CCon1 )。背书政策规定接受分类账交易( L1 )。并且只有在渠道()上的组织( O1 和 O2 )批准后才能接受交易。 *** 调用:只有在实例化之后，客户端应用程序才能够向对等体发送事务提议( P1 和 P2 )。事务提议就像链码( SC1 )的输入，这将导致对等节点 P1 和 P2 的认可的事务响应被分别发送回客户端应用程序 O1App1 和 O2App2 。这将在本章的交易流程一节中详细讨论。**

参照该图，组织 1 ( O1 )和组织 2 ( O2 )在同级 P1 和 P2 上安装了链码，分别归 O1 和 O2 所有。但是，由于链码是由 O1 发起的，组织 O2 不需要发起链码，因为它已经由 O1** 发起。此外，gossip 协议允许对等体相互通信。

同行的类型

对等体可以细分如下:

  • 强制对等体:认可对等体和非认可对等体，也称为提交者和领导者对等体。
  • 选项对等体:锚点对等体。这些都是可选的，没有它们，区块链网络也可以运行和存在。

以下是可用的不同类型的对等点:

  1. 认可同行:上一节详细介绍了认可同行。参照架构 : 概念视图图，同行( P1 和 P2 )有组织管理员安装的链码( O1 和 O2 )。因此，他们可以签署交易，并被称为签署对等体。
  2. 非 - 认可对等方(也称为提交对等方):参考上图，对等方 P4 (归组织 O1 所有)没有安装 chaincode。组织 1 的管理员( O1 )选择只在 P1 上安装 chaincode，而不在 P4 上安装。这突出了两点:
    • 首先，组织管理员可以有选择地在对等点上安装链码。
    • 其次，安装了链码的对等点称为认可对等点，没有安装链码的对等点可以存在于通道上。这样的对等点( P4 )是非签署对等点(称为提交对等点)。通道上的每个节点都是提交对等体:
      • 像 P4 这样的对等体(非签署对等体，也称为提交对等体)不能生成事务。但是，他们可以接受或拒绝分类账交易( L1 )。
    • 安装了 chaincode 的对等体可以生成事务，也可以签署事务。
    • 提交对等方接收交易块(由批准对等方发起的交易)，并在提交到分类帐的本地副本( L1 )之前进行验证。对等方(背书者和提交者)对分类帐副本()的这种提交构成了对分类帐的仅追加操作。

请记住，渠道配置( CCon1 )中存在的 chaincode 的背书政策( EP #1 )规定了在将交易追加到渠道的分类帐( L1** )之前，组织的哪些同行应该对交易进行数字签名。

  1. 领导同行:组织 O1 在渠道 C1 上有两个同行 P1 和 P4 ，其中 P1 是背书者 P4 是委托者。因此，事务需要被分发给组织中的所有对等体(提交者)( O1 )。事务的分发意味着从订购者分发到组织的提交对等点。为了确保事务分布，可以将一个对等点定义为领导者对等点(静态)，或者任何对等点都可以承担领导者的角色(动态)。因此，在我们的示例网络中，对于渠道-C1 和组织 O1 ，对等体 P1 被动态定义为领导对等体，它将向附属于渠道-C1 的组织 1 ( O1 )的所有对等体分发事务。
  2. 锚节点:对于组织间的对等通信，信道需要一个锚节点。这是一个可选的对等方，仅在需要跨组织通信时才需要。

一个对等体可以是全部四个。 O1 的例子 P1 是支持者、承诺者、领导者，也可以是主播同行。此外，对于一个渠道，总会有一个支持者、一个提交者和一个领导者。

演进网络

在本节中，我们将进一步发展网络以实现需求 #2。要求 #2 希望制作方组织 O1 与 O3 (零售组织 3)进行私下交易和沟通，因为他们已经就某些私下折扣率和付款条件达成一致。

创始人组织的管理者( O5 )在生产者组织( O1 )和第二个零售组织( O3 )之间定义了一个新的联合体。联合体定义在网络配置中定义( NC05 )。其中一个组织( O1 或 O5 )可以为新的联合体( X2 )定义一个新的渠道( C2 )。通道( C2 )配置驻留在通道配置( CCon2 )中。你可以观察到 C2 的通道配置驻留在 CCon2 中，与通道-C1 的配置( CCon1 )是分开的。两种通道配置都独立于网络配置( NC05 )。因此，只有 O1 和 O3 对 C2 有权利，而 O5 对频道-C2 没有权利。 O5 只给渠道( C2 )提供一个资源(订购服务——Ord O5)。

组织( O3 )给渠道( C2 )添加了一个同行( L2 )并有了不同的账本()。台账的范围仅限于渠道，因此，渠道-C1 有台账 L1 ，渠道-C2 有台账 L2 。链码 SC2 在渠道-C2 上安装并初始化，组织O3’s 申请( O3App3 ) 使用渠道-C2 调用链码 SC2 的交易。

网络配置和通道配置的物理实现

本节将介绍如何在区块链网络中实现物理配置。

逻辑上，通道配置( CCon1 和 CCon2 )似乎是通道的单一配置( C1 和 C2 )。实际上，信道的对等体拥有信道配置的副本。从逻辑上讲，网络配置 NC05 似乎作为区块链网络的单个文件存在。然而，实际上，它在区块链网络的所有订购节点上都被复制。

当管理员配置网络和通道时，他们向区块链网络发出配置事务。此类事务由组织(组织管理员)进行数字签名，如名为修改策略(mod_policy)的策略文件中所定义。

mod_policy文件是网络和通道配置内的策略。例如，当您向区块链添加更多组织时，这些组织及其权限会在区块链网络的网络配置中修改为mod_policy。

订购服务

每个排序节点维护网络配置的副本，并使用系统通道来执行配置事务并维护网络配置的一致副本。在图中，我们有两个订购节点— O5 和 O1 。创始人组织( O5 )通过更新网络配置( NC05 )添加制作人组织 O1 为管理员。该修改进一步将 O1 定义为区块链网络的管理员。生产者组织( O1 )将其资源(节点)用作区块链网络的附加订购者( O1 )。订货人 O5 由 O5 机构雇佣维护，其证书由 CA05 签发。订货方 O1 由组织 O1 提供和维护，其证书由 CA01 颁发。网络配置( NC05 )定义了被配置组织的参与者的确切权限( O5 和 O1 )。

订购服务还从客户端应用程序(dApp)收集认可的交易，并按块对它们进行订购。然后，这些块被分发到通道上的每个提交者节点。当达成共识时，每个提交对等方将记录并附加分类帐的本地副本。有趣的是，您会注意到订购服务非常细致地处理了交易的分配。即使相同的订购服务在多个渠道使用( C1 和 C2 )，它处理正确交易到正确渠道的分配。这在网络配置( NC05 )和通道配置( CCon1 和 CCon2 )中控制和定义。

对维护网络配置的一致副本的节点进行排序

为了理解排序节点如何维护网络配置的一致副本，我们需要看一下通道。

我们知道有两种类型的渠道:

  • 申请渠道:渠道 C1 和 C2 是申请渠道的例子。
  • 系统通道:订购节点由一个系统通道连接，该系统通道允许它们在彼此之间分发配置事务。因此，当管理员试图配置网络时，他们在这个系统通道上发出配置事务。然后，系统通道(在图中描述为系统通道)将确保这些配置事务在区块链网络上的订购节点之间的分布。

在这种配置中，应用程序 O1App1 和 O2App2 将在通道-C1 上基于链码 SC1 进行交易，并将使用通道-C1 与对等方 P1 、 P2 和订购方 O5 进行通信。应用程序 O3App3 将基于链码 SC2 进行交易，并将使用通道-C2 与对等方 P3 和订购方 O5 进行通信。这清楚地展示了精确的去中心化，不同的组织可以执行他们特定的事务，并在他们自己的分类帐中存储块。

作为多个通道的一部分时节点的行为

制作方组织( O1 )希望分别为财团 X1 和 X2 提供单独的申请渠道 C1 和 C2 。这将允许 O1 通过这些渠道与组织进行私下交易。因此，该图显示了 O1 的对等机 P1 ，以及安装在 P1 上的主机链码 SC2 。 P1 所属的 01 组织的客户端应用程序( O1App1 )现在可以基于链码 SC2 中定义的逻辑在渠道-C2 上进行交易。

节点行为是多个通道的一个元素，由该通道的通道配置控制。通道配置 CCon1 和 CCon2 分别定义了当节点 P1 是多个通道 C1 和 C2 的一部分时，节点可用的操作。类似地，应用程序 O1App1 现在可以分别基于链码 SC1 和 SC2 在通道 C1 和 C2 上执行事务，这同样由通道配置 CCon1 和 CCon2 决定。

Hyperledger 体系结构(分层视图)和组件

本节将介绍 Hyperledger 框架体系结构层和组件。如下图所示，HLF 体系结构分为四个主要层，每层都有协同工作的组件。这些层、组件及其交互共同构成了许可的区块链网络，如下图所示:

架构:分层视图

身份、安全和隐私

本节涵盖了区块链体系结构中特定于身份、安全和隐私的方面。在区块链网络中有各种各样的参与者，例如节点(提交者、签署者等等)、dApps 和客户端应用，以及网络和通道管理员。每个参与者都需要建立身份，因为正是这些参与者的身份决定了他们对区块链网络及其资源的访问权限。Principle 是一组身份和属性，其中身份是一个用户 ID，属性包括它所属的组织、它所属的角色等等。因此，很明显，权限是由身份的属性决定的。

HLF 使用 X.509 证书进行身份认证。然而，MSP 验证身份并确定这些身份在区块链网络中是否被允许。从高层次上讲，请记住 MSP 有规则，它在区块链网络中启用身份。然而，这些身份必须受到公钥基础设施的信任和验证。

一个得到许可的 HLF 区块链网络严格控制着参与者的身份。这是一个强制性的两步流程—建立参与者的身份和安全通信。

公钥基础设施

公钥基础设施 ( PKI )确保区块链网络中各种参与者之间的安全通信，并且还对发送到区块链网络的消息进行认证。PKI 由 ca 组成，ca 负责向参与者(用户、节点等)颁发数字证书。参与者基于这些证书被认证，然后消息被发送到区块链网络。

在 Hyperledger 框架的分布式区块链网络中，根 CA 是一个 HLF CA，它被配置为信任锚。它是一个自我认证的根 CA，也对中间 CA 的叶证书进行签名和认证。此外，这些中间 ca 可以签署和认证其他叶中间 ca。因此，对于给定的数字证书，信任可以追溯到根 CA。这被称为信任链。HLF，尤其是 HLF 成员服务，具有用于区块链网络安全运行的结构 CA 和中间 CA。

以下是 PKI 的一些关键要素:

  • 数字证书
  • 键
  • 卡丝 （人名）
  • 证书撤销列表 ( CRL )

数字证书

数字证书是包含证书持有者的各种属性的文档。这些证书符合标准，对于 HF，这是 X.509 标准。

以下是一些关于证书的简要信息:

  • 证书中有什么？证书类似于身份证，包括由以下内容组成的证书数据:
    • 算法信息(如 SHA256)
    • 发行人信息，包括证书的有效期(时间)
    • 主题信息，包括以下内容:
      • 主题详细信息，如组织单位
      • 主题公钥和签名算法详细信息
  • 证书的主体(用户或节点)可以使用该证书来证明他们的身份。
  • 为了证明他们的身份，主体可以使用私钥对发送到区块链网络的任何通信(交易等)进行签名。主体的公钥在证书本身中。然而，主体的私钥是秘密的和私有的。
  • 证书中包含的所有信息都经过加密，对其进行的任何更改都会将证书标记为无效。
  • 主体使用他们的私钥签名，并使用该证书来证明他们的身份。当其他方信任身份提供者(也称为 CA)时，交互方可以信任主体。各方信任 CA，并相信主题显示的证书未被篡改。

键

在这一节中，我们将讨论数字签名以及公钥和私钥。在前面的描述中，我们看到消息是由主题签名的。签署消息被称为消息的数字签名。正是数字签名保证了消息的完整性和身份验证。身份验证确保交易中涉及的各方确信消息发送者或创建者的身份，完整性确认消息在传输过程中未被修改/篡改。因此，正是数字签名保证了完整性和身份验证。交易(消息)发送方将使用他们的私钥对消息进行签名，并将其发送给接收方。接收方将使用发送方的公钥(众所周知)来验证消息的完整性和真实性。这意味着接收方将使用发送方的公钥来确保它是由声称是发送方的发送方发送的，并且是预期的发送方。公钥和私钥的组合确保了区块链网络上的安全通信。

卡丝 （人名）

CA 通常包含在 HLF 版本的 Docker 映像中，并作为 HLF CA 组件发布。在区块链网络的情况下，CA 有以下目的:

  • 注册节点
  • 注册节点

在 HLF 中，证书颁发机构是一种 CA 服务，它为参与节点创建和颁发证书(注册证书)，允许它们加入和参与区块链网络。这些证书(注册证书)采用标准的 X.509 v3 格式。然而，企业可以扩展 HLF CA，如果需要，他们甚至可以替换它。ca 向参与者(用户、组和节点)颁发符合 X.509 的证书。正是这些证书使参与者能够在区块链网络上进行交易和交互。ca 向参与者颁发证书，这些证书包括与主题(参与者)相关的各种信息，如前所示。ca 仅在用其私钥签署这些证书后才颁发这些证书。因此，CA 颁发的证书是由 CA 签署的，由于这些 CA 是可信的，所以参与者也是可信的。此外，证书中包含的信息是可信的，因为它是由 CA 签名的。只要接收者拥有 CA 的公钥，他们就可以信任该证书。

此外，当主体(参与者/发送者)签署任何交易时，接收者可以使用主体(发送者/参与者)的公钥来确保消息的真实性和完整性。可信 ca 包括 DigiCert 和 Verisign。这些证书没有任何私钥——无论是 CA 的还是参与者的。在区块链网络中，每个参与者(主体/参与者)都需要一个由组织的 CA 颁发的数字身份，这实际上意味着 CA 为参与者提供了一个可验证的数字身份。

以下是可用的 CA 类型:

  • 根证书颁发机构是大机构，如 Symantec，他们自行签署自己的证书，然后将这些证书颁发给其他证书颁发机构。中间 CA 是指拥有由根 CA 或另一个中间 CA 颁发的证书的 CA。这导致证书的信任链(信任链)。使用 CA 的组织可以放心地使用中间 CA，因为信任链将允许他们将证书追溯到根 CA。此外，信任链限制了根 CA 的暴露，这从信任链的安全角度来看是至关重要的。此外，参与区块链网络的各种组织可以使用不同的中间 ca，并且可能具有不同或相同的根 ca。
  • HLF 提供了一个名为 Fabric CA 的内置 CA，它是 HLF 区块链网络的根 CA。它是结构区块链网络的专用 CA；它不能提供在浏览器中使用的 SSL 证书。因此，组织可以为其 HLF 区块链网络使用商业公共根和中间 ca。HLF CA(也称为结构 CA)的功能如下:
    • HLF CA 既可以注册身份，也可以配置为使用现有的企业 LDAPs 作为用户注册中心
    • 对于成员组织、用户和管理员，HLF CA 可以颁发、续订和吊销区块链网络的注册证书和根证书
  • HLF CA 生成自签名的 X.509 证书，并且可以有一个或多个结构 CA，其中将有一个根 CA，其余的是中间 CA，并且信任链由 PKI 遵循。

证书吊销列表

ca 可以吊销证书，此类吊销的证书不构成过期证书。在身份泄露的情况下，证书可以被撤销，并放入一个名为 CRL 的列表中。建议任何想要验证任何其他方(主体方)的身份的一方应首先参考 CRL 来检查该方(主体方)的证书是否包含在被撤销的列表中。

会员服务

我们现在知道 PKI 为参与者提供了可验证的身份。然而，这些参与者如何在区块链网络上表现出自己是来自参与组织的可信参与者？每个组织都在一个 MSP 下管理其参与者。但是，如果组织想要管理一个参与者的不同组织单位 ( OU )，例如财务和法律单位，它们可以有多个 MSP。如果您检查从 CA 颁发给主题的证书，它将包含 ou 信息。这允许根据 ou 进一步控制对通道的访问。

成员资格服务管理参与者的身份，并用于验证参与者及其身份。在区块链网络的访问控制列表中控制系统资源(网络、通道等)的特定特权。成员服务代码在对等体和订购者上执行。它负责在 HLF 区块链网络上对身份进行认证、授权和管理。HLF 区块链网络的参与者具有身份，其中 PKI 生成与参与者相关联的证书(例如网络组件、组织、dApps 和客户端应用)。这有助于为网络级以及信道级的参与者创建访问控制规则，其中信道是参与者进行私人交易的区块链网络的子集。区块链网络中的访问控制和通道共同应对机密性和隐私挑战:

  • 认证 : HLF 使用 PKI 来验证用户和设备的身份。
  • 授权 : HLF 使用基于角色的访问控制 ( RBAC )来控制对一个实体的访问，比如控制一个身份对一个实体的读写访问(比如一个账本)。对给定资源的身份的访问控制基于 RBAC，其中身份被分配给角色，为资源定义授权策略，并且定义规则来确定哪些角色被授权访问该资源上的哪些内容。

苏格兰议会议员

这是 HLF 区块链网络的身份管理解决方案。MSP 执行以下任务:

  • 它注册并招募网络和渠道参与者
  • 它将证书映射到成员或参与组织
  • 对于一个组织来说，MSP 确定了参与者可以扮演的角色(管理等)
  • 它定义了参与者的网络和通道，以及访问权限，如读写权限

其主要活动如下:

  • MSP 通过列出用户的身份或授权 ca 为其成员分配有效身份来确定根 ca 和中间 ca，它们可以进一步定义域(也称为组织)的成员
  • MSP 代表一个组织，也负责网络上的 RBAC，以及该组织成员的渠道
  • 一个组织可以有一个或多个 OU，注册证书(X.509 证书)在证书中包含一个 OU 属性来定义该组织的业务领域

MSP 的类型

在本节中，我们将介绍 MSP 的类型。概括地说，有三种——网络 MSP、渠道 MSP 和本地 MSP:

  1. 网络 MSP :网络级别的 MSP 用于定义区块链网络，该网络被授权执行网络级别的管理任务，例如维护网络和创建通道；
    • 范围:网络级
    • 职责:管理活动，如定义渠道

  2. 通道 MSP :通道(也称为全局)MSP 在通道配置中定义。然而，每个节点都有一个通道/全局 MSP 的本地副本，它们通过协商保持同步。通道上的每个参与组织都定义了一个 MSP，该通道上的所有节点都将共享该 MSP，因此，将能够使用同一个真实来源对通道参与者进行身份验证。因此，任何新的参与组织首先需要将其 MSP 添加到通道配置中，以参与通道上的事务。通道 MSP 主要用于身份验证，不需要签署交易。渠道的所有成员都熟悉该组织成员参与的 MSP 的配置。这被称为通道 MSP:

    • 范围:渠道层面
    • 职责:通过在渠道级别定义实体成员的管理和参与权限，建立信任链

  3. 本地 MSP:T3】MSP 对节点和用户进行认证。每个节点和用户在其本地文件系统中都有一个本地 MSP。为了验证成员消息，并定义通道上下文之外的权限，对等方、订购方和客户端维护本地 MSP 的实例:

    • 范围:每个节点都有一个定义该节点权限的本地 MSP
    • 职责:验证成员消息，定义网络和通道级别之外的权限，并在本地应用配置时维护 MSP 的本地副本
    • 事实:
      • 诸如提交者、签署者和订购者的节点被称为本地 MSP。例子包括定义对等管理员等等。
      • 诸如客户端用户之类的用户使用本地 MSP 来认证与在信道上执行的交易相关的他们自己。
      • 参与者在组织中的成员资格是由作为本地 MSP 一部分的根或中间 CA 决定的。
    • 结构:下面的列表定义了构成 MSP 结构的各种元素。对于每种类型的元素，都有一个子文件夹，本地 MSP 作为文件夹存储在该特定子文件夹内的本地文件夹中。
      • 就结构而言，各种元素构成了本地 MSP，包括以下内容:
        • 根 CA 和中间 CA :根 CA 包含 MSP 中代表的组织信任的根 CA 的自签名证书(X.509 标准)。中间 CA 包含组织信任的中间 CA 证书列表。
        • 组织单元:可选元素，包含组织单位列表，用于限制组织成员。
        • 管理员:这包含作为组织管理员的参与者的身份。这就像定义角色一样。但是，访问权限(如添加新组织等)由系统资源决定，如通道配置或网络配置策略。CA 颁发证书中的角色属性还定义了参与者在组织中的角色，而不是在区块链网络中的角色。系统资源(通道、网络等)策略定义了该角色在区块链网络系统资源上的权限。
        • 吊销证书列表:逻辑上，这个可选列表与 CAs 和 CRL 是同一个列表。但是，它还规定了从组织中撤销参与者的成员资格。
        • 节点标识:强制元素，定义节点的标识。一个应该与密钥库(私有密钥)和节点身份一起存在于本地 MSP 中，允许节点(对等体，如签注者)在节点在网络或信道上发送的消息中认证自身；例如，背书者作为对交易建议的响应的一部分而发送的证书。
        • KeyStore :这个强制元素是节点的密钥，节点(提交者、订购者、客户端节点等)使用它对事务进行数字签名。它只是本地 MSP 的一部分，而不是通道 MSP 的一部分，因为通道 MSP 不发送事务，因此不需要签署事务。
        • TLS 根 CA 和 TLS 中间 CA :当一个节点想要连接到另一个节点时，TLS 通信被发送，例如提交者对等体和与订购者连接以获得分类帐的最近更新。此元素包含根 CA/中间 CA 的自签名证书。

所有 MSP(网络、渠道和本地)都应识别根或中间 ca 并与之交互，以确保建立信任链。

回到架构–概念视图部分的图，网络配置( NC05 )使用组织 O1 的 MSP 来确保参与者 P1 与组织 1 ( O1 )的关联。然后，网络配置( NC05 )使用访问策略中定义的 MSP 名称进一步向 O1 的参与者( P1 、 P4 和 P6 )授予特权；例如，将组织 1 的管理员P1(O1)定义为区块链网络的管理员。参考下面的 MSP 图，每个对等体在其文件系统中都有自己的本地 MSP 副本。此外，每个对等体保留其所属通道的全局 MSP 的副本；比如同行 P1 属于频道——C1和频道——C2。因此，尽管它有自己的本地 MSP，但它也包含一份通道配置副本，分别用于通道 1 和通道 2 的 CCon1 和 CCon2 。通道配置的本地副本也意味着全局 MSP 的本地副本。因此， P1 拥有频道-C1 和频道-C2 的全球 MSP 副本。

对于每个对等体，信任域是它所属的组织，它是对等体的本地 MSP 的一部分。但是，为了允许该组织(以及其同级组织)在通道上进行交易和通信，需要将组织的 MSP 添加到通道配置中:

会员服务提供商

该图还显示用户 A 属于组织 1 ( O1 )，并且用户 A 的身份由 CA01 (组织 1 的 CA)发布。属于 O1 的对等体 1 ( P1 )的本地 MSP 副本包含用户 A 的身份信息，根据用户请求的操作类型(本地或通道级)，对等体将验证用户 A 的身份。鉴于同行 P1 、 P3 、 P4 都在频道-C2 上，他们有一份全球 MSP。全球 MSP 将包含渠道( C2 )的所有成员( P1 、 P3 、 P4 )的证书和其他详细信息。此外，每个对等体都有自己的本地 MSP。

本地 - 级事务:参考下图，很明显可以在两个地方找到 MSP——通道配置(作为通道 MSP)，和作为本地对等体(本地 MSP)。本地 MSP 用于应用程序、用户、对等体和订购者，它们为该节点定义特权(权限)，例如对等体的管理。每个节点和用户都有一个本地 MSP。例如，用户的本地 MSP 允许用户在交易中验证自己，以及定义节点的参与权等。当用户 A 试图执行本地级事务时(比如安装链码)，对等方 P1 通过引用其本地 MSP 副本来验证用户 A 的身份。通过验证， P1 确保用户 A 属于组织 1，并且具有执行该事务的特权。只有通过验证，安装交易才能成功完成。

渠道 - 级交易:参与渠道的每个组织都必须有一个渠道 MSP。通道上的所有对等方和订购方对通道 MSP 有相同的看法。当用户 A 试图执行一个通道级事务时，比如启动链码，这需要所有参与组织的同意，那么对等 P1 将在执行事务前检查通道 MSP。渠道中的管理和参与权被定义为渠道 MSP。

频道(隐私提供商)

区块链商业网络的保密性是通过网络参与者之间的隔离通信来实现的，这是通过使用 HLF 信道来实现的。区块链商业网络中的交易在一个通道上执行，其中交易方被认证并被授权在该通道上实现交易。默认情况下，网络中的所有参与者都是通道的一部分。但是，对于私人交易，组织需要创建单独的渠道并授权成员使用该渠道。分类帐从一个渠道到另一个渠道是分开的，因此分类帐数据不能在两个渠道之间移动。分类帐数据和同行通过渠道分离，允许仍然属于同一个区块链网络的组织之间进行秘密和保密的交易。通道之间的数据分离是通过配置成员服务、链码和 gossip 协议来实现的。在这里，数据包括交易信息、分类账状态和渠道成员。该数据仅限于那些作为通道成员的经过验证的对等体。

客户端 SDK 向网络配置链代码传递参数，例如 MSP ID(在通道内唯一)、策略和成员(组织)。该调用在网络配置链代码上创建配置事务。这些版本化的配置事务(configtx)导致在渠道的分类帐上创建一个起源块。该 genesis 块记录诸如通道配置的信息。一旦一个成员被添加到一个通道中，它就可以访问 genesis 块上的相关信息。

一旦通道设置完成，参与者就可以部署 chaincode。然后，参与者可以提议交易、签署、订购和验证交易。MSP 向参与者授予访问权限，这些权限定义了参与者对通道的限制。通道外的参与者无法访问通道上的任何交易或消息。因此，根据渠道隔离交易增强了区块链网络提供的隐私保护。

程序传递控制系统

我们知道渠道有助于组织之间的私人和机密交易。但是，如果您希望在一个渠道上有几个组织，但是仍然希望将一些数据保留给参与该渠道的组织的子集，该怎么办呢？渠道有优势。然而，如果您不断地在需要私人通信的组织之间创建多个通道，那么您可能会以通道爆炸而告终，这将导致维护开销。您必须维护 MSP、策略和链码版本，这不允许我们处理在渠道中拥有组织子集的私有数据的用例。为了解决在一个渠道中允许组织子集的私有数据的挑战，HLF(从 1.2 版开始)提供了创建 PDC 的工具。

PDC–渠道中的更多隐私

通过 PDC，组织的子集可以在一个渠道内查询、评论和签署私有数据，而无需创建单独的渠道。

参照下图，同行 P1 属于组织 O1 ， P3 属于组织 O3 ，同行 P7 属于组织 O4 。这里， P1 、 P3 、 P7 都在频道-C1 。然而，组织 1 ( O1 )想要与 P3 进行私有数据交换，并且还想要与 P7 进行单独的私有数据交换。如果只遵循通道概念，那么系统将有多个通道。组织 O1 ( P1 )和组织 O3 ( P3 )将有单独的渠道，而组织 O1 ( P1 )和组织 O4 ( P7 )将有单独的渠道。处理此要求的另一种方式是允许 PDC 中渠道成员之间的私下交易:

分类账和私人数据

从分类帐的角度来看，每个对等体都有一个包含状态的分类帐——当前状态和事务日志。我们将在本章的后续章节中详细介绍分类账。该图将当前状态显示为分类帐状态，并显示分类帐中的交易日志。在这里，组织 1 有同行 P1 ，组织 3 有同行 P3 ，组织 7 有同行 P4 。由于 P1 和 P3 正在共享私有数据，该图显示了对等方 P1 和 P3 的私有状态( O1 和 O3 )。此外，由于 P1 和 P7 正在共享私有数据，该图显示了对等方 P1 和 P7 的私有状态( O1 和 O4 )。Chaincode ( SC2 )是在频道上实例化(C2)；因此，链码( SC2 )内的所有智能合约都可用于渠道( C2 )上的应用。该私有状态将被复制到来自想要进行私有通信的组织的所有对等体。那些授权的对等体将能够看到数据的散列，它位于主分类帐中，而真正的私有数据将在他们的私有数据库中。由于私有数据不会与未经授权的对等方同步，因此他们永远无法看到私有数据。但是，他们可以访问主分类帐的数据哈希。

PDC 是遵守通用数据保护条例 ( GDPR )的绝佳方式。其中一项法规规定，数据所有者可以删除私人数据。然而，我们知道区块链是不可改变的，一旦数据被记录到分类账中，就不能被删除。使用 PDC，私有数据保留在您的私有数据库中。它没有被写入分类帐。只有数据的散列被写入分类帐。

从技术上讲，PDC 由两个关键要素支持:

  1. 私有数据库:也称为每个对等体上的 SideDB，参与私有数据通信。您将回忆起本章中讨论的锚定对等点。由于有序节点不参与私有数据通信，因此需要通过 gossip 协议为 P2P 通信设置锚节点。
  2. 数据 hash : Hash 是对当前状态，主分类账。它充当事务证据，不能被删除，并且可以被通道中的所有对等体访问，而不管它们是否进入 PDC。

分布式分类帐

本节涵盖分类帐特定的区块链体系结构的各个方面。它还涵盖了节点，比如对等点和订购者，并且在定义订购者的同时，我们还将涵盖事务流流程。

节点

HLF 的部署视图包括作为 P2P 网络连接的节点，这些节点具有在这些节点之间共享的分布式边缘。节点在 HLF 中可以有不同的角色——对等节点和订购节点。

对等方:这些对等方提出交易，保存/应用和提交交易，并维护分类帐的本地副本。

对等体的类型如下:

  • 背书对等体，也称为背书者:这些从客户端/应用程序获得交易提议，验证客户端签名，获得受交易影响的世界状态的 RW 状态，并将这些状态发送给订购者。
  • 提交对等点，也称为提交者(非签署节点):在签署和订购之后，这些节点验证交易，将交易结果应用到本地分类帐。这被提交到分类帐，并且交易变得不可变。

在 HLF 中，每个签署者节点也是一个提交者节点。然而，并不是每个提交者都需要成为签署者节点。

  • 订购者:区块链网络中至少应存在一个订购者。排序者确保交易的正确排序。

凝视

同行构成了一个区块链网络，并主持分类帐和链码。我们在架构的概念视图中看到，每个对等体都有一个链代码和分类帐的副本。对等点提供 API，允许应用程序与它们交互，还可以启动、停止、配置、删除和重新配置对等点。一个对等体可以托管一个分类帐和链码，对等体只托管分类帐而不托管链码(应用程序链码)是可行的。对等体通常总是有系统链代码。HLF SDK 提供了 API，允许应用程序与对等体进行交互，因为如果应用程序需要查询分类帐或调用分类帐上的事务，应用程序将连接到对等体。然后，对等体依次调用链码来实现该事务的执行。

与订购者一样，对等体确保每个对等体上分类帐的同步性。我们将在随后的部分中介绍事务流，这将突出同级参与。这里有一个简短的概要:

  • 应用程序(希望执行事务的一方)连接到一个对等点。如果应用程序和对等方来自同一个组织，则证书由组织的 CA 颁发。
  • 对等体调用链码，从而生成建议响应。响应取决于来自应用程序的事务请求。例如，如果应用程序请求查询分类帐，则建议响应将具有查询结果，或者，如果应用程序请求更新分类帐，则建议响应将包括建议的分类帐更新。

  • 应用程序接收来自对等方的建议响应:

    • 如果是一个查询(分类帐-查询-交易)，那么当应用程序收到它的响应时，该过程就完成了
    • 如果是分类账更新(分类账更新 日期交易)，则请求进行到下一步

  • 对于分类帐更新请求(分类帐更新交易)，对等体不能发送响应，因为分类帐更新首先需要得到所有参与对等体的同意。这种改变分类账的协议被称为共识。

  • 由于分类账更新交易需要一致同意，对等体向应用程序返回一个建议的更新响应，这实际上是对等体建议的变更的快照。这类似于只有在达成共识后才在分类帐上执行的更改。
  • 应用程序接收响应。应用程序将从所有响应中构建一个事务，并将其发送到订购者的节点。
  • 订购者将从区块链网络中收集该交易和各种其他交易，并将它们汇编成一个块。
  • 然后，订购者将把这个块分发给所有对等(提交者)节点，其中也包括应用程序(在本例中)向其发送初始请求的对等节点。
  • 所有对等体，包括这个上下文中的对等体，都将验证该事务。
  • 交易验证成功后，对等方将更新分类账的本地副本。
  • 一旦分类帐被更新，初始请求被发送到的对等体将生成一个事件。
  • 该事件将被应用程序接收，这标志着更新事务的完成。

我们在架构–概念视图部分看到，各个组织拥有并贡献了对等体，这组对等体组成了区块链网络。由一个组织开发的应用程序通常连接到该组织的对等方。

一个区块链网络并不真正依赖于该组织及其贡献的同行。但是，至少应该有一个组织有一个对等方。有趣的是，组织对等体(属于任何组织)拥有相同的分类帐；然而，每个组织都可以自由地使用自己的代码语言来构建应用程序和表示逻辑。

从架构 : 概念视图图中，我们知道对等体连接到通道。通道也有通道配置，并包含全局 MSP。这个全局 MSP 有助于将对等体映射到他们的组织，因为颁发给对等体的证书是由该组织的 CA 发出的。例如，参考本章中的 MSP 图。这里，对等体 P1 的 s 证书是由 CA ( CA O1 )颁发的。通道配置( CCon1 )决定了身份(参与者如 P1 )是由 CA ( CA O1 )发出的，CA 来自组织 1 ( O1 )。这在OT20】1 中定义。MSP 包含在通道配置的全局 MSP 中。这有助于将同级与组织相关联。

每个对等体都有一个由组织的 CA 颁发的数字证书。这个数字证书充当对等方的身份。

在给定的时间点，一个对等体只能属于一个组织/由一个组织拥有。对等体可以驻留在任何地方；在本地机器上，在企业内部，在云上，等等。对等方的证书(身份)将该对等方与组织进行映射和关联。这种映射由 MSP 提供。除了通过 MSP 对用户进行认证之外，信道配置还涉及访问策略，访问策略决定了分配给对等体的特权(对等体的身份)。详情可在 MSP 部分找到。然而，简而言之，身份到组织的映射是由 MSP 定义的，连同分配给该特定组织中的对等体的角色，以及分配给该身份的权限(特权)。

订购者和交易流程

在区块链网络中，订购者维护分类账的同步性和一致性。我们已经看到了与分类账更新交易相关的细节，该交易需要网络中的所有参与对等体达成一致，以批准对分类账的更新。从其他对等方接收更新分类帐的批准的协议过程称为共识。一旦交易被所有对等方批准，它就被提交到分类帐，并且客户端应用程序随着提交的成功而被进一步更新(对分类帐的更新)。以下是总账-更新-交易的阶段:**

  • 提议:这是客户端应用程序将交易提议发送给通道对等方的阶段
  • 背书:这是模拟交易的阶段
  • 包装提案响应:在此阶段，每个背书人将其签署的背书返回给客户
  • 验证并发送订单:在此阶段，客户端应用程序随后验证提案响应并发送订单交易消息
  • 分配:在交易过程的这个阶段，订购者将把块分配给对等方
  • 验证和标记:在这个阶段，对等体将从订购者那里收到一个块，它们将把它标记为有效或无效
  • 通知:追加分类账时，在此阶段通知客户端应用程序

我们将在后面的一致意见部分详细讨论事务流。

分类帐

正如我们在第一章、探索区块链和 BaaS 中发现的，会计账簿将交易历史记录为借贷交易，而报表则显示当前余额。所有的贷方和借方分录都导致了当前的余额。现在，让我们建立类比，其中当前余额是分类账的当前状态，贷方和借方条目是交易日志条目。当前状态和交易日志一起构成分类账；区块链账本。要在分布式分类帐上进行交互(也称为交易),需要调用 chaincode:

  • 当前状态:也称为世界状态或简称为状态，这是一个键-值对，显示分类帐状态的当前值，它随着状态的创建、追加或删除而频繁变化。
  • 事务日志:这是导致当前世界状态的一组变化。在块中排序的事务被附加到区块链。事务集导致世界状态的当前值。这些交易，一旦排序和排序，不能修改，因此，块和区块链，也被称为分类账，成为不可改变的。

分类帐已分发；因此，它在所有的对等体上。我们在交易流中已经看到，在将交易提交到分类帐之前，需要达成共识。因此，分类帐与参与的对等体保持同步。

每个对等节点都有一个分类帐副本。这个副本包含事务日志和世界状态结果，作为键值对存储在数据库中。HLF 中的 DLT 有两个方面；世界状态和事务日志。分类帐状态包括一个键值对。世界状态是分布式分类帐在给定时间点的聚合状态。世界状态允许消费者获得分类帐的当前状态。分类帐的等式如下:

分布式总账=世界状态+交易日志

下图显示了由世界状态和事务日志组成的分类帐。事务日志由多个块组成，每个块包含一个或多个事务:

分类帐状态和交易日志

这个例子展示了一个名叫诺亚的男孩的小猪银行。世界状态和事务日志在开始时是空的。这由创世纪块 ( B0 )来表示。块 B1 包括交易 T1 ，其中 Daddy 将 10k 即贷方放入 PiggyBank 。这就像是爸爸账户的借方。第一个交易由块 1 表示( B1 )。第 1 块表示总账状态，其中键为 PiggyBank ，一个值为 10000 。此外，它还具有分类帐状态，其中键为 DaddyPutsToBank 并且值为 10000 。两种台账状态都是版本T34】0。版本 0 表示这是一个起始版本号，并且自创建以来尚未更新。

应用程序调用链码，链码实际上通过 API 访问分类帐状态，使用状态键对状态执行操作，例如get和put。

诺亚的妈妈和诺亚从小猪银行取钱。区块 B2 包括交易 T2 和 T3 。这里， T2 表示妈咪取 2k 即贷记妈咪账户的交易， T3 表示诺亚取 2k 即贷记诺亚账户的交易。小猪银行按 4k 借记。同样，区块 B3 包括 交易 T4 ，其中妈咪放 1k 即借记到妈咪账户，1k 贷记到 PiggyBank 。同样，块 B4 包括 交易 T5 ，其中诺亚取 3k 即贷记诺亚账户。在此状态下， PiggyBank 显示 PiggyBank 的最新当前状态，为 4k。因此，当前状态代表小猪银行的当前世界状态。即使世界状态被破坏，与当前状态相关的信息被破坏，按顺序重放事务将有助于创建当前世界状态。

世界国家数据库

我们在前面的章节中讨论了世界状态数据库。这里，让我们更详细地检查一下。它是一个数据库，提供查询并将其自身附加到分类帐的状态中。我们知道世界状态被建模为版本化的键值存储。这里，应用程序通过简单的put和get操作来追加或检索键值。世界状态在数据库中维护，数据库可以是 LevelDB 或 CouchDB。以下是对此数据库的快速比较和建议:

  • 相似之处:
    • 两者都可以存储二进制数据。
    • 都支持链码操作，比如get和set。这是get和set本质上获取和设置资产(键值)的地方。
    • 两者都支持范围查询，即通过范围查询键。
    • 两者都支持组合键；例如，资产 ID 和所有者 ID 的组合可用于获取特定所有者拥有的所有资产。

  • 差异:今天的业务应用程序将资产建模为 JSON。因此，CouchDB 允许应用程序使用 CouchDB 的 JSON 查询语言执行丰富的查询来链接资产被 JSON 建模的代码:

    • LevelDB 是默认的数据库，与一个节点并置，大部分嵌入在同一个操作系统进程中。
    • CouchDB 运行在一个独立的操作系统进程上。但是，它与网络节点和 CouchDB 实例保持一对一的关系。

  • 建议:

    • 当状态是简单的键值对时，建议使用 LevelDB。
    • 当状态结构是 JSON 时，那么推荐 CouchDB。
    • 有可能先从 LevelDB 开始，后来转移到 CouchDB。然而，我个人建议将资产的数据建模为 JSON，因此使用 CouchDB。
    • 建议对 CouchDB 使用索引，索引可以与链代码一起打包在不同的目录中。在对等体上安装和启动 chaincode 时，索引也部署到通道和 chaincode 的状态数据库，也称为 CouchDB。
  • 关键特性——可插拔 : HLF 有各种可插拔的组件，数据库就是其中之一。企业可以选择关系数据库、图形存储或时态数据库作为世界状态的数据库。

Chaincode

在第一章、探索区块链和 BaaS 中，我们了解了总账。有不同的分类账，例如，销售分类账记录财务交易，采购分类账记录支出和采购，而总分类账记录账户，负债，费用，收入等。类似地，在 HLF 中，事务日志是记录活动的分类帐。这些活动也被称为交易。分类帐的全局状态跟踪事务，这会改变分类帐的全局状态。世界状态是一个键值对，它被版本化，并且与事务日志一起构成了分类帐，该分类帐在区块链网络上的所有参与节点上都是可用的。现在，问题是:谁提议改变分类帐的世界状态？嗯，答案是 dApps。客户端应用程序通过执行链码中的业务逻辑向区块链网络发布交易，链码由智能合同组成。

所有节点都根据智能合约的最新副本进行协调。

现在，回头参考本章前面的分类账部分中的图表。在那个 PiggyBank 样本中， PiggyBank 和爸爸、妈妈和诺亚账户的账户余额显示了各方和 PiggyBank 账户之间发生的资产转移(也称为交易)的世界观。当妈妈和诺亚从小猪银行取钱时，它在 B2 块中表示为交易 T2 和 T3 。这里， PiggyBank 版本从 0 变为 1 ，因为它代表了键 PiggyBank 的值的变化。每当值发生变化时，就会创建一个新版本。所有这些事务都是针对链码执行的，这会导致工作状态的状态变化。那么，什么是链码？

链码(chain code)(和它的智能合同):这是一个分布式计算机程序，可以在 HLF 区块链网络上使用。在 PiggyBank 示例中，是链码使得资产(美元)在账户之间的移动不需要第三方或中介的参与。爸爸、妈妈和诺亚能够在没有第三方参与的情况下进行交易。

Chaincode 是一个计算机程序，在区块链网络上编译和部署。批准后，链码被部署到分布式区块链网络。它在 Docker 容器中独立于订购服务或对等进程运行。dApps 逻辑在 chaincode 中实现，其中 chaincode 用于初始化分类帐状态，然后管理它，这由 SDK 处理。客户端应用程序可以调用链码。因此，为链代码执行两种类型的事务——部署事务和调用事务。

  • Chaincodedeploy transaction:用户通过参与节点，创作一个 chain code(用 Golang 和类似的语言)并使用 HLF SDK 向区块链网络发布 deploy transaction。部署链码的许可被定义为访问控制，并且由 HLF CA 发布 ECert。Chaincode 运行在一个安全的 Docker 容器中。
  • Chaincodeinvoke transaction:dApps/client 应用程序将使用 SDK，通过发布一个导致调用 chain code 的事务来提议对分类帐的全局状态进行更改。应用程序通过传递 Chaincode 函数中定义的函数名和事务参数来调用 chaincode 的invoke函数。使用命令行或通过 SDK，可以针对 chaincode 的invoke函数执行查询事务。然而，在这个invoke函数调用中，并没有提议改变分类帐的世界状态。

对等体执行调用事务，每个提交对等体通过更新世界状态的本地副本来提交事务。我们将在随后的章节中详细分析链码、注册表等等。因此，本章仅限于链码的介绍。

到处都有共识

从其他对等方接收批准以更新分类帐的协议过程被称为共识。共识确保了以下几点:

  • 它确保分类帐交易在整个区块链网络中保持同步
  • 它确保只有有效和批准的交易被附加到分类帐
  • 它确保当追加交易时，它们遵循由订购者设置的相同顺序

为了达成共识，重要的是建立和维护交易顺序，并且有一种有效的方法来拒绝无效的交易被附加到分类账中。这可以通过 PBFT 来实现，它确保文件副本保持每个拷贝的一致性。比特币使用挖掘进行排序，其中每个计算节点将解决一个难题并定义顺序。HLF 提供了多种共识机制可供选择——SOLO 或 Kakfa。

共识不仅仅是建立交易的顺序。在 HLF 中，共识在交易流程中扮演着重要的角色——从提议到认可，再到订购、验证和附加。在整个交易流程中，身份验证发生在不同的阶段。这是一个持续的过程。有效负载由签署者和对等方签署，并且在整个事务流程中，有效负载被反复验证和认证。为了达成共识，重要的是确保交易的顺序得到满足，并且交易已经过背书政策。在提交之前，一定要确保获得足够的认可，并且事务已经通过版本控制检查，其中当前状态在提交到分类帐之前是一致的。版本控制检查是针对重复开销和其他数据完整性威胁的检查。

事务流图和流程流是正在进行的一致过程的表示。

对我来说，整个交易流程就是一个达成共识的过程。如果您检查下面的事务流，对等点会就事务的顺序和事务的内容达成一致。这是通过经历交易流程的各个阶段来实现的。在幕后，SDK 管理整个共识流程，并且在流程结束时的通知阶段通知客户。

频道(应用频道)包含关于共识选项和订购者组织的详细信息。例如，通道配置有一个名为 Kafka broker 的参数。如果将ConsensusType设置为 Kafka，则将其设置为频道订单的一致算法。它通常在区块链网络的引导期间建立，并且一旦在信道配置和区块链网络中配置，就被引导；然后，不可能通过配置来改变。另外，请注意，MSP 也是通过共识同步的。一致的意见是订购服务，当您在下一节中浏览交易流时，您会对此有所了解。

BFT 对 CFT :共识算法(协议)在 HLF 中是可插拔的，允许设计者基于用例选择共识算法。对于区块链商业网络由单个企业组成的情况，或者所有参与组织都是完全信任的，那么 BFT 不是理想的共识算法，因为信任已经存在。可以使用 CFT 算法，因为它们性能更好，吞吐量更大。然而，对于分散的分布式用例，包括多方，BFT 是最合适的共识算法。

交易流程

分类帐的同步性和一致性由订购者维护。在批准对分类帐的更新之前，达成共识。只有在所有同事批准后，分类帐才会更新。这是交易流程的一部分；并将在本节中详细介绍。

下图显示了交易流程:

交易流程

以下是交易流程的各个阶段:

提议:客户端应用发送总账-更新-交易 n 给通道上的对等体。参考上图，客户端应用程序 O1App1 在通道 C1 上发送(建议)一个事务。当安装并初始化 chaincode 时，一个认可策略被添加到通道配置中( CCon1 )。渠道的背书政策( C1 )规定组织 O1 ，组织 O2 必须批准交易。因此，当交易被提议时，它将到达通道( C1 )上的签署对等方，该通道属于组织 O1 和组织 O2 。参照该图，它指向 P1 和 P2 ，因为同行也在为组织 O1 和 O2 背书。

从技术上讲，应用程序使用 API，从而产生交易建议。交易建议类似于执行链码功能的请求，以便可以读取/更新分类帐数据。这里，应用程序使用一个 SDK (Node、Python 或 Java)和一个 API 来提议这样的事务。SDK 将负责将交易提议打包成一种架构格式(如 gRPC 上的协议缓冲区),并应用用户的私钥将数字签名添加到交易提议中。

背书 ( 模拟提案):客户端应用向通道上的对等体发送总账更新交易。这样的对等体是签署对等体。注意，对等体可以是签署者，也可以是提交者。在这个阶段，订购者的节点不被咨询，也不参与。以下是涉及的步骤:

  1. 应用程序生成一个交易建议，并将其发送给批准方。
  2. 该渠道将查阅背书政策以确定背书对等方，然后将该交易提案请求发送给所选的背书对等方:

我使用了单词choosed，因为 chaincode 的背书政策将规定一个渠道上的所有背书对等体是否需要背书一个交易提案请求。

  1. 每个背书对等体都有一份分类账和链码的本地副本。他们将根据交易建议请求执行链码，并生成交易建议响应。
  2. 每个签署方验证交易提案是否格式良好，并且在过去没有提交过。
  3. MSP 验证提交者的签名，并检查授权以确保客户端应用程序被授权在通道上执行事务(读/写)。诸如写策略之类的策略是在通道创建期间定义的，并且有助于确定用户对通道执行/提交事务的权限。
  4. 每个背书者将生成一个交易提议响应。他们还将使用自己的私钥对交易提议响应进行签名(对响应进行数字签名)。在此阶段，没有对分类帐的更新。
  5. 然后，每个签署人将向应用程序发送提案响应。对于一个事务，应用程序将接收多个建议回应。
  6. 在由各种选择的批准对等方发送到应用程序的交易提议响应中可能存在不一致，这可能是因为不同的批准对等方在不同的时间生成响应，并且在这些情况下分类帐状态是不同的。在这种情况下，应用程序可以执行以下操作:
    • 接受响应以允许交易流程继续进行下一步
    • 拒绝响应并终止交易流程
    • 发送另一个请求以获得更新的交易建议回应

从技术上讲，每个背书者将使用交易提议输入作为链码的输入参数。每个背书人接受交易提议，并使用存在的链码执行提议的交易。这些链码执行不会导致分类帐更新。他们只是模拟交易。背书人在模拟交易时，将获得当前的键和值列表(分类帐的当前状态)以及模拟的键和值列表(分类帐的未来状态)，它们将被写入分类帐。因此，有两组键和值(读取和写入组)。这些值集以及签署对等体的签名被添加到发送给 SDK 的提议响应中，SDK 将进一步解析应用程序要使用的有效负载。

打包提议响应:客户端应用程序将接收来自所有签署者的签署，并在接受交易提议响应后，将它发送到订购者的节点:

  • 从订购方节点的角度来看，许多应用程序将向其发送各自的交易建议响应。
  • 订购者将对这些交易进行分组排序和打包。这些街区就是区块链的街区:
    • 订购者将等待一段时间，将该时间段内的所有交易打包成一个块，或者，如果满足所需的块大小，则该块将准备好进行分发。
  • 订购者也没有链码的本地副本，因此，他们在定义程序块时不参考链码(判断)。
  • 注意:在 HLF 中，事务的排序并不重要。但是，无论它们以什么顺序被添加到块中，它们都将按那个顺序执行。
  • 注意:HLF 中的一个事务只出现在的一个块中，不会出现在多个块中。这意味着交易在块中的位置是最终的，并在此阶段得到保证。

从技术上来说，每个背书者将把它签署的背书返回给客户机(通过 SDK)。我们知道背书人已经获得了读写集。这些读写集是签名提案的一部分。

验证并发送订单:客户端应用程序将再次参与交易流程，并将执行两个活动——验证提案响应，对于分类账更新交易，客户端将连接一个订单服务进行进一步处理。

验证建议响应 : 客户端应用程序将验证建议响应:

  • 如果只是一个分类账查询交易，客户端应用程序将验证提议响应并收集其响应。它不会将其发送到订购服务。

  • 如果是一个分类账更新交易，那么应用程序将验证是否所有的签署方，如签署政策中所指定的，已经签署了该交易，以及它们是否都是有效的。顺序如下:

    • 客户端应用程序将首先验证认可对等签名
    • 然后，它比较来自每个认可对等体的提议响应，以检查提议响应是否相同

即使客户端应用程序选择不检查提议响应，签署策略仍将由对等方执行，并将在事务的最终提交中使用。

发送订单 : 在这个阶段，客户端应用程序将交易消息作为一个包(交易建议和响应)发送给订单服务。该交易消息包含以下内容:

  1. 两组键和值(读取和写入组)
  2. 签署的同行的签名
  3. 要提交事务的通道 ID

参照上图， O5 和 O1 为订购方，配置用于频道-C1 。因此，发往 C1 的交易消息将被广播给 O5 和 O1 订购方。他们将对事务消息进行排序，并创建这些事务的块。

从技术上讲，订购服务从它所连接和配置的所有通道接收这样的交易消息。订购服务将对这些交易进行排序和排序(按通道时间顺序)，并将创建交易块(按通道)。订购者永远不会创建交易，并将确保他们提供有保证的交付。order 的类为客户端应用程序提供了与 order 的节点进行交互的能力。订购者的节点有两个公开的 API—broadcast ()和deliver ()，它的双向流 API 在客户端应用程序和订购者之间有一个 gRPC 流连接。broadcast() API 使客户能够向订购者发送交易消息，而deliver() API 允许客户/消费者向订购者核实渠道信息和渠道配置。

分配:在交易过程的这个阶段，订购者将把块分配给对等方。对等体连接到区块链网络中的订购者。订购者将通过基于 gossip 协议的 P2P 通信将块分发给每个连接的对等体。

八卦协议(Gossip protocol):我想在这里谈一点八卦协议，因为发布是八卦协议被使用的阶段。订购者需要将交易消息分发给所有对等方。然而，这对于订购者来说是一个负担，并且当网络规模巨大时，几乎不可能达到所有的对等点。HLF 框架对此有一个解决方案。订购者不会将消息传递给每个对等方。订购者只将消息传递给被配置为领导者对等体的对等体。对于每个组织，在一个渠道上，都有一个确定的领导对等体。那些领导对等体将把那些消息分发给其他对等体等等。然后，对等体将这些消息转发给随机选择的若干对等体。这个随机数量的对等体是预先确定的，并且这种转发一直持续到消息到达所有对等体。整个过程被定义为广播，广播过程依赖于 gossip 协议来分发事务消息。

广播是分发消息的推送方法。然而，如果对等体从死亡状态转世到活着状态，则对等体使用拉方法来保持最新。

对等体自举:我们刚刚读到对等体向预定义或预定的对等体列表发送消息。这种决心是如何产生的？这是通过对等引导(也称为引导)实现的。当区块链网络建立后，每个对等点都有一个对等点自举集。之后，对等体检查对等体的存活状态。如果自举对等体失效，它会将其标记为失效。但是，它会定期检查它是活的还是死的。如果一个对等体死了，后来又活了，它将会在广播过程中丢失消息。因此，为了得到最新信息，对等体将提取信息，例如成员数据(对等体的存活和死亡状态)和分类帐数据(事务块)。

验证 和标记:在交易过程的这个阶段，对等方将从订购方接收块。他们将验证它们，并将它们标记为有效或无效:

  • 对等体将从块中挑选并处理事务。提货和执行交易的顺序与订购者对交易进行排序的顺序相同。对等方不执行此步骤的链代码。Chaincode 只在背书阶段执行，佐证了 chaincode 应该只存在于背书节点的事实。
  • 在处理交易时，每个对等体将验证该交易是根据实际生成该交易的 chaincode 中定义的签署策略签署的。这确保了所有打算签署事务的组织都签署了该事务，并且生成了相同的输出。
  • 如果经过验证，这意味着它被正确背书，然后会发生以下情况:
    • 对等体执行一致性检查。此检查旨在验证当前分类帐状态是否与对等方生成交易建议更新时的分类帐状态一致。如果一致，则交易被标记为有效。如果不一致，则不应用，并且事务被标记为无效，并被定义为失败的事务。例如，针对某项数字资产提出了一项交易并生成了一项提议回应，而该数字资产被另一项交易更新。在这种情况下，提案响应时间和一致性时间的分类帐状态不同，因此无法应用，因此标记为失败。
    • 一旦对等方验证了块中的所有事务，那么块中所有未失败的事务都将被提交到分类帐:
      • 失败的事务处理不会提交到分类帐，但会被视为成功，可供审计。

从技术上讲，每个对等体将把块附加到通道链上，并且只有有效的交易被附加到对等体的分类帐本地副本上(这是对当前世界状态的附加)。

通知:当一个块被提交到分类帐、对等体和链码时，它生成以下事件:

  • 对等体和链码生成以下事件:
    • 一个 peer 生成:block 事件和 transaction 事件。一个块事件包含整个块内容，而一个事务事件突出显示一个事务是有效的还是无效的(标记为失败)。
    • Chaincode 产生:一个 Chaincode 事件。
  • 应用程序可以订阅感兴趣的事件并接收通知。这些通知有助于应用程序了解事务的最终阶段。

前面定义的事务流清楚地显示了事务中涉及的各种参与者，从客户端应用程序到签署者、订购者、提交者和领导者。本节还明确强调了订购者在区块链网络中的重要作用。每个对等体验证交易，并遵循排序者在块中定义的顺序和次序。因此，是订购者确保了区块链网络的一致性。此外，它还确保交易在块中的位置永远不会改变，从而导致区块链网络中分类账的不变性。如果您重新阅读前面定义的事务处理过程，很明显所有的对等体都同意这些事务及其内容。订购者对这一协议过程进行调解，这被称为共识。

大型对象存储–链上或链下

本节讨论区块链网络内外的大型对象的存储。这部分是设计策略的一部分。但是，将此主题放在这里更合适，因为它是 PDC 的扩展，有助于实现它。

链上/链下架构的基本原理

数据存储和检索是区块链的核心，资产、账户、许可和交易都被视为数据。但是证据文件、x 光片、图像扫描、视频、法律合同文件等 PDF 格式的文档怎么办？区块链应用程序应该将这些文档存储在哪里？存储文档的架构上正确的方法是什么？这一章将讨论文档存储方法，以及区块链属性，比如不变性，是如何被保存的，即使是在离链存储中。

将图像、PDF 文件和其他对象作为区块链事务有效负载的一部分存储在链上是有争议的。这样做的原因是为了确保不可否认性和不变性适用于这些对象，就像它们适用于任何其他区块链数据一样。如果你存储的文档是离线的，只是包含了 URL 或者其他参考信息，那么就有被篡改的可能性和风险。当然，图像可以在离线存储中加密。然而，不被发现的篡改的可能性是存在的，因为它依赖于集中的第三方来管理文档。

反对在链上直接存储图像和大文件的观点与由于大的事务负载而显著影响性能有关。有三个方面需要考虑:

  • 网络延迟，因为大量(数 MB 甚至数 GB)有效负载必须通过网络发送给多个参与者
  • 计算成本，因为必须在签署消息时计算这些消息有效负载的数字签名哈希，并在收到消息时进行验证
  • 发送消息时 TLS 通道加密的开销
  • 存储成本，因为包含大型事务的数据块存储在多个区块链节点上

简而言之，在设计区块链应用程序时，在事务有效负载中包含大型对象对性能和成本的影响应该是一个重要的考虑因素。还可能存在潜在的保密问题，特别是在受监管的环境中，例如针对医疗保健数据的美国健康保险便携性和责任法案 ( HIPAA )法规、针对个人身份信息的欧盟 GDPR(PII)以及许多国家的类似法规。即使在许可的企业区块链栈(如 HLF)中，就对等体数量而言的网络规模较小，并且计算能力、网络带宽和存储可能更容易获得，从而使得可接受的有效载荷大小更大，但是由于企业应用的性质，保密性问题往往更大。

最终，答案将取决于用例、共享数据的性质，以及根据经验确定的特定有效负载大小的性能影响。虽然使用 HLF 和 Oracle Blockchain 平台，在技术上可以将文档存储在链上，但让我们将这与是否将文档存储在关系数据库中的类似争论进行比较。

数据库主要存储文本字符串、数字和日期值。使用int或float数据类型将允许您存储数字，var和varchar将允许您存储字符串和文本，而blob类型列(二进制大对象)将允许您存储二进制对象，如图像，或文档文件，如 pdf 或其他。然而，数据库的主要目的是提供快速高效的插入、检索和数据管理。虽然为了方便起见，可以将 blobs 存储在数据库中，但是将文档存储在数据库之外有很多优点。当文档存储在数据库之外时，性能要高很多倍，因为从文件系统存储和检索文档的性能远远高于数据库。事实上，一些数据库通过将 blobss 存储在文件系统中来处理 blob，在实际的数据库列中只有相关的指针和元数据信息，并在实际的数据库存储函数的掩护下实现这一点，以便它对数据库用户和应用程序完全透明。但是，仍然会增加一些成本，因此，在某些情况下，应用程序直接处理数据库外的文件存储可能会更好。

回到区块链，共享图像和文件作为区块链事务有效负载的一部分会带来各种限制，例如带宽、延迟(用于存储和检索图像)、各种节点之间的信息复制，以及由于块的大尺寸而加重共识过程的负担。事实上，由于区块链体系结构的分布式和可复制性，以及对网络延迟和 PKI 加密(用于数字签名及其验证)的严重依赖，反对让区块链负担大尺寸图像和文档的论点甚至比反对让数据库 blobs 负担大尺寸图像和文档的论点更强。因此，争论最终不是关于是否在链上存储文档，而是关于必要时的大小限制，以及应用程序的注意事项，以确保链上和链外存储是一致的，并且应用程序仍然可以受益于不可否认性和不变性属性，即使使用了链外存储。

在 HLF 事务流中，事务有效负载由客户端签名，并发送给一个或多个对等节点来执行。在将有效载荷交付给链代码执行容器之后，对等节点捕获链代码的读写集 ( 读写集)，如果有效载荷中的对象要存储在链上，那么这些读写集将包括这些对象。然后，对等体对 RWSets 进行签名，这涉及到对数据进行哈希计算，然后发送到客户端。客户必须验证签名，并且在多个签署者的情况下，比较结果以确保它们匹配。然后，一个加密的结果和所有的签名被发送到订购服务，在那里消息被存储在 Kafka 主题中。订购服务节点(osn)然后必须就将这些交易消息排序成块达成共识，这些块被发送到对等节点用于交易验证和分类帐更新。对等节点检查每个事务，验证其他签署者的签名，并在声明事务有效之前，对照当前世界状态数据库中的那些验证所有读取集数据字段的版本，将块附加到分类帐，并用写入集值更新世界状态数据库。

由于在区块链网络中，多方(客户端、对等节点和 osn)需要确保交易的准确性和有效性，并达成共识，因此任何涉及在链上存储图像或文档的交易都会降低区块链网络的速度。所有的消息传输、存储和检索、签名和签名验证操作以及字段验证也将消耗参与节点的大量资源。

关键设计原则

建议采用哪些选项和方法来解决这些限制？如何确保文档保持不变，并且即使文档存储在链外，不可否认性仍然适用？一个基本的最佳实践是让应用程序捕获一个不可变的文档散列，它实际上是文档、存储位置(内容管理系统中的 URL、对象存储等)和相关元数据的指纹，包括时间戳、用户凭证和版本号。这些数据随后成为文档记录，可以存储在链上，即使文档本身是离线存储的。文档记录是不可变的，并且当从链外存储器检索文档或图像对象时，它包含的文档散列可用于验证文档或图像对象的完整性。

在这个链上/链下设计模式中应用的其他重要实践如下:

  1. 在更新链上文档记录之前，请确保您已收到文档已成功离线存储的确认
  2. 在检索文档时，首先从区块链检索文档记录，使用位置信息检索文档本身，然后根据区块链记录中包含的哈希计算并验证其哈希

虽然可以在客户端应用程序中处理这些任务，但使用提供内置区块链锚定的链外存储解决方案会更有好处；也就是说，无论何时创建、访问、更新或删除任何文档，该解决方案都会自动在区块链上创建和更新记录。根据文档的性质，这可以是特定的内容管理/文档存储解决方案，也可以是在其容器中提供无差别 blob 存储的通用对象存储解决方案。因此，涉及链外文档的事务将由该存储解决方案处理，这反过来将创建链上不可变的文档记录。这利用了使用小文档记录的区块链网络的不变性，而文档本身被离线存储在文档存储服务中。

集成区块链–锚定文档存储解决方案

区块链锚定将有利于所有权证书、教育证书、监管合规报告、合同、实际签署或公证的文件、采购订单、税务发票、提单和其他运输材料以及贸易协议等文件。

在区块链网络上存储文档记录，包括加密哈希、位置和其他元数据，将补充典型的文档存储/内容管理功能，如版本控制、搜索、跟踪文档和文档级访问控制。

这样一个区块链锚定的文档即服务 ( BaDaaS )将管理两种类型的工件——离线存储的实际文档或图像文件，以及文档属性，如唯一的文档 ID、内容哈希、文档版本和其他元数据，作为不可改变的记录记录并发布到区块链网络。任何涉及这些链外文档的活动都将作为区块链事务存储在链内，而相关的文档属性将作为其有效负载存储在链内。

本质上，BaDaaS 提供了以下类型的 API:

  1. 通过调用POST调用上传文档的 API，或者通过PUT调用用新版本替换文档。出于分片的目的，每个文件夹或容器可以被映射到单独的区块链通道。
  2. 一个使用GETAPI 来检索文档的 API，它允许经过身份验证的用户下载或查看文档，但是只有在它的哈希与存储在区块链记录中的哈希进行了验证之后。
  3. 基于区块链事务历史检索文档历史的 API，包括所有相关版本和其他元数据更改、时间戳、用户身份等。
  4. 一个 API，用于检索最新版本的元数据，并验证文档内容是否与存储在区块链上的哈希相匹配，而无需下载文档本身。
  5. 用于管理访问权限和授予新权限的 API。这些更改也应该存储在链上，以确保它们作为一系列通过文档 ID 链接到文档记录的访问控制列表 ( ACL )记录的不变性。

这是一个解决特定类别用例的链上/链下存储需求的方法示例。它不会给区块链带来大容量负载的负担，但同时会确保以不可改变的方式在链上维护文档完整性和交易历史。

到目前为止，我们已经讨论了大型非结构化对象，比如二进制图像数据和 PDF 文件。这能应用于大尺寸的结构化文档吗？例如，在供应链协作需求预测和规划中，文档可以包含数百兆字节的结构化数据，作为区块链事务的有效负载来共享是不切实际的。好消息是可以使用类似于前面描述的非结构化文档的方法。对于区块链记录，只提取选定的数据，并对整个文档进行哈希处理，以确保可以在另一端验证其完整性。可以使用传统方式(例如，EDI 和 B2B 文件传输)传输文档，但是在传输的两端，区块链用于存储(发送时)以及检索和验证(接收时)相关的元数据字段，包括使用散列来验证所传输文档的完整性。

区块链应用的存储选项选择

企业可以选择以下选项之一来离线存储文档:

  1. 关系数据库或文档数据库——本地或云中(例如 Oracle 或 MongoDB)
  2. 文档管理或内容管理系统(例如，Oracle 内容和体验云)
  3. 分布式文件系统(例如 NFS)或分布式对象存储服务(例如 Oracle 云对象存储)
  4. 分布式数据库(例如，Apache Cassandra 宽列 NoSQL 数据库)
  5. P2P 文件共享网络(例如，星际文件系统 ( IPFS )或 Storj)

本节并不打算对这些数据存储解决方案中的每一个进行详细的回顾，而是作为区块链应用程序的离线存储解决方案的评估指南。首先，您可以将文档或图像数据存储在传统数据库(如 Oracle)或 NoSQL 数据库(如 MongoDB)中，后者提供更强的查询能力和更低的成本；然而，它伴随着低透明度、单点故障和强大的中央权威。

文档或内容管理系统提供了专门为文档定制的附加功能，例如文件夹结构、版本控制功能、以文档为中心的访问控制、ui、为处理文档而定制的 REST APIs 等等。然而，在作为具有单点故障的集中式解决方案方面，它们具有与数据库相似的缺点。当部署在云环境中时，可以通过适当的设计来减轻单点故障。

分布式文件系统或对象存储提供了其他选择，这些选择更简单、更便宜，并且比实际的文档更适合存储图像和其他二进制对象。请注意，虽然这些可以提供异步分布以避免单点故障，但在决定是在最初存储对象时提交区块链事务，还是等到对象被复制后再提交时，需要考虑与存储数据的异步复制相关联的延迟。答案可能取决于用例以及处理各种故障模式的能力。

像 Cassandra 这样的分布式数据库可以拥有遵循区块链拓扑结构的节点，从而消除了集中化问题。每个卡珊德拉节点可以共同位于区块链节点内。当文档被创建或更新到新版本时，本地 Cassandra 节点是第一个存储它的节点，然后它复制到其他节点。区块链记录更新事务可以同时提交给本地节点，但最终也会在其他节点上可用。使用分布式数据库的主要好处是可以在数据库节点和区块链节点之间实现本地关联，以进行更新和文档检索。然而，卡珊德拉和区块链中的复制在最终一致性规则下运行，但是速度不同(考虑到文档可能比相关联的区块链记录大得多)并且需要考虑不同的故障模式。

P2P 文件共享网络，例如 IPFS，其基于来自 BitTorrent 和 Git 的 P2P 概念而发展，但是其建立在DAG(有向无环图的缩写)架构上，使得能够在存储节点的分散网络中交换版本化的对象。每个对象(文件/文档)都有一个散列——一个用作其地址的唯一签名/ID。IPFS 根据对象的散列来检索对象，要求每个节点根据其散列来搜索文件。因此，将 IPFS 散列与文件散列和相关元数据一起存储在区块链记录中，提供了我们前面讨论过的核心锚定功能。IPFS 提供内容的历史版本控制和跨节点网络的高可用性。与 Cassandra 类似，IPFS 提供了一个分散的拓扑结构，尽管它更具可扩展性，因为它是基于文件系统而不是数据库的。但是，在应用程序的设计中，仍然需要考虑分发的延迟和潜在的故障模式。

摘要

本章重点阐述了 HLF、其体系结构和组件。在这一章中，我们看了 Hyperledger 项目，并浏览了 Hyperledger 项目的限定符。本章采用基于示例的方法来说明 HLF 的体系结构。我们探讨了对等体、节点、算法、共识、成员服务和订购服务，以及主身份、安全性和隐私。这一章还解释了渠道和 PDC 允许组织之间的私人交易。文章最后给出了存储大型对象的设计策略——链上存储或链下存储。从下一章开始，我们将深入研究创建一个 HLF 网络和编写链码来解决一个特定的用例。*

我们一直在努力

apachecn/AiLearning

【布客】中文翻译组