Oracle 区块链快速启动指南（全）

原文：zh.annas-archive.org/md5/acadfed886db9b7419ae428193b122c0

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书的创作基于这样一种信念：我们将共同积极促进区块链技术的发展，并不断激励其他人分享他们的经验，并进一步影响其他人这样做。在本书中，我们将做以下事情：

• 探索分布式分类账技术；区块链及其组件、特性、资格要求和架构；并揭开区块链即服务（BaaS）的突出地位之谜

• 参与建模基于区块链的业务网络，了解基于Hyperledger Fabric（HLF）开发业务网络，并评估区块链和 HLF 的使用案例及其潜在影响和集成

• 尝试利用Oracle Blockchain Platform（OBP）实践将网络拓扑转换为 OBP 的实用性

• 通过学习链码的完整生命周期，从开发到更新；从安装、初始化和测试到版本控制；最后，从集成到洞察，体验在业务网络中吸收智能的轻松和丰富性

本书的受众

本书旨在面向多样化的读者群体，从业务利益相关者、业务领导者；从区块链爱好者到设计师、架构师和开发人员；以及任何想要从本书提供的经验中受益的人。本书旨在成为学习区块链、HLF、设计策略以及在区块链平台上构建链码的快速参考指南。本书采用了一种模式，使读者可以将本书作为关于区块链、其使用案例、Hyperledger、设计策略以及区块链平台快速开发的参考书。

本书涵盖内容

第一章，探索区块链和 BaaS，深入探讨了区块链和分布式分类账技术。它还介绍了区块链分层架构、网络类型、参与者和结构。这一章为区块链铺平了道路，展示了它与分布式分类账技术的关系，并展示了它与之的相关性。本章将揭示 BaaS 平台的突出地位，其架构、特点、资格要求以及探索 OBP 显著性的预构建应用的易用性。

第二章，构建分布式账本技术和区块链，展示了 HLF 设计和实施策略的世界，同时深入研究了综合的五步设计策略——探索、参与、实验、体验和影响。在本章中，我们将构建作者创造的方程式，以证明区块链作为特定用例的合格解决方案。我们将研究各种许可商业网络的结构，例如合资企业、财团和创始人发起的，并一窥许可分布式自治组织（pDAO）。我们还将研究不同类型的用例，确认区块链的属性，并将它们视为各种用例及其采用背后的驱动力。本书包括一个关于金融科技的用例；帮助你学会通过定义其资产、参与者、分类帐、共识、交易、事件、权限和访问控制，来建模区块链业务网络（KonsensusChain）的艺术。它还探讨了如何将基于 Hyperledger 的许可业务网络与 BPM、SaaS 和其他应用程序集成，同时为样本业务网络创建基础设施。

第三章，深入了解 Hyperledger Fabric，展示了 Hyperledger 的架构，并允许你组装一个基于 Hyperledger 的样本业务网络。你将了解基于创始人和财团的业务网络。你将学习有关业务网络组件、向通道添加节点、使用链码和智能合约的知识。它将指导你使 dApp 或应用程序与业务网络进行交易。你还将深入研究身份、安全、隐私、成员服务和通道，以及通过 PiggyBank 示例演示账本状态和交易流程。这些细节将让你学会交易流程及其步骤，如提案、认可、打包响应、验证、排序、分发、验证、提交和通知。此外，你还将看到链上和链下架构作为私有数据收集的延伸。

第四章，在区块链平台上进行商业案例，使你能够与 OBP（开放银行项目）互动。你将学习如何设计与 OBP 构造相符的解决方案。同时，你还将看到样本业务网络拓扑结构、网络工件以及解决方案和部署架构。此外，你还将深入探讨 OBP 的详细特性和组件。你还将深入定义并创建一个基于创始人的业务网络实例。在本章中，你将看到一个与通道一起工作的丰富历史数据库。

第五章，使用 Oracle Blockchain 平台管理解决方案，让您实际操作将网络拓扑翻译到 OBP 上，创建网络利益相关者，并配置 OBP 实例。这一知识账本描述了交易基础设施设置，将参与者加入业务网络，访问控制，向业务网络添加智能性（链代码），以及 REST 代理配置来将链代码暴露给 dApp。

第六章，在 Oracle 区块链平台上开发解决方案，通过详细介绍链码开发，如所需的编程语言，开发工具和开发环境设置，为本书画上了句号。本章教会你关于映射资产模型、操作以及开发链码函数和接口。它重点介绍了链码从开发到更新的全部生命周期；包括安装、启动、测试和版本控制。它展示了使用 Go 和 Node.js 构建的代码库的完整链代码。本章还阐述了背书政策、私有数据集合及其与链码协同运作的功能。它涵盖了通过 shim 和 REST 端点进行的链码测试，以及使用 SDK、REST 和事件将客户端应用程序与业务网络集成。最后，它通过实验以链码日志和通道日志监视业务来呈现链码、交易和通道的见解。

获得本书的最大收益

代码示例在云环境和本地环境中进行了测试，可以通过在 VirtualBox 中使用 Oracle Linux ISO 映像创建虚拟机来进行。请下载 Oracle VirtualBox 6.x 并在具有 16 GB RAM 和至少 100 GB HDD 的机器（Windows/macOS/Linux）上安装。访问第四章，在区块链平台上进行业务案例，设置 OBP SDK部分，了解更多的安装步骤。

下载示例代码文件

您可以从您在www.packt.com上的账户中下载本书的示例代码文件。如果您在其他地方购买了本书，您可以访问www.packtpub.com/support注册并直接通过电子邮件收到文件。

您可以按照以下步骤下载代码文件：

1. 在www.packt.com上登录或注册。

2. 选择“支持”选项卡。

3. 点击“代码下载”。

4. 在搜索框中输入书名，然后按照屏幕上的指示操作。

文件下载完成后，请确保使用以下最新版本解压缩或提取文件夹：

• Windows 上的 WinRAR/7-Zip

• Mac 上的 Zipeg/iZip/UnRarX

• Linux 上的 7-Zip/PeaZip

该书的代码包也托管在 GitHub 上，网址是github.com/PacktPublishing/Oracle-Blockchain-Quick-Start-Guide。如果代码有更新，将会在现有的 GitHub 存储库上更新。

我们还提供来自我们丰富书籍和视频目录的其他代码包，请查看：github.com/PacktPublishing/。

下载彩色图片

我们还提供了一份具有本书中使用的屏幕截图/图表的彩色图片的 PDF 文件。您可以在这里下载： static.packt-cdn.com/downloads/9781789804164_ColorImages.pdf

使用的约定

这本书中使用了多种文本约定。

CodeInText：表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 句柄。以下是一个例子：“然后，从您的本地 Web 浏览器，只需输入 http://localhost:3000，您应该能看到控制台的 UI。”

一段代码的格式如下：

#Create user Oracle
sudo useradd oracle
sudo passwd oracle
<newPassword>

粗体：表示新术语、重要单词或屏幕上看到的词。例如，菜单或对话框中的单词会在文本中以这种方式出现。以下是一个示例：“点击右上角的 登录”。

警告或重要提示会像这样出现。

小贴士和技巧会像这样出现。

联系我们

我们始终欢迎来自读者的反馈。

一般反馈：如果您对本书的任何方面有疑问，请在邮件主题中提及书名，并发送邮件至 customercare@packtpub.com。

勘误：尽管我们已经尽最大努力确保内容的准确性，但错误是难免的。如果您在本书中发现了错误，我们将不胜感激地向我们报告。请访问 www.packt.com/submit-errata，选择您的书，点击勘误提交表格链接，然后输入详细信息。

盗版：如果您在互联网上发现我们作品的任何形式的非法复制，请向我们提供位置地址或网站名称，我们将不胜感激。请通过 copyright@packt.com 链接告诉我们。

如果您对成为作者感兴趣：如果您在某个领域拥有专业知识，并且有兴趣撰写或为书籍做出贡献，请访问 authors.packtpub.com。

评论

请留下评论。在阅读和使用本书之后，为什么不在购买书籍的网站上留下评论呢？潜在读者可以看到并使用您不偏不倚的意见做出购买决策，我们在 Packt 可以了解您对我们产品的想法，我们的作者可以看到您对他们的书的反馈。谢谢！

要了解有关 Packt 的更多信息，请访问 packt.com。

第一章：探索区块链和 BaaS

区块链被认为是一种具有颠覆性、改变游戏规则的技术，其影响将在未来二十年与互联网一样巨大。这个可编程经济在几乎每个行业都有用例和应用。区块链已经从一个时髦词发展成为对热衷者和实际实施者都非常感兴趣的东西。传道者们不再局限于概念证明（PoCs），而是已经开始实际的实施，并开始展示具体的成就。尽管采用速度较慢，但根据 Gartner 在 2019 年 6 月 3 日的预测（在www.gartner.com/上），到 2030 年采用率将达到 3.1 万亿美元。

区块链是一个让用户完全掌控交易和周围信息的世界。周围流动的信息是真实的、可信的、准确的、一致的、被接受的、完整的、及时可用的、广泛可用的、透明的和不可变的。区块链是一种分布式分类帐技术（DLT），它消除了中心化失效风险，而底层的密码学和算法将确保在这个不可变的世界中的安全性。由于信任存在于区块链网络本身，所以无需信任的中央第三方。欢迎来到区块链世界，一个分布式双向记账系统的世界。

这一章从会计系统、集中式和分散式分类帐开始，并创造了术语分布式双向记账系统。本章逐渐向区块链的定义和类比发展，并展示了点对点（P2P）网络提供的权益力量。在这里，您还将了解各种类型的区块链网络，例如许可和非许可，或公共和私有。本章然后逐渐向区块链架构的分层结构和交易结构以及区块和交易流程发展。最后，它介绍了您如何应对区块链解决方案，并定义了通过区块链即服务（BaaS）平台，如Oracle 区块链平台（OBP）来简化区块链采用的云方法—从 PoC 到生产。

会计系统 - 单式和复式

在我们深入讨论区块链、深入了解 Hyperledger Fabric 和 Oracle Cloud 解决方案之前，我们需要从两个核心原则开始 - 总账和会计。在会计系统中，业务交易记录在日记账和总账中。每笔交易的细节都被输入到各种日记账中。从日记账中的汇总信息然后转移到总账中（也称为过账）。总账中的信息成为试算平衡表和各种财务报表的来源。每笔交易都记录在日记账中，然后过账到总账中，该总账将此信息记录在各种账户中，例如资产账户、负债账户、所有者权益账户、收入账户和费用账户。

对于任何组织的会计系统来说，总账是其支柱。任何具有财务价值的事物都会被记录到组织的总账上。然而，这些总账是中央化的总账，组织对其拥有完全控制权。我们将在本章后面讨论中央化和分散化的总账。

会计系统 - 单式记账

会计系统旨在产生一份运营文档，显示资产所有权，保护资产以及执行各种其他任务。基本上，会计系统是一种强大的手段，用于检查资产损失，这些损失是由恶意人为活动、软件等造成的，并跟踪围绕这些资产的活动和交易。历史上，由于围绕资产的活动很少，单式记账足以证明资产的所有权。这是一种每笔交易在日记账中只有一次记账的记账系统。

单式记账系统类似于个人用于跟踪支票、存款和余额的支票注册。记录的信息很少，由个人拥有。这对于每天交易很少的以现金为基础的非常小型企业来说是一种高效的系统。没有基于信用的交易，拥有的资产非常少。最重要的是，无需发布收入、财务和资产负债表。从历史上看，它可能非常有效，即使在今天，对于那些符合上述属性的非常小的公司来说，它可能也会运行良好。

单录入会计系统存在各种挑战——没有科学或系统的规则来记录、过账和报告交易。它看起来像是一个不完整的系统，因为它没有记录账户的两个方面；因此，它无法真实反映利润或损失的情况，并且将无法反映组织的真实财务状况。由于所有这些缺点，单录入系统容易受到欺诈和账簿中各种错误的影响。因此，为了检查脆弱性，您需要信任一个集中的权威；因此，从历史上看，需要国王检查脆弱性并维护账簿周围的信任。然而，随着贸易的扩展，您需要一种机制来允许一个账簿所有者与另一个账簿所有者进行交易。这立即导致了双录入会计系统的出现。

会计系统 - 双录入

双录入系统提供了单录入系统中本质上无法获得的错误检查。每个账户都有两栏，每笔交易都反映在两个账户中。每笔交易都会产生两笔记录；但是，每笔交易在一个账户中有借方记录，而在另一个账户中有等额的贷方记录。双录入账户系统的一个示例是，如果一个组织想要购买一台价值$2,000 的新笔记本电脑。在这种情况下，该组织将会在支出账户中记录$2,000 的借方和在现金账户中记录$2,000 的贷方，以显示资产负债表中的减少。

双录入会计是一种展示交易影响的方式。例如，如果一个组织购买了一台笔记本电脑，会计分录并不清楚这台笔记本是用现金购买的，以换取另一台笔记本，还是赊购。只有当交易的两个影响都被记录时，这样的信息才能够得到。在会计系统中，这两个影响被称为借方和贷方。双录入会计系统遵循了对偶原理，这意味着，对于每笔借方记录，都必须有一个等额的贷方记录。借方记录显示诸如资产和费用增加，以及权益、收入和负债减少等影响。类似地，贷方记录显示诸如资产和费用减少，以及权益、收入和负债增加等影响。双录入系统确保会计等式保持平衡：

资产 = 负债 + 权益

在报告期末，总借方等于总贷方。资产负债表遵循该等式，其中总资产等于负债和权益的总和。任何偏离该等式的情况都会突显出错误。

有趣的是，单式记账系统只记录收入和支出，不监控所有权、负债和资产。然而，双式记账系统记录收入、支出、所有权、负债和资产，这使得轻松准确地得出和计算利润和损失、有助于检测欺诈、减少错误，并允许生成各种财务报表。由于交易的双方面都有记录，因此更容易让账簿保持完整。维护双重记账系统牵涉时间、金钱、技能和劳动。存在出错和疏漏的可能。在一个会计年度内，交易被记录并调整在最终账户中；如果跟踪交易是一个挑战，调整交易将会有困难。

在双重记账系统中，第一笔记录说明你拥有什么，而第二笔记录澄清你是如何得到它的。如果这些记录不平衡，那就清楚地表明对手方风险可能未被有效地计入，这会导致审计和纠正。在双重记账系统中，对对手价值的每一次变动都必须进行记账。多年来，这一简单、经得起检验、有效的会计系统一直是强制性的。

但是，考虑一下当不存在对手方风险的情况。假设系统不清楚谁拥有它并对资产和账簿中记录的价值负有责任。要发送或接收具有价值的资产，必须有对手方来接收和发送。直到今天，这些基础问题远未解决。组织的账簿记录了一项交易，对手方的账簿也记录了相同的交易；例如，供应商的账簿或银行的账簿。这反映了对手方对同一交易的看法。各种文件和陈述，如合同、发票、票据、银行对账单和收据，支持这些交易。这很容易出错，比如对账错误和现金缺失，进而导致争议。这需要争议解决，并且为了核对所有这些，组织投资于记录、分析和审计。

双重记账系统已经运作了几百年。在这一部分，我们不会强调三重记账系统的需求，而是会深入探讨分散化账簿。双重记账要求每个组织及其对手方维护自己的账簿，这反映了真相。然而，存在多个副本的真相。此外，组织和对手方投入时间、资源和金钱来执行真相调和，最终得出并达成一个统一的真相。

中央化对分散化账簿

本节突出了中央化和去中心化账簿以及分散化账簿，并概述了它们之间的差异。

以下图表显示了不同类型的系统：

系统和分类帐的类型

在本节中，我们将参考前面的图表来了解各种类型的分类帐的布局。在我们深入研究集中式和分布式分类帐之间的区别之前，让我们先了解一下不同类型的系统。

从控制的角度来看，系统有两种类型——集中化和去中心化系统：

• 集中式系统：一个实体控制整个系统，其中实体可以是一个人或一个企业。

• 去中心化系统：在去中心化系统中，可能有多个实体控制系统。没有单一的控制点，控制权是在各个独立实体之间共享的。

从位置的角度来看，系统有两种类型——集中式和分布式系统：

• 集中式系统：系统的所有组成部分，如服务器、分类帐等，都是共位的，存在于同一个位置。

• 分布式系统：系统的所有组成部分，如服务器、分类帐等，都不是共位的，而是存在于不同的位置。

这些系统的分类导致了以下系统变体：

• 分布式但集中化系统：分布式但集中化系统是系统的一类，从位置的角度来看，系统是分布式的，但系统由一个中央权威或中央实体控制。例如，云服务提供商提供各种服务，如计算、存储、SaaS、PaaS、IaaS 等。这些服务是通过分布式的服务器和数据库提供的。然而，整个系统由云服务提供商控制。这样的系统可以称为分布式但集中化系统。

• 分布式系统：从控制的角度来看，分布式系统是去中心化的，而从位置的角度来看，它们是分布式的。这意味着没有单一实体是系统的所有者或管理者，系统也不只存在于一个地点——它被广泛分布。DLT 及其类型，如区块链，就是这种分布式系统，其中控制不在一个实体手中。因此，没有单一实体可以改变或修改系统（去中心化）。另外，DLT 和区块链是基于 P2P 网络的，其中节点（对等方或参与者）是独立的，并且全球分布（分布式）。

分布式系统是去中心化系统的超集，并且基于 P2P 网络。

集中式分类帐

到目前为止，我们讨论的复式记账系统强调了一个具有集中式分类帐的会计系统。任何具有财务价值的事物都记录在日记帐中并发布到分类帐中。这些分类帐就像发布交易的中央仓库一样，它们是任何组织的支柱。

然而，中心化的分类账系统也有各种缺点。例如，银行控制着输入到银行分类账的交易，并且他们对银行对账单拥有绝对控制权。在这种情况下，他们可以随时惩罚你，并且可以随时从你的账户中转账。如果这样一个中心化的机构有恶意意图，后果可能是多方面的；他们可以在没有事先通知的情况下关闭他们的业务，从而禁止任何进一步的交易。这些例子主要被倾向于完全去中心化信任机构的区块链狂热者使用。

让我们看看一个更可行的挑战，涉及到银行。双向记账要求每个银行都要维护自己的分类账，以反映他们对真实的看法，随着越来越多的银行相互交易，他们需要调和他们对真相的看法，以得出一个统一的真相。如今，银行花费时间、金钱和资源来确保对单一真相达成共识。

显然，它们有自己的分类账和系统，这使得金融行业能够避免出现单一控制点和单一故障点的任何机会。此外，当客户在银行开立账户并将他/她的资金寄存在银行时，他/她对该银行有一定程度的信任。现在，责任在银行机构上，要保护你的资金和信息。另一方面，银行将投入大量时间、金钱、资源和精力来构建和维护一个系统，然后花费更多的时间、金钱、资源和精力与其他银行机构进行整合和核查，以确保他们的掌握的系统与其他银行机构的系统一致，以达成共识。

如果你仔细分析，你会发现每家银行的分类账实际上正在复制其他银行机构的功能。现在，如果其中一家银行的系统失败了怎么办？这会导致无法协调的局面吗？这不是更像一个单一故障点吗？答案在下一节和整本书中讨论的分布式分类账中。

分布式分类账

在全球范围内，在经济、法律、政治和制度系统中，关键要素是交易、合同和文件。它们决定了国家、企业、组织、社区和个人之间的关系，最重要的是，它们被认为提供了信任。有趣的是，这些要素在数字化转型中的参与程度还不是很大，也没有为更大的事业做出贡献。那么，解决方案是什么？分布式分类账和分布式账本技术（DLT），以及区块链，为这些关键挑战提供了解决方案。在本节中，我们将更多地探讨分布式分类账和 DLTs。

在分布式分类账中，没有中央机构或中央管理员。这是共享在网络上的资产数据库，网络上的每个参与方都有分类账的相同副本。这些资产可以是金融、法律和电子资产。这些资产价值的改变会在整个网络中反映出来，每个分类账的副本都会被附加。

许多组织、政府和机构使用了我们在中心分类账部分讨论过的分类账的中央数据库。中央分类账需要一个可信赖的中央机构来被交易各方信任；然而，在分布式分类账中，第三方的需求被省略掉了，这是吸引人们对 DLT 的吸引力之一。在这里，我悄悄地使用了 DLT 这个术语，因为分布式分类账可以被发音为分享分类账或 DLT，它们是同一个概念。

DLT 所颠覆性的地方在于分类账数据库是分布在网络中的所有节点或计算设备上，每个节点都有一个相同的分类账副本，节点独立地更新自己。所有参与的节点通过一种称为共识的过程达成一致意见，建立分类账的单一真相（真实的副本）。一旦达成一致，分布式分类账会被自动更新，最新的真相（真实的协议副本）会被分别附加在每个节点上。在阅读这一段时，你可能会想到银行的协调过程来建立对分类账的信任和一致性。使用 DLT，信任（协调）和一致性（协议）会无缝自动地发生。

我们刚刚发现的是在先前的故事中没有中央机构来维护分布式分类账。DLT 赋予系统减少对各种中央机构（如银行、律师、政府、监管办公室和第三方机构）的依赖的能力。分布式分类账省略了需要中央机构来验证、认证和处理交易的需求。DLT 上的过渡是被时间戳标记并且具有加密的唯一标识，被质疑的所有记录可以供参与者查看，这确保了交易的可验证和可核对的历史被不可变地存储。

在分散的分布式总账中，交易被复制到分布式总账中，这意味着所有参与节点的总账副本都被追加；然而，没有中央单一数据库。网络是分散的。这样的系统需要分散的共识，因为没有单一的联系点、单一的权威或方。因此，为了确保无信任，共识是必要的。在传统的数据库系统中，单一方代表交易客户行事，以修改系统的状态。然而，在分布式总账中，任何一方都可以记录，协议和算法管理着交易在网络总账上的发布。

下表列出了中心化账本和分布式账本之间的一些区别：

中心化账本	分布式账本
需要协调（内部和外部）。	不需要协调；然而，需要达成一致意见。
没有对数据库操作的限制。	它只能追加。
存在单一故障点。	它是分布式的；因此，没有单一故障点。
存在单一联系点。	它是分散的；因此，没有单一的权威。
存在第三方、中间人和门户。	这是点对点的。没有中央方，并且追加到总账的行为受到共识的约束。
需要备份和灾难恢复。	随着越来越多的参与节点加入网络，韧性和可用性增加。
可以代表某人执行操作。	存在加密身份验证和授权。
NA	添加到总账的数据是不可变的。
NA	节点之间存在直接交互，允许启动资产的直接交易，例如货币、房产证书或文件等。

有了总账知识，现在让我们深入了解 DLT 和区块链，并理解它们之间的区别。

DLT 和区块链

区块链是一个点对点网络，其中总账是分布式的，并且只有在达成共识后才会将交易发布到总账。这样的点对点网络，以及智能合约、加密学和算法等各种组件，有助于构建一个提供信任的区块链网络。区块链允许参与方（节点）在没有中介的情况下建立共识，这导致单一的分布式真相（总账）。没有协调、没有延迟和没有中介，交易将永远实时记录在一个不可变的总账上。

我们还没有涵盖有关区块链的详细信息，在这一部分中，我们也只是简要介绍了定义，并深入讨论了区块链与 DLT 之间的区别。到目前为止，我们知道分布式分类帐。区块链技术专注于安全高效地构建交易的不可变记录，也称为高重要性的活动。区块链（DLT 的一种形式）是最受接受的 DLT；然而，DLT 本身对未来有很多潜力。有各种类型的 DLT，如下图所示：

DLT

区块链将数据分组成块，将它们链接在一起，并通过密码学牢固地保护它们。区块链是一个不断增长的仅追加链，经过协商一致的交易只追加到块中。它们永远不会被改变或删除，这种不可变性具有各种用途。现在，由于区块链是 DLT 的一种形式，它是在区块链网络上分布的分类帐。每个节点都有一个分类帐副本，只有当交易达成共识时，才会安全地添加到其中。

DLT 是一个更广泛的术语，用于突出显示那些允许参与者（公共或私人）之间分发信息的技术。区块链是 DLT 的一种类型，得到了广泛的接受并且非常流行，因此它成为了 DLT 的代名词。DLT 专注于没有中央权威的技术，有趣的是，区块链是一系列块，而 DLT 既不要求链条也不要求块。对于区块链的愿景，DLT 产生了共鸣；因此，每个区块链都是一个 DLT。但是，DLT 不一定是区块链的必要条件。以下是关于 DLT 和区块链的类比，分别使用了术语车辆和汽车。因此，我们的等式是——每辆汽车都是一辆车辆；然而，并不是每辆车辆都必须是一辆汽车。

以下表格总结了 DLT 和区块链之间的区别：

DLT	区块链
这是一个分布在网络上的分类帐。	这是一个 P2P 分布式分类帐。
分类帐保持不变。	交易被分组到块中，块是不可变的。
DLT 包括一个确保协议的共识算法。	当达成共识时，块被添加到链中，每个块都有交易。
没有中央权威或集中式数据存储。	没有中央权威或集中式数据存储。

另外一些受欢迎和接受的 DLT 如下：

• Chain Core

• Corda

• 有向无环图（DAG）

• 哈希图

• peaq

• Quorum

总的来说，DLT 广泛地创建了一个系统——而区块链则特别地创建了一个系统，这个系统可以让世界拥有一个点对点的分布式账本，这个账本是可信的、不可变的、安全的，并且是基于共识的。DLT 有各种类型，比如区块链和 DAG，虽然区块链获得了更广泛的认可，但 DAG 正在缓慢而稳定地获得动力。就这本书而言，我们将集中讨论 Hyperledger Fabric 和区块链等 DLT。不过，无论是哪种 DLT，其核心优势都包括透明度、不可变性、高效性和没有第三方的存在。

是区块链的 DLT：

区块链是一种数据以块的形式存储的 DLT 形式。这些块是链接并加密的。因此，它也可以被称为块的加密链表，你可以追溯块的起源（这意味着你可以追溯到创世块）。这种块的链表（也称为区块链）是不断增长的。这种庞大的增长导致了交易速度缓慢，并且在点对点网络上需要大量的存储空间。

区块链技术作为平台：

我们先来谈谈区块链技术的第一个应用——加密货币。不过，本书不会进一步讨论加密货币。对于加密货币交易，账本被分布在点对点网络上。任何用户（节点）都可以无需许可加入网络，并开始交易。只要用户（节点）遵循交易协议，交易就可以被执行。如果交易有效，它们将被添加到区块链网络中。同样地，任何节点都可以参与共识过程，并开始验证交易。

这样的区块链网络是公开的，并通过浏览器应用程序向每个人提供读取权限。这样的交易信息不包含用户详细信息。它们只包含交易细节。这样的公共区块链网络不会对系统管理员产生费用，因为挖矿是由参与节点执行的，并且矿工会因为他们验证交易的努力而获得奖励。反过来，矿工可以通过照顾服务器、机器和电费来负担起基础设施的成本。你可以把这样的基础设施想象成是由人群资助、人群维护和人群验证的。成本是由参与节点共同分担的。通过这种方法，与集中式系统相比，基础设施的前期和维护成本大大降低了。一些流行的货币包括 Litecoin、Ripple、EOS、Bitcoin、Ethereum（Ether）等等。

除了加密货币，区块链平台还为无许可网络或有许可网络的增长提供支持。它可以作为各种类型交易和共识的平台，这些交易和共识代表了一个资产（有价值的东西）。无许可网络包括以太坊，而有许可网络包括 Hyperledger Fabric 和 R3 Corda。

不是区块链的 DLT：

有各种不是区块链的 DLT，比如 DAG、Hashgraph 和 数字资产控股（DAH）。它们也基于分布式账本的概念；然而，它们不是基于区块链（也称为区块链）的块链。它们大多是有效的，其交易量极高。DAH 主要与金融服务和银行等用例相关。Hashgraphs 是基于投票算法的有权限 DLT。DAG（表）是另一个不基于区块链的 DLT。目前它被用于 IOTA 和微支付。

比较区块链和 DAG：

区块链和 DAG 都是 DLT。然而，让我们来看看这两者之间的区别，以更好地了解它们的技术。

以下表格比较了 DLT - 区块链和 DAG：

特性	区块链	有向无环图
结构	它是一个区块链，交易被分组到块中。	它是一个链接交易的网络。没有交易块。
数据结构	它是一个链接列表（块列表）。	它是一个树（交易树）。
共识	交易按块验证以满足共识。	交易互相验证。
特征	提供透明度和不可变性。	提供高可扩展性和微不足道的费用。
用例	适用于交易量低、价值高的用例。	适用于高交易量的用例。
陷阱	交易成本高，存储和带宽要求高，计算能力也高（用于无需许可的场景）。	低交易量可能导致攻击。对于 DAG 的私有版本，它使用协调者，这不允许 DAG 完全去中心化。
方法	它是一个线性的、实用的 DLT，为交易提供几乎实时的更新，并提供去中心化。	它采用非线性方法，实际上在网络增长时结果更快的交易。

会计系统 - 三重会计或分布式双重会计

让我再次引导您回到会计系统。我们已经讨论过单式记账和复式记账系统。更多地关注分类账使我们熟悉了集中式和分布式去中心化分类账。此外，即使在本章中我们还没有将区块链的定义巩固下来之前，我们也试图将其与 DLT 进行比较。现在，我们回到了起点，回答另一个关于会计世界中的区块链的重要问题。

有很多关于三重会计系统的讨论。许多倡导者认为三重会计系统是对古老而经得起考验的双重会计系统的先进增强。借贷和贷方仍然是两个主要的条目，而第三个顶点条目是对所有以前的借贷和贷方的不可变链接，这意味着所有的账目条目都有一个不可变的加密封印。

假设两个组织正在进行一笔交易；一个组织将在其账户中发布收到的金额的借方，而另一个组织将在其账户中发布花费的金额的贷方。然而，这些发布是到不同分类帐中的。我们在银行机构的例子中以前已经见过这种情况。现在，这些组织有不同的分类帐副本，然后它们将对其进行调和以确保它们有一个共同的“真实”理解。分布式分类帐技术将确保没有两个分类帐。将存在一个分类帐，它将保持分布式，而区块链技术将确保发布到分布式分类帐的交易是不可变的并且安全密封的。不可变性将确保它永远不会被篡改，而加密技术将处理安全方面的问题。因此，企业和商业不需要调和分类帐，因为不存在单独的分类帐。

尽管有各种各样对于三重记账系统的定义，但要取代经过验证的双重记账系统将会非常困难。三重记账是一个复杂的术语；我们不否认在区块链网络中将交易发布到分布式分类帐有巨大的好处这一事实。在分布式、仅追加、不可变的分类帐中发布和记录交易有很多好处，我们将在本书中详细介绍这些。

例如，一旦签署了合同，区块链上就会创建一个区块，并且交易会发布到区块链网络中的分布式分类帐。有人可以针对该合同发出购买订单，这笔交易也会作为一个区块附加到区块链中，这意味着它也被发布到分布式分类帐中。可以针对这些购买订单发出账单，并且可以将支付与这些账单关联在不同的交易中，并记录到分布式分类帐中。您拥有一个区块链，其中显示了从合同到付款的交易，在一个单一的分布式分类帐中。这意味着您拥有出色的审计记录，并且所有交易方都能实时查看交易。像超级账本面料（Hyperledger Fabric）这样的权限分布式账本技术还可以进一步使您能够对这些交易提供受限制的访问。此外，这些发布的交易无需调和，是不可变的并且无处不在的。

我们刚刚学到，在区块链网络上的分布式账簿中，交易是不可变的，没有人可以伪造它们。交易被时间戳记录、验证，并通过共识达成一致，值得信赖；这提供了一种在任何时候实时检索、访问、分析和审计的简便方法。交易链，在区块中被捆绑在一起，并分布在区块链网络中，每个参与节点都拥有相同的账簿副本（网络上的单一真相）。在这个方程中，我们没有见到一个单一的权威/方，因为没有中央可信方；信任在区块链网络和分布式账簿中。欢迎来到区块链世界，一个分布式复式系统的世界。

总之，我个人相信分布式的复式记账系统。你可以把它称为三重记账系统，如果你愿意的话。然而，这种会计系统的本质保持不变——分布式、安全和不可变的复式记账系统。在这个方程中，DLT 提供了账簿的分布，而区块链技术将确保单一分布式账簿的密码学、安全性、数字收据和不可变性。因此，在本书中，我们将使用分布式复式记账系统这个术语，你仍然可以称之为三重记账系统。

区块链的定义和类比

通过对账簿、系统类型的事实检查以及了解 DLT 与区块链之间的区别，让我们来了解区块链的定义和类比。区块链是一个 P2P 网络，账簿是分布式的，交易只有在共识达成后才会被发布到账簿上。这样的 P2P 网络，以及各种组件，比如智能合约、密码学和算法，帮助构建了一个能够提供信任的区块链网络。区块链允许参与方（节点）在没有中间人的情况下建立共识，这导致了一个单一的分布式真相（账簿）。没有调解、没有延迟，交易是实时记录在永久不变的账簿上的。

让我们用一个类比来解释区块链。我们将区块链比作一个笔记本。每一页代表区块链上的一个区块。你可以在这一页上记录任何类型的数据，比如医疗记录和金融交易，这也被称为一个区块，其中每一页（区块）都与前一页（区块）相连。这个链不仅仅是到前一页的链接；它还包含有关页面的信息，一旦页面上的数据被定义并添加到笔记本上，就不能被更改。如果更改了，页面的信息也会更改。然后，它与其他页面的链接也会更改，以此类推。这是因为链上的连接被中断了。因此，每个链接页面上的行都是不可变的。

区块链技术还包括智能合约，这是智能程序化合约，也称为规则；这些在区块链网络上的某种类型事件发生时被定义和执行。它被称为区块链，因为区块的链是一个块的链表，其中每个块有一个或多个交易。这些交易在一定时间段内由区块链网络验证和验证。区块链协议的共识算法，采用了该区块链网络的规则和参与节点的激励。我们将在共识算法部分详细介绍这一点。

区块链是一个块的链，每个块上记录着在分布在区块链网络的所有参与节点上的分类帐（区块链）上记录的交易。这个分布式分类帐是分布式的双向分类帐（如前所述），用于记录任何数字资产或有价值的资产的交易。对于区块链网络，交易从它（分类帐）开始被记录，它们永远保持不变地留在那里。因此，可以从网络开始生成、追踪和验证财务报表。有趣的是，由于分类帐是分布式的，并且所有参与节点都有其副本，任何节点都可以验证交易并宣布交易验证以达成共识。

类比

让我们再看一个类比。让我们回到一个没有技术的时代。有一个美丽的村庄，有几个家庭，他们不是用货币，而是用商品进行交换。

一个蔬菜农民会用蔬菜交换大米，一个大米农民会用大米交换花生，依此类推。这种方式运作得很好，直到他们开始相互承诺为止。承诺（交易）是信用，其中一个农民会买蔬菜而不交出大米；相反，大米农民会承诺在大米收获时还蔬菜农民大米。同样，水果农民会得到大米，并承诺在收获时交付橙子。

蔬菜农民信任大米农民；然而，随着时间的推移，各种农民之间进行了几次承诺交易，跟踪这些承诺变得困难，这导致了信任的破裂。最终，村民们任命了一个人来跟踪这些承诺。这个人被赋予了名为分类帐人的头衔（中央第三方）。很快，分类帐人建立了信任；然而，他被承诺淹没，并开始要求费用（交易成本）。村民们同意付给他一部分承诺作为费用。最终，这将分类帐人变成了一个富有的人。后来，分类帐人沉溺于腐败，开始接受贿赂以篡改分类帐，贿赂村民以保住自己的位置，并有时增加费用。

很快，村民们意识到拥有一个分类帐管理人（集中式系统）的挑战。因此，他们决定，不再由单个分类帐管理人保留承诺，而是由每个人保留承诺（去中心化）。不会有一个人持有承诺；村民们会在指定地点聚集以进行承诺，并且每个村民都会记录每个承诺（P2P 网络）。

每周，他们会通过朗读他们对承诺的版本来验证这些承诺。如果大多数村民就某项承诺达成一致（共识），那么该承诺将被视为有效，并被视为真实（账本）。在出现问题时，具有大部分条目的承诺将被视为正确的承诺，并有助于解决基于承诺的任何问题（最长链）。随着时间的推移，他们增加了安全性和各种其他功能。

我们将重新讲述这个故事，并进行扩展。目前，我们了解到区块链是一种解决方案（协议），它允许无领导（去中心化）的对等节点（P2P）就交易达成一致（共识），并且一旦发生（同步），它们就会被记录（发布）在一个无处不在的防篡改（不可变）的分布式链表（分类帐）上，其中每个节点都持有其副本（分布式）。我们刚刚了解到区块链是一个 P2P 网络；现在，让我们确切地了解一下 P2P 网络到底是什么。

区块链组件

区块链由各种组件组成，在区块链网络中协同工作。在本章中，我们将介绍其中一些组件，以及一些其他组件，如成员服务，将在后续章节中详细讨论。以下是区块链组件的列表：

• 分类帐：分类帐是一个分布式分类帐，交易被不可变地记录/发布在其中。作为一种 DLT 类型，区块链确保了交易历史的不可变性，从创世区块到当前区块。在本章中，我们已经涵盖了单式记账和复式记账。区块链分类帐是分布式复式记账系统的安全实现。

• 对等网络和节点：P2P 网络是一种计算机网络，其中计算机（对等节点）分布并共享网络的工作量以达到最终目标。节点在区块链上执行交易。有两种类型的节点 —— 完整节点和轻节点。像区块链或超级账本（Hyperledger）这样的分布式分类帐技术可以是公共的或私有的。在公共区块链中，每个节点都有权益；然而，他们可以以不同的角色运行，例如作为矿工，作为完整节点，其中区块链的完整副本将被复制到这些节点上。他们也可以作为轻节点，并且只能持有密钥或区块头值。

• 智能合约或链码：对于像以太坊这样的区块链，以及像 Hyperledger 这样的 DLT，智能合约或链码是在区块链网络上执行的代码逻辑。参与节点或区块链客户端可以根据该业务逻辑（智能合约或链码）发出交易。随着区块链层的加入，账本不仅存储不可变的交易，还存储不可变的代码。

• 会员服务：对于像 Hyperledger 这样的 DLT，会员服务提供了身份和安全解决方案，确保用户参与区块链网络。认证和授权是会员服务的功能。它们主要用于私有和许可的区块链或 DLT。

• 事件：区块链或 DLT 负责在区块链/DLT 上发生特定定义的操作时引发事件。事件是让其他订阅应用程序或系统与区块链网络交互的有效方式。

• 共识：共识算法（或协议）是区块链平台存在的核心。毋庸置疑，区块链网络在没有共识的情况下无法存在。共识层是任何区块链（以太坊或 Hyperledger 等）中最关键和至关重要的层。共识负责验证块、排序块，并确保每个人都对其达成一致意见。有关共识算法的详细信息，请访问本章节的共识算法一节。

在前一节中，我们详细讨论了账本和分布式系统。在本节中，我们将专注于 P2P 网络。本章探索区块链和 BaaS和第二章理解分布式分类账技术和区块链将详细介绍所有列出的组件。

P2P 网络

区块链技术利用互联网并在计算机的 P2P 网络上运行。这些计算机运行区块链协议，允许这些计算机保留账本的副本。这个账本包括被打包在一起形成链的交易，起始区块。将块加入链中是通过共识达成一致，无需中介。

区块链分布式分类账在 P2P 网络上运行，交易通过共识算法使用密码学进行验证。区块链网络为其定义了共识算法，这基本上是验证区块链 P2P 网络上交易的规则。一旦达成共识，块就会被添加到账本中。将块添加到网络中的节点然后会获得激励（根据区块链类型而定）。因此，重点在于，在分布式分类账的 P2P 网络中，交易使用密码学进行验证并通过共识进行确认。

下图显示了网络的类型：

P2P 网络

如前图所示，集中式网络有一个中心节点，该节点定义和管理交易的验证和核实。所有其他连接节点依赖中央权威。中央权威可以完全访问和控制数据、信息和交易状态。尽管这是一个受严格监管的网络，但也是中央控制的。一方面，只要中央权威和参与节点之间的信任保持真实，就是安全可靠的；然而，人为错误、恶意意图、单一故障点和权力掌握在一个单一权威手中也存在自己的挑战。它适用于非常小的组织，可以迅速做出决策，甚至最小的决策也是可见的。去中心化网络与中心化网络几乎相同；然而，在这里，中心节点本身是分布式的。这意味着权威的集中化是分布式的。在去中心化网络中，每个节点不直接连接到节点；但在 P2P 网络中，每个节点都连接到其他节点。

股权网络或点对点网络

P2P 网络利用网络；然而，节点的连接和断开完全是自愿的。该网络是一个平等的网络，其中每个对等节点与任何其他对等节点一样平等和公正。一个对等节点向其他对等节点提供计算资源，而不需要中央权威来控制、管理或维护网络。即使它具有公平性，每个节点都有公平的机会扮演矿工的角色，或者可以将自己变成完整节点。每个节点都保存分布式账本的副本，这一区块链网络的协议确保了区块链网络的弹性和不可变性。只要有一个节点保留了分布式账本的副本，区块链网络就可以复活整个系统。

在 P2P 网络上，信息在所有参与节点之间记录和复制；因此，随着越来越多的节点加入区块链网络，P2P 网络的权力、一致性、可靠性和信任也会越来越多。此外，由于没有单一故障点和单一权威，系统不容易遭受黑客攻击、数据丢失、不一致性、人为错误或单一部分控制网络议程，因此权力和隐私仍然留给每个节点。请注意，正是共识算法确保了区块链上数据的同步。有各种共识算法，例如工作证明（PoW）和股权证明（PoS）。我们将在本书中详细讨论它们。

区块链架构的分层结构

本节介绍了区块链的分层架构。在本节中，我们还将涉及以太坊和 Hyperledger Fabric。在讨论 Hyperledger Fabric 基础设施时，我们也会深入了解 OBP 的基础设施。

下图显示了区块链的分层架构：

区块链分层架构

硬件和基础架构层

区块链的内容托管在位于这个美丽星球的数据中心中的服务器上。在浏览网页或使用任何应用程序时，客户端会从应用服务器请求内容或数据，通常称为客户端-服务器架构。但是，今天，客户端也可以连接到对等客户端，并在彼此之间共享数据。这样一个庞大的计算机集合彼此之间共享数据被称为 P2P 网络。区块链是一个 P2P 网络，它计算交易，验证它们，并以有序的形式将它们存储在共享账本中。这导致了一个分布式数据库，记录了所有数据、交易和其他相关信息。P2P 网络中的每台计算机都被称为一个节点。节点负责验证交易，将其组织成块，将其广播到区块链网络中等。在达成共识后，节点将块提交到区块链网络并更新其本地账本副本。这一层包括虚拟化（创建虚拟资源，如存储、网络、服务器等）。值得注意的是，节点是这一层的核心。当设备连接到区块链网络时，它被称为节点并被视为节点。在区块链网络上，这些节点是分散和分布式的。

以太坊 - 基础架构层

让我们来看看以太坊中的节点。任何人都可以在自己的计算机上运行一个以太坊节点。这将使他们的计算机能够参与到以太坊区块链网络中。节点可以运行一个客户端（兼容的客户端），如 Geth、Parity 或 Pantheon，以连接到以太坊区块链。Geth 是用 Go 语言编写的，Parity 是用 Rust 语言编写的，Pantheon 是用 Java 语言编写的。一个节点（运行节点的客户端）可以是轻节点（客户端）或全节点（客户端）。轻节点存储缓存，而全节点（客户端）存储数据集，随时间线性增长。轻节点（客户端）从以太坊区块链网络中获得有关以太坊状态的高保证，并且他们可以参与验证交易的执行。另一方面，任何参与全面执行共识并将整个区块链下载到节点本地存储的节点被称为全节点（客户端）。全节点验证签名，格式化交易和区块的数据，检查双重支付等。它们基本上验证交易并使用八卦协议将此信息传递给其他节点，称为对等节点。

这些以太坊节点（客户端）运行以太坊虚拟机（EVM）。EVM 是一个图灵完备的软件；一个基于股权的虚拟机，使不可信代码能够被全球点对点计算机网络执行。EVM 处理内部状态和计算。以太坊区块链是一个图灵完备的区块链，开发人员还可以为区块链开发程序（智能合约）。EVM 类似于 JVM，它们在区块链上的每个节点上运行。EVM 就像交易引擎一样，负责改变区块链的世界状态。EVM 作为沙盒运行，并为智能合约提供执行环境。

超级账本– 基础架构层

这个基于超级账本框架的区块链网络由对等节点组成，这些节点托管账本和链码（也称为智能合约）。基本上，对等体托管账本和链码的实例，这些实例关注单点故障。由于对等节点负责托管账本和链码，应用程序和管理员需要与这些对等节点进行交互。在超级账本中，一个节点可以托管多个账本。在一些情况下，对等节点只能托管一个账本，而无法托管链码（这种情况很少，但有可能）。大多数节点至少安装了一个链码，以更新或查询节点的账本。一个节点也可以托管多个链码和多个账本，由通道支持。您将在第三章，深入了解超级账本中了解更多关于通道和超级账本架构的信息。

要访问链码或账本，应用程序和管理员（通过管理应用程序）将始终通过超级账本软件开发工具包（SDK）API 连接到对等体。这些 API 允许应用程序在区块链网络上执行交易，并接收与流程确认相关的事件。有两种类型的交易——查询交易和更新交易。对于查询交易，不需要共识，因为对等体将立即从其账本的本地副本返回结果。然而，对于更新交易，没有个体对等体可以更新账本，因为其他对等体在更新账本之前需要达成一致。达成一致更新账本的过程被称为共识。您可以在第三章，深入了解超级账本中详细阅读关于账本更新交易过程。

特定的一组应用程序和对等体可以通过通道进行通信，因为通道是特定应用程序和对等体之间的一个分区——通信的路径。Hyperledger Fabric 适用于企业，并为私有许可（联盟）和私有无许可用例提供支持。各种志同道合的组织组成联盟，建立区块链业务网络。因此，对等体由各种组织拥有。这些组织为区块链网络的设置、维护和运营提供资源。资源之一是节点（对等体），只要在区块链业务网络上有一个组织拥有一个对等体仍然存活，业务网络就可以继续存在。

该组织的管理员分配节点给区块链业务网络。每个组织都有一个证书颁发机构，它为这些节点分配数字证书。这个数字证书（X.509）是这些对等体的数字身份。当对等体尝试连接到区块链业务网络上的通道时，这个数字身份有助于识别对等体的所属组织。通道具有策略，这些策略确定对等体的权限和特权。这个对等体在组织中的角色与对等体的身份与组织的映射由成员服务提供者（MSP）提供。与区块链业务网络交互的任何东西，如对等体、应用程序、管理员、订单者等，都必须有一个身份和一个关联的 MSP，以使它们能够与之集成。

订单节点确保区块链业务网络上账本的一致性。让我们快速了解一下基于 Hyperledger Fabric 的区块链网络的交易流程。整个过程由订单者（订单节点）进行调解，在此过程中，所有对等体就交易内容以及交易顺序达成一致。

交易流程：Hyperledger Fabric 基于区块链网络中的交易发生在一个多阶段过程中。请访问第三章的深入了解 Hyperledger Fabric，以获取更多详细信息。以下是交易流程的简要介绍：

1. 第一阶段（背书阶段）：应用程序发起账本更新交易。这个交易请求由背书对等体（作为背书者的节点）处理。这些节点背书所提议的账本更新并将背书发送给应用程序。然而，对账本不执行任何提交。

2. 第二阶段（排序阶段）：来自各种应用程序的背书交易的提案响应被订单者节点接收。这些节点将交易排序成块。

3. 第三阶段（分发阶段）：最后，有序的区块被分发到区块链业务网络中的所有对等方。这些对等方将验证交易，并在验证成功后将交易提交到账本的本地副本。

订单节点是整个交易过程的中介。此交易过程称为共识，因为区块链业务网络中的所有对等方都就交易和交易数据达成了一致意见。订购服务利用了面向消息的架构，订购服务可以以以下三种方式之一实现：

• 独立

• Kafka

• Raft

以下表格突出显示了各种订单服务实现的特点：

特点	独立	Kafka	Raft
节点数量	单个订购节点	一个组织的多个订购节点。	来自不同组织的多个订购节点。
容错	非容错	崩溃容错（CFT），它使用一个账本并遵循节点配置。使用 ZooKeeper 集合管理。	基于 Raft 协议的 CFT。
实施	开发和测试（非生产环境）	生产级别，但存在管理开销。	生产级别，比 Kafka 更容易实现。
分布式订单服务		Kafka 集群实际上由一个组织（可能是一个创始组织）运行。因此，所有的订购实际上都送到一个单一的组织。因此它是部分分散的。	允许分布式订购服务，因为各个组织可以贡献其节点来形成分布式订购服务。因此，它是完全分散的。

从物理存在的角度来看，节点可以位于以下位置之一：

• 由一个组织租用或拥有的云

• 数据中心或由一个组织拥有的本地环境

• 在本地机器上

从本质上讲，对等方的身份将其与组织关联起来，并确定其由该组织拥有。这些节点是区块链网络的基础和核心。它们具有不同的类型并执行各种功能，例如认可、排序、提交和托管链码，并确保账本的一致性。到目前为止，我们已经从以太坊和超级账本 Fabric 的角度讨论了基础设施。如果您想要查看特定供应商的基础设施提供情况，您可以访问本章的Oracle's Baas – OBP部分。

数据层

区块链是一个去中心化、大规模复制的数据库（分布式分类账），其中交易被排列在区块中，并放置在 P2P 网络中。所有账户的当前状态都存储在这样的数据库中。一个网络（公共或私有）由许多节点组成，若没有共同的共识，数据就不能被更改。区块链的数据结构可以表示为区块的链表，其中交易被排序。区块链的数据结构包括两个主要组成部分——指针和链表。指针是变量，它们指向另一个变量的位置，而链表则是由链接的区块组成的列表，每个区块都有数据和指向前一个区块的指针。一个Merkle 树是哈希的二叉树。每个区块都包含 Merkle 根哈希的信息，如上一个区块的哈希、时间戳、随机数、区块版本号以及当前难度目标。Merkle 树为区块链技术提供了安全性、完整性和不可辩驳性。Merkle 树，连同密码学和共识算法，是区块链技术的基础。例如，以太坊区块链使用 Patricia 树数据库来存储信息。Patricia 树（Trie）是一种 Merkle 树，它类似于键值存储。就像 Merkle 树一样，Patricia 树有一个根哈希。这个根哈希可以用来指代整棵树。因此，你不能在不修改根哈希的情况下修改树的内容。每个区块包含自上一个区块以来发生的交易列表，并且在应用这些交易后，Patricia 树的根哈希代表了新状态（状态树）。

创世区块（第一个区块）不包含指针，因为它是链中的第一个。下图显示了区块链中块的连接列表：

区块链结构

根据区块链的类型，数据被存储在区块中。例如，超级账本的区块将包括通道信息，而比特币区块链将包含有关发送者、接收者和金额的数据。我们已经多次使用了术语哈希。哈希是数据的唯一摘要。密码哈希算法（例如 SHA 256 算法）可以生成数据的定长哈希值。这些哈希有助于轻易识别区块，同时也有助于检测对区块所做的任何更改。每个区块都有前一个区块的哈希；因此，区块链本质上是一个哈希链。任何连接到区块链的新节点都将接收区块链网络的拷贝。只有在一致性达成后，才会将区块添加到本地区块链。

交易在区块链上进行数字签名，以确保存储在其中的数据的安全性和完整性。它们使用非对称加密的数字签名来保护有关区块、交易、交易方等信息。交易使用私钥进行签名，持有公钥的任何人都可以验证签名者。数字签名用于检查篡改。数字签名保证了完整性，因为加密的数据也被签名了。因此，任何篡改都会使签名无效。由于数据已经加密，因此无法检测到。即使检测到了，也无法篡改。数字签名还保护了发送者（所有者）的身份。私钥与所有者（用户）相关联；因此，签名在法律上与所有者相关联，无法否认。在本节中，我们详细讨论了交易。在下一节中，我们将详细介绍基于以太坊的区块链平台的交易流程。

网络层

网络层，也称为 P2P 层，负责节点间通信。它负责发现、交易和区块传播。这一层也可以称为传播层。这个 P2P 层确保节点可以发现彼此并可以相互通信、传播和同步，以维护区块链网络的有效当前状态。在本章的以下 交易流 小节中，体验 P2P 层的交易广播、交易提议、交易验证和交易提交。这一层还负责世界状态的传播。P2P 网络是一种计算机网络，其中计算机（节点）分布并共享网络的工作负载以达到最终目标。节点在区块链上执行交易。有两种节点——全节点和轻节点。全节点负责验证和验证交易、挖矿和强制共识规则的执行。它们负责维护网络的信任。轻节点只保留区块链的头（键）并可以发送交易。

交易流

此处描述的交易流程突出了 P2P 网络层中节点之间的互动。以下图表显示了以太坊区块链的交易流程：

区块链交易流程

下面的要点突出了以太坊区块链的交易流程，如上图所示：

• 交易初始化：轻节点或具有以太坊客户端的全节点数字签名并初始化交易

• 本地节点验证：一旦本地以太坊节点接收到交易，本地以太坊节点将执行以下检查：

  • 检查数字签名与发件人地址和交易内容的一致性

  • 检查发送方是否有足够的 gas 来支持正在处理的交易

  • 检查交易是否会导致智能合约功能失败

• 向区块链网络广播：交易被广播到区块链 P2P 网络，全节点将执行以下检查：

  • 重复上述验证检查

  • 全节点相互通信

  • 矿工节点将交易放入待处理区块，并启动共识（例如，PoW），以便尝试解决谜题

• 验证、挖矿和添加到区块链：以下步骤确保区块的验证和添加到区块链：

  • 一旦交易经过验证和挖矿，它将被添加到有效区块

  • 矿工将解决谜题并找到有效区块，该区块将被添加到区块链

• 有效区块添加到区块链：有效区块被追加到区块链并广播给节点：

  • 矿工节点将有效的区块追加到区块链。

  • 矿工将有效的区块广播到节点。

  • 在将区块追加到区块链后，矿工将向区块链对等节点广播此信息，每个节点都会重新验证区块，以确保当前（新）区块与前一个区块的一致性。一旦验证成功，节点将向其节点广播，依此类推。

• 交易已完成：发起节点将本地副本与区块链同步并执行交易：

  • 最后，区块到达发起交易的节点

  • 本地节点将与区块链同步本地副本，并执行区块中的交易。

  • 交易标记为已完成

共识层

共识协议是区块链平台存在的核心。俗话说，每个区块链都有一个共识算法。共识层是任何区块链（以太坊，超级账本或任何其他区块链）中最关键和重要的层。共识负责验证区块，对区块进行排序，并确保每个人都同意。以下是关于共识层的关键点：

• 共识协议（算法）在分布式 P2P 网络中的节点之间创建不可争议的一致协议。

• 共识保持所有节点同步。共识确保所有节点都同意真理。

• 共识确保权力保持分散和去中心化。没有单一实体可以控制整个区块链网络。

• 共识确保遵循单一链，并且它持有真理。

• 共识是节点遵循的规则，以确保交易在这些规则的边界内得到验证，并且区块遵循这些规则。

• 共识导致参与节点对真理的一致接受。

• 对于具有加密货币的区块链（例如以太坊），共识还奖励节点验证交易和维护区块链网络。

• 根据设计，共识协议无法被复制，因为复制或模仿它们的成本高且耗时。

• P2P 网络中的可靠性是通过共识协议实现的。

不同类型的区块链使用不同的共识方法。例如，遵循类似以太坊，比特币等无许可区块链网络的共识，被称为概率性共识。这种共识保证了分类账的一致性，尽管各参与者可能对区块有不同的观点。这意味着它们容易出现分类账分叉（也称为分歧分类账）。超级账本等许可区块链遵循确定性算法。这样的区块链网络具有特定的节点称为排序节点；由这些排序节点验证的区块被认为是最终和真实的。因此，不会出现分叉的可能性。

以下表格概述了本书中提到的一些共识算法的快速比较：

事实	PoW	PoS	PBFT
区块链类型	无许可	无许可和许可	许可
交易的终局性	概率性	概率性	确定性
需要代币	是	是	否
示例用法	比特币，以太坊	以太坊	超级账本

请访问区块链结构部分，详细分析各种共识算法。

应用层

应用层由智能合约，链码和 dApp 组成。应用层可以进一步分为两个子层 - 应用层和执行层。应用层包括最终用户用于与区块链网络交互的应用程序。它包括脚本，API，用户界面，框架。对于这些应用程序，区块链网络是后端系统，它们通常通过 API 与区块链网络连接。执行层是子层，由智能合约，基本规则和链码构成。这个子层包含实际执行的代码和已执行的规则。交易从应用层传播到执行层，但交易在语义层（智能合约和规则）进行验证和执行。应用程序将指令发送到执行层（链码；在超级账本的情况下），执行交易并确保区块链的确定性（例如超级账本之类的许可区块链）。

在以太坊运行引擎上执行的智能合约是用 Solidity 语言编写的。它需要编译器来在语法上证明代码的正确性。由于它是编译的，字节码更小，在以太坊虚拟机上运行速度更快。在以太坊虚拟机上执行的代码是完全隔离的，不会与网络或文件系统进行任何互动。

智能合约: 一段带有业务逻辑的代码，由唯一的地址标识，并驻留在 EVM 上。智能合约包含在针对这些函数执行事务时执行的函数。根据智能合约的逻辑，事务可能会导致合约状态的改变。开发人员可以使用 Solidity 或 Python 等任何语言编写智能合约，并可以使用特定的编译器将代码编译成字节码，然后将这些字节码部署到区块链上。一旦部署，智能合约就会被分配一个唯一的地址。区块链上的任何用户都可以对该智能合约执行事务。请参考以下以太坊区块链上事务步骤的事务流程。智能合约是用高级语言比如 Solidity 编写的，并部署到 EVM 上执行。然而，这些代码与外部世界相连；例如，区块链之间的逻辑执行等。这些称为 Oracles 和 dApps。

Oracles：智能合约基于值操作，并触发合同状态变化，但仅当满足定义的逻辑时。Oracle 是一个旨在安全地向智能合约提供这些值的代理。Oracles 类似于第三方服务的数据源，为智能合约提供值。

链码（Hyperledger Fabric）：智能合约是控制业务对象生命周期的事务逻辑，这些对象包含在世界状态中。然后将智能合约打包到 chaincode 中，然后将其部署到区块链业务网络中。在 Hyperledger 中，智能合约控制交易，而 chaincode 控制智能合约的打包和部署。一个链码可以包含许多智能合约。例如，在一个保险链码中，可以包含针对索赔、责任、处理等的智能合约。Chaincode 定义分类账的数据模式，启动它，对分类账执行更新（基于共识），并响应对分类账数据的查询。Chaincode 还产生事件，这允许其他应用程序订阅 chaincode 事件并执行后续的下游功能或流程。

在 Hyperledger Fabric 中，没有像 EVM（以太坊）那样的虚拟机。Chaincode 部署在网络节点上，智能合约运行在由组织拥有的对等节点上，主要使用标准语言如 Java、Node.js 和 Go 编写。Chaincode 在安全的 Docker 容器上运行，每个区块链实例都可用。这些容器独立于网络中的其他节点；然而，这些 chaincode 由对等节点编排并作为代理，允许通过 REST API 或 SDK 访问客户端应用程序。

Chaincodes 是为通道初始化的。管理员可以为给定通道的链码定义背书策略。这确保了链码中打包的所有智能合约都可用于该通道。由于这个原因，一个链码可能根据为该通道配置的背书策略，在不同的通道上遵循不同的背书策略。智能合约可以与同一通道或其他通道上的其他智能合约通信。

dApps：dApps 是运行在区块链等分布式技术之上的分布式应用程序，例如以太坊、比特币或超级账本 Fabric。它是一个利用智能合约或链码的去中心化应用程序。dApps 可以被视为与智能合约或链码交互的 Web 应用程序；然而，dApps 不受单个实体或组织控制。一旦部署，它们就属于区块链网络。dApps 是用户友好的应用程序，业务用户可以用来在区块链网络上进行交易。智能合约允许你连接到区块链，而 dApps 允许你连接到智能合约或链码。例如，如果你去 LinkedIn，网页会调用 API，从数据库中收集数据。然而，在 dApps 和智能合约的世界中，dApps 是基于 API 的 Web 应用程序，它们与智能合约连接，而智能合约又在分类帐上执行交易。一些 dApps 的示例是金融应用程序，例如发票保理、KYC 等。

区块链的结构

当用户在传统系统上执行交易时，涉及到一个可信的第三方，负责处理交易、记录交易、维护分类帐和余额，并收取交易费用。通过区块链等 DLT（例如以太坊），每个参与的全节点都有分类帐（区块链）的副本。信任在系统本身上，因为没有涉及任何一方。用户发起交易，交易被验证和分组（在一个区块中），并且根据共识，将区块添加到分类帐（区块链）中。

本节专注于区块头、交易、向区块添加交易，以及最终向区块链添加区块的结构。我们在本节中讨论了区块链，特别是以太坊。然而，在后续章节中，我们将详细探讨超级账本等分布式账本技术。在那里，我们将逐步介绍超级账本 Fabric 的结构、交易流程、参与者和特定算法。有关超级账本 Fabric 的详细信息，请访问 第三章《深入了解超级账本 Fabric》。

交易状态机

以太坊区块链是一个基于交易的状态机，从创世状态开始。然后，一笔交易会导致状态的改变，最近的状态被称为当前状态。因此，一笔交易是两个状态之间有效序列流的表示；区块链应该只包含由于有效交易而发生的有效状态交易。

交易被分组到块中。一个块与前一个块用一个加密哈希链接在一起，代表一系列被称为区块链的块的链。在这里，加密哈希被用作参考。块本身是日志，区块链是记录一个或多个交易的分类帐。奖励被提供给矿工，并且奖励发生在状态转换时。一个向矿工提供奖励的区块链需要有一个共识来向矿工传递价值。例如，以太坊将 Ether 视为以太坊区块链中的价值，并用于向矿工提供奖励。最小的价值单位 Wei 用于以太坊中的奖励。

挖矿是一个过程，各种节点解决一个谜题以验证一个交易，以便更多的交易可以添加为区块在区块链中。这个验证交易的过程被称为挖矿。许多矿工同时行动来验证交易，一旦完成，他们提交他们工作的证明，这是数学证明。矿工不仅需要解决这个谜题 - 他们需要在其他矿工之前解决它，才能将他们的区块添加到区块链中。这是矿工解决一个谜题并提交 PoW 的过程。获胜的矿工会获得某种形式的价值作为奖励。如果是以太坊，则向矿工提供一定数量的 Ether 作为奖励。

由于以太坊是去中心化的，每个节点都拥有股权并可以参与创建新的区块。也可能会有恶意参与者提出新的路径。因此，系统确保达成一致意见，从创世区块到当前区块的后续路径。以太坊使用GHOST（代表贪婪最重要观察子树）协议来检查区块链中多个分支的创建，并遵循最佳有效路径。

账户类型

帐户地址（160 位唯一标识符）与帐户状态之间的映射被称为世界状态，这个世界状态保存在 Merkle 树（Trie）中。 Trie 保存在状态数据库中。由于根节点在加密上依赖于所有内部节点的数据，根节点的哈希可以被用作区块链网络的全局安全身份。

小对象构成了以太坊的共享全局状态。这些对象通过消息传递框架进行交互。这些对象被称为账户。每个账户都有一个状态，并且每个账户都有一个 20 字节的地址，这些账户通过 160 位的标识符进行标识。以太坊有两种账户，外部拥有账户没有与之关联的代码，它们能够发起新的交易。然而，合约账户有与之关联的合约代码，以及一个唯一的地址，它们不能发起新的交易。合约账户只能执行合约之间的消息传递。请记住，外部账户通过使用其私钥对其进行签名，并将这些交易发送到另一个外部账户或合约账户来发起交易。如果交易发送到一个合约账户，这将导致执行合约账户的业务逻辑（智能合约的账户）。

这两种账户都有一个账户状态，由四个组件表示：nonce、余额、存储根和代码哈希。对于外部拥有账户，nonce 强调了从账户地址发起的交易，而对于合约账户，它表示了由该合约账户创建的合约。余额显示了以太的基本单位（在以太坊区块链中）。存储根保存了默克尔树根节点的哈希，而代码哈希包含了部署在 EVM 上的合约账户上的代码的哈希。

深入区块结构

一个区块由区块头（BH）、交易集（BT）和当前区块叔块的其他区块头（BU）组成，如下代码所示：

B = (BH, BT, BU)

叔块是那些矿工的区块被孤立并未能进入区块链的区块。然而，他们成功地挖矿了区块，但是他们的区块未能及时添加。以太坊也向这些矿工提供了很低的激励。

以太坊区块头包括以下组件：

• 父哈希：父区块头的哈希

• 叔块哈希：当前区块叔块列表部分的哈希

• 受益者：矿工的账户地址，有权获得激励

• 状态根：Trie 的根节点哈希

• 交易根：Trie 的根节点哈希，其中包含区块的交易列表部分

• 收据根：Trie 的根节点哈希，其中包含列在区块中的每笔交易的收据

• 日志布隆：例如记录器地址和日志主题等日志信息

• 难度：代表区块的难度水平的值

• 编号：展示祖先区块值的数字；例如，对于创世区块，这个数字是零

• Gas 限制：显示每个区块的燃气限制的值

• 已使用 Gas：显示区块中交易使用的 gas 值

• 时间戳：区块初始时的时间；基本上，它是系统时间

• Extra Data: 包含区块数据的数组；它只是 32 个字节，应该只包含相关数据。

• mixHash: 一个哈希值，当与 nonce 混合时，将证明对区块执行的计算足够。

• Nonce: 一个哈希值，当与 mixHash 混合时，将证明对区块执行的计算足够。

每个交易的收据包括交易所在的区块的累积气体价格、为交易创建的日志集、交易日志的布隆过滤器和交易的状态代码。

交易

交易由外部账户签名和创建。这些交易导致合约账户之间发送消息和创建合约账户。每个交易具有以下字段：

• Nonce: 列出发送者发起的交易数。

• Gas Price: 以 Wei 为单位支付的用于执行交易的计算成本的价值（价格）。

• Gas Limit: 给定交易的最大气体限制；给定交易的成本不应超过此限制。

• To: 消息或交易的接收者地址。

• Value: 要转移到收件人的已交易价值。

• V，r，s: 交易发送者的签名。

• Init: 通常与合约创建交易相关联，指定了用于账户初始化的 EVM 代码；它在账户创建时执行一次，然后被丢弃。

• Data: 消息调用的输入数据。

下图显示了交易、区块和区块包含到区块链中，这些在本节中详细讨论。在阅读有关交易组件、区块头组件、区块链和交易流程时，请参考此图。它还显示了在整个过程中的共识的包含：

交易

交易在以太坊虚拟机（EVM）中执行。当执行交易时，它经过初始验证：

1. 发起者签名的有效性

2. 交易的 nonce 的有效性（必须与发送者的当前 nonce 匹配）

3. 检查气体限制（它应大于交易使用的固有气体）

4. 交易的形式是否正确

5. 发送者账户应具有足够的资金用于预付款。

一旦交易成功验证，将执行以下步骤：

1. 交易的成本从发送者的账户余额中预先扣除。

2. 发送者账户的 nonce 值增加 1。

3. 执行交易，并在交易执行期间，执行合约（智能合约）中的交易逻辑。

4. 在交易执行时，收集各种子状态信息，例如日志系列和退款余额。此外，计算剩余气体（总气体限制减去固有气体使用）。

5. 一旦交易用于创建有效状态，未使用的燃气将退还给发送者，矿工将获得激励，并且用于交易的燃气将添加到燃气计数器中，该计数器跟踪属于区块的所有交易使用的总燃气。

6. 最后，状态被更改并为交易创建日志。

添加交易到一个区块

现在，我们知道交易在 EVM 中执行，它们必须经历各种验证和处理步骤。

在本节中，我们将逐步介绍将交易添加到区块的步骤，具体如下：

1. 验证 ommer：在区块链头中，每个 ommer 区块必须是有效的头部

2. 验证交易：用于区块的燃气应该等于或小于列在区块上的所有交易使用的燃气

3. 应用奖励，也称为激励：矿工会获得奖励

4. 验证状态和区块 nonce：对每个交易应用状态更改并定义新的区块

将区块追加到区块链

现在，我们了解了如何将交易添加到区块中。在本节中，我们将看看如何将区块添加到区块链中。我们已经知道，区块头包含 mixHash 和 nonce，它们证明了对区块执行的计算的充分性。计算的这种充分性被定义为矿工创建新区块所必须经历的总难度。 总难度或区块难度的算法称为 PoW 算法（在以太坊中也称为 Ethash）。只有包含给定难度的 PoW 的区块才有效（可能很快会被 PoS 替换）。

通过扫描截至该时间点的区块头，为每个区块计算一个种子。从种子计算出伪随机高速缓存，并从高速缓存生成数据集。全节点和矿工需要存储这个数据集。矿工将随机选择数据集的几个片段，并将它们哈希在一起形成 mixHash。每个矿工将继续重复生成 mixHash 的这个集合，直到 mixHash 匹配 nonce。当 mixHash 匹配 nonce 时，nonce 被视为有效，因此区块被视为有效，并且可以添加到区块链中。该区块中的交易也被视为已确认。

记住，网络上有许多矿工，它们在不同的时间听到交易。因此，每个矿工都在挖掘不同的交易（这也可能基于每笔交易关联的交易费用），因此生成自己的区块。由于每个矿工都在自己的区块中构建自己的一组交易，那么被挖掘和验证的区块如何达成共识呢？他们根据共识达成共同协议。

共识算法

很明显，矿工执行交易验证并构建自己的交易区块。一旦他们解决难题并创建一个新的有效区块，他们会将其广播到区块链网络。这就是区块链共识算法出现的地方，它将确保区块链网络就交易排序和需要将哪个有效区块添加到区块链达成共识。记住，关于将谁的区块视为下一个区块的决定也确定了对矿工的奖励。这由 PoW 或 PoS 等共识算法负责处理。

以太坊使用 PoW，很快将转向 PoS。使用 PoS 作为区块链网络的共识算法，任何首先解决问题并广播有效区块的矿工将被视为赢家。在 PoS 中，新区块的创建者是以确定性方式选择的，取决于其财富，也被定义为其股份。有趣的是，在 PoS 中没有区块奖励，因此矿工将获得交易费用。这就是为什么在 PoS 中矿工是锻造者而不是矿工的原因。以下表格列出了 PoW 和 PoS 之间的区别：

PoW	PoS
PoW 是区块链网络中的原始共识算法。	下一个区块链的共识算法，例如以太坊。
矿工互相竞争以验证并提出一个有效区块添加到区块链中，以便矿工获得奖励。	没有矿工，也没有挖矿奖励。锻造者（创建新区块的人）是确定性选择的，并且获得交易费用。
第一个挖到有效区块的矿工将获得奖励。	区块的创建者由其在货币中的份额或股份确定。
许多矿工解决难题是昂贵的，需要计算能力和能源。	PoS 方法更环保更便宜。
主要优点是抗 DoS 攻击防御和股份对挖矿可能性的低影响。挖矿可能性可能导致高股份持有者掌控区块链网络的情况。	使用 PoS Casper，将有一个验证者池和网络，将从该池中选择锻造者。锻造者需要提交存款以参与并列入验证者池中的验证者名单。如果他们违反或行为不端，将受到经济处罚，他们的存款将被收走，并且将被取消列名。
主要缺点是巨额支出、计算的无用性和 51% 攻击，其中 51% 攻击意味着用户或群体控制了网络中大多数的挖矿算力。	要进行 51% 攻击，验证者需要拥有价值（货币）总供应量的 51%。因此，要攻击以太坊，所需的美元金额在数十亿美元，而其发生远非现实。

下面详细概述了一些共识方法：

• PoW：这是最早的共识算法。它被用于比特币和其他加密货币。共识是一个处理交易区块并将其添加到区块链的算法，当节点之间达成一致意见时便将其完成。因此，对于遵循 PoW 共识的网络，该网络会依照 PoW 规则来建立各种交易区块，并将其添加到区块链中。生成 PoW 并允许节点将区块添加到区块链的过程被称为挖矿，参与挖矿的节点被称为矿工。在矿工将一个区块添加到区块链之前，PoW 要求矿工解决一个复杂的业务问题（也称之为谜题）。作为解决业务问题（谜题）的交换，矿工会获得奖励。在类似比特币或以太坊这样的货币型区块链中，他们会被授予加密货币。基本上，矿工与其他矿工竞争，以找到每个哈希函数的正确哈希。一旦一名矿工找到解决方案并找到正确的哈希，它会将其传播到 P2P 网络中的所有其他节点。其他节点在将区块（交易集）添加到区块链之前验证哈希。为了维持区块时间，网络会动态调整问题（谜题）的难度级别。如果多个矿工同时解决问题，那么最长的链被认为是获胜者，因为最长的链是最可信赖的链。

  这解决了双重支付问题，但从能源和费用的角度来看，它是慢且昂贵的，也不被认为是可扩展的。

• PoS：这是比特币提出的另一种共识算法，建议于 2011 年，并首次由 Peercoin（2012 年）实施。在 PoS 中，矿工挖掘的几率取决于矿工在系统中拥有的股权（代币）。例如，拥有 15%股权（代币）的矿工有 15%的几率挖掘下一个区块。基于 PoS 共识的区块链网络是昂贵的攻击对象，同时也是节能的。因此，在 PoS 中，创建区块并获得奖励的几率取决于网络中的股权。基本上，创建区块的几率与底层加密货币的股权成正比。

  但这是否意味着富者越富呢？为了防止这种情况，PoS 采用了随机化技术，即检查中心化，这可能会在一个富裕节点变得更富并最终接管整个网络时引起。攻击者在试图基于 PoS 攻击区块链网络时会失去其股权。PoS 存在无所作为问题，即区块生成者可以为多个区块链（也称为分叉）投票，因此，他们可以阻止系统达成共识。

• 时间过去证明（PoET）：由英特尔在 2016 年推出，PoET 共识算法适用于许可的区块链网络，如 Hyperledger sawtooth。PoET 算法基于等待时间，参与节点（称为验证者）等待一段随机选择的时间。验证者生成一个随机等待时间并在此期间进入休眠。第一个醒来的人（也被称为睡眠时间最短的人）将有机会向区块链提交新的区块并向 P2P 网络中的所有节点传播该信息。通过这种随机等待时间，每个节点都有公平且类似的概率向网络添加区块。PoET 算法需要处理两个任务——首先，它需要确保参与节点确实选择了随机的休眠时间（而不是最短的休眠时间），其次，节点已经达到了休眠时间，没有在休眠时间中醒来。PoET 具有成本效益，并为所有参与者提供平等的机会。但它不适用于无许可的公共区块链网络。

  PoET 导致了领导者的选择，领导权会随机分配给整个网络中的验证者。由于验证者参与的成本较低，它扩大了验证者的人口，因此增强了共识算法的健壮性。

• 拜占庭容错（BFT）：这不是证明算法家族的一部分。它的名字源于古典的拜占庭将军问题。一支军队与他们的拜占庭将军包围了一座城堡。将军们散布在城堡周围，要想成功进攻，他们必须一起攻击。如果所有将军不一起攻击，他们就会输掉战争。现在，他们需要相互通信达成共识，以便同时发动攻击。

  从技术角度来说，需要一个拥有多个对等节点的系统来达成共识，即使有少数攻击者和恶意节点试图影响这些节点。实用的拜占庭容错算法可以帮助解决 BFT。

• 拜占庭容错实用性（PBFT）：Hyperledger Fabric 采用这种共识机制。PBFT 提供了一种设计用于容忍恶意节点（拜占庭故障）的拜占庭状态机复制。所有节点都有顺序排序，其中一个节点被宣布为领导节点（主节点），其他节点被称为追随者节点（次要/备用节点）。任何节点都可以通过从追随者节点转变为领导者节点，大多数是通过循环算法，成为领导者。所有节点需要执行两项任务，首先，他们需要验证消息来自特定对等节点，其次，他们需要验证并确保消息在传播过程中没有被修改。无论网络状态如何，所有节点都将达成共识并使用多数规则。整个网络都基于一个假设，即网络节点不会超过三分之一是恶意的。节点越多，网络就越安全。它具有以下阶段：

1. 客户端向领导节点发送请求

2. 领导节点将此消息传播给所有追随者（次要）节点

3. 所有节点（领导者和追随者）都将执行客户端请求的任务，并向客户端发送响应

4. 当客户端收到n + 1个相同结果的答复时（其中n是最大数量的恶意节点），客户端将验证响应并确保请求（攻击或撤退）成功服务

这也基于节点是确定性的事实。当所有诚实的节点就订单达成一致意见并集体接受或拒绝订单时，最终结果就被达成。

区块链网络的类型

广义来说，有两种区块链网络——公共和私有。两者都是 P2P 网络，余额表分布在可以参与交易的人群之中。余额表副本在参与者之间复制，而那些可以执行只能追加在余额表上的交易的参与者会持有余额表的副本，并参与达成将一个区块添加到区块链的共识。除了公共或私有外，区块链也可以是无需许可的（比如比特币或以太坊）和需许可的（比如 Hyperledger 区块链框架）.

无需许可的区块链也被称为公共区块链，因为任何人都可以加入网络。无需许可的 P2P 系统不需要设定一定数量的同行者在线并且一般较慢。在无需许可的区块链上，各方在不验证交易方身份的情况下进行通信。任何人都可以加入无需许可的区块链，比如以太坊，并进行读写交易。由于演员未知，网络中可能存在恶意演员的可能性。

有权限网络是仅允许预授权用户或组织执行写入交易的区块链网络。由于节点有限，它们更快速、更经济，可以符合监管要求，并且易于维护。必须对参与方进行预验证，因此交易双方是已知的。有许可 P2P 网络必须保证正常运行，并且在通信链路上需要高水平的服务质量。像 Hyperledger Fabric 这样的有许可区块链确保只有交易各方参与交易，并且交易记录仅向这些参与者显示，而不是向整个网络显示。因此，数据隐私、不可变性和安全性是 Hyperledger 为企业提供的主要功能。

尽管有两种区块链网络——公共和私有——根据权限，它们可以被分类为公共和无许可、公共和有许可、私有和无许可以及私有和有许可，如下图所示：

区块链类型

基于权限的区块链网络可以分类如下：

• 公共和无许可区块链：这些是开放透明的，提供去中心化和匿名性。它们是无信任的，并提供不可变性。这意味着任何人都可以加入区块链网络。用户（在节点上）可以使用所需的软件启用其系统并加入区块链网络。公共区块链消除了中间人，从而降低了成本，缩短了协调所需的时间，并提供了网络的透明性。公共区块链是无信任的，信任在共识中。交易被复制到每个参与的节点，并且共识负责验证和同步要添加到区块链的交易。这使得不信任的各方可以放心地执行交易。节点越多，撤销交易就越不可能；因此，公共区块链是不可变的。尽管任何人都可以阅读交易，但用户的身份是受到保护的，因此提供了匿名性。

• 公共和有权限的区块链：这些区块链是可扩展的、成本效益高、透明的，并且提供了非居间和匿名性。公共和有权限的区块链允许任何人读取交易，但只有少数有权限的用户可以编写交易（例如，政府雇员的工资和房地产登记）。另外，它可以允许少数人读取交易并让所有人编写交易（例如，投票）。公共和有权限的区块链被指定用于这样的用例，即人们或当局（例如指定的雇员或机构）用公开可见的数据批准交易。如果公共和有权限的区块链属于允许任何人读取但只有少数有权限的参与者可以编写的类型，那么这样的系统就不需要基于昂贵的共识算法，比如 PoW。这样的区块链网络是可扩展的。不是每个人都会参与验证，只有一个验证者被选择。因此，与公共和无权限的网络相比，它不会慢且昂贵。虽然没有中间人，但只有少数机构能够读取或编写。

• 私人和无权限的区块链：只有个人或被选中的成员可以运行全节点进行交易、验证和读取交易。少数人可以执行编写交易和验证交易，而所有人都可以读取。它可以应用于包括审计在内的用例，并且大多数被企业采用，这些企业希望在企业内部探索区块链。所有的权限都是企业的核心；因此，它们不是去中心化的，它们只能被分布。在积极的一面，它允许企业合规并满足隐私需求来实施区块链。此外，它允许加密审计。然而，整个去中心化网络的理念都丢失了。

• 私人和有权限的区块链：公共区块链导致我们运行一个全节点的情景，这意味着节点为该网络所有应用程序执行计算。这会降低区块链网络的性能。这可能适用于一些用例；然而，对于企业要求来说，公共区块链不是答案。企业正在寻找一个区块链网络，其中一个节点只执行给定应用程序所需的计算。此外，他们需要一个区块链网络，其中参与方是可识别的（不一定是受信任的），并且可以授予权限。此外，即使所有参与者都在同一个区块链网络上，也可以保证一定组参与者之间的数据隐私。此外，共识由预定义的节点集控制，这导致了更快速且低成本的商业网络。

对企业需求的答案是私有和有权限的区块链网络。私有和有权限的区块链也可以称为联盟区块链。它们由一个联盟（成员的联盟）控制。节点是预定义的，访问权限被定义。此类区块链网络的示例包括 R3 和 Hyperledger Fabric。

私有和有权限的区块链/联盟提供以下内容：

• 比公共区块链更好的治理：公共区块链网络缺乏治理，无法确保区块链网络的有效演进（例如，更新、运营机制的更改和共识）。因此，纠正缺陷速度较慢，阻碍了创新。另一方面，由于志同道合的企业可以迅速决定创新并发展业务网络以满足企业的动态需求，所以联盟可以迅速行动。

• 成本效益：公共区块链的前期成本较低；然而，对于发起交易的节点来说，它变得昂贵。初始基础设施成本可能较低，但随着时间的推移，运营成本增加，这反映在交易成本的增加上。由于公共网络是无信任的，信任依赖于共识机制。昂贵的共识机制，如 PoW 和 PoS，不适用。在联盟中，涉及到志同道合的信任方。因此，不需要昂贵的共识机制。此外，联盟不包括交易费用。在许多方面，联盟不仅成本效益高，而且速度更快。

• 隐私与安全：联盟或私有和有权限的区块链网络具有极高的安全性。访问控制层对于联盟来说是一级公民，并确保一组定义明确的人员访问网络。访问权限定义为读取、写入和部署代码（智能合约/链代码）以及验证交易。公共区块链由矿工（也称为验证者）保护。他们解决复杂问题（挖矿）以验证交易，并作为回报获得激励和奖励。在私有和有权限的网络中，安全性由可识别的节点对区块的创建具有预测性的分布来保证，这些节点极不可能串通。恶意串通和 51%攻击不适用，因为这种恶意行为很容易被检测到，涉及的各方将根据联盟管理规则受到处罚。交易对所有人不可见。这为企业提供了与信任商业网络提供的隐私信任的能力进行交易。

以下表格突出显示了从权限角度来看不同类型的区块链之间的相似性和差异：

公共和无权限	公共和有权限	私有和无权限	私有和有权限
公开且透明的。	公开且受限的。	受限但透明读取。	受限（混合方法）。
写入和读取全部。	写入全部，读取受限。	写入受限，读取全部。	写入受限，读取受限。
每个人都可以加入、交易、读取和审计。	每个人都可以加入和交易，但只有获得许可的用户可以读取和审计。	每个人都可以加入，没有人可以交易，每个人都可以读取和审计。	没有人可以加入、交易、读取和审计。
任何人都可以下载协议并参与验证交易。	符合预定义标准的任何人都可以下载协议并参与验证交易。	网络中的任何人都可以参与和验证交易。但是，这仅限于企业内部。	只有联盟成员可以验证交易。

下表突出了不同类型的区块链在交易和匿名性方面的相似之处和差异之处：

公开且无许可	公开但有许可	私有且无许可	私有且有许可
交易是匿名且透明的。	交易是匿名的，但不透明。	交易不是匿名的，但是透明的。	交易既不是匿名的，也不透明。
写入交易可以由任何人撰写或发起；例如，我向比尔发送 10 比特币。每个人都会知道转移了 10 个比特币。	写入交易可以由任何人撰写或发起；例如，我正在投票。然而，我为谁投票可以由授权机构计数。另一个例子是，写入可以由少数人执行，但所有人都可以读取。	写入交易由少数人执行，但任何人都可以读取。例如，授权方写入有关库存来源的信息，随后的写入由另外一些中间方或设备执行；但是，任何人都可以读取。	写入交易可以由授权用户撰写或发起；例如，我向比尔发送 10 美元。授权机构将知道转移了 10 美元。
每个人都将参与交易验证，验证者不是被选中的。	没有人可以参与交易验证，验证者是被选中的。	没有人可以参与交易验证，验证者是被选中的。	没有人可以参与交易验证，验证者是被选中的。
真正的民主：完全的权益。	全部写入权益。	全部读取权益。	受限制的。
交易批准时间长。通常需要几分钟。	交易批准时间长。通常需要几分钟。	交易批准时间短。	交易批准时间短。

下表显示了不同类型区块链的共识和用例：

公开和无需许可	公开和需要许可	私密和无需许可	私密和需要许可
开放和去中心化。	开放和可控制。	受限制的。	封闭和受限制的。
任何人都可以运行全节点来交易、验证和读取交易。	不只是任何人都可以运行全节点来交易、验证和读取交易。所有人都可以执行写交易，而少数人可以验证和读取交易。	只有个人或选定的成员可以运行全节点来交易、验证和读取交易。少数人可以执行写交易和验证交易，而所有人都可以读取。	只有联盟成员可以运行全节点来交易、验证和读取交易。此外，只有经许可的用户可以读取。
例如，比特币、以太坊和莱特币。	例如，以太坊。	例如，超级账本 Fabric。	例如，超级账本 Fabric，R3 和 Corda。
共识 - PoW。	PoS，PoA。	PBFT。	PBFT 和 FBA。
使用案例—加密货币，视频游戏。	使用案例—投票，民意调查记录。	使用案例—供应链溯源，政府记录保存和评估记录。	使用案例—纳税申报，联合体，联盟。

公开和无需许可 区块链的优势如下：

• 创建和运行去中心化应用（dApps）的基础设施成本为零。

• 无需可信任方或中介；没有中介。

• 网络开放透明，提供匿名性。

• 网络提供了无需信任的和不可变的特性。

公开和需要许可 区块链的优势如下：

• 创建和运行 dApps 的基础设施成本为零。

• 无需可信任方或中介；没有中介。

• 可扩展、快速且成本较低。

私密和无需许可 区块链的优势如下：

• 交易成本降低。

• 无需协调。

• 简化文档处理。

• 数据冗余降低。

• 规模扩大。

• 更好地遵守法规。

• 自动合规功能。

• 实现了确定性。

私密和需要许可 区块链的优势如下：

• 比公共区块链拥有更好的治理。

• 交易成本降低。无需协调。

• 文档处理简化，数据冗余减少。

• 参与者已预先批准且身份已知，隐私和安全性更好。

• Consortia 专注于决策，并不使用单一方。

• 不存在单点故障。

• 它的规模更大，遵守法规合规性。

• 它实现了确定性。

公开和无需许可 区块链的劣势如下：

• 可扩展性：对于可以创建的交易数量有限制，通常在高峰期间可达到几分钟。因此，此类去中心化系统不具有可扩展性。

• 缓慢和成本更高：具体包括以下内容：

  • 每个人都会参与验证，并且没有选定验证器。当每个节点执行相同任务时，如执行代码（智能合约）或验证交易时，可以达成共识。这种复制过程是缓慢、耗时且成本高昂，例如存储、电力和处理能力等多个方面。

  • 随着交易数量增加，执行这些交易的成本也会增加，这导致矿工拥挤执行高价值交易，因此系统变得缓慢和昂贵。

• 身份是匿名的：匿名参与者可能是恶意的。

• 不可变性是一个挑战：虽然事务和区块的不可变性是公共区块链的主要特征，但代码（智能合约）的不可变性对区块链网络来说是一个挑战。区块链认为智能合约部署是一个事务，因为它们是事务，所以它们是不可变的。因此，任何错误或问题或代码循环都无法纠正。这意味着智能合约在部署之前需要经过精心构建和测试，并且应具有KILL（也称为关闭）调用的操作以停止进一步的损害。

• 终局性：没有终局性和 51% 攻击（理论）。

• 可能导致集中化：要实现公共区块链的代币化优势，节点要作为完整节点运行。完整节点意味着节点携带了完整的区块链副本。随着区块链网络规模的增长，对于较小的参与者和个体节点来说，作为完整节点运行变得成本高昂。只有较大的参与者才能作为完整节点运行，这种情况可能导致集中化，从而影响区块链网络。

公共和有许可 区块链的缺点如下：

• 身份是匿名的，参与者匿名，可能恶意行为

• 不可变性是一个挑战

• 没有终局性和 51% 攻击（理论）

• 这可能导致集中化

私有和无许可 区块链的缺点如下：

• 它仍然有中间人，因此不是去中心化的。

• 它是中心化的，因此不是去中心化的。但是，它可以是分布式的。

• 参与者未经事先批准，身份未知，尽管恶意用户不能执行写入交易，只能读取信息。

私有和有许可 区块链的缺点如下：

• 不完全分布式：它仍然有中间人，因此不是完全分布式的。

• 联合体形成是一个挑战：联合体的形成需要志同道合的企业共同合作解决共同业务问题。除了定义联合体的结构、运作和治理模型外，还有许多问题需要回答以正式建立一个联合体：

  • 如何确保联合体不会导致权力集中？

  • 谁控制了联合体？

  • 主要财团成员是否比后来加入的成员更有利？

  • 谁受益于已经存在的基础设施？这是否给新成员或后来加入者造成混乱和基础设施依赖或锁定？

  • 谁决定新成员的加入或任何成员的排除？

  • 谁决定财团非核心成员的加入/排除？

  • 运营决策将如何执行？

  • 财团将如何融资？

  • 争端如何实现？

• 争端解决和仲裁员：包括以下内容：

  • 联合企业和各方的财团具有自己的业务复杂性，这些复杂性可能导致争端。因此，一个财团必须有仲裁员来解决争端。这意味着财团需要一个仲裁功能，负责处理财团成员之间的参与合同（通过法律文件）。

  • 一个财团还可能需要智能合约（链代码）审计员来验证智能合约以及智能合约与外部应用程序和数据源的接口和集成。这样的独立审计员将为财团提供保证，并帮助凸显漏洞。

在本节中，我们比较了不同类型的区块链，并了解了它们的优缺点等。在下一节中，重点将放在区块链架构的分层结构上。

区块链平台

到目前为止，我们已经探讨了不同类型的区块链网络。在本节中，我们将快速看一下两个主要的区块链平台—以太坊和超级账本 Fabric。

以下是这两个平台的概述：

• 以太坊：这是一个开源的、公共的区块链网络。它是核心区块链概念的延伸，现在支持超越货币的应用。开发者可以构建去中心化应用程序（通过智能合约），甚至可以构建去中心化自治组织（DAOs）。它是一个通用平台，交易通过 PoW 共识验证。以太坊用作企业对消费者（B2C）用例和应用程序的想法。这是一个公共区块链，因此所有参与者都可以访问账本。它支持 Solidity，并具有内置货币（以太币）。

• 超级账本 Fabric：这是一个面向企业应用的平台。这个平台是开源和模块化的，并运行 BFT 共识算法。超级账本并不真正有一个共识机制。由于其可插拔的架构，共识可以根据用例插入其中。账本不是公共的，它更适用于企业对企业（B2B）的用例或应用程序。链代码（也称为智能合约）可以用标准语言编写，如 Java、Go 和 Node.js。它没有内置货币。

运营包括以下内容：

• 以太坊：这是一个公共区块链，参与者（节点）可以随时参与。

• 超级账本超级账本 Fabric：这是一个私有区块链，参与者（节点）被授予权利参与。

共识如下：

• 以太坊：每个参与节点扮演的角色是相似的。所有节点都需要就一个交易达成共识才能提交。即使参与交易的节点也需要参与共识。以太坊的共识基于 PoW 算法或 PoW/PoS 的混合形式（称为 Casper）。

• 超级账本超级账本 Fabric：每个参与节点扮演的角色可能不同。一些节点是验证节点，一些是背书节点，一些是排序节点等。因此，在建立共识的过程中，不同的节点将执行不同的任务。节点可以选择不进行共识（No-op）或者选择 PBFT 等协议进行协议。没有第三方强制选择共识机制。除了共识之外，超级账本超级账本 Fabric 在交易的生命周期内还提供身份验证。它还支持频道和私有数据收集，以便在各方之间进行更私密的交易。交易被排序然后添加到区块，然后分布到频道上。频道进一步控制交易对业务网络参与者的可见性。

选择：根据用例和应用程序的不同，您可以选择以太坊还是超级账本。以下是一些需要注意的点：

• 以太坊：以太坊是公开和无许可的，并提供透明性。其各种优势如前文所列。然而，以太坊的隐私性和可伸缩性较低。

• 超级账本超级账本 Fabric：解决了隐私和可伸缩性问题，并提供了访问控制、高交易速度和弹性。此外，它还是模块化和可插拔的，适用于各种 B2B 企业用例。

代码执行如下：

• 以太坊：代码，也被称为智能合约，是在以太坊虚拟机（EVM）上执行的。以太坊网络提供了执行智能合约和使其达成共识的服务。它们还提供了调用外部预言机的服务。智能合约的范围一直持续到业务网络的生命周期结束。因此，良好的开发实践是编写具有 KILL 方法的智能合约。

• 超级账本超级账本 Fabric：代码，也被称为链码，可以用标准编程语言编写，如 Java、Node.js 和 Go。链码在业务网络上执行，并由业务网络节点验证和背书。与以太坊不同的是，超级账本超级账本 Fabric 支持链码的版本控制和升级。以下是从链码角度来看超级账本超级账本 Fabric 的一些亮点 -

  • 可以将 chaincode 升级到新版本，只要保持相同的链码名称；否则，它将被视为不同的 chaincode。升级是区块链网络上的一项交易，会导致将新版本的 chaincode 绑定到通道上。在更新 chaincode 之前，在背书人上安装新版本的 chaincode。

  • 旧版本会发生什么？所有绑定到先前（旧）版本的 chaincode 的其他通道可以继续执行旧版本。您向通道提交 chaincode 升级 交易。因此，只有执行了升级交易的通道会受到影响。所有其他通道，未执行升级交易的通道将继续运行旧版本。

  • Chaincode 甚至可以被停止。然而，在 v1.4 版本中，启动和停止生命周期事务 未 实现。这些是未来的增强功能。在升级之前，停止事务将是停止 chaincode 事务的一种逻辑方式。

  • 可选地，您可以通过从背书人中删除 chaincode 容器来停止链码。实际上，您可以从运行背书者的每台主机（VM）中删除 chaincode 的容器。

Hyperledger Fabric 支持以太坊。从 Hyperledger Fabric 1.3 版本开始，用 Solidity 和 Vyper 编写的智能合约现在也可以在 Hyperledger Fabric 上执行，因为它支持 EVM。这是一个新的智能合约运行时，并支持 web3.js 以增强 dApps（去中心化应用程序）的开发。这进一步促进了权限区块链上 dApps 的开发。访问www.hyperledger.org/以获取有关此功能的更多详细信息。

区块链参与者

参与某项行动或区块链网络的实体被称为角色，这是区块链角色的缩写。在本节中，我们将介绍涉及区块链的各种角色。然而，在深入了解之前，让我们简要回顾一下私有区块链。前一部分介绍了各种类型的区块链网络。但是，在本节中，我们将主要定义私有区块链网络的角色。

以下表格列出了私有区块链网络的一些主要属性，对于理解区块链角色至关重要：

特征	私有和无许可的	私有和受许可的（联合体）
所有者	单一所有者	联合体或创始组织
一致性	由单一所有者管理	由联合体（一组指定参与者）管理
读取交易	任何节点	仅受许可节点
网络	分布式	去中心化

私有区块链旨在解决企业业务案例，并且这种演变正在获得动力。私有和有许可的是一个跨越各种组织的财团区块链，但它有一个受控的用户组。虽然参与者不是完全可信的，但可以确定（具有身份）。志同道合的企业或试图追求相似目标的企业可以组成一个财团来解决业务需求，提高信任、透明度和问责制，并增强现有的业务流程和工作流程。

私有和无许可的区块链并不真正分布式。它们是分散的，并且完全由单一所有者控制。由于它由单一机构拥有和运营，因此在这样的网络中建立的共识不能被信任，因为权力掌握在中央机构手中选择用户和影响共识。财团区块链（私有和有许可的区块链）由创始组织拥有，但由财团（来自不同组织的一组参与者）管理。可以信任共识，因为各个组织参与其中，并且它们对结果具有集体利益。

财团提供了许多好处，如下所示：

• 并非每个企业或组织都需要构建区块链解决方案。它们可以共享业务网络并共同构建，这样既经济实惠又节省时间。

• 较小的组织可以按使用量付费加入联盟，并完全将其业务扩展到区块链上。

• 财团的成员组织需要确定反映其共同问题的用例。然后，他们可以定义一个治理机构，并共同构建解决方案以满足业务需求。

• 参与者的身份是已知的，这增强了信任水平。

• 一致性不能受到影响，因为财团成员管理着区块链网络。

• 区块链网络的访问控制和区块链网络的功能可以确保数据的隐私和增强安全性。

• 参与许可的许可由区块链网络的监管机构发放。

• 特定交易的许可参与者仅限于对交易的权限。

• 财团具有弹性，并提供高安全性、性能、可扩展性和事务吞吐量。

到目前为止，我们已经讨论了各种私有区块链网络以及财团的好处。现在，让我们回到本节的主题——参与者。以下图显示了私有区块链网络的各种参与者：

区块链参与者

每个参与者在区块链网络的发展、运作和维护中都有一个明确定义的关键角色。然而，最具挑战性的工作在于架构师。

设计、构建、维护和使用区块链应用的架构涉及各种角色，如下所述：

• 流程所有者：流程所有者是业务流程的主题专家。他们对于识别业务挑战和帮助定义共同问题至关重要，这成为了形成财团的基础。流程所有者是定义使用案例的关键参与者。他们是关于现有流程的专家，从功能角度定义应该流程，并为区块链商业网络奠定基础。

• 区块链监管权威：他们是业务网络的主要当局（来自财团的创始组织成员）。他们向参与者发放许可证（证书），通常可以更广泛地访问网络。他们定义访问控制，发放证书等。他们对流程具有功能性了解，并确保正确的参与者可以访问区块链网络的相关部分。他们在定义财团中至关重要，因为私人和获准权限的区块链网络基于可识别参与者和定义的访问控制。与架构师一起，他们负责识别和定义以下内容：

  • 用于设立、发展和运营财团和区块链网络的资金

  • 为区块链网络选择基础设施

  • 区块链网络中参与者和最终用户的访问控制和参与

  • 定义和建立信任机构

  • 为将导致区块链网络发展的计划定义治理

  • 为财团和其成员确立投资回报率

  • 定义追踪、计划追踪等程序

• 区块链架构师：他们应该具备业务分析背景，并且对技术有所了解。区块链架构师应该了解他们的同行、共识、安全性、链码、集成、分类帐和应用。他们与权威一起定义并决定在财团及其解决方案中使用共识算法、标准、最佳实践等。区块链架构师负责以下活动：

  • 深入挖掘识别使用案例

  • 分析并为给定的使用案例选择特定的区块链解决方案

  • 定义适用于填补空白的区块链/DLT 解决方案

  • 提供估计、计划风险和定义里程碑

  • 构建和设计解决方案

  • 与基础设施、区块链操作者和开发团队一起正确实现区块链解决方案

  • 定义区块链网络的复用、可审计性和监控

  • 分析和量化区块链网络的性能、恢复力、安全性、可扩展性和事务吞吐量

  • 定义区块链网络的版本策略、治理模型和生产准备情况

• 区块链解决方案提供商：一个财团可以选择作为区块链业务网络基础设施的 BaaS（云）提供。他们也可以建立本地解决方案。区块链架构师和区块链管理机构可以决定基础设施。一旦决定，区块链解决方案提供商（无论是云端还是本地）可以负责设置、管理、维护和支持区块链网络的基础设施。区块链解决方案提供商是来自区块链云服务提供商的团队，负责创建和维护区块链网络，提供安全解决方案，并提供部署和维护智能合约或链代码的便利性。

• 区块链网络运营商：他们定义业务网络，配置业务网络，访问控制和监控业务网络。他们关注区块链业务网络的运萂部分。他们主要关注节点、共识和区块链网络的安全，而不关心智能合约和用户界面代码。

• 区块链开发者：区块链开发者关注代码（链代码、UI 和分析）。他们还负责将区块链网络的链代码与其他应用程序、数据源、事件和分类账集成。他们对区块链网络的运行、共识、安全、节点和订购节点是透明的。但是，他们应该了解区块链的基本原理。任何具有在任何高级编程语言中编码的能力并且对区块链/DLT 技术有基本了解的人都可以作为区块链开发者承担以下责任：

  • 开发智能合约或链代码

  • 部署和测试智能合约或链代码

  • 在代码中使用 API 与区块链网络交互

  • 开发、部署和维护 dApps 和用户界面作为智能合约的 Web 应用程序

• 区块链最终用户：拥有 dApps Web 应用程序访问权限的最终用户能够通过 UI 或 Web 应用程序消费区块链智能合约。这使最终用户能够针对智能合约执行交易，而底层的区块链技术对他们来说是透明的。

• 区块链审计员：由于联盟包括各个企业和离散方，因此具有自己的业务复杂性。这些复杂性可能导致争端。因此，联盟必须有仲裁员来解决争端。这意味着联盟需要一种仲裁功能，负责联盟成员之间的参与合同（通过法律文件）。暂时，CPA 管理机构将处理这些法律文件，直到它们变成智能合同（链码）并充当智能仲裁员为止。联盟可以聘请智能合同（链码）审计员来验证智能合同，并验证智能合同与外部应用程序和数据源的接口和集成。这样的独立审计员将为联盟提供保证，并帮助发现漏洞。此外，它允许诸如 SEC 之类的监管机构对数据进行只读获取，以便他们可以在可用信息宇宙中识别交易细节。

BaaS

区块链是一种颠覆性的技术，也是未来趋势。然而，由于技术复杂性、缺乏专业知识和技能以及操作开销，区块链的采用速度较慢。这些挑战逐渐被进入区块链解决方案的云服务提供商所解决，其提供了 BaaS 方案，明确了我们应该在哪里托管解决方案。

到目前为止，我们已经讨论了 DLT、区块链、中心化和去中心化系统以及分类账。我们还研究了区块链结构、区块等等。现在，我想通过为后续章节奠定下一步的基础来结束本章。这一节讨论了本书的重心（CG）。后续章节将围绕使用案例和使用 Oracle 的区块链云平台（BaaS）实施使用案例展开。在这个阶段，你可能会对我们如何实施此业务感到好奇。把这一节当作对区块链解决方案提供商以及其应该驻留何处的一瞥。在实施区块链之前有各种步骤。它们始于识别使用案例和选择解决方案提供商。你需要回答的一些问题如下：

• 为什么你需要区块链以及背后的原因是什么？

• 这是战略选择还是战术推动？

• 你在构建什么，以及你是如何构建它的？

• 谁参与其中，他们如何参与，谁会决定，等等？

• 解决方案将在何处存储-在本地还是云上？

• 谁将进行管理？

• 谁将负责韧性？

很多答案都隐藏在 BaaS 中。

BaaS 资格

BaaS 是一个托管消费者区块链应用和解决方案的区块链平台。区块链平台（BaaS）提供商收费处理区块链基础设施的设置、维护和支持。对于企业和企业家来说，这是一个提升，因为它减轻了客户的很多负担，并允许他们专注于识别用例和开发区块链应用和解决方案。诸如网络可用性、可扩展性、性能等问题留给服务提供商。区块链触及了广泛的受众，包括架构师、设计师、开发人员、热情的传道者、业务和流程所有者、IT 战略师和经济学家。此外，作为一种全栈云解决方案，BaaS 使企业家、热情的传道者、企业等能够及时高效地把握 Dlt 和区块链的潜力。BaaS 正在成为扩大 Dlt 和区块链采用的真正催化剂。

在选择 BaaS 提供商时，以下是一些要考虑的资格因素：

• 标准：这些包括以下内容：

  • 它是一个已建立的云服务提供商吗？

  • 是否基于行业标准？

  • 是否兼容和可互操作？它与其他账本也是可互操作的吗？

• 快速设置：是否允许快速设置区块链网络？

• 集成和其他服务提供：这些包括以下内容：

  • 是否支持 REST 代理，以便将 OBP 与 SaaS、PaaS 和其他本地应用集成？

  • 是否提供数据安全、集成服务和对象/文档存储等服务？

  • 是否提供容器和计算与存储服务等云服务？

• 安全和隐私：这些包括以下内容：

  • 是否提供集成的身份管理和安全性？

  • 是否关心隐私、数据分区和私有通道？

• 是否具有弹性：这些包括以下内容：

  • 是否提供高可用性？

  • 是否提供备份和灾难恢复？

  • 是否提供增强的性能（区块链网络和共识）？

• 智能合约/链代码—部署、版本控制、标准、审计和测试：这些包括以下内容：

  • 是否提供在标准语言（如 Java 和 Node.js）中部署链代码的功能？

  • 是否允许回滚到链代码的上一个版本？

  • 是否提供/支持测试链代码的工具？

  • 是否有可信的开发社区？

• 吃自己的药丸：是否提供市场上的应用程序，并在自己的 BaaS 上构建？

• 监控：是否提供交易监控和仪表盘？

以下图表突出了 BaaS 平台的关键资格要求：

BaaS 资格审查

BaaS 使用案例

为了简化，BaaS 解决了成本、效率和透明度方面的挑战。它使企业能够探索、实验、体验，然后参与区块链。它消除了实施的复杂性，使企业能够专注于核心业务。这类似于陈年威士忌。你可以信任它的制造商并支付费用来享用它。你不需要深入了解它是在哪里制造的，以什么条件制造的，如何对待的等等。区块链实现了产品溯源。

在 DLT 的用例周围涌现了大量的想法，这对 DLT、区块链和 BaaS 都是有利的，并且区块链和 BaaS 将推动 DLT 和区块链的采用浪潮，从而实现和满足企业、客户和企业家的这些想法。可以通过利用 BaaS 来解决各种用例：

• 实力（教育和专业）：实力台账可以作为证书、评估、技能等的真实来源。它提供实力所有权，对资产（证书、成绩单、技能、证据等）拥有完全权限，并提供全面跟踪和追踪个人的证书、技能和知识的解决方案。除了证书外，还有各种用例。例如，在招聘时，组织需要关于申请人资格的真实可信的信息。实力台账将提供持有申请人证书、技能、经验、专业知识和其他相关报告的台账，不可变地。此外，由于这些记录是不可变的，甚至申请人也无法伪造它以满足特定的工作要求。我们可以轻松计算雇佣伪造技能的申请人所涉及的风险。

• 供应链：一个供应台账可以作为资产管理、采购、产品生命周期管理、物流、溯源、欺诈检测等的真实来源。它可以超越溯源（产品追踪）到区块链上的整个 SCM 生命周期。

• 政府：政府机构持有公民数据和各种其他敏感信息。敏感性系数带来了安全和隐私风险。区块链的公共存储库，以及哈希、加密和其他成熟的技术，可以解决黑客攻击、数据修改、信息丢失等问题。信任台账可以处理公民权利、选票、捐款等。带有信任台账的投票平台可以确保无欺诈的投票和无欺诈的计票，并检查选票操纵。结果迅速，执行选举的整个过程可以做到具有成本效益、及时和值得信赖。唯一身份（UID）的身份台账可以数字化安全身份管理。

• 房地产：所有权账簿可以作为财产所有权的真相，简化财产上市，允许在几分钟内转让所有权，减少上市成本等。

• 医疗保健：健康账簿可以作为追踪患者和医生信息的真相。这将防止药物伪造，保障和控制诸如处方和病史等信息的安全和受控交换。目前的系统将医疗信息存储在信息孤岛中，分享和使用受到了严格限制。健康账簿将导致在不可变和安全的账簿上存储信息，离散的利益相关者根据其权限访问信息。区块链及其链代码可以自动进行审计和追踪个体的健康和历史，甚至允许患者将其医疗记录用于研究获得报酬，这对人类是巨大的收益。

• 保险：保险账簿可以作为从保单销售到结算的真实来源，其中包括保单的销售，保单的维护（续约、终止、调整等），索赔，评估和证据，以及结算。这将消除繁琐的流程，减少第三方参与，加快结算速度等。

• 知识产权：知识产权账簿可以成为专利和知识产权商标的真实来源；它减少了知识产权的滥用，确保知识产权所有者获得其知识产权的信用和经济利益等。

• 金融科技：财富账簿可以作为跨境支付和更快的 B2B 交易的基础。它消除了对账，增强了交易者之间的信任等。它还可以用于清算和结算，贸易融资，KYC 和 AML。

• 其他行业：这些也可以使用 BaaS，具体如下：

  • 旅行：可以用于乘客处理、旅行追踪和追踪，作为乘客身份的单一真相来源等。将关键文件存放在账簿上可以检查护照伪造、逃避检查、非法移民等。

  • 人道主义：可用于慈善、捐赠等。

  • 交通运输：使用案例包括追踪等。

  • 石油和天然气：可用于货运管理、付款、运输等。

• 分析：这里将分析推广为一个横向行业，因为我相信这句话：有数据的地方就有分析（Vivek Acharya）。参考前面关于医疗保健的例子——患者尝试将他们的医疗记录变现也对人类有很大的帮助。如果这种情况发生，就需要一个高效的分析平台来理解区块链数据。除此之外，账簿上的交易数据可以带来更大的见解。区块链和人工智能结合可以带来更好的预测、有效的预测，以及实时回答业务和最终用户的问题。

BaaS 的主要优势

区块链即服务（BaaS）是在诸如 Hyperledger Fabric 之类的平台之上拥有众多功能的平台。使用 BaaS 提供的服务，客户可以创建网络和通道，构建和部署链码和分布式应用程序（dApps）。云服务提供商负责处理基础设施的敏捷性、可伸缩性和运营效率等琐碎但必要的活动，而客户可以专注于构建应用程序和链码。BaaS 极大地推动了区块链的采用，在大多数主要云解决方案提供商中都提供了 BaaS 服务。

使用诸如 Oracle 的区块链云服务等云平台，您无需自行提供安全性、身份管理、容器管理、管理控制台管理、基础设施、高可用性和恢复等方面的服务。所有这些都由云服务提供商提供。以下是 BaaS 的一些关键优势：

• 快速的供应能力

• 配置简便

• 成员快速入职

• 内置身份管理

• 提升安全性和保密性

• 高效的开发和测试

• 与流程和应用程序的优化集成

• 更好的性能和可伸缩性

• 高可用性和运营弹性

• 出色的可伸缩性

• 将基础设施与客户开发智能合约和应用程序的主要任务解耦

• 允许客户探索其传统应用程序和业务流程的众多可能性。

Oracle 的 BaaS - OBP

BaaS 在其基础（也称为其核心）之上提供了许多功能。Hyperledger Fabric（基础）并未预装。因此，企业需要构建链码并从 Hyperledger Fabric 中受益；他们需要设置 Hyperledger Fabric 基础设施，处理其先决条件，并对其进行配置和维护。企业需要确保已安装的 Hyperledger Fabric 环境与安全利益相集成，并管理所有容器的生命周期。企业需要处理补丁和升级，并确保系统的高可用性、性能、业务网络管理等。Oracle 的区块链平台基于 Hyperledger Fabric。通过 OBP，企业设置、管理和维护区块链平台的责任将转移到 Oracle（BaaS 提供商），企业可以继续专注于构建世界级的区块链应用程序和解决方案。

Linux 基金会的 Hyperledger Fabric 是 OBP 的基础基础（核心）。由于 Hyperledger Fabric 是基础，任何供应商（包括 Oracle）在其上提供解决方案都必须自动遵循行业标准。区块链平台，例如 Oracle 的区块链平台，可以简化创建一个网络，不同组织的参与者可以参与并共同工作。互操作性挑战，如治理、命名约定标准和统一数据模型，需要满足共识。例如，一个由参与者相互同意的标准、参与规则、成本和利润共享、治理机制和集体风险缓解的财团，以及包括分析、审计和验证以确保顺畅的区块链网络操作。

OBP 提供一个控制台来管理网络、通道和用户。它提供了一个 REST 代理和各种其他基础设施服务来设置、构建和维护区块链网络。它是建立在 Hyperledger Fabric 之上的，为简化操作、增强安全性和提高可访问性增加了许多丰富的功能。Oracle OBP 是 Oracle 提供的一种 BaaS 服务，有潜力解决企业 DLT/区块链用例。Oracle 的提供包括基础设施服务和各种嵌入式资源，如计算、容器、存储、事件流和身份管理。Oracle 具有以下特点：

• 基于标准：Oracle BaaS 的核心是 Hyperledger Fabric；因此，它自动遵循行业标准。因此，构建在 OBP 上的应用程序是可互操作和兼容的。这个特性与前一节中列出的 BaaS 限定符标准相匹配。

• 预装的：Oracle 的区块链平台包括预装的身份解决方案（Oracle 的身份管理）、对象存储（内嵌式存档）和 RESTful API。Oracle 的提供包括一个操作控制台，用于配置和管理整个区块链业务网络。简化了将 B2B 合作伙伴引入区块链网络，并且合作伙伴可以通过内置的身份解决方案进行验证。此功能类似于 BaaS 限定符：快速设置、安全性、隐私、以及链码管理和监控。

• 可插拔的：它提供与Oracle 集成云服务（OICS）的集成服务，允许与 SaaS 和 PaaS 应用程序快速集成。这个特性符合 BaaS 限定符集成和其他服务，如下所述：

  • 企业可以利用 OICS 工具来处理云服务，以构建和扩展 BPM（工作流）应用程序。企业可以使用 SDK 或 RESTful API 扩展其 SaaS 应用程序。

  • 在 Oracle 开发平台上构建的应用程序（例如，VBCS）可以使用各种标准（Java、Node.js 和 Go）和 API 调用链码操作。

  • 企业可以在应用程序容器云服务、Java 云服务、移动云服务或应用程序构建器云服务上构建应用程序，并可以使用 SOA 云服务、流程云服务和 API 发起区块链交易。

• 企业级解决方案：这是一个托管服务，具有高可用性、增强的安全性和分类账的持续备份。该功能符合 BaaS 资格标准——弹性。

• 自动化：Oracle 的自主数据库是 OBP 的支柱。因此，它利用了 Oracle 的自主数据库的好处，如自助提供、自动升级、增强的安全性和监控。它可以在没有停机时间的情况下自动应用安全补丁，提高多层次的安全性，并以加密状态存储数据。它提供自我修复功能，确保了最高的可用性，并将计划和非计划停机时间减少到不到两分半钟。该功能符合BaaS 资格标准中的弹性和监控。

• 隐私：Hyperledger Fabric 提供通道和私密数据收集（详细信息请参阅第三章，深入研究 Hyperledger Fabric）。Oracle 的产品只允许批准的对等方加入通道。该功能符合BaaS 资格标准中的安全和隐私。

在分析区块链解决方案，确定使用案例并选择最相关的区块链平台时，战略性地看待核心系统、业务流程以及企业将从在生态系统中引入区块链中获得的好处是非常重要的。我们正处于云化（云）基础架构、应用程序和流程的时代。区块链云平台是您云策略的绝佳补充。云和区块链策略与对未来自治组织的愿景紧密相关。本书介绍了 Hyperledger Fabric 及其通过 Oracle 区块链云平台实现的细节和实践。我们将在后续章节详细介绍此内容。

预构建的区块链应用程序

上一节列出了 OBP 及其特性。它还试图将它们与 BaaS 资格标准相匹配。除了一个（吃自己的药丸）之外，几乎所有 OBP 的特性都符合 BaaS 资格标准。在本节中，我们将扩展 OBP 的特性并将它们与吃自己的药丸资格标准匹配。该资格标准实际上显示了供应商的 BaaS 产品的能力和成熟度。在这种情况下，Oracle 提供了许多构建在 OBP 上的应用程序。

Oracle 是创建基于 SaaS 的区块链应用的先驱，允许业务应用程序利用区块链技术进行可追溯性、增强安全性和简化共识。这些基于 SaaS 的区块链应用是使用 OBP 构建的，并在 Oracle 的云平台上运行。它们与其他 SaaS 应用程序（例如供应链管理（SCM）、企业资源规划（ERP）和其他基于云的应用程序）无缝集成。它们还与机器学习应用程序、物联网和人工智能应用程序集成。

这些应用程序解决了企业面临的常见挑战，如跟踪、追溯、可见性和根本原因分析。区块链是一种能记住的技术。它是一种消除产品跟踪、追溯和可见性障碍的技术。Oracle 区块链应用程序允许跟踪、追溯和分析产品通过其供应链周期的情况。这些应用程序还允许根本原因分析，并在诸如产品损坏、运输延误、交付延误和质量低下等挑战性情况下提供建议。

这些区块链应用程序提供以下优势：

• 它们提供预先构建的解决方案来解决常见的业务挑战。

• 这些应用程序是可配置的，允许更快地将应用程序与区块链技术相互连接，以满足业务需求。

• 它是将 B2B 合作伙伴添加到区块链业务网络的一站式商店。

• 它可以快速解决业务挑战，并为企业节省时间。

• 它为 SaaS 和本地应用程序带来业务敏捷性，使它们能够快速利用区块链技术的好处。

• 它无缝集成了物联网和基于人工智能的应用程序。

• 它提供了预先构建的分析仪表板，以增强企业、其合作伙伴和供应商之间的透明度、信任和可见性。

这些应用程序为业务问题提供解决方案，如召回、纠纷、欺诈、合规问题和仿冒品。它们提供跨供应链的分析和端到端的追溯性。它们提供了一个预先构建的仪表板，展示物联网、人工智能和区块链交易。这使企业能够实时洞察业务情况。以下是 Oracle 提供的应用程序（在撰写本书时）：

• Oracle 智能追踪和追溯：它提供端到端的资产跟踪和追溯。它为供应链过程中的每个步骤和事件提供数字化足迹。它实时提供这些事件和供应链过程中的步骤的洞察力，从制造到运输，再到销售和交付。

• Oracle 产品渊源和来源：它允许用户验证产品的来源。

• Oracle 智能冷链：它跟踪产品从制造到销售的状态，并提供其完整的审计追踪。它会发出针对异常情况的变更，并提供预防建议。

• Oracle 保修与使用跟踪：它跟踪高价值资产，并提供资产使用的完整审计跟踪。这些审计跟踪是可验证的日志，可用于产品保修和责任索赔。

企业可以改变其现有业务流程，并从这些适合企业使用的应用程序中获得即时好处。这些应用程序让企业可以开发一个允许与供应商和合作伙伴进行安全、透明和高效交易的区块链网络。此外，它解决了跟踪、追踪、可见性和根本原因分析等常见业务问题。这确实是应用程序的未来。这些应用程序与现有的本地和云应用程序无缝配合。企业可以使用现成的区块链应用程序，利用区块链网络模板建立他们的区块链业务网络，并使用预构建的集成扩展和整合应用程序。我们将在后续章节中更多地了解这一点。

摘要

在这一章中，我们深入研究了分类帐、区块链的定义、区块链结构和层次。我们还简单看了一下区块链结构、区块、交易以及如何将区块添加到区块链中。我们熟悉了区块链中的参与者、组件和算法。我们还尝试创造了分布式复式记账（也称为三重记账）这个术语。第二章，理解分布式分类账技术和区块链，将列举区块链和超级账本的用例，并帮助我们为其确定可能的方法。企业正在探索分布式账本技术和区块链的巨大机会，并承认这种分布式技术的战略性和长期利益；然而，企业采用这种技术之前需要解决各种与分布式账本技术和区块链相关的挑战。尽管存在挑战，但也有大量的机会。随着分布式账本技术和区块链的信任和利益增长，企业将探索并更多地参与采用分布式账本技术/区块链。让我们深入研究第二章，理解分布式分类账技术和区块链，并通过解决各种用例来探索类似区块链的分布式账本技术所提供的大量机会。

第二章：理解分布式账本技术和区块链

区块链是一系列按时间顺序排列的交易，这些交易经由共识达成一致，并被分组成块。这保证了账本（链）的信息是可靠且可信的，因为每个条目（块）都经过网络验证并得到网络的认可。对于记录账本来说，分布式账本技术（DLT）及其变种（区块链）是一场革命。凭借其不可变的可信账本、没有单一故障点、没有中心化第三方和分散的信任等特性，DLT 和区块链引发了一场热潮（由想象力催化），使我们能够设想各种 DLT 和区块链的用例。

区块链的一种应用引起了大家的关注，即比特币，它是一个全球分布的不可变记录账本。自从发现它（我不将其称为发明）以来，企业、组织、企业、创业者，最近是个人，都了解到了这项颠覆性技术的重要性。有一段时间，比特币的大规模旅程掩盖了其潜在技术。然而，当世界见证了加密货币的巨大波动时，所有人都对由潜在颠覆性技术创造的头条新闻感兴趣。今天，有许多共识协议、各种 DLT 和区块链，全球正在尝试确定 DLT 和区块链可以解决的不同用例。

自从发现以来，DLT（分布式账本技术）和区块链已经不断壮大。数十亿美元被投入到区块链项目中，这一趋势年复一年地增长。研究者们正在探索并验证各种用例，从防止人口贩卖到数字身份，从教育到医疗等等。

前一章重点介绍了账本、区块链、DLT 技术及其结构的概述。本章将深入探讨 DLT、其挑战与机遇，并将钻研各种用例。我们还将关注设计策略以及它如何让我们探索并参与业务场景。

DLT 的挑战与机遇

企业正在探索 DLT 和区块链的巨大机会，并认识到这种颠覆性技术的战略和长期利益。然而，DLT 和区块链存在各种挑战，需要在企业采用之前加以解决。本节总结了 DLT 面临的挑战以及其提供的机遇。

与 DLT 相关的挑战

本节介绍了 DLT 采用面临的主要挑战。

感知

底层技术的不成熟被认为存在的挑战：技术的不成熟促使人们相信使用它构建的解决方案可能面临挑战。最近，显然 DLT 在处理更多并发用户的交易方面存在困难。性能不佳的 DLT 和区块链应用程序，从交易和性能角度来看，降低了 DLT 和区块链的吸引力和竞争力。

与数据安全相关的认知挑战：企业需要安全的数据访问和分布式账本技术（DLT）和区块链的许可实施。DLT 和区块链作为分散化分布式账本的本质，被认为比集中式账本更安全，然而这需要数据支持事实。大多数分析集中在 DLT 和区块链的影响上；然而，注意力需要转向技术的使用以及围绕其的法规。对我来说，一个更完善的监管框架，技术将被更广泛地采纳，这对 DLT 和区块链同样适用。

共识

术语一致性和清晰度：DLT 与区块链、共识、法规和安全性的模糊性，以及它们之间的关系，增加了对这一颠覆性技术的困惑。业务利益相关者、决策者、消费者和企业仍在分析 DLT 和区块链的用例。清晰度越高，采用率越高，因为企业将更清楚地了解用例。

法规不确定性：考虑到企业已经投入相当多的资源来保持符合标准和法规，确立围绕 DLT 和区块链的法规是至关重要的。否则，缺乏法规，DLT 和区块链的采用将仍然存在疑问。

事实

围绕技术缺乏结构化治理：围绕 DLT 和区块链的治理是具有挑战性的，特别是当账本是分布式的时候。由于 DLT 和区块链是点对点的，用户使用他们的密钥进行交易；这就是为什么围绕密钥管理的治理，以及密钥丢失的清晰度和合法性，仍然需要发展。

不紧急：对于任何技术的采用，另一个重要因素是其需求。如果有需求和紧迫性，技术将会见证从监管者和企业方面的巨大转变。由于企业已经投资于当前与法规相符的 IT 基础设施，它们没有迫切需要转向 DLT 和区块链；这是一项巨大的架构变更和巨大的飞跃。它还涉及成本，企业需要评估投资回报率（ROI）。这些因素降低了 DLT 和区块链的紧急性和采用。

未知因素

早期采用者面临的未知风险：如今，每个企业都有明确定义的流程、IT 系统和分析解决方案，满足其当前需求并符合法规和标准。采用尚未标准化的分布式账本技术和区块链技术解决方案需要对现有解决方案进行大幅重新设计，风险未知。还有一点就是它们的清晰度问题。即使有一定程度的计算战略利益支持分布式账本技术和区块链技术，企业也因为软件和人才资源成本而不愿采用。只有当分布式账本技术和区块链技术对企业的利益超过成本和风险时，企业才会转向这些技术。

缺乏对智能合约替代真实合同的清晰认识：在涉及智能合约和链码时存在缺乏清晰认识的情况。人们假设它们会用简单的自动执行条件替代真实的法律合同。这种缺乏清晰认识将随着智能合约的演进而逐渐消失，而当企业分享智能合约作为复杂真实合同替代品的影响故事时，智能合约将会大放光彩。

缺乏数据突显企业可以获得的优势：由于分布式账本技术和区块链技术尚未被广泛采用，有关其性能的数据尚未被共享和广泛知晓。对于企业采用分布式账本技术和区块链技术的益处以及其对传统集中式账本方法与分散式账本方法的影响的精确评估尚不清楚。对于企业采用分布式账本技术和区块链技术的好处的清晰认识仍然需要巩固。

作为分布式账本技术和区块链技术的爱好者和传道者，我坚信围绕这种颠覆性技术的挑战不会阻碍其被接受和采用。正如我们之前讨论过的，信任越大，技术被采用的可能性就越大。企业越看到它们的价值和好处，法规和标准就越会制定出来。有趣的是，成熟度和采用之间存在着差异，完全取决于企业在使用分布式账本技术和区块链技术中发现的好处。好处越多（即使分布式账本技术和区块链技术的成熟度较低），它们被采用的可能性就越大。分布式账本技术和区块链技术可能需要比被采用更长的时间来成熟。

分布式账本技术和区块链技术提供的机会

这是一个去中介化的时代，在这个时代，Uber 没有车辆，Facebook 让数十亿人联系，Airbnb 没有房地产，Amazon 在几乎不保留大量库存的情况下销售几乎所有商品。包括保险、医疗保健、金融、交通运输、物流、零售和房地产在内的各种行业都涉及中介。所有涉及中介的案例都是区块链的潜在应用案例。这允许在消费者和生产者之间去除中介，同时注入信任、可靠性、强大性、不可变性和机密性。金融和非金融行业迅速意识到了 DLT 和区块链技术及其颠覆性应用的潜力。DLT 和区块链可以应用于多个行业，从金融领域到音乐，从知识产权到教育和医疗保健。DLT 和区块链持续应用于解决各种用例的规模是如此之大，以至于世界经济论坛预测，到 2027 年，全球 GDP 的 10%将存储在区块链上。

现在是时候了解 DLT 和区块链所提供的机遇了。

效率与新颖的收入流增益

效率提升：涉及第三方和以人为中心的企业流程可以自动化和重新设计以获得效率。例如，有了 DLT 和区块链，就不需要第三方进行数据同步和控制，这使得第三方不再需要，从而提高了交易的效率。之前我们讨论了需要交易双方进行协调的情况，其中包括资产和其价值。有了 DLT 和区块链，每个人都拥有相同的可信账本副本，因此不需要协调。这是一个重大的成本节约和广泛采用的推动因素。

新颖的收入流: 高效、改进和整合的流程将为企业带来新颖的收入流，因为他们将能够快速扩展，更快地与其他组织整合，通过引入敏捷性快速应对新挑战。

商业模式和增强的弹性

广泛的商业模式：缺乏第三方打开了各种应用和商业模式的可能性。企业可以采用对-等（P2P）交易，从而推动众包经济、共享经济的增长，或者将贫困人口引入主流体系。

增强的弹性：DLT 和区块链，凭借其分布式的特性，允许参与节点拥有账本的副本。即使网络失败，每个节点都持有账本和上面的交易副本。没有任何单一实体拥有它；每个人都拥有它，这增强了网络的弹性。

信任的继承

由于没有单点故障，也没有单个或第三方作为中央权威，每个人都拥有网络，但同时又不拥有。交易被添加为块，但只有在达成共识时才会添加；一旦追加到块中，并且块添加到链上，它就会变得无处不在且不可改变。在没有第三方参与并且不依赖于集中式数据库的情况下，分布式账本技术和区块链在身份验证、安全性以及对一个不可变、受信任、分布式平台上的信任验证方面提供了机会。

不可变性和更智能的世界

记录不可变性的优势：由于分布式账本技术和区块链中的交易是不可变的，提供了一致性和清晰的报告。由于它们是不可变的，出现错误的几率极低，而网络本身也会防范欺诈行为。

更智能的世界：在分布式账本技术和区块链中，企业之间的协议、企业与消费者之间的协议、个人与机器之间的协议、机器与机器之间的协议等都是使用智能合约来实现的。这些智能合约是自动执行的，因此协议的行政和执行成本大大降低。在合同或协议解释方面，风险显著降低，这进一步减少了传统合同和协议冲突时产生的任何法律成本。

大量的用例：分布式账本技术和区块链在政府到金融，再到供应链管理（SCM）以及人类赋权等众多用例中都找到了机会。本章将涵盖其中一些用例。

传统技术和解决方案的挑战

人类对于理解价值交换的演变有其根源于不确定性的水平。不确定性越大，对于价值交换的信任就越少。确定性越高，价值交换就越大。区块链试图解决各种传统挑战，比如信任、中介、保密性、健壮性、韧性和可用性。现在让我们一起来讨论一下：

• 无需信任：当你处理一个集中式系统时，你将信任放在系统和负责处理系统及其安全性的人和机器的基础上。你对你正在处理的组织有内在的信任。例如，我们使用电子邮件服务很多年了，有时也发送重要的个人邮件。我们对提供这些电子邮件服务的组织有内在的信任和确定性，相信我们的电子邮件既不会被篡改也不会丢失。然而，它能被修改吗？你试图从银行或政府等机构获取的数据能被篡改吗？答案是肯定的。另一方面，区块链提供了一个无需信任的生态系统，其中信息不能被篡改，并且可以确定地传递。人类寻找无需信任的生态系统的探索被区块链所解决。

• 无中间人：谈到信任时，我们可以感觉到它是企业与企业之间或企业与消费者之间交换价值的基础。此外，当信任跨越边界、界限和法规时，信任变得更加复杂、昂贵、低效、容易出错和缓慢。当一个中间人介入时，这个方程变得更加复杂。区块链被证明是一个强大的选择，作为去中介、无需信任的经济体，其中信任直接存在于企业之间、人与人之间或企业与人之间，而没有机构化的中介或第三方作为集中式信任机构。没有中间人，信任存在于系统/生态系统本身，合作、伙伴关系和机会是无限的。此外，区块链允许组织之间、消费者、机器或彼此进行交易，而无需任何中间人。对我来说，这是信任的演变，其中信任存在于一个生态系统和技术中，现在允许各方在没有受信任的中间人的情况下进行交易。在进行交易时，理解机密性至关重要。

• 保密性：这是个人、组织或各方保持其数据私密的权利，其行为既不被记录也不被监控。他们可以通过匿名化不让他人了解任何关于他们的信息，或者不在交易本身中发布任何敏感信息或文档，或者进行加密信息的交易来获得隐私。保密性是关于根据协议向个人、组织或各方安全且受控地交换敏感信息。它也可以称为权限访问，即授予权限以允许各方访问信息。在这个技术先进的时代，技术已经侵犯了隐私。个人、组织和机构的数据和信息在公共领域，这些领域在他们的防火墙之外托管或被他人用于监视和推导模式并衡量活动。

一个例子是面部识别，它不仅仅是一种技术；它是一种生物识别，有趣的是它不需要你的同意。指纹和视网膜扫描需要你的同意；然而，通过面部识别，某人可以在没有你的批准的情况下使用你的身份。信息可以被推导出来，并且你的模式可以被识别出来，这些都是使用面部技术的应用。用微笑支付或将个人与照片或动态定价联系起来是当今流行的面部识别应用的一些例子。通过复杂的模式匹配，技术甚至可以将数据与个人或组织相关联。

利用区块链技术，用户是所有者，并可以决定可以共享的信息的深度和级别以及与谁共享。例如，用户可以选择为政府的安全计划共享他们的面部识别生物特征身份，而不是为用户购买行为的模式识别商业用途共享。

区块链通过加密和访问控制提供了保密性和隐私。持久化数据被加密并存储，而在传输过程中的数据则通过启用双向传输层安全性（TLS）来保护。此外，它还加密了针对智能合约或链码执行的交易。基于角色的访问控制或基于属性的访问控制定义了谁可以根据用户的角色配置文件或用户的属性执行交易。除此之外，你应该只与那些应该访问它的参与方共享数据和信息（例如，Hyperledger Fabric 的私有通道）。这样一来，一个组织假设信息只与应该访问它的参与方共享。如果你使用的是不公开的、仅特定于仅由同意的参与方进行交易的通道的分布式账本，则可以将保密性提升到下一个级别。

• 健壮性： 在前一部分我们讨论了信任，我们了解到信任是关于正确执行交易的。然而，信任也延伸到管理异常情况。系统管理可信异常的能力被称为健壮性。在区块链中，健壮性至关重要，因为它是一个基于共识的生态系统，可以在没有中介的情况下建立信任。当两个矿工同时找到谜题解决方案时，区块链可以处理异常情况。区块链提出了遵循最长链的解决方案，在一个周期内巩固一个单一的链将有助于解决这种双重挖掘问题。同样，双花异常可以通过允许接受引用数字资产的第一笔交易，拒绝引用同一资产的第二笔交易来解决。这其中存在挑战，但系统的底层健壮性增强了信任。毕竟，在区块链中，信任建立在系统本身上，而是区块链系统的健壮性将吸引企业和个人参与其中。

• 弹性： 弹性意味着个体从冲击状态恢复的能力，例如，一份巨额手机账单，或者你刚把手机掉进水里。你从这些冲击中以多快、多积极地恢复定义了你的弹性。同样，在区块链中，弹性是区块链网络从故障中恢复的能力。有趣的是，由于区块链技术的本质，它天然具有弹性。通过分布式账本（DLT），交易被备份并在参与节点上可用。随着越来越多的节点加入区块链网络，其可用性增加。由于数据在每个节点都可用，弹性不是问题。它是分布式的，因此没有单一故障点，同时也是去中心化的，这意味着没有单一权威。这导致了在一个系统中拥有卓越的灾难恢复能力，其中节点可以随时连接或断开区块链网络。

• 可用性： 由于区块链网络不需要集中的权威来信任和维护它，而且它是弹性的，节点可以随时连接和断开，系统的可用性得到了提升。随着越来越多的节点连接到网络，网络变得更加可用。即使在区块链网络中只有一个节点存活时，它也被归类为可用。没有交易遗漏，没有人为错误，以及一个所有交易达成共识的系统，区块链提供了一个弹性、健壮的系统。交易是不可变的，可以验证，而这种验证的结果总是一致的。想象一下，一个相对于传统技术有如此多好处的系统；它吸引企业和企业相信区块链是一场革命。

设计战略

本节将详细介绍设计区块链解决方案以建立业务网络的细节。许多企业、企业家和组织正在分析区块链。他们正在采用区块链来获得业务对业务交易的交易速度，以不可变的方式存储信息并安全地共享信息。对于企业来说，区块链是一个平台，通过交易来交换价值，而无需中央仲裁者的干预。这一切都很好；然而，我们应该从哪里开始呢？本节涵盖了定义区块链设计策略。

我从我的书《我们与诺亚一起醒来》中使用了以下术语，并发现我在那本书中探讨的自我提升概念也可以应用于技术领域：

探索	参与	实验	体验	影响
用例识别	现状流程	获得技能	分析结果	共享
证明用例	未来流程	灵活	衡量结果	影响
区块链网络结构	全面解决方案设计	开发、测试	分析教训
业务网络目标	选择 MVP	提升、测试
治理	制定长期愿景	部署
争议和仲裁者	未来的增强
	定义范围
	定义故事板

前面的表格列出了区块链解决方案的设计策略。本节将更详细地讨论它。

在制定各种决策时，例如确定用例和通过区块链技术证明用例时，与企业关键利益相关者进行研讨会和会议总是有益的。这也有助于确定区块链的类型、定义治理和仲裁者等。在研讨会期间可以遵循以下原则：

• 将研讨会定义为业务研讨会，并列出可以在随后的技术研讨会中回答的技术问题。

• 强调确定用例并通过回答和评分各种因素来证明它们。

• 持续评估观众的反应、问题和倾向，这些倾向可能与或远离区块链相一致。将这些反馈用于后续改进问题结果的证明问题（如下一节所列）。

• 理解现状和未来流程，因为它们有助于将解决方案与业务需求对齐。

• 在研讨会中包括区块链专家、技术专家和安全专家，因为他们有助于回答具体的技术问题，并帮助他们朝着真正的业务需求发展。

• 确定关键利益相关者并建立利益相关者联盟（业务联盟和技术联盟），以便您可以更有效地进行后续的研讨会。

• 与技术联盟同时进行并行设计会议。早期的设计会议为方程式带来了两个非常重要的因素：简单和清晰。

• 在设计会议开始和结束时利用商业联盟的反馈，以及在商业会议结束时利用技术联盟的反馈。这将有助于建立平衡并使事情保持在正确的轨道上。

探索

本部分涵盖了将用例识别和证明为区块链技术候选的工作。我们还将涵盖识别区块链的类型、治理和仲裁员。

识别和证明用例

启动研讨会将确定用例，以高层次起草，并分析区块链作为解决手头用例的候选方案。这一探索至关重要，因为它确保所有参与方达成共识，采用区块链来解决用例。它有助于量化需要基于区块链的解决方案的需求。

以下是将用于量化作为用例解决方案的区块链需求的方程中的因素列表。根据所选用例，根据以下因素量化对区块链需求：

• 真相:

  • 是否需要各方之间的调和？

  • 在企业、其合作伙伴和供应商之间是否存在信息孤岛？

• 中介:

  • 是否存在现有中介？

  • 这些中介是否仅确保信任？

  • 是否需要包括具有相似共同问题的参与者？

• 多方:

  • 此用例是否导致与他人分享信息？

  • 多个参与方是否需要更新报告？

  • 是否需要来自其他来源或利益相关者的信息？

  • 是否是其他参与方遇到的类似问题？

• 交易:

  • 此用例是否需要企业报告交易的准确性？

  • 此用例是否需要交易透明？

  • 此用例是否需要交易隐私？

  • 是否需要高交易吞吐量？

• 权威:

  • 是否需要参与者之间的监管机构？

  • 是否预见到其他参与方的加入？

• 标准和其他解决方案:

  • 此用例是否容易突出资产（或者你是否可以轻松识别资产？）、交易和事件？

  • 此用例是否导致轻松数字化业务价值链中的资产？

  • 是否可以用传统技术更好地解决？

量化需要区块链的算法是什么？

针对上述因素，确保为每个问题起草两个单独的因素——一个是关键性因素问题，另一个是满意度因素问题。这些问题的答案应该由参与者给出。例如，关于真相的第一个因素可以用以下问题来扩展：

• 关键因素: 各方之间的调和是否至关重要？

• 满意度因素: 当前各方之间的调和是否令人满意？

形成所有其他因素，并将它们扩展到衡量关键性因素和满意度因素。这成为帮助证明对区块链需求的方程的关键。在这里，我正在尝试制定一个方程来证明对区块链的需求: 让我称之为 区块链证明方程 (BJE)。

让我们使用这个 BJE 来量化对区块链的需求。为使用情况因素分配一个数字，并检查是否对给定的使用情况合理使用区块链。换句话说，我们可以说使用情况因素在突显区块链的可用性方面至关重要。在本节中，我将尝试草拟一个方程来证明对区块链的需求。区块链的需求如下:

• 合理的: 当使用情况对企业至关重要，但目前尚未得到很好的服务时。这意味着他们对当前解决方案不满意。

• 未合理: 当使用情况对企业不是至关重要，但目前已经得到很好的服务。这意味着他们对当前解决方案感到满意。

最终，我们将在结果 合理时考虑对区块链的需求; 否则，就不需要区块链。

构建方程式

通过研讨会和会议来让参与者根据两个因素对上述问题进行评分:关键性因素 (CF) 和 满意度因素 (SF)。这些因素需要独立回答，评分从零到五，其中五是极其关键的，零是不关键的; 同样，五是极其满意的，零是不满意的。

让我制定方程:

BN = CF + (CF - SF)

在这里，BN 是区块链需求，CF 是关键性因素，SF 是满意度因素。

这意味着:* 区块链需求 * = 关键因素 * + ( 关键因素 * - * 满意度因素 * )。在这里，关键因素 是将因素评为极其关键的人的百分比，而满意度因素 是将因素评为极度满意的人的百分比。在这个方程中，关键性 是将结果评为非常或极端重要的人的百分比，而满意度 是将结果评为非常或极端满意的人的百分比。

如果 80% 的受访者将因素评为极其关键，而只有 20% 的受访者将其评为极度满意，那么对区块链的需求是合理的。然而，如果只有 20% 的受访者将因素评为极其关键，而 80% 的受访者将其评为极度满意，那么对区块链的需求是不合理的。

我将在我的下一本书《面向解决方案设计师的区块链》中更详细地开发这个方程和围绕它的图表。现在，我们将探讨这个方程，并看看它如何快速帮助根据手头的各种因素量化(证明)对给定使用情况的区块链需求。

区块链的类型

一旦您证明了对区块链的需求，就可以分析各种因素以确定哪种区块链解决方案适合使用情况。 以下图表在确定哪种类型的区块链满足您的需求方面是不言自明的。 但是，如果您想深入了解每种区块链的细节，可以参考第一章中的《区块链和 BaaS 的探索》区块链网络类型部分，我们在那里提供了有关不同区块链类型的详细信息。

以下图表说明了用于识别特定类型区块链需求的合格条件：

区块链的类型

上述图表清楚地突出了可以帮助您识别所需区块链网络类型的合格条件。

商业网络的结构

到目前为止，作为设计策略的一部分，我们已经确定了使用情况以及用于证明对区块链需求的合格/因素。 我们还分析了使用情况，并就所需的区块链网络类型达成了一致意见。 从本章开始，我们将专注于许可区块链，因为本书是关于 Hyperledger Fabric 和许可区块链的。 在本节中，我们将重点介绍基于区块链的业务网络的结构定义，特别是对于许可区块链网络。 许可区块链业务网络由一个以上的企业组成。 它们解决了一个共同的业务问题，并且希望利用区块链技术的优势。 因此，首先出现的问题是如何定义许可区块链网络的范围和结构。

定义结构是至关重要的，因为它会影响税收、法律、管辖权和治理。 许可区块链网络可以结构化如下：

• 基于联盟的商业网络：它们可以是联合企业，其中所有成员都像创始人一样：

  • 合资企业（JVs）：这通常是一个庞大的中央结构。 合资企业是刚性的，并且通常将创始人置于主导地位。 但是，如果忽略了合资企业的缺点，那么组建一个联盟是一个有效的选择。 每个成员（以财务参与形式）可以被添加为创始人，并且可以在创始人之间形成合资企业法人实体。 他们可以民主决定联盟的设置、维护和运营。

• 创始人驱动的商业网络：创始人驱动的商业网络由创始人建立和维护。 在这种情况下，创始人能够处理业务网络，并可以决定未来技术方向。 它们可以是以下类型之一：

  • 基于软件许可驱动：这是指一个技术公司或解决方案/平台提供商为创始人驱动的商业网络提供支持；例如，IBM 或 Oracle 从头开始构建一个解决方案，负责处理财团。这种配置可能导致技术集中化。

  • 开源驱动：这样的网络由一个开源巨头运行；Linux 基金会的 Hyperledger 项目和以太坊就是例子。开源仍然缺乏企业支持、项目治理、项目财务等能力。

• 基于社区的商业网络：这些是由社区驱动的区块链网络，其要么由标准驱动，要么是自主驱动的：

  • 许可去中心化自治组织（pDAO）：去中心化自治组织（DAOs）就像合作组织一样，不同的合作方提供资金。例如，用于无许可 DAOs 的资金由 ICO 和代币安排。也可能存在一种 pDAO，其中财团的治理在规则中设定，这些规则体现在链码本身中。在这样的配置中，是链码驱动财团的运作。财团的创始人可以处理财团的设置和维护。操作会由链码自动处理。

pDAOs

pDAOs 是去中心化的（无单一管理机构）和自治的（自给自足）。这意味着它们是由参与企业拥有的基于社区的区块链网络。然而，运营、资金和争议解决都将由治理自主许可组织的链码自动处理。这种企业财团的设置将消除维护和处理财团运作所需的庞大企业行动。所有决策都是民主的，由处理财团运作的代码驱动。这样的企业财团将定义链码的运作和维护。实质上，它们首先会定义商业网络的宪法。之后，链码将负责自动实现宪法。每个提案，比如添加和移除成员，都可以作为交易提交给链码，链码将负责在区块链上执行它。这样一个由社区驱动的区块链网络是为区块链而设的，由区块链驱动，为区块链所用。权力不掌握在少数人手中；它是分散的，有特定用例的底层许可网络和链码驱动的许可。

我相信 pDAO 可能是企业区块链采用的未来。这样的企业联合体可以由少数参与者开始。所有的法律确定性都可以通过法律结构解决，差异可以通过仲裁者解决。阅读我的下一本书，面向解决方案设计者的区块链，其中详细介绍了 pDAO。

商业网络目标和治理

上一节概述了如何定义和选择区块链的结构。设计策略的下一步应该专注于建立业务网络目标和治理。定义业务网络目标和治理也需要分析结果，在定义区块链网络时收集。本节与上一节并行进行，因为上一节中做出的决定在这里得到了确认。

在选择区块链结构之前，需要分析各种问题。以下是一些将对选择特定区块链结构产生强烈影响的问题：

• 如何确保联合体不会导致权力集中？

• 谁控制联合体？

• 主要的联合体成员是否比后加入者获益更多？

• 谁从已存在的基础设施中受益？这是否会给新加入者或后加入者带来困惑和基础设施依赖性或锁定？

• 谁决定新成员的加入或成员的排除？

• 谁决定联合体的非核心成员的纳入/排除？

• 运营决策将如何执行？

• 联合体将如何融资？

• 争议如何解决？

治理是一个更广泛的话题，超出了本书的范围。目前，你应该理解它是定义业务网络以及从维护和运营角度扩展业务网络的重要步骤。

争议解决和仲裁者

由于联合体包括各种企业和独立方，因此它具有自己的业务复杂性。这些复杂性可能导致争议。因此，联合体必须有仲裁者来解决争议。这意味着联合体需要一个仲裁功能，负责处理联合体成员之间的参与合同（通过法律文件）。这可能是负责处理法律文件的注册会计师机构，直到这些文件也变成智能合约（链码），其作为智能仲裁者。

一个联合体可以聘请智能合约（链码）审计员来验证智能合约，并验证智能合约与外部应用程序和数据源的接口和集成。这样的独立审计员将为联合体提供保证，并帮助发现漏洞。

参与、实验、体验和影响

一旦您探索了设计策略，就是与现有流程和将来流程进行交互并定义解决方案的时候了。 解决方案的整体设计将确保流程、用例和技术之间的同步性。 用大爆炸开始区块链解决方案可能是一个问题。 选择一个最小可行产品（MVP），并为未来的增强制定草图。 从一个简单、清晰但关键的用例开始。 这样做有两个好处：

• 简单和清晰的流程将帮助您以有效和及时的方式将要求转化为解决方案。

• 用例的关键性将巩固区块链处理关键用例的能力

从一个较小的区块链业务网络开始。 尽量不要包括仲裁员、监管机构和大型联盟。 设计一个可扩展和动态的解决方案，但构建一个满足用例范围的最小可行产品。 关于此的详细信息超出了本书的范围。 您应该遵循敏捷的方式开发基于区块链的解决方案。 您可以在我的下一本书《面向解决方案设计者的区块链》中了解更多有关区块链解决方案设计的信息。

区块链属性和用例

DLT，如区块链，被视为本世纪最具颠覆性的技术进步之一。 尽管它需要克服许多监管挑战才能成为大多数的一部分，但区块链的各种属性使其真正革命性。 正是区块链的属性为各行各业提供了无数的潜力。 在本节中，我们将讨论区块链的属性以及由这些属性催化的用例。

区块链属性

随着区块链的首个应用比特币的巨大成功，以及以太坊和超级账本的出现，企业、组织、行业领袖、企业家和个人已经意识到，区块链不是一个异想天开的梦想，而是一场真正的革命，将把今天的企业跨越各行各业推进到一个新的数字化企业时代。 DLT 和区块链的各种属性可以实现去中心化的自治市场，促进交易和协调摩擦的减少，允许安全地维护和共享去中心化的记录，并使消费者和企业能够追踪产品、供应和文件的来源。

以下是区块链最重要的属性列表：

• 共享和透明的访问：这导致数据的一致性，允许参与者在更新在参与者之间复制时访问一致的数据。 对于经许可的区块链，它仅允许授权参与者访问数据。 透明度增强了系统的审计性和信任，并降低了欺诈和审计的成本。

• 不可变性：区块链是只能追加的；记录不能被更改或删除。不可变性增强了系统中存在的信息的信心，并减少了欺诈的潜力。

• 验证和不可否认的交易：只有在达成共识后，交易才会被添加到区块链中。因此，交易的有效性不容否认。

• 隔离保密：通过许可区块链，交易可以被视图访问，只有授权参与者或方能进行更新。

• 去中心化：像区块链这样的分布式账本技术是没有中央机构控制的去中心化 P2P 网络。这导致了第三方和中介机构的消失，从而进一步降低了交易成本并实现了几乎实时的交易执行。

• 分布式账本：所有参与节点都维护账本的副本。因此，不需要对账，因为分布式账本技术保证了数据的一致性。由于数据一致性得到保证，因此不需要对账、争议解决和由于争议解决而导致的延迟。

• 智能合约/链代码：业务逻辑在智能合约或链代码中编写，由参与者验证并共享，从而在自动化业务流程中形成高度信任。在区块链中，任何资产都可以被数字化表示，交易将根据这些智能合约或链代码中定义的业务逻辑进行执行。

• 韧性：无信任的生态系统，健壮性、机密性和可用性是我们先前讨论过的其他几个特性。

这些特性不仅推动了各行业各种用例的演进，还解决了分布式账本技术和区块链的认知挑战。除此之外，区块链可以被定制为诸如 Hyperledger 之类的许可区块链。在许可区块链中，只有授权方才能访问区块链网络，并且只能查看和更新相关信息和任务。尽管许可区块链需要精心规划，但它消除了企业对区块链的担忧。诸如Oracle 区块链平台（OBP）之类的各种 BaaS 为许可区块链提供解决方案，并推动了许可区块链的采用。因此，BaaS 本质上正在催化区块链革命的采用。

特性和使用案例

区块链有几个颠覆性属性，对各行业具有吸引力，并为整个行业范围内的一系列用例提供了解决方案。尽管金融业继续是探索和实施 DLT 和区块链用例的主要新兴参与者，但区块链具有吸引力的几个优势/属性对一个行业也具有吸引力，例如不可变的永久记录、公共记录存储库、通用格式、可访问性和带有时间戳哈希的公证，并且它们还解决了各种政府和法律用例，如投票、提案、治理服务、交易组织、点对点债券、土地所有权、IP 注册、税收收据、公证服务和文件注册服务。

同样，分布式账本、去中心化网络、交易共识和无信任对手等属性吸引了数字货币、支付、汇款、金融行业、银行业、保险业、结算、交易、衍生品、内部审计和众筹等市场的用例。区块链和 DLT 的属性，如大规模协调、交易安全性和通信（也称为消息传递），对物联网（IoT）领域非常有吸引力，并推动了诸如智能家庭网络、连接汽车、智能城市、个性化机器人、数字助理、无人机和传感器网络等大量用例的链条。医疗保健用例，如数字健康钱包、智能健康令牌、健康数据分析、健康数据库、通用电子病历和个人发展合同，可利用 DLT 和区块链的属性，如大规模多流集成、隐私和安全、实时可访问性和通用格式。

上述属性还涉及艺术、科学和人工智能用例，如点对点资源网络、鸦片分析、社区超级计算机、电影、艺术追踪和跟踪、区块链倡导者、数字思维文件和区块链学习者。以下图表列出了一些用例，仅是对 DLT 和区块链为企业、组织和个人带来的可能性和机遇的一个初步了解：

属性和用例

上述图表显示了帮助实现各种行业用例的属性，如政府、法律、市场、物联网和医疗保健。属性列出了属性，而用例列突出显示了对于特定行业最具吸引力的用例。

用例类型

广义上讲，区块链是一个理想的用例，用于由自身附加在协商的非可交换交易上的分布式账本上的分布式共识。在本节中，我将把区块链用例分类为几个类别；然而，我相信存在数百万个用例，这是非可交换状态转换函数的结果。列出的用例分类是详尽的。

让我们从简单地将区块链的定义放入一个等式开始：

区块链 = 谁拥有 - 什么，何时，以及多少

何时 是时间线，而 多少 是数量。然而，什么 是这里讨论的主题。我对区块链进行分类的努力集中在 什么 和 谁 上。

什么： 什么 代表资产；基本上是宝贵的稀缺资产。身份、货币、土地所有权、合同、投票、来源和付款等资产是宝贵且稀缺的。让我们分析区块链的各种应用，并检查它们实际上管理的是什么。比特币管理账户，以太坊管理合同状态，Everledger 管理与钻石相关的事件，而 Ripple 管理信任线，等等。同样，对于 Hyperledger Fabric，资产可以是有形资产，如房地产和硬件，而无形资产可以是合同和知识产权。因此，区块链是那些要求通过记录在不可变账本上来建立分布式共识以交易这些资产的情况的潜在解决方案。

谁： 在任何给定时间点，区块链都是一种货币、网络、协议或平台。这是一个推动世界走向 DAO 或 分布式自治社区（DAC）的概念。我将在整个过程中交替使用这些术语。

组织或企业是一组共同努力实现一定目标并遵循规则的人员。这些组织拥有资产和负债，这意味着有一组人员和法律合同确立了持有资产和拥有负债的真相。一个组织的行为是因为一组关键人员之间存在相互共识。同样，雇佣某人意味着雇员同意提供某些服务，而雇主同意提供货币和其他福利。在所有这些情况下，都存在合同（一组规则）。

问题是：我们真的需要管理层来执行这些规则吗，还是我们需要在某些业务功能上的某些工作来执行这些合同？工业化通过在底层引入机器来回答了这个问题；像区块链这样的 DLT 是否也能在顶层做到这一点？组织建立和运作在合同和规则上，同时遵循法规，这又是一套规则。组织执行这些合同和规则以产生收入，提供服务，并为他们为组织提供服务而支付的员工支付工资，以便组织可以向客户提供服务并向政府支付税款。这些不能通过软件来实现吗，特别是通过区块链和 Hyperledger 这样的 DLT 来实现吗？

对我来说，答案是是，而且人的参与很少。可以有 DAO（也称为 DAC），其中资产所有者是利益相关者，智能合约和链码是管理组织的日常、战略和战术运营的规则和合同。参与节点本身就是员工，他们负责最小限度地验证、核实和达成共识，并获得最少的奖励。是的，现在完全勾画出 DAO 即将到来的未来还为时过早；可能会有一个由超级智能合约管理政策和关系的分布式一世界政府。

现在回到现在，并回顾前面的等式，让我们集中精力放在谁上。在采用区块链时，您应该寻找的关键要素如下：资产是什么，业务在向区块链迈进时将同意什么共识机制？您是否计划建立一个 DAO，还是您的业务计划建立一个各方将进行交互并建立一个财团的业务网络？在这里，我暗示了区块链的许可和非许可世界。无论哪种情况，谁都很重要，需要确定。由于 DAO 和 DAC 的世界正在展开，我正在考虑一个由智能合约和链码推动的市场作为区块链用例的一个类别。分布式账本世界变得越来越成熟，世界将更接近 DAO 和 DAC 的现实。现在，让我们再次回到等式，并看看除了什么和谁之外的另外两部分。这两个部分是什么时候和多少。实际上，多少是一个泛指，表示资产的数量和所有其他参数。什么时候有助于分析时间表、事件日期和交易。

现在，问题是，我们如何获取关于谁、何时、什么和多少的信息？这些信息是区块链生态系统的一部分，并带来了第三个最重要的用例类别，即分析。进入设计和开发，并始终提出解决方案的可见性方面。根据该等式及其周围的定义，区块链用例有三个主要类别：

• 数字资产

• 数字分析

• 数字平台

在本节中，我们将深入研究这些类别，并列出这些区块链用例的子类别。

数字资产

当我们使用术语“数字资产”时，我们统计了一大堆资产，主要分为以下几个类别：

• 有形资产和

• 无形资产。

下面是有形资产的子类别：

• 金融资产：货币、股票（上市和非上市）、债券、衍生品、大宗商品、金融、小额信贷、慈善事业和众筹。

• 记录：记录可以是公开的、半公开的，也可以是其他类型的：

• 公共记录：

  • 财务记录，如支出记录、交易记录、抵押记录和服务记录

  • 公共记录，如企业所有权记录、监管记录、企业设立/解散记录、卫生/安全检查记录、移民记录和政府法律

  • 标题，如地契

  • 注册，如车辆注册和法证证据

  • 许可证和许可证，如营业执照、建筑许可证和枪支许可证

  • 证书，如出生证、死亡证和结婚证

  • 数字身份，如护照、社保号码、唯一标识、选民身份证、投票、产品的数字代币等

• 半公开记录：

  • 证书，即学位、成绩、学习评估报告等

  • 记录，如员工记录、行为记录、医疗记录、会计记录、业务交易记录、仲裁、供应记录、递送记录和公民记录

• 私人记录：

  • 合同和担保

  • 个人，如遗嘱、信托、签名和 GPS 数据

  • 密钥，如车钥匙、酒店钥匙、公寓和家庭钥匙、储物柜钥匙、租车钥匙和包裹递送钥匙

下面是无形资产的子类别：

• 无形资产，如优惠券、门票、专利、预订、商标、版权、许可证（如软件许可证、视频游戏许可证和电影许可证）、域名、艺术证明（如作者、照片和视频或音频所有权记录）

• 杂项，如温度记录和体育记录

在这里，我们尝试列举一些这些资产。然而，在区块链上管理和记录这些资产的用例有很多。此外，还有一种特殊的用例类别，处理某些资产的来源，并且大多数情况下实施在供应链管理案例中，例如从供应商到货架的追踪，追踪药品，以及药丸的保管。以下是这些用例的可能子类别：

• 数字身份

• 证据来源

• 记录

让我们再多谈谈这些子类别。

数字身份：身份盗窃和身份欺诈是数字世界常见的头条新闻。每年全球都会有数十亿的记录被窃取、丢失和泄露，三分之二的数据泄露是由于身份盗窃和身份欺诈。区块链 DNA 包括不可变性和本地身份验证，这抑制了身份盗窃和身份欺诈。例如，如果身份验证系统仅基于生物特征，那么身份验证问题就被省略了。因此，银行、政府和组织可以使用极为准确的结果。即使在生物特征身份验证变成现实之前（不仅仅是在特定情况下全世界都能使用），私钥所有权也是一种高度安全且验证身份的成熟方式，其中密钥是数字资产。因此，用户身份可以在不暴露宝贵信息（如个人数据）的风险下进行管理和验证。通过数字代币对人类身份、物品身份和独特性进行验证和管理。数字代币是将物理物品与物品的数字身份映射的资产。然后，这个数字代币可以用于供应链管理，以证明来源，例如为知识产权赋予权利。

记录：区块链不是一个去中心化的数据库；它是一个记录系统。每天、每时每刻，企业都在与这些资产进行交易，资产在供应商、客户、合作伙伴和个人之间进行交换。区块链是一个记录这些交易和这些资产的数字身份的系统。这是不可改变的，增强了系统上存在的信息的保密性，并减少了欺诈机会。 此外，一致达成共识后，交易将添加到区块链中的块中。因此，无法否认交易的有效性。

产品溯源：凭借独特的数字身份（数字代币），任何物理物品都能证明其真实性和起源。由于总账中的记录是不可变的，物品可以从其起源追踪到终点。追溯性检查假冒产品，并允许消费者在拿取物品前获得充分信息，因为现在责任转移到了消费者，因为消费者对产品的起源、历程、运输中的温度、农场、地区等有充分了解。消费者可以作出明智的决定。有了产品溯源，每个产品都将说出真相。公司了解他们获供的材料，可以检查是否使用了劣质物品来制造产品，并了解可能出现的问题。

此外，区块链将消除组织因检查物品和产品而产生的成本。这就是为什么产品上市时间缩短而信任倍增的原因。对于追溯性，区块链引入了产品的透明性、可持续性和信任。最终消费者在拿起产品之前就对产品、成分和其历程有充分了解。区块链允许对产品进行智能追踪和追溯，并管理产品的数字身份（例如，序列号），记录其起源，标记构成部分的认证，并跟踪产品在转变、包装、运输、存储和上架过程中的整个旅程，同时管理监管合规性，召回和检查产品的真实性。

这些子类别是相互关联的。例如，对于追溯性，产品的数字身份是必不可少的。该产品的交易，比如转化、包装、运输、存储和上架都被记录在总账上，以便分析产品的数字足迹。这些数字足迹帮助消费者跟踪和追踪产品。但在更广泛的层面上，我们将它们视为追踪和追溯分析用例的推动因素，尽管它们主要与资产的数字记录有关。

数字分析

区块链总账是一个不可改变的记录系统。随着世界开始采用越来越多的区块链用例，想象一下在无需权限的区块链中包含的巨大数据量。即使是有权限的区块链也会有财团或私人数据，这些数据将继续大规模增长。区块链上的分析和预测分析将揭示许多故事、事实和见解。这样的生态系统将提供实时、可信且未经篡改的信息，这将不仅赋予企业而且赋予小型组织和个人分析信息的能力，在有权限的区块链中，相关（经授权的）信息。

区块链在金融技术中有许多用例，比如贸易融资，智能合约和去中心化应用程序（dApps）可以被创建来增强支付速度，并减少跨境和各方执行交易所需的时间。区块链智能合约、链代码或 dApp 可以简化结算和清算功能。这些 dApp 将导致巨大的交易和贸易数据，合同和交易数据根据这些合同执行。这些数据对战略和战术目的非常有用，数字区块链分析将有助于分析区块链数据。这导致了诸如反洗钱（AML）和欺诈分析、风险分析、交易执行、运营分析、合规报告和监管报告等区块链分析用例。

数字平台

一组组织可以建立一个平台，让他们的客户以统一的系统与他们互动。或者，几个个人可以从家里或智能设备上投票进行变革，结果将在当天可用。所有这些都是可能的，因为建立在区块链平台上的现代转型应用程序的数组。这样的应用程序被称为 dApp。

dApp 提供了一个去中心化的平台来构建去中心化应用程序。这些 dApp 继承了区块链的许多好处，如点对点交互、无信任系统和可靠性的共识。由于 dApp 继承了区块链的好处，构建在一个区块链平台上，数据不是集中记录的，而是分布式的。这排除了单点故障的可能性，提高了交易速度，因为不需要调和，降低了成本，因为没有第三方参与，减少了欺诈及其相关成本，同时增强了透明度。应用程序上市所需的成本和时间大大减少，而且区块链很容易与旧系统集成，因此给企业提供了区块链与传统系统共存的机会。

在 dApp 之外，还有 DAO 和 DAC 的世界。智能合约/链代码可以被设计成可以执行大部分业务功能。区块链可以通过执行作为智能合约或链代码的一部分编写的法律合同和规则来运行业务，并参考记录、数据和文档，这些记录、数据和文档都记录在区块链账本上。

区块链应用市场是一个重要领域，许多应用程序可用于解决简单到复杂的问题，这些应用程序建立在诸如以太坊用于无需许可的应用程序、超级账本面向许可用例的区块链平台，以及超级账本和物联网协会（IOTA）用于基于物联网的用例等区块链平台之上。例如，股票交易遵循 T+3，即交易在被接受后三天结算。使用区块链，交易可以立即结算。政府法规可以纳入到 dApps 和 DAO 中，因为合规性是可以编码进智能合约或链码的政府规定。这将使法规融入到 dApps 和 DAOs/DACs 中。有关 DAOs/DACs 的详细信息，请参阅前一节。

区块链与物联网的结合提供了一个生态系统，其中机器之间的互动被记录、处理和共享。区块链将物联网数据的不可变记录添加到区块链分类帐中，从而为物联网系统带来了无需信任和透明性。通过设备的数字身份，区块链允许对设备进行身份验证、验证身份，并为许可和无许可用例开启了多种用例。IOTA 是物联网的数据层，它依赖于一个称为有向无环图（DAG）的 DLT，在这里重点是执行和记录机器之间的交易。

以下图表显示基于三个主要用例类别的不同用例：

分类的用例

接下来的部分将深入探讨一些用例。

探索用例

在设计策略部分，我们试图为基于区块链的商业解决方案定义一个设计策略，其中包括五个步骤：探索、参与、实验、体验和影响。在本节中，我们将专注于第一步。在这一步中，我们将探讨几个区块链用例。它们如下：

• 房地产登记和所有权转移

• 了解您的客户

• 发票保理

政府 - 房地产登记和所有权转移

不动产由政府记录和维护，主要在地方政府层面。例如，一个国家的评估员负责记录和维护国家的财产记录。虽然一些国家已经数字化，但许多国家仍然使用传统方法，并依赖于纸质系统。多多少少，记录导致了合法所有权、交易记录的记录以及检查非法处置。本质上，记录是合法所有权的证据。在这个记录过程中，政府是一个值得信赖的权威，负责维护财产记录，评估其价值，并征收税款。作为一个值得信赖的中央权威，政府机构提供信任并倡导透明度。此外，政府的中央权威还提供了一套程序，用于认可财产权、保护文件、将财产权显示为透明的公共记录，并提供无缝的方法来转移这些权利和记录转移交易的所有权。简而言之，公众寻求记录和权利维护，产权和权利的转移，以及记录转移交易和信任。

这不是听起来像是区块链可以解决的有效用例吗？事实上，许多地方和国际政府已经开始采用区块链来在区块链上数字记录土地所有权记录。它在许多方面都有所帮助，比如透明度、保护记录、检查欺诈性转移以及记录转移。这个用例涵盖了一个简单的区块链解决方案，用于不动产登记、评估和上市。

当前流程存在的挑战

记录一项行为会产生行政成本。通常，文件通过电子表格、邮寄、电子邮件或亲自递交纸质文件至登记处。然后，将其扫描并上传至文件存储中。这导致记录被发布到中央存储中。从那时起，记录的信息被用来确定记录的所有权。该记录的所有权也对公众开放供参考。任何进一步的交易，如所有权转移，都需要在同一中央存储中进行。这是昂贵、低效、容易出错和耗时的。

区块链，救星

记录将存储在区块链或政府的中央知识库中，其引用可以在区块链上。有关大型对象存储的更多详细信息，请参阅第三章中的大型对象存储-在链上或链下部分，深入了解超级账本的细节。土地或房地产所有权记录为数字资产，并可在区块链上供公众参考。交易可以针对这些资产执行，并且资产可以快速转移。政府机构不需要一直扫描文件、打印标签、记录文件并对其进行维护。该数字资产的所有信息都在不可变的区块链中可用。税收交易也可以针对这些资产执行。可以评估房地产价值，并且该价值评估可以作为这些数字资产（房地产）的交易发布在区块链上。一切都记录在一个地方，并且可以基于区块链记录生成分析和报告。区块链为对数字资产（房地产）执行的所有交易提供了可追溯和可审计的记录历史。

各种交易，如单个包裹更改交易（其中数字资产被拆分、合并或重新分类），可以记录在区块链上。各种建议，如 58 和 193（指加利福尼亚州的道具），导致父母与子女之间或祖父母与孙子之间的房地产转让交易，可以记录在不可变的分类账上。各种其他生命周期事件，如地址更改和任何属性更改也可以记录。由于数据可在区块链上获得，因此很容易与其他部门共享，并且这也使得其他部门可以连接到一个来源以获取相关信息。各种其他交易也可以发生在数字资产上，例如估价、评估和卷校正，这些交易可以在数字资产上进行，并且可以记录以进行审计和可追溯性。

用于房地产（也称为房地产或房地产）登记的区块链解决方案可以是RealPropertyChain注册表。这是一个区块链解决方案，其中记录了房地产记录，如土地记录和建筑记录。这些属性在区块链上被识别为数字资产，并且对这些数字资产（记录）的交易被记录在区块链平台上：

房地产登记和评估的区块链解决方案

前面的图表展示了一个简单的用于房地产登记、评估、上市和分析的区块链解决方案。它是一个具有以下组件的区块链平台：

• 有一个注册房地产的 dApp，它还将验证并将纳税人与之关联。它被称为房地产记录管理系统。记录的房地产将拥有数字身份，系统将识别它为具有定义所有权和确定纳税人的独特数字资产。如果财产已记录，则可以使用财产的唯一数字资产 ID 来验证它及其所有权。

• 有一款允许您列出房产的 dApp。同样，房地产所有者授权列出房产。此列表将允许您买卖房产。如今，有多重列表服务（MLSes），这是一个房地产数据库，房地产经纪人需要支付费用以列出、购买和出售房产。各种网站，如 Zillow，与这些 MLSes 合作处理住宅物业，而其他公司如 CoStar 与 MLSes 合作处理商业物业。为了出售您的房产，您需要支付注册到这些 MLSes 的经纪人。有时候是销售价格的 6 到 9％。这是一项昂贵的交易，为了获得更好的交易，您可能需要与 MLS 合作以拓宽市场范围。基于区块链的 dApp 正在寻求在区块链上列出授权房产。现在买卖透明，交易不可更改，人人可及。

• 区块链去中心化应用（dApp）也可以被创建用来分析房地产数据，展示趋势、评估价值变化和房地产交易。

• 可以创建诸如评估与评定等智能合约，它可以处理所有权转移、建筑许可等。例如，当一项财产（数字资产）发生转移时，区块链会收到契据的副本。智能合约将根据州法判断是否需要重新评估。如果需要重新评估，则智能合约通信服务将确定财产的新市场价值并将新的评估价值传达给纳税人。此类智能合约还将处理免税规则，如残疾免税和退伍军人免税。此外，某些所有权转移，如丈夫到妻子，不会导致重新评估。这些智能合约处理此类评估规则，并为纳税人创建新的评估价值。智能合约还可以与纳税人沟通，提供新的评估，让房产所有者在不同意评估价值时提出申诉。

• 其他系统，如法律和司法系统以及税务收集者，可以轻松连接到区块链并从中访问相关的授权信息。

区块链解决方案的优势

区块链解决方案在财产登记、列表和评估方面的优势如下：

• 效率：目前，契据记录是昂贵的。将房地产登记引入区块链平台会导致房地产作为资产服务（PaaAS），在其中被不可变地记录下来。随后的交易，如所有权变更、评估和评估，可以由智能合约来处理，这增加了效率；它更少出错，更高效。

• 实时：房地产记录实时更新。所有权转移、评估和重新评估计算等交易几乎可以立即由智能合约执行。区块链增强了公共信息的透明度和准确性，实时性得到了提升。

• 不可变的交易：由于数字资产注册和交易记录位于 DLT 上，它是不可变的，容易受到攻击，并且防篡改。像海地发生的地震这样的自然灾害，导致土地记录被摧毁可能会发生。这种情况在像区块链这样的不可变账本上是不会发生的。

• 信任：区块链为房地产登记和记录、房地产交易记录、房地产挂牌、自动评估和评估、易于集成等提供了信任、透明度、效率、准确性和安全性。这表明，区块链是中心化房地产登记、所有权和交易系统的强大替代品。

社会因素

基于区块链的土地所有权登记解决方案对于像洪都拉斯这样的国家意味着很多，世界银行向洪都拉斯政府发放了美元以帮助其数字化土地所有权。中心化系统并不是可行的解决方案，因为腐败分子可能会对其进行黑客攻击和篡改。区块链解决方案是这种问题最合适的解决方案，因为它是不可变的，无法被篡改。另一个例子是印度，那里有三分之二的民事案件与土地和房地产有关。根据政府数据，有 2200 万个待处理案件。其中，有 600 万个已经拖延了五年以上。在区块链平台上，土地和房地产记录是具有独特数字身份的数字资产。它们被不可变地存储在账本上，区块链系统将处理这些数字资产的交易，如所有权的转移、属性的变更、新建筑和贷款。用户、授权机构和政府几乎可以即时地跟踪和追溯数字资产的整个历史。这样的系统将是高度无组织和腐败地区的福音。

房地产众筹

另一个有趣的用例与前面的用例相一致，与房地产众筹有关。房地产众筹，其中代币代表了房产的部分所有权，已经存在了很长一段时间。但是，当您想要变现而您的合作伙伴在那个时候还没有准备好时，问题就出现了。通过数字资产（如房地产）的基于代币的所有权，您可以交易您的代币而不必担心问题，并根据您的意愿和需求变现。代币或固定数量的数字代币可以代表数字资产（如土地、建筑物或公寓）的所有权百分比。根据百分比，您将获得租金收入或股息。对于那些想要进入房地产并想要投资房地产但也想要从小额投资开始的人来说，这是一个开放的窗口。现在你可以拥有一部分企业、一部分房屋或一部分公寓，并从其租金或股息中获得潜在收益。

金融科技 - 了解你的客户

为了检查法规风险、洗钱、未经授权的融资等问题，银行正在花费数十亿美元来吸纳新客户并为现有客户维持合规性。虽然开立账户是一个简单、直接的过程，但它涉及法规程序来识别和进一步验证申请人。这些过程被称为了解你的客户（KYC）。这个过程面临着不断变化的监管变化，需要及时更新以满足合规要求。它是复杂的、耗时的和昂贵的。大约每家银行每年花费 6 亿到 3 亿美元。每个 KYC 大约需要 5 到 45 天的时间，平均需要 24 天才能完成新账户的开立。此外，金融机构需要维护他们的系统和流程，以保持符合不断变化的监管要求。此外，由于从一家银行到另一家银行的变化，客户并没有统一的体验。除此之外，银行每年共同花费数十亿美元用于反洗钱。

显然，所有金融机构和银行的负担导致客户开户不良。在这种情况下，区块链是一个潜在的救星，因为它允许金融机构共享负担。此外，它消除了努力的重复，因为客户详情将在共享的分布式账本上可用。通过区块链启用的 KYC 流程，客户的最新信息可在共享的分布式账本上获得。参与的金融机构和银行将就是否需要对客户数据进行更改达成共识，并参与一种基于共识的联合方法来验证申请人。

目前，KYC/入职涉及从申请人收集文件，与信用机构合作验证申请人的身份，并将其纳入 AML 和非法金融交易。这一链条涉及多个参与方，耗时、费用高、缓慢且容易出错。

现在

目前，KYC，也称为入职过程，面临许多挑战。首先，由于信用、账户、法律和运营等不同部门遵循不同的流程，缺乏结构。由于每个部门对法规的解释不同，因此每个金融机构或银行都有单独的流程。其次，这些流程需要遵守不断变化的法规。第三，需要一系列文件和各种接触点来验证申请人，这增加了时间和成本。

未来

像加密、安全、散列和透明度、不可变性等特性的区块链技术将确保银行试图访问的记录准确、一致、安全、可靠和真实。由于数据是共享的，它既不受单一实体控制，也没有单一故障点。凭借共识，数据也是可靠的。区块链上的客户/申请人个人数据的可用性是一个可以解决的问题。每个金融机构和银行都可以维护自己的安全数据库来托管其客户的数据，并且只分享到区块链的链接或区块链的令牌。

对于申请人，金融机构或银行执行 KYC 过程，以验证申请人的身份。这确保个人没有参与任何非法金融交易。申请人向金融机构或银行提供某些信息，然后由银行的业务线（LOB），也称为部门，使用该信息来验证申请人是否参与 AML 和非法融资活动。通过 KYC 的区块链解决方案，即使参与的银行也可以在安全的共享不可变账本上分享申请人的验证。客户的任何错误交易都将立即引发对区块链的警报，这可以由参与的银行和金融机构使用来标记该客户。

KYC 本质上是涉及多方的身份移动。由于区块链是共享的、不可变的、可靠的和安全的，并且没有单一的权威或单一的故障点，银行和金融机构不需要协调。

关于下图中的预区块链 KYC 流程，申请人提交文件，包括政府发行的身份证明文件，如社会安全号码、驾驶执照和护照，以及其他信息，如就业、商业税收和地址证明。银行收集这些文件，并在启动扫描后将其转发给中央中介以验证人员身份。中介将存储此类信息在中央数据库中，并将成本用于管理、维护和保护此类数据。这些成本进一步被银行传递。此外，每个参与的银行和金融机构都会重复相同的流程：

KYC 使用案例

虽然申请人提交了政府发行的身份证明，但仍然存在一个挑战，那就是保证级别。最主要的挑战在于证明你是谁。中介将检查各种数据源、信用机构等，但保证级别仍然是一个值得怀疑的问题。

如果申请人是第一次申请者，甚至连信用历史都没有怎么办？在最高保证级别中缺少的链条是对申请者的生物识别身份验证。申请者可以提供政府发行的身份证明文件，如护照、社会安全号码或驾驶执照，以及生物特征。通过匹配生物特征和政府身份，可以保证最高的保证级别。这意味着中央中介也必须具备生物识别数据。这增加了数据保护成本，并引入了复杂的设备，以便扫描申请者的生物特征。

区块链上的 KYC/入门流程

申请人的唯一数字身份是基于政府发布的标识符和生物特征生成的。生物特征添加了最高级别的保证，由政府身份证支持。这将作为客户在区块链网络上的唯一数字身份。这有助于申请人成为客户后进行跨境交易。另外，使用区块链 KYC 解决方案，没有中央中介，因此每家银行和金融机构无需重复进行 KYC 检查。共享的不可变分布式账本将提供给银行或金融机构请求，以及申请人的允许，用于跨银行和机构的客户活动。如果有任何可疑情况，它也会发出警报，让银行和机构标记该客户。对于客户执行的所有后续交易，其数字身份将附加到每个交易中，这意味着每个交易都具有客户的数字签名，具有最高级别的保证。客户的数字身份可以帮助您访问客户的相关信息，例如其地址，并让您跟踪和追踪任何交易。这也将帮助您标记任何可疑交易，并有助于减少错误的阳性。通过区块链，没有中央中介。因此，不存在单一故障点，不可变的共享账本成为真实性的来源。

在区块链上的处理

使用区块链，KYC/入职流程将如下进行：

1. 申请人携带其政府身份证、地址和纳税证明前往银行。

2. 银行将扫描文件，以及申请人的生物特征，并将其推送到区块链上（假设银行开始使用生物特征进行入职）。或者，客户可以直接将其 KYC 文件上传到区块链上（如前面的示意图所示）。

3. 区块链网络将使用政府身份证的某些属性，例如社会安全号码和出生日期，以及，如果启用生物特征识别，将使用生物特征识别来生成申请人的唯一数字身份。如果申请人已存在，验证的信息将返回给银行。

4. 当一个新的申请人被添加到区块链时，将执行一个交易，参与的银行和金融机构进行验证。因此，数字身份是经过高度保证的，并基于共识添加，这也意味着它是可靠的。同样，对已经存在客户信息进行的任何更改都可以在共识后追加到区块链上。所有更新和新添加都可以实时访问给参与的银行和金融机构。

5. 经验证的申请人将被添加为客户。

6. 由该客户执行的交易将始终包含其数字签名。

这确保了客户的数字身份的创建以及每个交易都有经过验证的数字签名。然而，让我们讨论谁可以访问区块链上的数据。由于数据可在共享的分布式分类帐上获得，因此第三方可以在获得权限后进行访问以进行验证。这样可以防止对数据的未经授权访问，并赋予个人用户和机构用户权力。

当申请人向银行提供信息以及其生物特征时，他们的数字身份是由区块链系统创建的。然而，在用户授予权限之前，没有人可以访问它。用户将拥有数据，其他人只能在用户提供同意后访问。用户可以通过登录 KYC 门户（作为区块链网络的 dApp 的统一 KYC 门户）并建立数据的私钥来授予权限。现在，银行和其他第三方可以访问数据进行验证，数据仍然由用户拥有。此外，每个验证请求和对用户数据的每次访问都将留下痕迹，这将赋予最终用户权力，并告知他们谁在使用他们的信息以及用途。

KYC 流程可以构建为智能合约，然后可在各行业中使用，并进一步促进标准化。区块链提供了严格的防欺诈检查，因为区块链上的数据是不可变的。银行和金融机构不需要单独进行验证。由于数据在共享的分布式分类帐上，各方可以访问数据，尽管它仍然由最终用户拥有。由于交易已签署，可以在整个区块链网络中发现任何欺诈活动。由于账本上的数据是受信任的，可靠的和不可变的，因此不需要进行二次验证。欺诈和欺诈交易可以实时发现，这节省了未检测到的欺诈和诈骗的后果。

我们之前讨论的 KYC 解决方案是客户的分布式数字身份解决方案。此外，将银行和金融机构引入区块链消除了冗余。使用数字身份签署交易有助于防范欺诈并识别非法和欺诈性交易。然而，KYC 及其基础的区块链数字身份解决方案还有各种用例。它可以找到需要唯一数字身份的用例的解决方案；例如，会员卡，法律体系和信用评级机构。除此之外，所有涉及交易的用例都是基于区块链的 KYC 解决方案的主要候选对象。示例包括赌注，数字权利，微型融资，P2P 借贷，汇款，全球支付，股权，债务，众筹，衍生品，投票，所有权，所有权记录，知识产权和医疗保健。

金融科技 – 发票保理

小型企业通常将其发票带给较大的融资公司，如银行，以获得融资。通常情况下，企业与企业和企业与政府的交易，尤其是采购，需要更长时间才能付款。公司通常将发票出售给发票融资公司，并可以为未付发票获得融资。通常情况下，发票金额的 75%至 85%。其余部分在发票融资公司收到金额后收到，剩余金额由发票融资公司扣除费用。发票融资公司收取的金额通常取决于付款条件。付款条件越长，发票保理公司收取的费用就越高。全球范围内，大约有 3 万亿美元的发票保理业务。全球范围内，大约有 2%的发票融资每年都受到欺诈行为的影响。

今天有什么？

银行和金融机构确实有检查欺诈并应对潜在风险的流程；但是，这是一项劳动密集型、手动、昂贵、耗时且低效的工作。以下是发票保理的主要步骤：

1. 供应商向其客户开具带有付款条款（30 至 90 天）的发票。

2. 供应商需要现金，因此达成协议将发票分配给了保理公司，其中包括费用和其他细节。

3. 发票被出售并分配给了一个保理公司。

4. 保理公司将预付发票金额的大约 80%。

5. 在发票到期日，客户支付给保理公司发票金额。

6. 保理公司在扣除费用后向供应商支付剩余的 20%。

我们试图解决什么问题？

大多数情况下，公司将发票提交给多个融资机构或银行。由于融资公司和银行之间缺乏集成的沟通机制，存在潜在的漏洞，可能成为欺诈的潜在点。由于公司有多个地方可以将其发票提交，并且由于金融机构和银行之间缺乏集成，它们不知道同一张发票被提交给多个融资机构或银行。此外，发票可能被篡改并提交给各方以获得融资。在这里，我们谈论了两个主要挑战：首先，相同的发票被发送给各方，其次，篡改的发票被发送给各方。除此之外，发票保理还涉及其他风险，如不付款和迟付款等。其他风险包括发票可能是假的，或者可能已被篡改。发票保理也是用于验证客户及其客户身份的用例。经过验证和建立的身份可以降低迟付款和不付款的风险。

将发票保理引入区块链将导致整个发票保理流程的去中心化。区块链智能合约将负责协议和验证参与者的信用（供应商及其客户，根据本节中的先前示例）。由于这是一笔不可变的交易记录，参与方还可以分析参与者的过去表现，有助于降低风险并增加整个流程的透明度。基于超级账本的区块链解决方案，特别是基于 Hyperledger Fabric 的解决方案，将有助于减少发票融资中由于缺乏沟通和双重开票而发生的欺诈。

财团为基础的解决方案

基于许可的基于 Hyperledger 的解决方案可以帮助公司在分类账上共享关于发票的关键信息，但不会向他们提供客户数据的详细洞察。尽管它是银行、金融机构等的财团，但它们是竞争对手。在财团为基础的解决方案中，发票卖方将与特定的因素（银行或金融机构）联系。发票的数字身份将在区块链网络上进行验证。在唯一性的情况下，该发票将被因素（银行或金融机构）考虑为保理。供应商可以允许其客户成为区块链网络的一部分，以便客户可以直接向因素支付款项。所有交易将通过区块链网络进行处理，由交易方的数字身份签名，并包含有关发票的数字身份（数字资产）的信息。

正如您可以想象的那样，发票的数字身份，也称为数字代币，由区块链网络发行并且是唯一的。因此，在区块链网络上不可能发生双重发票。此外，所有方，如银行和金融机构，都在财团中；因此，每个人都将了解发票，消除了任何沟通问题。这也将检查卖方同时向多家放贷人提供相同或篡改的发票的任何机会。如果他们这样做，发票将只支付一个请求，并且双重开票行为将永久记录在区块链上，这可能会影响卖方的信用评级。随着区块链网络的发展，可以更加重视卖方和放贷人的信用评分。卖方的评级越高，他们需要支付的费用就越少，这将鼓励合法和值得信赖的卖方。借助区块链，发票保理还可以向中小投资者推广。

市场解决方案

应收账款卖家可以通过一个 dApp 使用区块链平台，这将允许他们选择想要出售的应收账款。一旦一张应收账款被标记为出售，一个经过验证的保理方可以接受应收账款。如果卖方同意，这意味着卖方已同意保理协议和费用。在这种情况下，智能合约将向卖方和卖方支付款项。到期日，智能合约将会从客户账户发起贷记交易，将资金转入保理公司账户。在向保理公司付款后，智能合约将继续处理剩余款项给卖方，并将费用记入保理公司账户。

在整个过程中，一旦将应收账款推送至区块链平台进行交易，所有交易都由智能合约自动处理。供应商、保理方和客户都将被智能合约自动开具发票、贷记和借记。发票的某些属性可以用来生成一个唯一的哈希，也被称为发票的数字身份。发票属性的任何更改都将导致发票哈希的更改，并且可以很容易被区块链网络发现。

代币化市场

在区块链的作用下，应收账款保理超越了银行和金融机构的边界。小型和中型投资者也可以参与应收账款保理。比如，发票买卖是一个建立在区块链解决方案上的 dApp：

• 应收账款卖家可以使用该应用并选择一张要交易的应收账款。

• 卖方可以根据之前的评分设置应收账款金额或智能合约。卖方的信用评分将调整应收账款的价格。

• 区块链智能合约（应收账款保理智能合约）将生成发票的数字身份（数字代币）并进行重复性验证。

• 经过验证后，应收账款将会根据应收账款金额的百分比或分数进行代币化。

• 出借者（小型、中型或大型）可以拥有那些代币。代币代表应向卖方支付的部分。拥有代币意味着同意向卖方支付款项。

• 到期日，智能合约将会从客户账户发起债务交易，将资金转入保理公司账户，根据出借者（保理公司账户）所拥有的代币数量。

• 向出借者（保理公司账户）付款后，智能合约将继续处理剩余款项给卖方，并将费用记入出借者/保理公司账户。

以下图表展示了含有区块链和不含有区块链的应收账款保理过程：

应收账款保理使用案例

由于这是一种基于代币的方法，小型、中型和大型出借者可以通过区块链网络的不可篡改性、信任性和可靠性跨越边界购买应收账款。

与使用案例互动

在设计策略部分，我们试图定义一个由五个步骤组成的区块链设计策略：探索、参与、实验、经验和影响。在本节中，我们将集中于第二步。在这一步中，我们将与我们在前一节中定义的用例之一进行交互。第五章、在 Oracle 区块链平台上管理解决方案，以及 第六章、在 Oracle 区块链平台上开发解决方案，负责试验解决方案。在那里，我们将定义另一个用例，并尝试为解决方案构建链码。我们还将设置和配置一个区块链网络来运行链码，并通过 REST 进行集成以连接链码。

在本章中，当与用例交互时，我们将首先定义流程——首先是现状流程，然后是未来流程。在前一节中，我们已经涵盖了很多流程方面的内容，这就是为什么本节将关注现状流程。在交互过程中，我们将学习定义模型的艺术，包括资产、数据模型、交易、参与者、事件和访问控制。一旦流程被定义并且组件被识别，我们将研究用例的集成架构和基础设施配置。

为给定用例参与和定义基于区块链的业务网络的步骤如下：

1. 定义现状流程以识别问题并定义一个高层次的流程（未来）

2. 识别和定义区块链网络组件：

   • 识别参与者。

   • 定义资产和数据模型。

   • 在交易细节中定义业务流程。这样可以帮助你识别交易和事件。

定义流程

此用例涵盖应收账款保理，也称为发票保理。这是一种金融交易，允许企业从未清算的发票中快速产生价值。我们将首先定义现状流程，然后定义未来流程，这样我们就可以识别各种区块链组件。

现状流程

卖方与客户进行交易并开具发票。这些发票到期日为 30 天、90 天或其他期限，取决于供应商和他们的客户的业务条款。因此，他们的客户不会立即付款给卖方。在这些情况下，卖方希望立即获得现金以运营或扩大业务，他们可以选择出售未结应收账款。这使卖方能够满足其紧急需求。发票卖方通常以折扣的形式出售未结发票。买方通常接受折扣并立即支付卖方。但是，买方只支付折扣后的金额，例如，总发票金额的 90%。在幕后，买方检查付款方（客户）的信用历史，因为最终要支付买方的是客户。在此过程中，有三方参与——发票卖方、发票债务人（付款方）和发票保理方（买方）。这种发票保理也称为应收账款融资或应收账款保理。它是一种基于资产的融资（ABL），允许卖方的应收账款作为抵押品。

To-be 流程

在较高层次上，供应商向其客户（客户 A 和客户 B）交付商品。供应商向这些客户发出付款发票。发票 1 应于 30 天内支付给客户 A，发票 2 应于 90 天内支付给客户 B。供应商需要即时现金，并以 5%和 10%的折扣分别出售发票 1 和发票 2。银行 1 和银行 2 也是区块链业务网络（KonsensusChainBC）的参与者。他们浏览可用的发票并对其进行保理。银行 1 对发票 1 进行保理，并向供应商支付发票价值的 95%，而银行 2 对发票 2 进行保理，并向供应商支付发票价值的 90%。保理将导致立即向供应商支付发票。立即支付确认将导致客户的应收账款更新。现在，客户 1 需要支付给银行 1，而客户 2 需要支付给银行 2。应付款项已更新为新的收款人详细信息。到期日时，应从付款方（客户）账户直接支付给买方（银行）账户，并更新客户的 AP 系统。在客户 1 和 2 支付发票的总金额达到 100%后，买方将支付剩余的发票金额给卖方。但是，买方（银行 1 和银行 2）将支付给卖方的余额中减去交易费。

识别和定义业务网络组件

以下图表突出显示了名为 KonsensusChainBC 的商业网络的各种区块链组件。 这些组件包括资产、交易、事件、通道以及区块链网络的访问控制列表。 由于该区块链业务网络是在基于 Hyperledger Fabric 的区块链上实现的，因此它也有通道的概念。 虽然这一步需要详细的交易和事件流程，但你可以直接跳转到交易流程步骤，然后再回到这一部分。

基于交易流程，你可以在区块链业务网络上得到以下组件列表：

KonsensusChainBC 的区块链组件

访问第三章，深入 Hyperledger Fabric，了解有关交易、事件、通道、参与者和访问控制的详细信息。 访问第五章，使用 Oracle 区块链平台管理解决方案，以在 OBP 上配置网络。

定义资产

资产可以是任何价值。 资产可以是有形资产，例如房地产和硬件，也可以是无形资产，例如合同和证书。 资产可以使用链码交易进行修改。 因此，在确定交易之前，最好确定将在区块链网络上进行交易的资产。 身份、货币、土地所有权、合同、投票、来源和支付等资产是宝贵且稀缺的。 让我们分析区块链的各种应用，并检查它们实际管理了什么。 例如，比特币中的帐户是资产，以太坊管理合同状态，Everledger 管理钻石资产，等等。 同样，对于 Hyperledger Fabric，资产可以是有形资产，例如房地产和硬件，其中无形资产可以是合同和知识产权等事物。 这意味着，区块链是那些需要进行资产交易并建立去中心化共识并将其记录在不可变账本上的情况的潜在解决方案。

对于这个业务案例，主要资产是发票。 以下是资产的一些属性：

• 发票 ID/号码

• 发票描述

• 交易货币

• 原始发票金额

• 未清发票金额

• 保理发票金额（根据折扣百分比计算）

• 发票到期日

• 发票折扣百分比

• 客户 ID 和其他客户详细信息

• 供应商 ID 和其他供应商详细信息（同样包括银行的详细信息）

• 保理参与者 ID（同意发票保理的银行）

• 保理详情（保理银行的详情等等）

• 发票里程碑（状态）

• 付款方协议（是/否）

定义参与者

本小节集中在定义商业网络的参与者。 对于发票保理的用例，涉及以下各方：

• 供应商，也被称为发票的销售商或发行人：

  • 供应商也是区块链网络（KonsensusChainBC）的创始人，该网络连接了各种银行和客户作为参与者

  • 区块链网络的链码呈现为名为 KonsensusChain 的 dApp

  • 此 dApp 提供了销售应收账款的解决方案。它还配备了用户界面，允许供应商（卖方）、买家（保理方）和客户（付款人/债务人）进行交易

  • 供应商的应收账款与区块链网络相连

• 客户（客户 A 和客户 B）也被称为付款人/债务人：

  • 客户使用 KonsensusChain dApp 浏览发票的里程碑（状态）并检查收款人的信息。

  • 客户的应付账款与区块链网络相连，其中订阅从区块链网络发出的事件。各种事件允许客户的应付账款（AP）更新收款人详细信息，并使用正在进行的发票状态更改更新其 AP 系统。

• 银行是购买发票的一方。它们也被称为买家。在这种情况下有两家银行（银行 1 和银行 2）。

• 验证者是具有交易摘要访问权限但没有许多详细信息的参与者。例如，想要检查发票保理中的欺诈并需要访问交易摘要的政府机构，如证券交易委员会（SEC）。

以下图示显示了参与者：

KonsensusChainBC 商业网络参与者

用虚线/蓝色表示的圆圈显示了客户 1、供应商和所有银行之间的渠道，而用实线/红色表示的圆圈显示了客户 2 和供应商之间的渠道。我们将在第三章中更详细地讨论渠道，深入了解 Hyperledger Fabric。

详细的流程，包括交易和事件

此部分是识别交易和事件的核心，也为定义渠道和访问控制奠定了基础。我们将在本节中涵盖所有剩余的区块链组件。

供应商（卖方）以发票价值的 5% 折扣（发票 1 开给客户 A）和发票价值的 10% 折扣（发票 1 开给客户 B）的价格出售应收账款。供应商的应收账款（AR）将自动将发票推送到区块链网络（KonsensusChainBC）。推送到区块链网络的应收账款发票被标记为“待审批保理”的里程碑（状态）。

以下是卖方执行的确保发票可用于保理的步骤：

1. KonsensusChain dApp 提供了一个供应商（基于角色）的用户界面。此 UI 允许卖方批准 AR 发票，这些发票正在等待因素化（待批准因素化）。一旦批准，发票将可供银行因素化。

2. 一旦批准，链码（KonsensusChain dApps 背后的智能合约）将发出交易 交易 AR 发票，并且发票的里程碑（状态）将为 可因素化。

银行（买方/付款方）使用面向买方的 dApps（KonsensusChain）和用户界面。

以下是付款方执行的步骤：

1. 银行 1 和银行 2 使用 dApps 用户界面浏览可因素化的发票。

2. 在浏览时，dApp 发出 查看可用发票交易。

3. 银行浏览发票并选择要购买的发票。这将导致交易 购买可用发票，并且发票的里程碑变化为 启动因素：

假设银行 1 购买了客户 A 的发票，银行 2 购买了客户 B 的发票。以下是此假设的结果：

1. 此状态（启动因素）变更将导致 因素支付折扣发票 交易的自动执行，并且发票的里程碑将变为 发票已因素化。

2. 因素支付折扣发票 交易生成两个事件：因素卖方事件 和 因素支付方事件。因素卖方事件 将导致以下活动：

   • 银行 1 的系统将支付供应商发票金额的 95%（对应客户 A 的发票 1）和 供应商发票金额的 90%（对应客户 B 的发票 2）。

   • 因素卖方事件 还将导致供应商的 AR 系统更新其记录。

客户（债务人/收款人）账款系统将从链码接收 因素支付方事件。以下是因素支付方事件的影响和客户账款（AP）的变化：

1. 因素支付方事件 还将导致客户的账款（AP）系统更新记录：

   • 客户 1 和客户 2 订阅了包含唯一客户身份、发票标识和收款人帐户详细信息的因素支付方事件过滤器。这将允许 AP 系统将收款人详细信息与发票关联起来。

   • 这些事件将包含关于作为付款人/债务人列出的发票的详细信息。这些发票现在将具有修改后的收款人（银行）详细信息。在这种情况下，银行的详细信息和银行的帐户详细信息也将成为事件的一部分。

2. 客户的 AP 系统还将调用 直接支付因素 交易。这是客户同意直接支付收款人（发票买方/因素）的协议。这不会导致发票的里程碑变化，但将 付款方协议 发票属性设置为 true。

当发票到期时，即客户 A 为 30 天，客户 B 为 90 天，KonsensusChain (链码) 将自动向收款人 (银行) 支付发票价值的 100%。当发票到期时，以下事件发生：

1. 到期的发票将导致债务人支付发票交易。这将会改变发票的里程碑为债务人支付保理款

2. 在执行债务人支付发票交易后，链码将自动导致保理商支付贴现发票交易，并且发票的里程碑将是保理商支付卖方。这将导致以下结果：

   • 这一步将导致银行（买方/保理商）向发票卖方（供应商）支付剩余发票款项。

   • 发票的保理商（买方）将支付剩余款项给卖方（本例中的供应商），扣除保理费。

   • 付款后，卖方系统将自动调用保理商支付全额发票交易。这是向 KonsensusChain 区块链网络指示成功收款的最终指标。在这个最后阶段，发票的里程碑 (状态) 将是发票保理完成。

下图突出显示了整个交易流程：

交易流程

集成架构

下图展示了各种系统如何与区块链业务网络集成。 应用程序可以使用 REST、SDK 和事件与区块链网络集成。这样可以简化应用程序开发，并与区块链网络集成。事件允许 SaaS、PaaS 和自定义流程订阅事件并相应地做出响应。

在本章中设计的业务场景是因为所有参与者都是 KonsensusChain 区块链网络的一部分，并且正在使用 dApp 执行交易。这样的 dApp 提供了基于角色的用户界面，允许参与者连接到应用程序并执行交易。然而，我们也讨论了导致更新应收账款和更新应付账款的交易。AR 和 AP 分别是供应商和客户 1 的 SaaS 和本地部署 (E-Business Suite) 应用程序。这些应用程序可以订阅区块链事件并相应地采取行动。

根据我们的业务场景，卖方 (供应商) 可以通过 REST 与区块链网络 (KonsensusChain) 集成，并执行交易应收账款发票交易。此交易将导致在区块链网络中发现发票。银行的应用程序可以通过 REST 和 SDK 将其 SaaS、PaaS 和自定义流程与区块链网络连接起来。客户 2 没有 SaaS，他们使用 BPM 解决方案构建他们的流程和应用程序。这样的应用程序也可以订阅区块链事件，并通过 REST 连接。

验证者正在使用 Java、Go 和 Node.js 进行高级集成：

集成架构

业务网络的基础设施

到目前为止，我们已经详细介绍了应收账款保理的用例，并对业务网络（KonsensusChain）进行了建模以实现该用例。我们还了解了与区块链网络的集成选项。本节专门讨论实现业务网络基础设施的问题。到目前为止，我们讨论的用例可以在诸如 Hyperledger Fabric 之类的许可区块链上实现。因此，我们将尝试使用基于 Hyperledger Fabric 的云平台来定义基础设施。我们在 第一章 的 BaaS 部分中简要了解了 OBP。在本节中，我们将尝试在 OBP 上实现业务用例。

从基础设施的角度来看，Oracle 提供了一个区块链的云托管平台，预装有各种基础服务，如计算、存储、身份管理（身份验证）、容器、对象存储（内置归档）、日志和管理分析（运营）等。各种 SaaS 应用程序、PaaS 应用程序、本地应用程序和遗留应用程序都可以使用 Oracle 的集成云服务与区块链集成，并且可以订阅从区块链业务网络中引发（发出）的事件。

以下图表显示了 OBP 是在 Hyperledger Fabric 之上构建的：

OBP 利用 Hyperledger Fabric

供应商（卖方）组织计划启动一个财团，并决定采用基于创始人的财团，因此向其中添加了几个更多的参与组织。为此，他们在 OBP 上设置了区块链实例。每个区块链实例包含托管容器、虚拟机、身份管理、块和对象存储以及 Kafka，即 Oracle 事件中心云服务。在本节中，我们将深入讨论业务案例，并尝试为其实现基础设施。

KonsensusChain 是一个基于创始人的区块链网络，其链码负责财务交易、发票买卖、向发票销售商支付款项以及从最终客户处收取款项。KonsensusChain 设置在 OBP 上。对于每个组织（创始人和参与者），它都有一个物理机器。由于它是一个生产部署，其排序基于 Kafka，并且排序节点是由创始人组织创建的。此基础设施还包括每个组织的一个 证书颁发机构（CA）。根据每小时少于 1,000 次交易的要求，此高度可用的配置将如下所示：

• 两个 fabric CA 节点在不同的虚拟机（VMs）上复制，以实现 高可用性（HA）。

• 供应商（创始人）将拥有两个对等节点，而客户和银行各有两个对等节点。

• 存储容量为 4 TB。

• 每个 VM 上都有一个复制的控制台节点，以实现高可用性。这个控制台可以用来管理参与者，创始人可以用它来管理链码。

• 集成了身份云服务，允许组织管理角色和身份。

• 将在一个隔离的 VM 中为链码提供一个容器。您可以使用控制台来管理链码。

• REST 代理节点将在不同的 VM 上进行复制，以实现高可用性。这些节点提供 RESTful API。

• 也提供了负载均衡器和运维管理和监控。

• 提供配置备份的对象存储，以及通过区域的块复制。

• 创始人（卖方/供应商）将拥有两个 Kafka orderer 节点，这些节点将在不同的 VM 上进行复制，以实现高可用性。

以下图表显示了我们在本节中讨论的区块链业务网络（KonsensusChain）的基础设施：

区块链业务网络的基础设施

每个组织都将获得一个区块链实例（一个创始人和五个参与者实例）。每个实例都包括节点-一个对等节点、一个控制台节点、一个 REST 代理节点和一个 CA 节点，而创始人将拥有一个 orderer 节点。实例还与对象存储集成，用于动态备份配置和账本。备份包括账本块、通道配置、检查点、链码和用于配置文件和日志文件的节点。备份和恢复是自动流程。它还使用 Oracle 事件中心云服务来处理 orderer 节点上的 Kafka。REST 代理节点将允许 RESTful API，这进一步帮助 SaaS、PaaS 及其应用程序与区块链业务网络连接和集成。通过所有这些服务、容器和基础设施，OBP 负责区块链业务网络的高可用性、可伸缩性和弹性。

总结

本章突出了 DLT 和区块链的挑战和机遇。本章还深入探讨了区块链的各种属性，以及这些属性如何颠覆了在不同场景中使用区块链的方式。在本章中，我们还深入研究了建模一个用例以及展示用例实施的集成方面和基础设施。设计策略 部分提到了这五个阶段——探索、参与、实验、体验和影响。我们还涵盖了设计策略的最初两个阶段（探索和参与）。我们通过审视各种用例来探索设计策略，证明采用区块链的合理性，并试图制定一个方程来证明/量化在给定用例中使用区块链的可行性。之后，我们通过为给定用例定义基于区块链的业务网络来参与设计策略。在这里，我们勾勒了流程，并确定了各种基于区块链的业务网络组件，如资产、交易、参与者、事件、访问控制和通道。我的下一本书，《面向解决方案设计师的区块链》，将详细介绍设计策略。在这个版本中，第五章，在 Oracle 区块链平台上管理解决方案 和 第六章，在 Oracle 区块链平台上开发解决方案，涵盖了设计策略的实验部分，您将学习如何构建链码并在区块链平台上运行它。这使您能够对区块链平台进行实验。从下一章开始，我们将探索 Hyperledger，其架构和其他细节。

第三章：深入了解 Hyperledger Fabric

权限区块链已经发展，以满足在一组已知（但不一定受信任的）但可识别的参与者中采用区块链的需求。这些参与者首先需要被明确地接纳到区块链网络中。在这里，了解（识别）参与者比完全信任这些已知参与者更为重要。这些参与者可能不信任彼此，但是已知和可识别，它们是被共同目标连接在一起的。Hyperledger Fabric（一种权限区块链）使用拜占庭容错（BFT）变体实用 BFT（PBFT）作为共识协议，而不是工作证明（PoW）。HLF 为权限区块链提供了改进的功能特性，如保密性和一致性，同时还提供了改进和增强的非功能特性，如性能和可伸缩性。

本章重点介绍 HLF 的基础知识。这将使您理解在 HLF 中如何实现业务逻辑，并了解促进读写操作到分布式账本的各种交易类型。Linux Foundation 正在与各大公司和一些最聪明的开发人员合作，致力于解决 IT 世界面临的一些最复杂的挑战，并促进开源技术的商业应用。这是有史以来规模最大的开源软件项目。Linux Foundation 是各种开源项目的母项目。对于大数据和分析，它支持 R 语言，以及贡献项目。对于网络，它支持 ONAP（Open Network Automation Platform）和 OpenDaylight 等项目。对于云计算，它支持 Cloud Foundry 和云原生计算等项目。同样，对于区块链，Linux Foundation 负责处理 Hyperledger 项目。

简介 Hyperledger 项目

Hyperledger 项目始于 2015 年 12 月，由 Linux Foundation 主办，旨在创建先进的跨行业分布式账本技术（DLT）和区块链技术。它托管区块链框架并支持一些工具。这是一个开源项目的集合，其中一些项目是 DLT 框架，包括 Iroha、Sawtooth 和 Fabric。

Hyperledger 托管的框架

以下是由 Hyperledger 托管的框架。这些被分类如下：

• Hyperledger Burrow

• Hyperledger Fabric

• Hyperledger Indy

• Hyperledger Iroha

• Hyperledger Sawtooth

Hyperledger Burrow:

• 贡献者：最初由 Monax 贡献，由 Intel 共同赞助。

• 主要特点: Burrow 是一种轻量级、快速、高效的权限链码机器。它利用 Tendermint 协议进行共识。Burrow 最重要的特点是区块链的速度。在区块链速度方面有三个维度。第一个是代码库的事务吞吐量。第二个是区块在网络内的传播速度。第三个和最后一个维度是区块最终化的时间（也就是区块的最终性）。Burrow 是一个非分叉的区块链，事务终局性是有保证的。终局性增强了系统的整体速度，因为应用程序和系统可以立即依赖区块链网络上的信息。

• 目标: 它提供了一个模块化的区块链客户端，其中包含一个部分按照以太坊虚拟机（EVM）规格开发的权限智能合约解释器。它是一个权限智能合约机器，提供了一个模块化的区块链客户端，其中包含部分符合 EVM 规格的权限智能合约解释器。

• 共识协议: Tendermint。

Hyperledger Fabric (HLF):

• 贡献者: 最初由 Digital Asset 和 IBM 贡献

• 主要特点: 模块化可插拔架构，以及高水平的隐私和机密性权限

• 目标: 用作开发具有模块化架构的权限企业应用程序或解决方案的基础

• 共识协议: Apache Kafka

Hyperledger Indy:

• 贡献者: Sovrin 基金会。

• 主要特点: 专为去中心化身份而建。它管理密钥，证明和其他相关信息，从而使各方之间的可信等的对等交互成为可能。

• 目标: 提供工具、库和可重复使用的组件，以创建和使用可在应用程序之间互操作的独立身份。

• 共识协议: PBFT。

Hyperledger Iroha:

• 贡献者: Soramitsu、日立、NTT 数据和 Colu 贡献。

• 主要特点: 允许对账户和数字资产进行操作

• 目标: Hyperledger Iroha 强调移动应用程序开发，并提供了 Android 和 iOS 的客户端库，使它与其他 Hyperledger 框架区分开来

• 语言: C++

• 共识协议: 又一个共识 (YAC)

Hyperledger Sawtooth:

• 贡献者: 英特尔。

• 主要特点: 供 DLT 应用程序使用的模块化平台。

• 目标: Sawtooth 在一个不信任的世界中创建了一个数字平台，实现了物理可追溯性。它是一个利用模块化平台构建、部署和运行分布式账本的区块链框架。它支持权限部署和无权限部署。

• 共识协议: 耗时证明 (PoET) 共识。

前述的 Hyperledger 框架用于构建 DLT 和区块链应用程序，以及一系列模块（也称为工具）用于方便地部署和维护区块链应用程序，分析账本数据，和管理区块链网络。

由 Hyperledger 托管的工具

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

• Hyperledger Caliper

• Hyperledger Cello

• Hyperledger Composer

• Hyperledger Quilt

• Hyperledger Explorer

• Hyperledger URSA

Hyperledger Caliper:

• 贡献者：甲骨文、华为和其他公司。

• 目标：测量特定区块链实现的性能

• 关键特点：它允许生成具有各种性能指标的报告，如资源利用率、每秒交易数和交易延迟

Hyperledger Cello:

• 贡献者：IBM、华为和其他公司。

• 目标：为企业提供Blockchain-as-a-Service（BaaS）, 从而快速实现企业区块链解决方案。它减少了复杂性，最小化了创建、终止和管理区块链所需的工作量。

• 关键特点：除了各种基础设施，如bare metal和虚拟机，它还提供多租户服务。它通过简化的控制面板实现了快速创建和管理区块链的功能，并可立即提供区块链实例。

Hyperledger Composer:

• 贡献者：IBM 和 Ox-chains 的贡献者是维护者社区，但鼓励每个人参与和贡献。

• 目标：开发一组协作工具，促进快速、简便地建立区块链商业网络，以使开发人员能够快速创建链码和应用程序。

• 关键特点：使用 JavaScript 和工具，包括 Node.js、npm 和 CLI 构建。其模块化语言有助于资产定义、参与者定义和交易定义。这三个组件构成了区块链网络。它可以更快、更容易地开发区块链应用程序。

Hyperledger Quilt:

• 贡献者：NTT 数据和瑞波。

• 目标：通过实现Interledger Protocol（ILP），实现账本系统之间的互操作性。ILP 是一种支付协议，旨在跨分布式和非分布式账本转移价值。

• 关键特点：允许账本之间进行原子交换（甚至是非区块链或分布式账本），以及每个账本内的账户具有单一的命名空间。

Hyperledger Explorer:

• 贡献者：IBM、DTCC 和英特尔。

• 目标：允许授权参与者探索 DLT 项目。它还允许可视化区块链操作，从而使企业能够从数据中提取价值。

• 关键特性: 浏览器可以查看、调用、部署或查询区块、交易和相关数据，网络信息（名称、状态和节点列表）、链码和交易家族，以及存储在分类账上的任何其他相关信息。

Hyperledger Ursa:

• 贡献者: Ursa 的贡献者包括 Hyperledger Indy、Sawtooth 和 Fabric 开发人员，他们致力于这些模块的安全方面。此外，为确保所有加密算法符合标准，还有几位密码学家参与其中。

• 关键特性: 旨在为 Hyperledger 中的其他项目提供模块化、灵活的加密库。

• 目标: 确保其他 Hyperledger 项目对受信任的加密库的安全和更轻松访问。其模块化库将帮助区块链开发人员通过简单的配置切换或更改加密方案。

• 语言: Rust.

HLF – 特性和限定符

与 Linux 基金会一起，各种公司，如富士通和 IBM，正参与 HLF 项目的合作。HLF 是一个设计和构建模块化应用程序的权限区块链框架。

以下是 Hyperledger 框架的关键功能:

• HLF 受到来自各组织的卓越多样化的技术指导委员会的监督。

• HLF 是模块化和可配置的，这使得它对于各种用例都非常有用，从银行、金融和供应链到教育和医疗。

• 它是一种 DLT，其中链码是用通用编程语言（如 Java、Go 和 Node.js）编写的，而不是使用DSL（领域特定语言）。这也使得 HLF 更接近那些使用这些语言构建和精通这些语言的企业。

• HLF 是一个开源的、企业级的、权限区块链。

• HLF 采用模块化组件化方法和易于使用的 API。

• 由于 HLF 是受权限控制的，它遵循治理模型来处理纠纷。

• HLF 支持可插拔的共识协议，区块链网络可以选择共识协议以解决其用例。例如，对于单一企业区块链解决方案，崩溃容错（CFT）共识可能比 BFT 更吸引人，因为 BFT 更适合多企业区块链网络。

• 成员服务（HLF 的关键组件）是即插即用的。

• HLF 还具有可插拔的身份管理协议，例如轻量级目录访问协议（LDAP）和 OpenID Connect。这也使得 HLF 对拥有多样化身份解决方案的企业更具吸引力。

• 在 HLF 中，智能合约，也称为链码，在容器中执行（例如，Docker），因此与分类账状态隔离。

• 在 HLF 中，分类账可以配置为支持各种数据库管理系统。

• HLF 不需要加密货币，这显著减少了区块链存在对加密货币的依赖，并降低了攻击风险。

• HLF 服务图显示了 HLF 的各种组件。它们是通过 API 和 SDK 集成、组装和交互。主要组件如下：

  • 身份

  • 账本

  • 交易

  • 共识

  • 智能合约

  • 安全和加密服务

为什么选择 Hyperledger？

在第一章，探索区块链和 BaaS，以及第二章，理解分布式账本技术和区块链中，我们涵盖了 DLT 和区块链。另外，我们了解了各种网络拓扑，如集中式、分布式和去中心化系统。我们还熟悉了区块链的结构、交易和各种其他区块链概念。我们对许可和无许可区块链进行了详细分析和讨论。像以太坊和比特币这样的无许可区块链是开放区块链，任何人都可以参与其中。另一方面，许可区块链允许有限的参与者管理区块链网络，只有经过授权和认证的参与者才能访问它。

与无许可区块链相关的各种优势，同样，使用许可区块链也有优势。许可区块链成本效益高，交易开销低。由于交易验证和验证更快，交易成本非常低，交易时间更短。选择区块链网络背后的决策完全取决于用例和消息和交易的可见性。然而，在我看来，与企业形成共鸣的关键区别是确定谁将参与区块链业务网络，谁有权在业务网络上进行交易；另一个原因是能够增强制造商和消费者之间的直接关系，并降低或消除对中间人或第三方（中介）的依赖。

我们正处在去中介化的时代。这一趋势由 Uber、亚马逊、Airbnb 等公司发起，它们没有拥有任何车辆、实际库存或房间库存，但它们让生产者和消费者连接和交易。区块链和分布式账本进一步赋予生产者和消费者权力，从方程式中剔除第三方和中介。许可区块链通过对区块链网络进行许可访问和在参与者之间传输交易，进一步允许数据在区块链网络上的隔离，从而实现隐私和数据的保密性。与区块链一样，分布式账本完全有可能颠覆那些严重依赖中介的行业，比如保险、医疗保健、交通运输、零售、物流、房地产和教育。

就企业而言，区块链在高层次上提供以下几点：

• 它检查恶意节点篡改数据传输的风险，以确保数据传输的防篡改。这由保护交易树以及获得 PoW 的复杂性来实现。恶意用户不能在没有重新计算 PoW 哈希的情况下更改/篡改数据，这是一项艰巨的任务，需要极端的计算能力。

• 由于 HLF 区块链是受许可的，区块链网络是在已知参与者中进行操作的，这在区块链网络本身提供了高水平的信任。

• 使用 HLF 的通道，可以进一步保障参与者之间的交易。

• 它消除了对单一中心故障点的依赖。

• 一致性由协议保证，采用相同的验证规则和区块布局。

• 所有节点将遵循最长的链，确保在各地建立协议。

• 区块链降低不确定性，增强各方之间的信任，实现更快速、更安全的交易。

• 企业选择的许可区块链允许企业为参与者制定成员资格规则，提供不可变性（防篡改，区块链代表着真相）、隐私性和保密性（授权进行敏感数据安全交换）、可扩展性、可靠性、可用性（支持关键任务应用）和可审计性（管理、跟踪、追溯、验证和监控）。

在无需许可区块链中，交易在每个节点上执行（假设共识机制是 PoW）。这意味着缺乏保密性，因为数据和智能合约以及交易数据都可以在网络上的每个节点上找到。对企业来说，保密性和交易数据的可见性非常重要。在 B2B 交易的情况下，企业不希望一个合作伙伴提供的特别费率数据对另一个合作伙伴可见，尽管无需许可网络通过加密数据来解决保密性问题。然而，使用 PoW 的无需许可区块链网络将导致数据在每个节点上都可用，这突显了在未来可能有可能解密数据，以及节点上的数据的本地可用性。在 HLF 中，除了已识别的参与者以及加密外，通道提供了最高级别的保密性。在这里，只有参与节点才能访问链码和交易数据，而且这也是由访问控制进一步控制的。这为区块链网络引入了高级别的隐私和保密性。

无需许可与受许可区块链：

当我们讨论为什么选择 Hyperledger ？时，很有必要快速了解无需许可区块链和受许可区块链（如 HLF）之间的差异。让我们从执行方式、确定性和保密性的角度分析这些分布式账本（DLT）的变体：

• 执行方式：

  • 无需许可区块链，如以太坊，观察到交易的顺序执行，它们遵循顺序-执行的架构。所有对等方执行顺序-执行 风格的交易，这导致了性能和可扩展性的限制。在这里，吞吐量与交易的延迟成反比。然而，无需许可区块链试图通过围绕加密货币进行编排来处理这个问题。这确保了每笔交易都包括一定数量的燃料/气体。因此，每个交易执行步骤都需要通过智能合约付费。然而，这种吞食加密货币的机制可能不适用于受许可区块链。

  • 允许的区块链，如 HLF 的架构，支持可伸缩性和性能，同时也支持信任。 HLF 的架构基于执行-排序-验证（E-O-V）架构，其中交易甚至在达成共识之前就已被执行。交易的执行（execute）将确保交易的正确性（认可），而模块化可插拔式共识协议将导致排序（order）交易。此外，在提交交易之前，交易受特定于应用程序的认可政策验证（validate）。E-O-V 解决了允许的区块链订购和执行架构所面临的灵活性、可伸缩性、性能和保密性问题。 HLF 允许子组中的一部分对等方并行执行交易。有趣的是，链码将认可工作委托给某些指定的对等方；因此，不同的链码可以指定不同的对等方作为认可者，从而支持并行执行。请注意，Hyperledger Fabric 会在交易被排序之前执行交易。

• 确定性：

  • 共识确保节点对交易达成一致意见，因此智能合约应该确定性地执行交易。如果不确定，建立共识就没有意义。此外，这种非确定性会导致共识的无效，并且会导致分支。因此，智能合约语言和编译器应确保智能合约的执行是确定性的。因此，各种区块链都选择了领域特定语言。这迫使开发人员学习新的语言，只是为了确保智能合约的确定性。

  • HLF 的 E-O-V 架构确保交易受特定于应用程序的认可政策验证。这意味着是特定于应用程序的政策确保了多少以及哪些对等方节点将验证和确保链码的确定性执行。因此，子组的一部分将执行（认可）交易以满足认可政策。这将在排序之前过滤出不一致的结果，并从而消除任何不确定性。因为消除了不确定性，HLF 支持使用标准编程语言。你可以使用 Go、Node.js 和 Java 编写链码。

• 确定性的混合复制驱动程序：

  • HLF 遵循被动复制和主动复制。通过广泛执行（认可），被动复制实现了确定性和并行执行。它还通过只在达成共识后将交易提交到账本来实现主动复制。因此，HLF 遵循混合复制策略。同样，共识的选择是特定于用例的，或者与该用例部署相关，因为 Hyperledger 支持模块化共识机制。这允许实施者选择任何自己喜欢的共识协议，比如 BFT 或 CFT。

• 机密性：

  • 利用 PoW 的无许可区块链在每个节点上执行交易。因此，每个交易和智能合约对每个节点都是可见的，这明确表明了 PoW 提供的 BFT 的保密性损失。保密性的丧失是企业客户及其用例所面临的挑战。例如，如果一家企业希望与一些供应商建立某些价格，并与非高级供应商建立不同价格，它们将无法保持这些首选价格的保密性。如果所有供应商都在同一区块链网络上并访问相同的智能合约，则不可能与不同供应商维持不同的交易关系（价格）。无许可区块链提供了两种解决方案：

    • 它加密了这些首选信息。然而，数据和智能合约都在每个节点上。加密可能会被破解，且始终存在丢失信息的风险。

    • 零知识证明（ZKP）可以处理保密性丢失。然而，ZKP 的计算会增加延迟并消耗资源。这意味着 ZKP 可以解决保密性问题，尽管这会导致性能问题。

• 像 HLF 这样的许可区块链提供了通道和私有数据收集（PDC）来解决保密性问题。

区块链解决方案的 Go/No–Go

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

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

• 是否需要一个共享的共享数据库？

• 对于业务流程，参与方是否缺乏信任？

• 是否有多个方参与了向数据库承诺？

• 是否涉及第三方或中间人参与业务流程？

• 业务流程数据是否存在于多个数据库中？

• 是否需要数据的不可变性或交易的日志/历史记录？

• 交易频率是否在每秒 10,000 次左右？

• 交易规则是否不经常更改？（在区块链上编写的规则是预先设置的，一旦部署并启动，链码将不会根据新规则改变路线）。由于区块链上的一切都是确定性的，规则更改应用程序通常不适合区块链）。

• 过程中没有存储大量静态数据吗？

• 过程中的数据量不大吗？（由于数据被复制，大规模的数据复制到所有节点并不是区块链的有效用例）。

• 是否没有从外部来源检索数据的需求？

如果前面的任何问题的答案是是，那么区块链就是企业用例的解决方案。此外，如果需要交易公开，那么企业用例需要一个无权限的区块链解决方案，否则需要一个像 HLF 这样的有权限的区块链解决方案。

架构 - 概念视图

在我们深入了解 HLF 架构及其组件之前，让我们首先了解一些重要术语的概念视图。通过一个例子来阅读本节，以把握一些基本知识，并在阅读架构和组件后回顾本节，以进一步确认对 HLF 的理解。

KonsensusChain 组织决定创建一个产品链（一条名为 ProductChain 的区块链业务网络）来使生产商和零售商进行交易。此外，它将允许监管机构验证产品的合法性。 KonsensusChain 组织将充当创始组织，并不参与任何交易。然而，它将建立区块链网络，开发用户界面、链码应用程序，并进一步维护和操作业务网络（财团）。这是一个基于 HLF 的创始者发起的区块链网络模型，在这个模型中，参与组织已创建了一个财团。在此示例中，创始者并不完全提供 dApp。dApps 是由组织单独构建的。然而，它们使用 SDK、REST API 和其他集成方法与业务区块链网络连接并执行交易。

以下是意图成为区块链网络一部分的不同组织：

• 生产商组织：标识为组织 1（O1），这是一个生产某些产品并将它们销售给零售商的组织。监管机构进一步验证这些产品的合法性。生产组织 O1 的证书授权机构（CA）是 CA 01。

• 零售商组织：标识为组织 2（O2），这是一个从生产组织 O1 购买产品并转售给其消费者的组织。零售商组织 O2 的 CA 是 CA O2。

• 零售商组织：标识为组织 1（O3），这是一个从生产组织 O1 购买产品并转售给其消费者的组织。零售商组织 O3 的 CA 是 CA O3。

• 监管机构：标识为监管机构（O4），这是一个验证产品并核实产品合法性的监管机构。

• 创始组织：KonsensusChain.com 是创始组织，标识为组织 5（O5）。所有零售商和生产商已经同意将 O5 作为 ProductChain 区块链网络（区块链网络的虚构名称）的创始组织。

以下是这个基于区块链的业务网络（ProductChain）的要求：

• 需求一：生产者组织（O1）希望与零售商组织（O2）进行私人交易和沟通，因为他们已经就某些产品的特定价格达成一致，并希望保持交易隐私。

• 需求二：类似地，生产者组织（O1）希望与零售商组织（O3）进行私人交易和沟通，因为他们已经就某些折扣和付款条款达成了一致，他们希望保密。

以下是本节将参考的业务网络的概念图：

架构：概念视图

构建区块链网络

本节讨论了业务网络的构建块，并涵盖了组建业务网络所涉及的步骤。所有术语均基于 HLF。以下是构建业务网络所需的步骤：

步骤 1：启动区块链网络：组建网络的第一步是启动一个排序器。在示例中（参考上述 架构：概念视图 图），节点 O5 归属于组织 O5，也被定义为排序器。创始组织（O5）使用网络配置 NC05，并为区块链网络配置了一个排序服务（Ord05）。这个设置为创始组织（O5）在区块链网络（ProductChain）上提供了完整的管理权限。组织 O5 的 CA 是 CA O5。该 CA 向创始组织（O5）的网络节点管理员颁发证书：

• 从本质上讲，排序服务由创始组织（O5）或云平台管理员托管，并由 O5 进一步管理和管理。网络配置文件 NC05 定义了组织 O5 在业务网络上的权限和特权信息。

• CAs 是 HLF 的核心。HLF 提供了一个内置的 Fabric CA 以便快速启动。然而，组织可以使用自己的 CAs。不同的参与者使用证书在区块链网络上进行身份识别。在这个虚构的区块链网络（ProductChain）中，我们将定义五个 CAs，每个组织一个。

• 网络配置（NC05）使用称为 成员服务提供商（MSP）的结构，将由 CA05 发出的证书映射到 O5 组织的证书持有人。此外，NC05 使用 MSP 名称在策略中授予来自创始组织（O5）的参与者对区块链网络资源的访问权限。以识别来自 O5 的参与者为例，该参与者充当区块链网络的管理员，并进一步向区块链网络添加新的成员组织。

创始者添加其他管理员：创始组织(O5)通过更新网络配置(NC05)将生产者组织(O1)添加为管理员。此修改进一步定义O1为区块链网络的管理员。生产者组织利用其资源（节点）作为区块链网络的附加订货者(O1)。

第二步：定义联盟以实现交易的分离和安全性。其次，我们将看看如何定义联盟。它是两个或更多组织的关联，他们参与以实现共同的目标。在联盟中，每个参与的组织都有其自己的法律地位，并通过协议约定加入其中。这种联盟形成不同于第二章所定义的联盟，理解分布式分类账技术和区块链。在第二章中，理解分布式分类账技术和区块链，创始组织本身定义并拥有联盟，并且参与交易。在这里，创始者负责建立、维护和操作区块链网络的基础设施。它还提供了一个解决方案，各种组织可以融合并形成联盟和通道，并且可以进行交易。这样的配置可以允许云平台提供商管理业务网络，而无需参与其中。毕竟，联盟是一群志同道合的组织，致力于解决共同的问题。在这个过程中，他们在业务网络中利用自己的资源。在这个示例中，创始组织正在利用自己的基础设施，并且雇佣了几个节点作为订货者。在这个联盟中，以下内容适用：

• 创始组织正在利用自己的基础设施，并且雇佣节点P5(Ord O5)作为订货节点。

• 生产者组织O1（也被定义为网络管理员）定义了一个名为Consortium-X1的联盟，其成员为组织O1和组织O2。

• 联盟定义保存在网络配置（NC05）文件中。

第三步：定义通道：第三，我们将创建一个通道，允许联盟成员之间安全地进行交易。通常，这些通道被称为应用程序通道：

• 通道配置CCon1管理Channel-C1。Channel-C1是为Consortium-X1创建的。O1和O2都可以管理通道配置CCon1，并且他们对其拥有平等的权限。

• 通道配置(CCon1)完全独立于网络配置(NC05)，因此组织O5对通道配置(CCon1)没有控制权。然而，Channel-C1连接到订货服务(Ord 05)。

• 通道配置（CCon1）包含定义组织（O1 和 O2）在 Channel-C1 上进行交易权限的策略。其他组织，如 O3 和 O5，无法影响其上的交易。

向通道添加对等点：

• 向通道添加对等点，组织 1：对等点 P1 被生产者组织（O1）加入到业务网络中。这是因为该组织拥有对等点（O1 拥有 P1）。图中的对等点 P1 也托管分类帐 1（L1）的副本。很明显，P1 和 O5（对等点和订购服务）可以通过 Channel-C1 互相通信。

• 向通道添加对等点，组织 2：同样，对等点 P2 被零售商组织（O2）加入到通道中，该组织拥有对等点 P2。对等点 P2 也托管分类帐 1（L1）的副本。很明显，P2 和 O5（对等点和订购服务）可以通过 Channel-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）相关联。

• 功能：在启动时，对等点（P1）向订购者（Ord O5）发送请求。订购者（Ord O5）通过参考通道配置（CCon1）验证来自对等点（P1）的请求。这种验证解锁了关于P1在通道（C1）上的权限（访问控制）的信息。它有助于确定对等点（P1）可以在分类帐 1（L1）上执行的操作（读/写）。对对等点 P2 也是如此。

添加链码并允许应用访问分类帐：在这个示例中，创始人并未完全提供 dApp。dApps 是由组织单独构建的。

但是，它们使用 SDK、REST API 和其他集成方法来连接业务区块链网络并执行交易：

• 生产者组织（O1）拥有应用程序（O1App1），零售商组织（O2）拥有应用程序（O2App2）。这些应用程序与链码（智能合约）集成，定义为图表中的链码（SC1）。链码（SC1）部署在对等方 1（P1）和对等方 2（P2）上，并允许 dApp（O1App1和O1App2）访问分类账 1（L1）。所有参与实体，如应用程序（O1App1和O2App2）、对等方（P1和P2）和订购服务（O5）都使用 Channel-C1 进行通信（交易）。

• dApp（O1App1和O2App2）也被称为客户端应用程序。它们也与组织（O1和O2）关联的身份。链码（SC1）定义了操作，应用程序（dApps）可以与链码集成，以执行允许访问分类账（L1）的事务。应用程序（O1App1和O2App2）对分类账（L1）的访问完全由链码（SC1）操作管理。

  • 链码是由组织的（O1）开发团队开发的，并由财团团队（X1的成员，如O1和O2）审查和同意。然而，在部署到对等方之前，财团对链码的共识是必需的。

链码及其阶段

链码有四个阶段 —— 安装、初始化、定义背书人和允许事务。接下来对这些阶段进行了详细分析。您也可以将它们与示例联系起来：

• 已安装：在与链码（开发和测试）相关的共识事件中，组织（O1）管理员可以在对等方节点（P1和P2）上部署（安装）链码（链码）。尽管安装了链码的对等方可以完全访问和了解链码，但客户端应用程序（dApp）仅限于调用事务。有趣的是，仅在通道上安装链码并不能使客户端应用程序（O1App1和O2App2）能够针对链码（SC1）发出事务。这只有在链码初始化时才能发生。

• 已启动：到目前为止，链码仅安装在对等方（P1和P2）上。因此，除了对等方（P1和P2）之外，其他通道参与者不知道它。生产者组织（O1）将在通道（C1）上启动链码（SC1）。一旦在通道上启动了链码，其他通道参与者，如 dApp（O1App1和O2App2）可以调用链码（SC1）。此外，只有已安装链码的对等方才能访问链码逻辑。然而，链码逻辑对其他组件不可访问，但可以调用链码的操作。

• 背书：参考前述架构：概念视图图，清楚地表明组织（O1和O2）是X1 联盟的一部分。它们定义了通道（C1），通道由通道配置（CCon1）管理。话虽如此，背书策略（EP #1）也是通道配置的一部分，CCon1。当链码启动时，背书策略（EP #1）附加到通道配置（CCon1）。正是背书策略决定了账本（L1）上交易的接受。只有通道（C1）上的组织（O1和O2）批准时，交易才能被接受。

• 调用：仅在实例化之后，客户端应用程序才能将交易提案发送到对等体（P1和P2）。交易提案类似于链码（SC1）的输入，这将导致对等体节点P1和P2向客户端应用程序，O1App1和O2App2，分别发送一个背书交易响应。这将在本章的交易流程部分进一步讨论。

参考图，组织 1（O1）和组织 2（O2）在对等体P1和P2上安装了链码，这些对等体分别由O1和O2拥有。然而，由于链码由O1初始化，组织O2不需要初始化链码，因为它已经由O1初始化。此外，流言协议允许对等体相互通信。

对等体类型

对等体可细分如下：

• 强制性对等体：背书对等体和非背书对等体，也称为提交者和领导对等体。

• 可选对等体：锚对等体。这些是可选的，区块链网络可以在没有它们的情况下运行和存在。

以下是可用的不同类型的对等体：

1. 背书对等体：前一节详细介绍了背书对等体。参考架构：概念视图图，对等体（P1和P2）由组织（O1和O2）的管理员安装了链码。因此，它们可以背书交易，并被称为背书对等体。

2. 非-背书对等体（也称为提交对等体）：参考前面的图表，属于组织O1的对等体P4没有安装链码。组织 1（O1）的管理员选择仅在P1上安装链码，而不在P4上安装。这突出了两点：

   • 首先，组织管理员可以选择性地在对等体上安装链码。

   • 其次，已安装链码的对等体称为背书对等体，而没有安装链码的对等体可以存在于通道上。这些对等体（P4）是非背书对等体（称为提交对等体）。通道上的每个节点都是一个提交对等体：

     • 像P4（非背书对等体，也称为提交对等体）这样的对等体不能生成交易。然而，他们可以接受或拒绝要附加到账本（L1）的交易。

   • 安装了链码的对等体可以生成交易并背书交易。

   • 提交对等体接收交易块（由背书对等体发起的交易）并在提交到账本的本地副本之前进行验证。这样一次对账本副本（L1）的提交（背书者和提交者）构成了对账本的追加操作。

请记住，链码的背书政策（EP #1），存在于通道配置（CCon1）中，规定了一个组织的哪些对等体在被附加到通道账本（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）添加了一个对等体（P3），并拥有不同的账本（L2）。账本的范围限定在通道内，因此，通道-C1拥有账本L1，而通道-C2拥有账本L2。链码SC2被安装并在通道-C2上初始化，并且组织O3的应用程序（O3App3）使用通道-C2来调用针对链码SC2的交易。

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

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

逻辑上，通道配置（CCon1和CCon2）似乎是通道（C1和C2）的单一配置。在实践中，通道的对等方承载了通道配置的副本。从逻辑上讲，网络配置NC05似乎存在于区块链网络的单个文件中。但实际上，它被复制到区块链网络的所有订购节点上。

当管理员配置网络和通道时，他们向区块链网络发出配置事务。这些事务由组织（组织管理员）进行数字签名，如修改策略（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 将基于链代码 SC1 在 Channel-C1 上进行交易，并将使用 Channel-C1 与同行 P1、P2 和排序者 O5 进行通信。应用程序 O3App3 将基于链代码 SC2 进行交易，并使用 Channel-C2 与同行 P3 和排序者 O5 进行通信。这清楚地展示了精确的去中心化，在这种情况下，不同组织可以执行它们特定的交易并将区块存储在自己的账本上。

当节点加入多个通道时的行为

生产者组织（O1）希望为联合体X1和X2分别拥有单独的应用通道C1和C2。这将允许O1与这些通道上的组织进行私密交易。因此，图表显示了O1的对等方P1，并且还在P1上安装了链码SC2。组织01的客户应用程序（O1App1）现在将能够根据链码SC2中定义的逻辑在通道-C2上进行交易。

节点的行为，作为多个通道的一部分，由该通道的通道配置控制。通道配置CCon1和CCon2分别定义了节点（P1）在加入多个通道C1和C2时可用的操作。同样，应用程序O1App1现在可以根据链码SC1和SC2在通道C1和C2上执行交易，这也是由通道配置CCon1和CCon2决定的。

Hyperledger 架构（分层视图）和组件

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

架构：分层视图

身份、安全和隐私

本节涵盖了与身份、安全和隐私相关的区块链架构方面的内容。区块链网络中有各种参与者，如节点（提交者、认可者等）、dApps 和客户应用程序，以及网络和通道管理员。这些参与者中的每一个都需要建立身份，因为这些参与者的身份决定了它们在区块链网络及其资源上的访问权限。原则是一组身份和属性，其中身份是用户 ID，属性包括其所属的组织、其所属的角色等。因此，很明显权限是由身份的属性决定的。

HLF 使用 X.509 证书进行身份验证。然而，MSP 验证身份并确定这些身份是否被允许进入区块链网络。从高层来看，MSP 拥有规则，这些规则使得区块链网络中的身份生效。但是，这些身份必须经由公钥基础设施进行信任和验证。

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

公钥基础设施

公钥基础设施（PKI）确保区块链网络中各参与者之间的安全通信，并验证发送到区块链网络的消息。PKI 包括 CA，负责向参与者（用户、节点等）发放数字证书。参与者根据这些证书进行身份验证，然后将消息发送到区块链网络。

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

以下是 PKI 的一些关键元素：

• 数字证书

• 密钥

• CA

• 证书吊销列表（CRL）

数字证书

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

这里是关于证书的一些简要细节：

• 证书中有什么？证书就像身份证，包括以下证书数据：

  • 算法信息（如 SHA256）

  • 发行者信息，包括证书的有效期（时间）

  • 包括以下信息的主体信息：

    • 主体详细信息，例如组织单位

    • 主体公钥和签名算法详细信息

• 证书的主体（用户或节点）可以使用该证书证明其身份。

• 为了证明他们的身份，主体可以使用私钥对发送到区块链网络的任何通信（交易等）进行签名。主体的公钥包含在证书本身中。但是，主体的私钥是保密的和私密的。

• 证书中包含的所有信息都以一种加密方式进行加密，任何对其的更改都将标记证书为无效。

• 主体使用他们的私钥签名，并使用此证书证明他们的身份。由于其他各方信任身份提供者，也称为 CA，因此互动方可以信任主体。各方信任 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 类型如下：

• 根 CA 是大公司，如 Symantec，它们自签自己的证书，然后将这些证书发放给其他 CA。中间 CA 是由根 CA 或其他中间 CA 发放证书的 CA。这导致了证书的 TrustChain（信任链）。使用 CA 的组织可以放心使用中间 CA，因为 TrustChain 将允许它们追溯证书回到根 CA。此外，TrustChain 限制了根 CA 的风险，这对于 TrustChain 的安全性视角至关重要。此外，参与区块链网络的各种组织可以使用不同的中间 CA，并且可能有不同的或相同的根 CA。

• HLF 提供了一个内置 CA，称为 Fabric CA，它是 HLF 区块链网络的根 CA。它是 Fabric 区块链网络的私有 CA；它不能为浏览器中使用的 SSL 证书提供服务。因此，组织可以为其 HLF 区块链网络使用商业公共根和中间 CA。HLF CA，也称为 Fabric CA，的功能如下：

  • HLF CA 可以注册身份，也可以配置为使用现有的企业 LDAP 作为用户注册表

  • 对于成员组织、用户和管理员，HLF CA 可以为区块链网络发放、更新和撤销注册证书和根证书

• HLF CA 生成自签名的 X.509 证书，可以有一个或多个 Fabric CA，其中一个是根 CA，其余是中间 CA，遵循 PKI 的信任链。

CRL

CA 可以吊销证书，吊销的证书不构成过期的证书。在身份受到威胁的情况下，可以吊销证书，并将其放入称为 CRL 的列表中。建议任何想要验证其他方（主体方）身份的一方首先参考 CRL，检查该方（主体方的）的证书是否包含在吊销列表中。

成员服务

我们现在知道 PKI 为参与者提供了可验证的身份。但是，这些参与者如何在区块链网络上代表自己作为参与组织的受信任参与者呢？每个组织都在单个 MSP 下管理其参与者。但是，如果组织想要管理参与者的不同组织单位（OU），如财务和法律单位，组织可以拥有多个 MSP。如果您检查由 CA 发布给主体的证书，它将包含 OU 信息。这允许根据 OU 进一步控制对频道的访问。

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

• 身份验证：HLF 使用 PKI 验证用户和设备的身份。

• 授权：HLF 使用基于角色的访问控制（RBAC）来控制对实体的访问，例如控制身份对实体（例如分类帐）的读写访问。对于给定资源的身份的访问控制基于 RBAC，其中身份被分配给角色，为资源定义了授权策略，并定义了确定哪些角色有权访问资源上的什么的规则。

MSP

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

• 它注册和列出网络和通道参与者

• 它将证书映射到成员或参与组织

• 对于一个组织，MSP 确定一个参与者可以扮演的角色（行政等）

• 它定义了参与者的网络和通道以及访问权限，例如读和写

其主要活动如下：

• MSP 确定了根 CA 和中间 CA，后者可以进一步定义域的成员，也称为组织，要么通过列出其用户的身份，要么通过授权 CA 为其成员分配有效身份

• MSP 代表一个组织，并且还负责网络的 RBAC 和该组织成员的通道

• 一个组织可以有一个或多个 OUs，并且注册证书（X.509 证书）在证书中包含一个 OU 属性，以定义该组织的业务领域

MSP 的类型

在本节中，我们将介绍 MSP 的类型。大体上说，有三种——网络 MSP、通道 MSP 和本地 MSP：

1. 网络 MSP：网络级别的 MSP 用于定义被授权执行网络级别管理任务的区块链网络，例如维护网络和创建通道：

   • 范围：网络级别

   • 职责：定义通道等管理活动

2. 通道 MSP：通道（也称为全局）MSP 在通道配置中定义。然而，每个节点都有一个本地副本的通道/全局 MSP，通过共识保持同步。通道上的每个参与组织都有一个定义好的 MSP，该通道上的所有节点都将共享该 MSP，因此，将能够使用相同的身份验证单一真相源对通道参与者进行身份验证。因此，任何新的参与组织首先需要将其 MSP 添加到通道配置中，以便在通道上进行交易。通道 MSP 主要用于身份验证，不需要对交易进行签名。通道的所有成员都熟悉 MSP 的配置，其中该组织的成员参与。这被称为通道 MSP：

   • 范围：通道级别

   • 职责：通过定义通道级别实体的管理和参与权限来建立信任链

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

   • 范围：每个节点都有一个定义该节点权限的本地 MSP

   • 职责：对成员消息进行身份验证并在网络和通道级别之外定义权限，并在本地应用配置时维护 MSP 的本地副本

   • 事实：

     • 诸如提交者、背书者和订购者之类的节点被称为本地 MSP。例如，定义对等方管理员等。

     • 客户用户等用户使用本地 MSP 对其在通道上执行的交易进行身份验证。

     • 参与组织的成员身份由作为本地 MSP 一部分的根 CA 或中间 CA 确定。

   • 结构：以下列表定义了构成 MSP 结构的各种元素。对于每种类型的元素，都有一个子文件夹，本地 MSP 存储在本地文件夹中作为文件夹，位于该特定子文件夹内。

     • 就结构而言，本地 MSP 包括以下各种元素：

       • 根 CA 和中间 CA：根 CA 包含由 MSP 中代表的组织信任的自签名证书（X.509 标准）。中间 CA 包含由组织信任的中间 CA 证书列表。

       • 组织单位：这是一个可选元素，包含一个 OU 列表，用于限制组织成员。

       • 管理员：这包含了作为组织管理员的参与者的身份。这类似于定义角色。然而，访问权限（例如添加新组织等）由系统资源确定，例如通道配置或网络配置策略。CA 发布证书中的角色属性还定义了参与者在组织中的角色，而不是在区块链网络上的角色。是系统资源（通道、网络等）策略定义了该角色在区块链网络系统资源上的权限。

       • 吊销证书列表：逻辑上，这个可选列表与 CAs 和 CRL 是相同的列表。然而，它还定义了参与者从组织中的吊销资格。

       • 节点身份：这是一个强制性元素，定义了节点的身份。应该存在于本地 MSP 中，以及 KeyStore（私钥）和节点身份，允许节点（如背书人等同行）在网络或通道上发送的消息中对自己进行身份验证；例如，背书人作为响应交易提议的一部分发送的证书。

       • 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）特权；例如，将P1定义为来自组织 1（O1）的区块链网络管理员。参考以下 MSP 图表，每个对等方在其文件系统中都有自己的本地 MSP 副本。此外，每个对等方都保留其所属通道的全局 MSP 的副本；例如，对等方P1属于Channel-C1和Channel-C2。因此，尽管它有自己的本地 MSP，但它还包含对通道 1 和 2 的通道配置CCon1和CCon2的副本。通道配置的本地副本也意味着全局 MSP 的本地副本。因此，P1拥有Channel-C1和Channel-C2的全局 MSP 的副本。

每个对等方的信任域是其所属的组织，这是对等方本地 MSP 的一部分。然而，为了让该组织（以及其对等方）能够在通道上进行交易和通信，组织的 MSP 需要添加到通道配置中：

成员服务提供者

该图表还显示用户 A 属于组织 1（O1），用户 A 的身份由CA01（组织 1 的 CA）颁发。属于O1的对等方 1（P1）的本地 MSP 副本包含用户 A 的身份信息。根据用户请求的操作类型（本地或通道级别），对等方将验证用户 A 的身份。鉴于对等方P1、P3和P4位于Channel-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 通道实现的。区块链业务网络中的交易在通道上执行，在该通道上，交易各方经过验证和授权，可以在该通道上执行交易。默认情况下，网络中的所有参与者都属于一个通道。但是，对于私有交易，组织需要创建单独的通道并将成员授权给该通道。账本从通道到通道分开，因此账本数据无法在通道之间移动。通过通道将账本数据和对等方分开，允许在仍然属于同一区块链网络的组织之间进行私有和机密交易。通道之间的数据分离是通过配置成员服务、链码和八卦协议实现的。这里的数据包括交易信息、账本状态和通道成员资格。这些数据仅限于那些经过验证的通道成员对等方。

客户端 SDK 将参数（例如渠道内唯一的 MSP ID、策略和成员（组织））传递给网络配置链代码。此调用会在网络配置链代码上创建配置交易。这些有版本的配置交易（configtx）导致在渠道分类帐上创建创世区块。此创世区块记录诸如渠道配置之类的信息。一旦将成员添加到渠道中，它就可以访问创世区块上的相关信息。

参与者在渠道设置完成后可以部署链代码。然后，参与者可以提出交易、认可、排序和验证交易。访问权限由参与者的 MSP 授予，并且这些权限定义了参与者在渠道上的限制。渠道外的参与者无权访问渠道上的任何交易或消息。因此，根据其渠道对交易进行隔离增强了区块链网络提供的隐私。

PDC

我们知道渠道在组织之间促进了私人和机密的交易。但是，如果您希望在一个渠道上有几个组织，但仍然希望将一些数据保留给参与该渠道的组织的子集，该怎么办？渠道有优势。然而，如果您不断创建在需要私人通信的组织之间的多个渠道，则可能会导致渠道爆炸，这将增加维护开销。您必须维护 MSP、策略和链代码版本，这不允许我们解决在渠道中为一些组织的子集拥有私人数据的用例。为了解决在渠道中允许一些组织的子集拥有私人数据的挑战，HLF（从 v1.2 开始）提供了创建 PDC 的功能。

PDC – 更多渠道隐私

有了 PDC，组织的子集可以在一个渠道内查询、评论和认可私人数据，而不需要创建单独的渠道。

参考下图，节点P1属于组织O1，P3属于组织O3，节点P7属于组织O4。在这里，P1，P3和P7都在Channel-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）。链码（SC2）在通道（C2）上 被实例化；因此，链码（SC2）中的所有智能合约对通道（C2）上的应用程序都是可用的。这些私有状态将从想要进行私有通信的组织的所有节点复制到所有节点。被授权的节点将能够看到数据的哈希值，这些哈希值位于主分类账中，而真实的私有数据将存储在它们的私有数据库中。由于私有数据未与未经授权的节点同步，它们永远无法看到私有数据。但是，主分类账的数据哈希值对它们是可见的。

PDC 是遵守通用数据保护条例（GDPR）的绝佳方式。其中一个规定是数据所有者可以删除私有数据。但是，我们知道区块链是不可变的，一旦数据被记录到分类账上，就无法被删除。使用 PDC，私有数据仍然保留在您的私有数据库中。它不会被写入分类账。只有数据的哈希值被写入分类账。

在技术上，PDC 得到两个关键元素的支持：

1. 私有数据库：在每个节点上也称为 SideDB，并参与私有数据通信。您将回忆起本章中讨论的锚定节点。由于排序节点不参与私有数据通信，需要为点对点通信通过八卦协议设置锚定节点。

2. 数据哈希： 哈希值位于当前状态的主分类账中。它作为交易的证据，无法被移除，且无论节点是否涉及到 PDC，所有通道中的节点都能访问它。

分布式账本

本章涵盖了与分类账特定的区块链架构方面。它还涵盖了节点，如节点和排序者，并且在定义排序者时，我们也将涵盖交易流程。

节点

HLF 的部署视图包括连接为点对点网络的节点，这些节点共享分布式账本。节点在 HLF 中可以担任不同的角色——节点和排序者。

节点： 提议交易，保存/应用并提交交易，并维护分类账的本地副本。

节点的类型如下：

• 认可同行，也称为认可者: 从客户端/应用程序获取交易提案，验证客户签名，获取将受交易影响的世界状态的 RW 状态，并将这些状态发送给排序器。

• 提交同行，也称为提交者（非认可节点）: 在认可和排序之后，对交易进行验证，将交易结果应用于本地分类账。这将提交到分类账，并且交易变得不可更改。

在 HLF 中，每个认可者节点也是一个提交者节点。但是，并非每个提交者都需要是认可者节点。

• 排序器: 区块链网络中至少需要存在一个排序器。排序器确保交易的正确排序。

同行

同行构成了一个区块链网络，托管分类账和链码。我们在架构的概念视图中看到，每个同行都有链码和分类账的副本。同行提供 API，允许应用程序与其互动，也允许启动、停止、配置、删除和重新配置同行。一个同行可以托管一个分类账和链码，同行也可以只托管分类账而不托管链码（应用程序链码）。同行通常始终具有系统链码。HLF SDK 提供 API，允许应用程序与同行互动，因为需要查询分类账或在分类账上调用交易时，应用程序会连接到同行。然后，同行调用链码来执行该交易。

与排序器一起，同行确保每个同行上的分类账同步。我们将在后续部分介绍交易流程，重点突出同行的参与。以下是该内容的简要概要:

• 应用程序（希望执行交易的一方）连接到一个同行。当应用程序和同行来自同一组织时，证书由组织的 CA 发放。

• 同行调用链码，导致生成提案响应。响应取决于应用程序的交易请求。例如，如果应用程序请求对分类账的查询，那么提案响应将包含查询结果，或者如果应用程序请求对分类账的更新，那么提案响应将包括提议的分类账更新。

• 应用程序从同行接收提案响应:

  • 如果是一个查询（分类账查询交易），那么流程已经完成，因为应用程序已经收到了响应

  • 如果是一个分类账更新（分类账更新交易），请求随后进入下一步

• 对于分类账更新请求（分类账更新交易），同行不能将响应发送，因为首先所有参与同行都需要同意更改分类账。这改变分类账的一致性称为共识。

• 由于对于账本更新事务需要共识，节点会向应用程序返回一个建议的更新响应，实际上是对节点提出的更改的快照。这类似于只有在达成共识后才对账本进行更改。

• 应用程序收到响应。应用程序将从所有响应中构建一个事务并将其发送到订购者节点。

• 订购者将从区块链网络收集此事务和其他各种事务，并将它们编译成一个区块。

• 接着，订购者将把这个区块分发给所有的节点（提交者），其中也包括应用程序（在这个示例中）发送初始请求的节点。

• 所有的节点，包括当前上下文中的节点，都将验证该事务。

• 在成功验证事务后，节点将更新账本的本地副本。

• 一旦账本更新完成，发送初始请求的节点将生成一个事件。

• 这个事件将被应用程序接收，标志着更新事务的完成。

我们在架构 - 概念视图部分看到，节点由各种组织拥有和贡献，并且这组节点形成了区块链网络。通常由组织开发的应用程序通常连接到该组织的节点。

区块链网络并非真正依赖于组织及其贡献的节点。然而，至少应存在一个组织和一个节点。有趣的是，组织节点（属于任何组织）托管相同的账本；然而，每个组织都可以自由使用其自己的代码语言来构建应用程序和演示逻辑。

从架构：概念视图图中，我们知道节点连接到通道。通道还具有通道配置并包含全局 MSP。该全局 MSP 有助于将节点映射到其组织，因为发给节点的证书来自该组织的 CA。例如，参考本章中的MSP图。这里，节点P1'的证书由 CA（CA O1）颁发。通道配置（CCon1）确定身份（参与者如P1）是由 CA（CA O1）颁发的，这来自组织 1（O1）。这在O****1中定义。MSP 包含在通道配置的全局 MSP 中。这有助于将节点与组织关联起来。

每个节点都有由组织的 CA 颁发的数字证书。该数字证书充当节点的身份。

在特定的时间点，一个同行只能属于/被一个组织拥有。同行可以随处存在；在本地计算机上，在企业内部，云上等等。是同行的证书（身份）将其映射并与一个组织相关联。这种映射由 MSP 提供。除了通过 MSP 对用户进行认证外，通道配置还涉及访问策略，确定对同行（同行的身份）分配的特权。这方面的详细信息可以在MSP部分找到。不过，简而言之，身份与组织的映射由 MSP 定义，并确定了在该特定组织中分配给同行的角色，以及分配给该身份的权利（特权）。

订单者和交易流程

在区块链网络中，订单者维护分类帐的同步性和一致性。我们已经看到了关于分类帐更新交易的细节，该交易需要网络中的所有参与同行达成一致以批准对分类帐的更新。从其他同行那里获得批准以更新分类帐的同意过程称为共识。一旦交易得到所有同行的批准，它就会提交到分类帐，并且客户端应用程序也会得到提交的成功更新（对分类帐的更新）。以下是*分类帐更新交易**的各个阶段：

• 提案：这是客户端应用程序将交易提案发送到通道同行的阶段

• 认可：这是模拟交易的阶段

• 打包提案响应：在这个阶段，每个认可者将其签名的认可返回给客户端

• 验证并发送给订购者：在这个阶段，客户端应用程序验证提案响应并发送交易消息给订购者

• 分发：在交易过程的这个阶段，订单者将区块分发给同行

• 验证和标记：在这个阶段，同行会收到来自订单者的区块，并将其标记为有效或无效

• 通知：当分类帐被附加时，客户端应用在此阶段会收到通知

我们稍后将详细讨论无处不在的共识部分的交易流程。

分类帐

正如我们在第一章中发现的，探索区块链和 BaaS，会计分类帐记录了记账的交易历史，而报表显示当前余额。所有的借贷记录导致了当前余额。现在，让我们建立类比，当前余额就是分类帐的当前状态，借贷记录就是交易日志条目。当前状态和交易日志一起形成了一个分类帐；一个区块链分类帐。在分布式分类帐上进行交互（也称为交易），需要调用链码：

• 当前状态：也称为世界状态或只是状态，这是一个键值对，显示了分类帐状态的当前值，随着状态的创建、追加或删除而经常变化。

• 交易日志：这是导致当前世界状态的更改集。经过排序和序列化的交易追加到区块链上。一组交易导致了当前世界状态的值。一旦排序和序列化，这些交易就不能被修改，因此，区块和区块链，也称为分类帐，变得不可变。

分类帐是分布式的；因此，它位于所有节点上。我们已经在交易流程中看到，需要在将交易提交到分类帐之前达成共识。因此，分类帐与参与节点保持同步。

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

分布式分类帐 = 世界状态 + 交易日志

以下图表显示了由世界状态和交易日志组成的分类帐。交易日志包括各种区块，每个区块包含一个或多个交易：

分类帐状态和交易日志

这个示例展示了一个名叫诺亚的男孩的存钱罐。世界状态和交易日志在开始时是空的。这由创世区块（B0）表示。区块 B1 包括交易 T1，其中爸爸存了 10k，即向存钱罐充值。这就像是向爸爸的账户借钱。第一笔交易由区块 1（B1）表示。区块 1 表示分类帐状态，其中Key为存钱罐，Value为10000。此外，它还有分类帐状态，其中Key为爸爸存入银行，Value为10000。两个分类帐状态都是在版本 0。版本 0表示这是一个起始版本号，并且自创建以来它们还没有被更新过。

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

诺亚的妈妈和诺亚从存钱罐中取钱。区块B2包含交易T2和T3。这里，T2代表交易，妈妈取了 2 千，即存入妈妈的账户，T3代表一笔交易，诺亚取了 2 千，即存入诺亚的账户。存钱罐被扣除了 4 千。同样，区块 B3包含交易 T4，其中妈妈存入 1 千，即从妈妈的账户扣除 1 千，同时存入存钱罐1 千。同样，区块 B4包含交易 T5，其中诺亚取了 3 千，即存入诺亚的账户。在这个状态下，存钱罐显示了存钱罐的最新当前状态，即 4 千。因此，当前状态代表了存钱罐的当前世界状态。即使世界状态被损坏并且与当前状态相关的信息被破坏，按顺序重放交易将有助于创建当前世界状态。

世界状态数据库

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

• 相似之处:

  • 两者都可以存储二进制数据。

  • 两者都支持链码操作，如get和set。这就是get和set实质上是获取和设置资产（键的值）。

  • 两者都支持范围查询，其中键通过范围查询。

  • 两者都支持复合键；例如，资产 ID 和所有者 ID 的组合可用于获取特定所有者拥有的所有资产。

• 不同之处：今天的业务应用将资产建模为 JSON。因此，CouchDB 允许应用程序执行丰富的查询到链码，其中资产是以 JSON 模型化的，使用 CouchDB 的 JSON 查询语言：

  • LevelDB 是默认数据库，并与节点共存，主要嵌入在同一操作系统进程中。

  • CouchDB 在单独的操作系统进程上运行。但是，它与网络节点和 CouchDB 实例之间维护一对一的关系。

• 推荐：

  • 当状态为简单键值对时，推荐使用 LevelDB。

  • 当状态结构为 JSON 时，建议使用 CouchDB。

  • 可以从 LevelDB 开始，然后转到 CouchDB。但我个人建议将资产数据建模为 JSON，因此使用 CouchDB。

  • CouchDB 推荐使用索引，其中索引可以与链码一起打包在不同的目录中。当链码安装并在对等方上启动时，索引也会部署到通道和链码的状态数据库，也称为 CouchDB。

• 关键特性-可插拔：HLF 有各种可插拔的组件，数据库就是其中之一。企业可以选择关系数据库、图形存储或临时数据库作为世界状态的数据库。

区块链代码

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

所有节点都协调一致，以获取智能合约的最新副本。

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

区块链代码（及其智能合约）：这是一个分布式计算机程序，可在 HLF 区块链网络上使用。在 PiggyBank 示例中，正是这个区块链代码使资产（美元）在账户之间进行转移，而无需第三方或中介的参与。爸爸、妈妈和诺亚能够在没有第三方参与的情况下进行交易。

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

• Chaincode 部署交易：用户通过参与节点授权一个 chaincode（使用 Golang 或类似语言）并使用 HLF SDK 向区块链网络发出部署交易。部署 chaincode 的权限被定义为访问控制，并由 HLF CA 发布 ECert。Chaincode 在安全的 Docker 容器中运行。

• Chaincode 调用交易：dApps/客户端应用将使用 SDK 通过发出一笔交易来提议更改账本的世界状态，从而调用 chaincode。应用程序通过传递 chaincode 函数中定义的函数名和交易参数来调用 chaincode 的 invoke 函数。可以使用命令行或通过 SDK 对 chaincode 的 invoke 函数执行查询交易。然而，在此 invoke 函数调用中，没有提案来更改账本的世界状态。

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

处处共识

从其他对等节点收到批准以更新账本的协议过程称为共识。共识确保以下内容：

• 它确保账本交易在整个区块链网络中同步

• 它确保只有有效和批准的交易被附加到账本上

• 它确保附加的交易遵循由订购者设置的相同顺序

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

共识不仅仅意味着建立交易顺序。在 HLF 中，共识在交易流程中扮演着重要角色——从提案到背书，到排序，验证和附加。在整个交易流程中，身份验证发生在各个阶段。这是一个持续进行的过程。背书人和对等方对有效载荷进行签名，然后有效载荷在整个交易流程中反复验证和认证。为了达成共识，重要的是确保交易的顺序以及交易是否符合背书政策。在提交之前，确保获得足够的背书并且交易通过版本检查是至关重要的，在提交到总账（账本）之前，必须达成当前状态一致。版本检查是针对双重支付和其他数据完整性威胁的检查。

交易流程图和过程流程是正在进行的共识过程的表示。

对我来说，整个交易流程就是一个共识过程。如果您查看以下交易流程，对交易顺序和交易内容进行协商一致。这是通过经历交易流程的各个阶段完成的。在幕后，SDK 管理整个共识过程，当过程结束时，在通知阶段客户端会得到通知。

通道（应用通道）包含有关共识选项和排序组织的详细信息。例如，通道配置有一个名为 Kafka broker 的参数。如果设置为ConsensusType为 Kafka，那么它将被设置为通道的订单作为共识算法。通常在区块链网络引导过程中建立，并且一旦在通道配置和区块链网络中配置完毕，那么就无法通过配置更改。另外，要注意 MSP 也通过共识进行同步。共识是顺序服务，当您浏览以下部分的交易流程时，您将对此有更清晰的了解。

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

交易流程

通过订单节点维护分类账的同步性和一致性。在批准对分类账的更新之前，需要达成共识。只有在所有对等方批准后，分类账才会更新。这是交易流程的一部分；在本节中将详细介绍。

以下图显示了交易流程：

交易流程

以下是交易流程的阶段：

提案：客户端应用程序向通道上的对等方发送ledger-update-transaction。参考前面的图表，客户端应用程序O1App1在Channel-C1上发送（提出）一个交易。当链码安装和启动时，将向通道配置（CCon1）添加背书策略。通道（C1）的背书策略规定组织O1和组织O2必须批准交易。因此，当提出交易时，它会发送到通道（C1）上的背书同行，这些同行属于组织O1和组织O2。参考图表，它发送到P1和P2，因为这些对等方也是组织O1和O2的背书同行。

从技术上讲，应用程序使用 API 生成交易提案。交易提案类似于对执行链码函数的请求，以便读取/更新分类账数据。在这里，应用程序使用 SDK（Node、Python 或 Java）和 API 之一来提出这样的交易。SDK 将负责将交易提案打包成一种架构格式（例如通过 gRPC 的协议缓冲区），并使用用户的私钥向交易提案添加数字签名。

背书（模拟提案）：客户端应用程序向通道上的对等方发送一个ledger-update-transaction。这些对等方是背书同行。请注意，对等方既可以是背书者，也可以是提交者。在这个阶段，不会查询订单节点，也不会参与其中。涉及以下步骤：

1. 应用程序生成交易提案并将其发送给背书同行。

2. 通道将根据背书策略确定背书对等方，然后将该交易提案请求路由到选择的背书对等方：

我使用了“选择”这个词，因为链码的背书策略将决定通道上的所有背书对等方是否需要背书一个交易提案请求。

1. 每个背书对等方都有分类账和链码的本地副本。他们将根据交易提案请求执行链码，并生成一个交易提案响应。

2. 每个背书对等方都会验证交易提案是否格式良好，并且以前未提交过。

3. 提交者的签名由 MSP 验证，授权检查以确保客户应用程序有权限在通道上执行交易（读/写）。在通道创建期间定义诸如写策略之类的政策，并有助于确定用户执行/提交交易到通道的资格。

4. 每个背书者将生成一份交易提案响应。他们还将使用他们的私钥对交易提案响应进行签名（数字签名响应）。在这个阶段，帐本上没有任何更新。

5. 然后，每个背书者将向应用程序发送提案响应。对于一个交易，应用程序将会收到多个提案响应。

6. 由于不同的背书对等方在不同的时间生成响应，并且在这些实例期间账本状态不同，因此应用程序发送的交易提案响应可能存在不一致性。在这种情况下，应用程序可以执行以下操作：

   • 接受响应以允许交易过程继续到更进一步的步骤

   • 拒绝响应并终止交易过程

   • 发送另一个请求以获取更近期的交易提案响应

从技术上讲，每个背书者将使用交易提案输入作为链码的输入参数。每个背书者都将获取交易提案，并使用当前存在的链码执行提议的交易。这些链码执行不会导致账本的更新。它们只模拟交易。在模拟交易的同时，背书者将获取一个键和值的当前列表（账本的当前状态）和一个模拟的键和值列表（账本的即将更新状态），这将被写入账本。因此，有两组键和值（读集和写集）。这些值集，连同背书对等方的签名，被添加到发送给 SDK 的提案响应中，SDK 将进一步解析负载以供应用程序消费。

打包提案响应：客户应用程序将收到所有背书者的背书，并在接受交易提案响应后将其发送到订购者节点：

• 从订购者节点的角度看，许多应用程序将向其发送各自的交易提案响应。

• 订购者将把这些交易排序并打包成区块。这些区块就是区块链中的区块：

  • 订购者将等待一定时间，将该时间段内的所有交易打包成一个区块，或者如果满足了期望的区块大小，则该区块将准备好进行分发。

• 订购者也没有链码的本地副本，因此，他们在定义区块时不参考链码（做出评判）。

• 注意：在 HLF 中，交易的顺序并不重要。但是，无论它们以何种顺序被添加到块中，它们都将按照那个顺序被执行。

• 注意：HLF 中的交易只存在于一个区块中，而不是多个区块。这意味着交易在区块中的位置是最终确定的，并在此阶段得到了保证。

从技术上讲，每个背书者都会将其签署的背书返回给客户端（通过 SDK）。我们知道背书者已经获取了读取和写入集合。这些读取和写入集合是签署提案的一部分。

验证并发送进行排序：客户端应用程序将再次参与交易流程，并执行两项活动——验证提案响应，并且对于账本更新交易，客户端将连接到排序服务进行进一步处理。

验证提案响应：客户端应用程序将验证提案响应：

• 如果只是一个账本查询交易，客户端应用程序将验证提案响应并收集其响应。它将不会将其发送给排序服务。

• 如果这是一个账本更新交易，那么应用程序将验证背书策略中指定的所有背书对等体是否已经对交易进行了背书，并且它们是否都是有效的。序列如下：

  • 客户端应用程序将首先验证背书对等体的签名

  • 然后，它比较每个背书对等体的提案响应，检查提案响应是否相同。

即使客户端应用程序选择不检查提案响应，背书策略仍将由对等体执行，并将在交易最终提交时使用。

发送进行排序：在此阶段，客户端应用程序将交易消息作为一个捆绑包（交易提案和一个响应）发送到排序服务。这个交易消息包含以下内容：

1. 两组键和值（读和写集）

2. 背书对等体的签名

3. 交易要提交到的通道 ID

参考前面的图表，O5 和 O1 是排序者，它们配置了Channel-C1。因此，为C1准备的交易消息将被广播到O5和O1排序者。它们将对交易消息进行排序、排序并创建这些交易的区块。

技术上，订购服务从其连接和配置的所有渠道接收此类交易消息。订购服务将对这些交易进行排序和排序（按渠道按时间顺序），并创建交易区块（每个渠道）。订购者永远不会创建交易，并确保它们提供了可靠的交付。订购者类提供了客户端应用与订购者节点进行交互的功能。订购者节点具有两个公开的 API——broadcast()和deliver()，以及其在客户端应用程序和订购者之间具有双向流的 gRPC 流连接的 API。broadcast() API 使客户能够将交易消息发送到订购者，而deliver() API 允许客户/消费者查询有关通道信息和通道配置的信息。

分发：在交易过程的这个阶段，订购者将区块分发给对等节点。对等节点连接到区块链网络中的订购者。订购者将通过基于八卦协议的 P2P 通信将区块分发给每个连接的对等节点。

八卦协议：我想在这里稍微谈谈八卦协议，因为分发是使用八卦协议的阶段。订购者需要将交易消息分发给所有对等节点。然而，对订购者来说这是一个负担，而且在网络规模庞大时几乎不可能达到所有对等节点。HLF 框架为此提供了解决方案。订购者不会将消息传递给每个对等节点。订购者只会将消息传递给配置为领导对等节点的对等节点。对于每个组织，在通道上，有一个确定的领导对等节点。这些领导对等节点将这些消息分发给其他对等节点等。然后对等节点将这些消息转发给随机选择的一些对等节点。这个随机的对等节点数量是预先确定的，此转发过程将持续，直到消息达到所有对等节点。整个过程被定义为广播，广播过程依赖于八卦协议来分发交易消息。

广播是一种推送消息的方法。然而，如果对等节点从死亡状态转变为活动状态，则对等节点使用拉取方法保持最新。

节点引导：我们刚刚提到节点向预定义或预定的节点列表发送消息。这个确定是如何发生的呢？这通过节点引导（也称为引导）完成。当区块链网络建立时，每个节点都获得一组引导节点。之后，节点会检查节点的存活状态。如果引导节点死了，它将标记为死亡。但是它会定期检查节点是否存活/死了。如果一个节点死了，而后变得存活，它会错过广播过程中的信息。因此，为了获取最新信息，该节点将拉取信息，例如成员数据（节点的存活和死了状态）和账本数据（交易的区块）。

验证与标记：在交易过程的这一阶段，节点将从订购方接收区块。他们将对其进行验证并标记为有效或无效：

• 节点将选择并处理区块中的交易。选择和执行交易的顺序与订购方对交易排序的顺序相同。节点在此步骤不执行链码。链码仅在背书阶段执行，从而证实链码应该仅存在于背书节点上。

• 在处理交易时，每个节点都会验证交易是否按照链码中定义的背书策略正确背书，这实际上是由生成此交易的链码生成的。这确保了所有应该背书交易的组织都已经进行了背书，并生成相同的输出。

• 若验证通过，则表示正确背书，随后发生以下情况：

  • 节点执行一致性检查。此检查是为了验证当前账本状态是否与节点生成交易提案更新时的账本状态兼容。如果一致，则交易被标记为有效。如果不一致，则不被应用，并且交易被标记为无效，定义为一笔失败交易。例如，对一项数字资产提出了交易，生成了提案响应，并且由另一笔交易更新了。在这种情况下，提案响应时的账本状态和一致性时的账本状态不同，因此无法应用，因此被标记为失败。

  • 一旦节点验证了区块中的所有交易，那么区块中所有未失败的交易都会提交到账本：

    • 失败的交易不会提交到账本，但被视为成功并可用于审计。

从技术上讲，每个节点将区块追加到通道的链中，并且只有有效的交易被追加到节点本地账本的副本中（即追加到当前世界状态）。

通知：当区块提交到账本、节点和链码时，会生成以下事件：

• 对等方和链码生成以下事件：

  • 对等方生成：区块事件和交易事件。区块事件包含整个区块内容，而交易事件突出显示了交易是否被验证或无效（标记为失败）。

  • 链码生成：链码事件。

• 应用程序可以订阅感兴趣的事件并接收通知。这些通知帮助应用程序了解交易的最终阶段。

先前定义的交易流程清晰地展示了涉及交易的各个参与者，从客户端应用程序到背书人、排序器、提交者和领导者。本节还清楚地突出了排序器在区块链网络中的强大作用。每个对等方都会验证交易，并按照排序器在区块中定义的顺序和顺序进行操作。因此，排序器确保区块链网络的一致性。此外，它确保交易在区块中的位置永远不会改变，并因此为区块链网络中的账本引入不可变性。如果重新阅读先前定义的交易过程，可以明显地看出所有对等方都同意交易及其内容。排序器调节此协议过程，称为共识。

大对象存储 - 在链上或链外

本节讨论了在区块链网络上或链外存储大对象。本节是设计策略的一部分。然而，将此主题定位在这里更为相关，因为它是 PDC 的延伸并有助于实现它。

链上/链外架构的原理

区块链的核心是数据存储和检索，其中资产、账户、权限和交易被视为数据。但是对于诸如证据文件、X 光、图像扫描、视频和 PDF 格式的法律合同文件等文档呢？区块链应用应该把这些文档存储在哪里？存储文档的正确方法是什么？本章将讨论文档存储方法以及如何保留区块链属性（如不可变性），即使是在链外存储的情况下也可以实现。

有论点认为，将图像、PDF 文件和其他对象存储在链上作为区块链交易的一部分是有益的。这样做的原因是确保与任何其他区块链数据一样，不可否认性和不可变性也适用于这些对象。如果将文档存储在链外，并且仅包括 URL 或其他参考信息，则存在篡改的可能性和风险。当然，可以在链外存储中对图像进行加密。然而，存在未被检测到的篡改可能性，以及对管理文档的集中化第三方的依赖。

直接将图像和大文件存储在链上的反对意见涉及到由于大交易负载而对性能产生显著影响。有三个值得考虑的方面：

• 网络延迟，因为需要将大型（多个 MB 或甚至 GB）的负载发送到多个参与者的网络上

• 计算成本，因为在签署消息时必须计算这些消息负载的数字签名哈希，并在接收消息时验证。

• 发送消息时的 TLS 通道加密成本

• 存储成本，因为包含大型交易的区块存储在多个区块链节点上

简而言之，在设计区块链应用程序时，将大型对象包含在交易负载中的性能和成本影响应该是一个重要考虑因素。还可能存在潜在的保密性问题，特别是在受监管的情境中，例如美国健康保险可移植性和责任法案（HIPAA）对医疗数据的规定，欧盟《通用数据保护条例》对个人身份信息（PII）的规定，以及许多国家的类似法规。尽管在像 HLF 这样的许可企业区块链堆栈中，网络规模（以对等体数量为单位）、计算能力、网络带宽和存储可能更易获得，从而使可接受的负载大小更高，但由于企业应用的性质，保密性问题往往更加突出。

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

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

返回到区块链，将图像和文件作为区块链交易负载的一部分共享引发了各种限制，例如带宽、延迟（存储和检索图像所需的时间）、在各个节点之间重复信息以及由于区块大小的增大而给共识过程带来的负担。实际上，由于区块链架构的分布式和复制性质以及对网络延迟和 PKI 加密（用于数字签名及其验证）的关键依赖，反对在区块链上存储大尺寸图像和文档的论点甚至比反对在数据库 BLOB 上这样做的论点更加强有力。因此，论点最终不在于是否在链上存储文档，而在于当有必要时的尺寸限制以及应用考虑因素，以确保链上和链下存储一致，并且应用仍然可以从不可否认性和不可变性属性中获益，即使使用链下存储时也是如此。

在 HLF 事务流程中，客户端签署事务负载并将其发送到一个或多个对等节点以执行。将负载传递到链码执行容器后，对等节点会捕获链码的读写集（RWSets），如果它们要被存储在链上，则包括来自负载的对象。然后，对等节点对 RWSets 进行签名，这涉及对数据进行哈希计算，并将其发送到客户端。客户端必须验证签名，并在存在多个背书人的情况下，比较结果以确保它们匹配。然后，加密结果和所有签名被发送到排序服务，在那里消息被存储在 Kafka 主题中。排序服务节点（OSNs）随后必须就将这些交易消息定序到块中达成共识，这些块被发送到对等节点以进行交易验证和分类帐更新。对等节点会逐个处理每个交易，验证其他背书人的签名，并在声明交易有效之前将所有读取集数据字段的版本与当前世界状态数据库中的值进行比对，然后将块附加到分类帐，并使用写入集的值更新世界状态数据库。

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

关键设计原则

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

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

1. 在将文档记录更新到链上之前，请确保已收到文档成功存储到链外的确认。

2. 在检索文档时，首先从区块链检索文档记录，使用位置信息检索文档本身，然后计算并验证其哈希与包含在区块链记录中的哈希是否相符。

尽管可以在客户端应用程序中处理这些任务，但更有利的是使用一个提供内置到区块链的锚定的离链存储解决方案；也就是说，一个解决方案，每当创建、访问、更新或删除任何文档时都会自动在区块链上创建和更新记录。根据文档的性质，这可以是一个特定的内容管理/文档存储解决方案，或者是一个提供容器中未差异化的 blob 存储的通用对象存储解决方案。因此，涉及离链文档的交易将由这个存储解决方案处理，而这个存储解决方案将在链上创建不可变文档记录。这利用了区块链网络的不可变性，使用小型文档记录，而文档本身则存储在文档存储服务中。

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

区块链锚定对于所有权证书、教育证书、合规性报告、合同、有或无实体签名的文件、采购订单、具有税务影响的发票、提单和其他运输材料以及贸易协议等文档将是有益的。

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

这样的区块链锚定文档作为服务（BaDaaS）将管理两种类型的工件：存储在链下的实际文档或图像文件，以及文档属性，如唯一的文档 ID、内容散列、文档版本和其他元数据，记录并发布到区块链网络上作为不可变记录。涉及这些链下文件的任何活动都将作为区块链交易存储在链上，而相关的文档属性将作为其载荷存储在链上。

实质上，BaDaaS 提供以下类型的 API：

1. 通过调用POST进行文档上传的 API，或者通过PUT进行新版替换的 API。为了分片目的，可以将每个文件夹或容器映射到一个单独的区块链通道上。

2. 一个用于使用GET API 检索文档的 API，允许经过身份验证的用户下载或查看文档，但只有在其散列已在区块链记录中进行验证后才能进行。

3. 基于区块链交易历史检索文档历史的 API，包括所有相关版本和其他元数据更改、时间戳、用户身份等。

4. 一个用于检索最新版本的元数据并验证文档内容是否与存储在区块链上的散列匹配，而无需下载文档本身的 API。

5. 用于管理访问权限并授予新权限的 API。这些更改还应存储在链上，以确保它们作为一系列与文档记录通过文档 ID 相关联的访问控制列表（ACL）记录的不可变性。

这是一种方法示例，可解决某些用例的链上/链下存储需求。它不会使区块链负担过大的负载，但同时，会以一种不可变的方式在链上维护文档完整性和交易历史。

到目前为止，我们已经讨论了大量的非结构化对象，如二进制图像数据和 PDF 文件。这种方法能够应用于大型结构化文档吗？例如，在供应链协作需求预测和计划中，文档可能包含数百 MB 的结构化数据，这是不实际作为区块链交易负载进行共享的。好消息是，可以使用类似于前述的非结构化文档的方法。只有选择的数据被提取用于区块链记录，整个文档被散列以确保其完整性可以在另一端验证。文档可以使用传统方式传输（例如 EDI 和 B2B 文件传输），但在传输的两端，区块链被用于存储（发送时）和检索和验证（接收时）相关的元数据字段，包括使用散列验证传输文档的完整性。

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

企业可以选择以下选项之一将文档存储在链下：

1. 关系型或文档数据库——在本地或云端（例如，Oracle 或 MongoDB）

2. 文档管理或内容管理系统（例如，Oracle 内容和体验云）

3. 一个分布式文件系统（例如，NFS）或分布式对象存储服务（例如，Oracle 云对象存储）

4. 一个分布式数据库（例如，Apache Cassandra 宽列 NoSQL 数据库）

5. 一个 P2P 文件共享网络（例如，星际文件系统（IPFS）或 Storj）

本节旨在不对这些数据存储解决方案进行详细审查，而是作为评估它们作为区块链应用的离链存储解决方案的指南。首先，您可以将文档或图像数据存储在传统数据库中，例如 Oracle，或者 NoSQL 数据库中，例如 MongoDB，后者提供更强大的查询功能和更低的成本；然而，它带来了低透明度、单点故障以及中央权威的强烈存在。

文档或内容管理系统提供了针对文档的额外功能——例如文件夹结构、版本控制功能、面向文档的访问控制、用户界面、专为处理文档而设计的 REST API 等等。然而，它们与数据库类似，存在单点故障的问题。在云环境中部署时，可以通过适当的设计来减轻单点故障的影响。

分布式文件系统或对象存储提供了其他选择，这些选择更简单且更便宜，更适合存储图像和其他二进制对象，而不是实际文档。请注意，虽然这些选项可以提供异步分发以避免单点故障，但在决定何时提交区块链事务时需要考虑存储数据的异步复制所带来的延迟，或者等待直到数据被复制。答案可能取决于使用情况和处理各种故障模式的能力。

分布式数据库，比如 Cassandra，可以具有遵循区块链拓扑结构并消除中心化担忧的节点。每个 Cassandra 节点可以与区块链节点位于同一位置。当文档被创建或更新为新版本时，本地 Cassandra 节点是首先存储它的节点，然后将其复制到其他节点。区块链记录更新交易可以同时提交到本地节点，但最终也会在其他节点上可用。使用分布式数据库的关键好处是可以实现数据库节点与区块链节点之间的本地关联，用于更新和文档检索。然而，Cassandra 和区块链中的复制都遵循最终一致性规则，但速度不同（考虑到文档可能比关联的区块链记录大得多），需要考虑不同的故障模式。

基于比特币和 Git 的 P2P 概念演变而来的 P2P 文件共享网络，比如 IPFS，建立在DAG（即有向无环图）架构之上，使得分布式存储节点网络中的版本化对象可以进行交换。每个对象（文件/文档）都有一个哈希值——作为其地址的唯一标识/ID。IPFS 根据哈希值检索对象——每个节点被要求根据其哈希值搜索文件。因此，在区块链记录中存储 IPFS 哈希值与文件哈希值及相关元数据提供了我们之前讨论过的核心锚定能力。IPFS 提供内容的历史版本和网络节点的高可用性。与 Cassandra 类似，IPFS 提供了分散的拓扑结构，尽管它更具可伸缩性，因为它是基于文件系统而不是数据库的。然而，在应用程序设计中仍然需要考虑分发的延迟和潜在的故障模式。

摘要

本章重点介绍了 HLF、其架构和组件。在本章中，我们研究了 Hyperledger 项目，并详细介绍了 Hyperledger 项目的资格标准。本章采用了基于示例的方法来阐述 HLF 的架构。我们探讨了对等体、节点、算法、共识、成员服务、排序服务，以及主要身份、安全性和隐私性。本章还解释了通道和 PDC，以允许组织之间进行私人交易。最后，对存储大型对象的设计策略进行了总结——是在链上还是链下。从下一章开始，我们将深入探讨创建 HLF 网络并编写链码以解决特定的应用场景。

第四章：在区块链平台上进行业务案例的参与

上一章探讨了 Hyperledger 的架构，并向您展示了如何组装一个基于 Hyperledger 的示例业务网络。它提供了基于创建者和基于财团的业务网络的解释。它阐述了业务网络组件，向通道添加对等体，并处理链码和智能合约。它还涵盖了身份、安全性、隐私、会员服务、通道、分类账和交易流。在本章中，我们将学习如何设计与Oracle 区块链平台（OBP）构造一致的解决方案。本章分为两部分：第一部分重点介绍围绕证书发行和与信任方共享证书在区块链网络上的使用案例。第二部分涵盖了区块链即服务（BaaS）平台，该平台为实现区块链技术的潜力提供了一条有效、高效和经济的途径。

BaaS 是区块链采用的催化剂。BaaS 提供者确保安装和维护您的区块链网络，使您的业务和 IT 能够专注于链码和 dApps。整个区块链生态系统将由云服务提供商管理、管理、维护和支持。许多顶级供应商，如 Oracle，都有一个用于 BaaS 的托管平台即服务（PaaS）产品，因为 BaaS 允许客户以经济高效的方式将其 SaaS、业务流程管理（BPM）流程、自定义应用程序等带入区块链的能力。本章还通过探索教育部门的一个使用案例来探索 Oracle 的 BaaS，向您展示如何轻松使用区块链平台。

理解业务场景

教育是人类社会的基础建设部门。它还促进了劳动力不断根据时代变化的需要进行新知识领域的持续技能提升。尽管它是最古老的行业之一，但仍然存在效率低下的问题：

• 多个手动流程导致管理延迟

• 管理延迟导致验证延迟

• 手动流程总是会对学生的证书的真实性产生一些怀疑

为了在 OBP 上构建一个解决方案，我们在这个业务流程中选择了一个场景，涉及到资格证书的批准、以安全方式向学生颁发证书，并以可信的方式与其他利益相关者（如雇主和其他教育机构）共享证书。

引入使用案例

这个使用案例包括与个人的教育资格/学历的生命周期相关的互动和流程的典型设置。在这本书中，我们将考虑涉及以下情景的使用案例方面：

• 主管机关发布/批准证书

• 证书对所有者（即学生）的可用性

• 第三方（如雇主或其他教育机构）对证书的验证

在现实生活中，有太多利益相关者参与此场景，例如特定的学习学校、考试控制机构、发行机构、学生、其他机构和雇主。为了简单起见，我们将考虑以下利益相关者：

• Oracle Red School（ORS）：证书创建者（学习学校）

• Oracle Empire University（OEU）：证书审批者和颁发者（大学）

• 学生、雇主、其他大学：证书查看者/验证者

让我们快速看一下这个用例中现有的真实流程：

证书创建、审批、颁发和审查流程

现有流程存在以下效率问题：

• 手工验证流程使其变慢。

• 验证过程在确定欺诈性声明方面很慢。

• 它需要外部背景验证服务。

• 基于纸张的证书容易丢失或损坏。

• 伪造纸质证书和验证流程中的差距使证书的可信度成问题。

用例资格标准

在向我们的业务场景提出基于区块链的解决方案之前，让我们首先评估并看看它是否符合区块链解决方案的资格。我们如何确信基于区块链的解决方案应用于某一用例会真正解决当前流程面临的挑战？

让我们思考一下区块链技术可以克服的用例的特征方面和限制方面。以下考虑并非详尽无遗；而是一种试图提出区块链解决方案的指示性方法。

以下是区块链技术可以克服的用例的特征方面和限制方面：

• 用中心化解决方案可以解决该用例吗？由 OEU 管理的中心化解决方案会加速某些方面，与纯手工流程（如果存在）相比，但它会带来其他挑战，并不能解决所有现有的效率问题。中心化解决方案的挑战如下：

  • 中心化解决方案不能保证 ORS 和 OEU 的业务流程协同。因此，离线和在线流程之间的断裂不会提供系统效率的太多改进。

  • 从系统或信任的角度来看，将存在单一故障点。

  • 它要求其他方信任一个单一实体（OEU），而不需要其他利益相关者的验证或授权。

  • 它没有提供防止发放虚假证书的有效解决方案。

• 是否有多个利益相关者共享的数字资产？考虑到在此用例中，教育证书是数字资产，它确实将在 ORS 和 OEU 之间共享，用于生成、处理、授予以及验证。

• 数字资产需要以安全方式存储和访问吗？由于证书将成为共享资产，并将由不同的利益相关者访问，因此安全机制至关重要。考虑到资产的性质，安全对于以下方面非常重要：

  • 对其任何访问都应适当进行跟踪

  • 对证书数据的任何更新都应得到 ORS 和 OEU 的认可

  • 证书应受到任何篡改和未经授权访问的保护

• 组织间可能存在信任问题吗？需要建立 ORS、OEU 和证书查看者之间的信任。用例的解决方案应通过设计确保自动建立信任。

区块链解决方案的好处

用例需要一个数字资产（教育证书），应该在利益相关者之间共享，并具有以下特征：

• 共享资产状态

• 互相认可和验证的数据工作流程

• 所有授权的利益相关者透明而安全地访问

• 未篡改的、永久的存在证明和批准证明

考虑到解决方案的所需特征，基于区块链的解决方案是一个合适的选择。凭借其固有的支持不可变性、共享账本、安全访问和交易认可属性，基于区块链的解决方案将能够满足所有用例要求。此外，它还将通过涉及更多利益相关者和智能合约的应用，开启进一步的自动化和流程效率的可能性。

以下是基于区块链的解决方案对我们的用例带来的关键好处：

• 一个可信、防篡改的教育证书数字存储库

• 消除丢失或损坏的风险

• 流程简化（几乎实时）的验证程序，因为教育证书存储在受信任的、不可变的、共享账本上，并具有适当的授权

进一步的可能性如下：

• 个人大规模协作完成的完整教育资格历史

• 将此类真实来源作为进一步批准（例如研究资助和工业合作）的先决条件

• 将教育资格作为一种普遍且业界认可的表示进行标记（例如，EduCoin）

设计解决方案

现在我们已经为基于区块链的解决方案合格，让我们开始根据 OBP 结构设计解决方案。

设计过程没有固定的步骤顺序。这取决于解决方案设计者的自主选择。主要目标应该是明确 OBP 解决方案的各个方面，从逻辑视图到部署方面。

业务网络拓扑

正如我们之前提到的，对于我们的用例，我们考虑三种利益相关者。它们分别是 OEU、ORS 和证书查看者/验证者（让我们简称为CVs）。我们需要根据他们的功能确定每个利益相关者的角色：

• OEU 是大学或控制机构，其下设有不同的学校（学院）。正是这个实体最终有权批准学生提交给他们学校的教育证书。

• ORS 是其中一个学校，学生在该学校注册并完成他们的教育。完成后，ORS 将评估并提交学生的教育证书给 OEU。在更广泛的背景下，ORS 可以被归类为代表性区块链实体学校的一部分。这取决于业务需求和实现环境。

• 诸如学生、雇主和职业机构的 CVs 主要是数据（教育证书）的使用者，因此只能对网络进行只读访问。

基于这一前提，以下表格描述了实体：

组织	实体类型	访问类型
OEU	创始人	读/写
ORS	受权参与者	读/写
CVs	参与者	读取

通道关联

在我们的用例中，一种类型的资产将与所有利益相关者共享，即证书数据。这需要每个人都能够访问相同的账本数据。因此，这将是一个单一通道网络组织，所有利益相关者将以前面列出的各种访问角色连接在一起。

以下图示逻辑地展示了解决方案中 OBP 节点将如何被创建：

网络拓扑和通道关联

该图示展示了各个利益相关者与单一通道的关联。

网络构件

确定网络拓扑和利益相关者后，让我们定义在网络上共享的资产和对其执行的操作。

资产模型

对于给定的用例，我们主要在账本上存储两种类型的对象：

• 学生（接收者）：基本信息

• 证书：证书数据

以下图示是资产结构及其高层次之间的关系：

资产模型

链码交易

该用例要求各个阶段的利益相关者执行以下交易：

交易	执行者	描述
CreateReceiver	ORS	创建新的接收者或学生
AddCertificate	ORS	为接收者插入证书
ApproveCertificate	OEU	批准证书
搜索操作
QueryByCert_id	所有	查询证书
QueryByRecev_id	所有	按 ID 查询接收者
GetCertificateHistory	OEU/ORS/接收者	查询记录的一个关键字的历史
QueryAllCerts	OEU/ORS	查询所有学生的所有证书

解决方案运营流程

到目前为止，我们已经确定了 OBP 项目相关者，他们的关联，账本数据模型以及链码交易。本节将帮助您可视化基于 OBP 的解决方案对现有业务流程所带来的改变，从而克服当前面临的低效和挑战。

以下图表显示了符合条件的使用情形的解决方案流程：

解决方案流程

解决方案架构

作为解决方案架构的一部分，本节涵盖了 OBP 解决方案的整体高级组件视图和运行时部署视图，以及其组件和实例。

高级架构

让我们确定实施基于 OBP 的解决方案所需的解决方案组件和它们之间的交互。以下图表描述了高级解决方案架构：

解决方案架构 - 高级层次

这些是解决方案的组件：

• OBP 仪表板为 OEU 和 ORS 管理员/操作员提供一个接口，以执行 OBP 管理和配置任务。

• 不同的客户端应用程序集将为每个利益相关方而需要：

  • ORS：

    • 创建学生条目，将证书数据插入账本中

    • 能够搜索学生和证书数据

  • OEU：

    • 能够搜索学生和证书数据

    • 批准/拒绝学生的成绩证明数据

  • 学生 (CV)：

    • 能够查看已批准的证书

    • 为证书验证器生成一个标记，以验证存储在 OBP 账本上的他们的学术资格

  • 证书验证器：

    • 能够使用学生使用 OBP 解决方案生成的标记来验证学生的学术资格

部署架构

以下图表显示了 OBP 所有部件和组成解决方案组件如何在 Oracle Cloud 实例上运行。 Oracle Cloud 通过集成的 Oracle Identity Cloud Service（IDCS）保证整个云设备通过其强大且可扩展的Oracle Cloud Infrastructure（OCI）可用性域：

部署架构 [Oracle 镜像]

文档存储 - 推荐与 OBP 一起使用的方法

就像我们的用例一样，今天企业业务流程相关的很多情景涉及文档对象的交换。就实用性而言，对于许多情况，文档本身仅仅是对实体流程的直接采纳。它主要提供了一个对交易相关持有人手中可信实体资产的感知。技术上，这是与商业交易相关的数据值的逻辑分组，例如已经达成的条款和条件、合同和交易数据。

借助基于区块链的可信解决方案，比如我们正在 OBP 上构建的解决方案，实际上我们可以摆脱许多文档对象的需求。然而，出于实际性考虑，文档可能会共存，并且随着采用程度的增加而逐渐变得不相关（并非在所有情况下都是如此）。

目前，可以采用以下方法来存储企业文档以及核心 OBP 解决方案（分类帐）数据：

• 在 OBP 分类帐上进行写入事务时：

  • 生成文档的哈希值，将哈希值记录在分类帐上（链上），并将文档存储在链下

  • 文档的链下存储可以是基于云的 Oracle 内容和体验服务，或其他 Oracle 云存储选项，如对象存储或文件存储

  • 哈希逻辑应由交易参与者协商达成一致，并且必须得到适当的保护。

  • 在智能合约之外执行哈希和文档存储操作可以减少其执行时间。

• 在读取交易时（即在获取文档资产时）：

  • 从所选的文档存储获取文档。

  • 获取文档的哈希并发送给智能合约进行比较和验证。

  • 在匹配成功时，可以阅读文档。否则，应报告意外情况。

有关此方面的更多详情，请参考上一章节中的文档存储部分。

到目前为止，我们已经通过了业务场景并定义了用例。我们通过分析用例来证明需要区块链解决方案，并通过符合用例资格来了解用例。一旦我们决定用例适合区块链解决方案，我们就对基于区块链的解决方案进行了设计。本章的后半部分集中在探索 OBP 及其架构，并设置 OBP 网络实例。

探索 OBP

正如我们已经知道的，OBP 基于开源的 Hyperledger Fabric。但是对于企业来说，Fabric 并不够，因为它并非预安装。以下是从零开始为企业构建工作区块链网络所需的一些高级要求：

• 设置所有先决条件、配置和容器。

• 设置容器生命周期管理以管理节点、通道、链码等所有容器。

• 安装用户管理等安全性，这是企业中最重要的组件之一。

• 管理系统升级计划和补丁，以便与快速变化保持一致。由于 Hyperledger Fabric 是开源的，技术将不断演变，因此您需要不断管理系统升级计划和补丁。

• 确保所有资源的高可用性和可伸缩性。

• 为数据提供安全性并提供集成端点，例如 REST API，以与其他产品连接，比如 SaaS 应用程序、ERP 或任何第三方应用程序。

• 与各种工具一起监视和处理运营任务，如检查节点的健康状况和利用率、通道活动、对等方活动、通道管理、对等方管理、链码管理和网络管理。

要从基础到生产组织一个区块链网络，您需要技能、资源和时间（也许需要几个月）来设置和维护所有这些需求。Oracle 对所有这些需求负责，并提供了 OBP 服务。在本节中，我们将深入探讨 OBP 的架构，并学习如何设置 OBP 实例和区块链网络。

OBP 架构概览

OBP 提供了一个预组装的平台，用于构建区块链网络、部署和运行智能合约以及维护分布式账本。一旦通过几次点击进行服务配置，管理员便可以使用 Web 控制台动态更新区块链配置并监视其运行。开发人员可以部署智能合约并使用 REST API 或客户端 SDK 集成应用程序。OBP 实现了实时的分布式点对点交易，并允许应用程序（新的或现有的）在区块链网络上进行交易和共享数据。

欲了解 OBP 产品的最新更新，请参考 www.oracle.com/cloud/blockchain/。

因为 OBP 是 Oracle 云平台的一部分，它预先与底层云服务组件配套，包括用于身份验证的身份云服务、用于嵌入式归档的对象存储、操作和故障排除的管理和日志分析等。用户可以配置多个对等节点和通道以实现可用性、扩展性和保密性，Oracle 云将自动处理底层依赖关系。以下图表对架构进行了高级解释，并说明了 OBP 如何为开源 Hyperledger Fabric 增加价值：

OBP 高级架构

OBP 是一种权限区块链，并且利用内置的 Oracle IDCS 到 Hyperledger Fabric 来提供以下功能：

• 用户和角色管理

• OBP 控制台、REST 代理和证书颁发机构（CA）的身份验证

• 身份联合和第三方客户端证书支持以启用财团形成并简化成员入职流程

OBP 运行在 OCI 上，它是一个 PaaS 服务。因此，存储、可扩展性、高可用性和基础架构将由 Oracle 负责。使用 Oracle 集成云服务的适配器，可以将其与 Oracle SaaS、PaaS 和本地应用程序集成，实现区块链交易、事件和查询。由于 OBP 基于 Hyperledger Fabric，它还允许我们连接使用 Hyperledger Fabric 的外部成员节点。这些外部成员节点可以位于客户数据中心或第三方云服务中。下图显示了 OCI 上 OBP 服务级架构：

OBP 服务级架构

Oracle 已经对 Hyperledger Fabric 进行了许多增强，使 OBP 成为企业级服务。每个区块链实例都包含托管容器、虚拟机、身份管理、区块和对象存储以及 Oracle 事件中心云服务，这是一个专用的 Kafka 连接。

区块链实例

OBP 实例（本书中称为区块链实例）是包含对等节点、排序器、操作控制台、CA、REST 代理和链码的容器集合。OBP 实例与身份管理集成以管理用户和角色。它还集成了 Oracle 对象存储以动态备份配置更改和分类帐，并在需要时进行恢复。Oracle 对象存储将备份区块链实例中的所有组件，包括分类帐中的所有块文件，其中还包括系统通道和客户通道中的数据、通道列表、最新检查点、链码的源代码、配置文件和节点的配置文件和日志文件。此备份和恢复过程将在 OBP 中自动完成，而无需用户注意。OBP 使用 Oracle 事件中心云服务作为排序器的专用 Kafka。默认的 REST 代理可用于将 OBP 与任何其他应用程序集成，例如 SaaS、PaaS、本地或其他第三方应用程序。

到现在为止，你应该知道区块链需要大量容器和大量存储资源，因此资源密集型。由于 OBP 在 Oracle 云上运行，Oracle 将负责存储、可扩展性和服务的高可用性。

OBP 有两种方式可用。一种是通过安装 Oracle 提供的预构建虚拟机，另一种选项是在 Oracle 云中创建帐户，并从服务组合中提供区块链平台。除了访问和创建区块链实例的初始步骤外，所有其他功能和导航都是相同的。让我们看看这两种 OBP 配置方式。

设置 OBP SDK

本节展示了如何在笔记本电脑或本地机器上设置 OBP SDK。这仅供参考；然而，还有其他方法，如在 OCI 等云基础设施中设置。以下是设置 OBP SDK 的流程。

先决条件

这些是设置 OBP SDK 的先决条件：

• Oracle Linux 版本 7.3 或更高（OBP 在任何带有 Docker 的 Linux 上运行，但推荐使用 Oracle Linux），并且必须具有互联网访问权限，并且 Linux 内核版本必须大于 3.10。

• 磁盘空间取决于计划部署的实例数量。

• 对于应用程序，推荐每个实例使用 4 GB 内存。

• 在配置完成后，有多个 Docker 容器在运行，并且每个容器对主机机器的 CPU 周期的访问应该是无限制的。为了确保每个容器运行顺畅，推荐至少使用两个 CPU。

• 需要主机名。

• 需要 Oracle 用户，因为进程在 Docker 容器中运行（例如 peer 和 orderer）。

当从浏览器访问时，主机名应该是一个可解析的名称。在本地设置 OBP 的情况下，主机名必须是您的 VM 运行时的名称。在同一 OBP VM 中创建多个组织时，主机名将保持不变（即 VM 名称），但每个组织的端口范围将不同。

#create user oracle
sudo useradd oracle
sudo passwd oracle
<newPassword>

准备 Docker 环境

要构建和安装 OBP SDK，需要安装最新的 Docker 引擎和 Docker Compose：

1. Docker 引擎安装：OBP SDK 需要最新版本的 Docker 引擎。执行以下命令查找 Docker 引擎版本：

docker --version

1. 如果版本不是 Docker version 17.05.0-ce 或更高，则按以下说明安装/更新 Docker 的最新版本。

2. 使用以下命令使用 docker yum 仓库命令替换 OS（操作系统）版本为您的特定 OS 版本：

$ sudo tee /etc/yum.repos.d/docker.repo <<-EOF 
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/oraclelinux/7
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

1. 安装 Docker 引擎：

$sudo yum install docker-engine-17.05.0.ce

1. 检查 Docker 引擎版本：

$docker –version

以下截图显示版本：

Docker 版本

1. 启动 Docker 引擎：

sudo systemctl restart docker

1. 对 Docker 守护进程的用户进行身份验证：

sudo usermod -a -G docker $USER

1. 解包并部署 区块链云服务（BCS）SDK，并借助以下代码片段解压缩它：

As opc user switch to 
/usr/localcd 
/usr/localsudo 
mkdir bcssdk
cd bcssdk

1. 从网络或本地来源复制 OBP SDK。

2. 执行以下命令将构建包解压到 bcssdk 目录：

sudo unzip obcs-sdk-19.1.3-20190129043733.zip -d /usr/local/bcssdk

本书使用 OBP SDK 版本 19.1.3，其中 Hyperledger Fabric 版本为 1.3。

1. 现在我们需要安装图像并开始配置控制台。作为 root 用户，运行 build 命令以加载和安装 Docker 图像：

./build.sh

以下截图显示了 build.sh 的输出：

运行 build.sh

1. 等待 Docker 加载：

docker load

1. 确认使用 Y，然后图像安装完成后控制台将自动启动：

开始配置

有一些你需要记住的要点：

• 如果防火墙处于活动状态，build.sh 将提示用户停止防火墙并重新启动 Docker 守护程序。

• 请使用 build.sh 开始配置控制台。如果用户选择不停止防火墙，则在配置或配置后可能会出现问题。因此，在这种情况下，我们建议使用根用户。

• 如果防火墙关闭，用户 oracle 已存在，并且非根用户具有 Docker 访问权限，则可以使用此用户运行此命令。

配置

由于 OBP SDK 仅用于开发目的，每个已提供的实例只能存在 60 天。一旦过期，实例将不再工作。如果需要继续测试或原型制作，则需要提供新实例。

执行以下步骤进行配置：

1. 请使用以下命令行开始配置控制台（如果尚未启动）：

./build.sh [-d <package directory>, default is current path] [-w provision workspace directory, default ~/obcs_workspace] [-p provision console port, default 3000]

1. 将会观察到以下消息：

OBP 控制台 URL

1. 现在，您可以从本地机器使用 ssh 和端口转发访问控制台。在 Linux/mac 系统上，打开终端窗口并输入以下内容：

ssh -L <localPort>:<remoteIP>:3000 opc@<remoteIP>

1. 然后，从本地的 Web 浏览器中，只需输入 http://localhost:3000，您就可以看到控制台的用户界面：

OBP 控制台

使用 SDK 创建区块链实例

使用 OBP SDK 创建区块链实例的过程如下：

1. 打开 VM 的登录 URL，例如，http://studentvm2:3000/。

2. 将打开 Oracle 登录页面。首次需要创建用户。

3. 输入用户名和密码（记住这些凭据以备将来使用）。

4. 单击“登录”。

5. 如果用户不存在，将打开一个标题为“创建用户”的对话框窗口，如下截图所示：

OBP SDK 登录

1. 单击“确定”创建用户。

2. 创建用户后，将打开 OBP 实例页面，如下截图所示。使用此页面创建实例并列出所有已创建的实例：

OBP SDK 控制台

在 OBP SDK 中创建创始人实例

要创建创始人实例，请在“创建实例”部分提供详细信息，并确保选中“创始人”复选框：

1. 名称：如下截图所示，可以设置要创建的实例的名称，例如，detroitauto。

2. 主机地址：如下截图所示，输入已设置了 SDK 的 VM 的主机地址。只能使用此主机地址访问实例。

3. 起始端口：参考截图，在实例创建后输入一个端口（或一系列端口）以访问控制台：

OBP SDK 创始人 1

1. 单击“创建”按钮，等待一段时间以查看已创建的实例，因为必须创建多个容器和虚拟机，并使其运行起来。

2. 当实例创建完成后，将在左侧的“实例”下可见：

OBP SDK 创始人

1. 单击实例名称后，将打开该实例的区块链控制台。

现在让我们在 OBP SDK 中创建一个参与者实例。

在 OBP SDK 中创建参与者实例

要创建参与者，请按照上述步骤操作，但取消选中“创始人”：

1. 请参考以下截图：

OBP SDK 参与者

1. 单击“创建”，等待几分钟（在我的情况下，是 4 分钟）；然后您将看到新的参与者实例已添加到实例列表中，如下所示：

OBP SDK 参与者

参考OBP 的特性和组件部分，了解 OBP 控制台的外观并探索其功能。

在 Oracle Cloud 上进行 OBP 规划

访问 Oracle 云中的 OBP 的流程如下：

1. 打开 cloud.oracle.com。

2. 单击右上角的“登录”。

3. 输入您的Cloud Account Name，然后单击“下一步”。

4. 输入您的用户名和密码，然后单击“登录”按钮。

5. 将打开“云我的服务”页面。

6. 单击左上角的汉堡图标，展开“服务”菜单。然后，您将在列表中看到“区块链平台”，如下所示：

OBP 云我的服务

1. 单击“区块链平台”。将打开 OBP 控制台。这是您可以创建新的 OBP 实例或查看帐户中创建的实例列表的位置。您还可以查看实例活动的历史记录：

OBP 云控制台

在 Oracle Cloud 上创建创始人实例

一旦您按照前一节所示打开 OBP 控制台，请单击“创建实例”：

1. 将打开“创建实例”页面：

OBP 云创始人

1. 按照上图中显示的表单填写详细信息。

2. 确保“创建新网络”复选框已启用。这在创建创始人时非常重要。

3. 单击“下一步”。将显示包含您提供的详细信息的页面以供确认，如以下截图所示：

OBP 云创始人

1. 验证所有详细信息，然后单击“创建”。

2. 稍等片刻。成功创建实例后，将显示以下屏幕。将发送电子邮件确认到提供的电子邮件地址：

OBP 云创始人

1. 在实例名称旁边，单击汉堡图标。将显示一个菜单。如果单击“区块链控制台”选项，则将打开该实例的控制台。

在 Oracle Cloud 上创建参与者实例。

要创建参与者，请按照之前在 在 Oracle Cloud 上创建创建者实例 部分提到的步骤，但取消选中创建新网络：

1. 请参考以下截图：

OBP 云参与者。

1. 创建参与者实例后，您可以在 OBP 控制台的“实例”选项卡中看到实例列表，如以下截图所示：

OBP 云实例。

OBP 的功能和组件。

在本节中，我们将看到 Oracle 区块链实例控制台的外观，并检查其功能。如果您使用 OBP SDK 或通过 Oracle Cloud 创建区块链实例，则 OBP 实例的控制台将与以下截图中显示的相同：

OBP 实例仪表板。

控制台有多个选项卡，在接下来的部分中我们将逐个探讨它们。

仪表板。

这是第一个选项卡，显示以下内容的摘要：

• 实例已创建或参与的通道数量。

• 实例正在使用的对等方数量。

• 部署和运行在实例上的链代码数量。

• 通道的活动，例如通道上创建的区块数量和通道上的用户交易数量。

• 对等方的活动，例如背书和提交。

• 实例的健康状况，例如正在运行和停止的节点数量。

• CPU、内存和磁盘利用率的指标。

在仪表板上显示这些数据的同时，如果实例是创建者，则还会显示参与网络的顺序和组织的数量。

每个区块链网络只会有一个排序者，并且在 OBP 中它将与创建者一起。

网络拓扑结构。

此选项卡显示参与网络的所有人。此外，它还显示了网络的拓扑视图：

OBP 网络拓扑结构。

上图显示了网络的结构以及组织和节点之间的关系。

节点拓扑结构。

此选项卡显示所有对等方，包括自身对等方和远程对等方，他们都是网络的一部分，以及一个 CA 节点。如果是创建者，可以看到一个额外的用于排序的节点。它还显示了网络的节点和对等方的拓扑视图：

OBP 节点拓扑结构。

上图显示了对等方和通道之间的关系。

通道。

此选项卡用于管理实例的通道。它将列出实例所属的所有通道。还可以从这里创建新通道。可以管理通道级别的策略，可以向通道添加新对等点，以及可以向通道添加或删除组织。每个通道都将有自己的分类帐，并显示分类帐的所有区块和交易。一旦创建了通道，就无法删除。

链码。

此标签用于管理链码，并列出实例中所有网络的所有链码。这里可以进行链码的部署、启动和实例化。该链码可以写入并更新渠道的分类账。一旦部署链码，它不能被更新。链码可以在多个渠道中实例化。每个链码在一个渠道中每个版本只能实例化一次，这意味着如果在一个渠道的节点上实例化了链码，那么渠道中的其他节点只需部署链码，实例化将自动反映在它们上面。每个链码都有其自己的日志和私有数据集合，这些数据也可以从此标签访问。

开发者工具。

此标签允许我们访问 OBP 文档，并提供来自 Oracle 的 SDK、工具和预构建示例链码的下载链接。

在接下来的章节中，我们将了解如何创建区块链网络并邀请组织参与网络，创建和部署链码，使用链码，测试分类账，使用 REST 代理等等。

与 OBP 一起使用丰富历史数据库。

OBP 使用 Hyperledger Fabric 历史数据库来管理分类账，并在控制台中呈现分类账交易信息。只有链码可以访问这个历史数据库，不能向任何外部应用程序公开查询分析数据。即使它们提供区块链服务，分析也不能被忽略。因此，OBP 集成了丰富的历史数据库以满足这一要求。

丰富历史数据库是 OBP 外部的，并包含您选择的渠道中区块链账本交易的数据。您可以将丰富的历史数据库集成到 OBP 实例控制台中，并选择需要在数据库中捕获数据的渠道。一旦在一个渠道上启用丰富历史数据库，该渠道的所有交易都将同步到数据库中。这种级别的数据收集使丰富历史数据库成为生成分类账活动分析和可视化报告的绝佳数据源。您可以使用任何分析工具，例如 Oracle Analytics Cloud 或 Oracle Data Visualization Cloud Service，访问丰富历史数据库并创建分析报告或数据可视化。

OBP 只支持 Oracle 数据库，例如 Oracle Autonomous Data Warehouse 或 Oracle Database Cloud Service（ODCS），使用 OCI 创建丰富的历史数据库。

创建 ODCS 连接字符串。

OBP 可以在 OCI 中与 ODCS 集成为丰富历史数据库。然而，还必须通过端口 1521 启用对数据库的访问。

获取 ODCS 信息。

在 OCI 控制台中创建与 ODCS 连接的过程如下：

1. 登录 Oracle Cloud，My Services 页面将会打开。

2. 单击左上角的汉堡菜单图标，展开“服务”菜单，选择“数据库”选项。

3. 在 DB 系统下，找到要连接的数据库并记录其公共 IP 地址。

4. 单击数据库的名称并捕获以下字段的值：

   • 数据库唯一名称

   • 主机域名

   • 端口

5. 查找具有对此数据库的读取权限的数据库用户的用户名和密码。

启用端口 1521 以访问数据库

在 ODCS 上启用端口1521的过程如下：

1. 如前所示，导航至 DB 系统并单击要连接的数据库。

2. 点击“虚拟云网络”。

3. 在安全性列表下，导航到相应的子网。

4. 点击“<目标数据库>的默认安全列表”。将显示安全列表页面。

5. 点击“编辑所有规则”。

6. 添加一个入口规则，允许来自公共互联网的任何流量到达此数据库节点的端口1521，设置如下：

   • 源 CIDR：0.0.0/0

   • IP 协议：TCP

   • 源端口范围：全部

   • 目标端口范围：1521

   • 允许：端口为1521的 TCP 流量

创建连接字符串

启用对 Oracle 数据库的访问后，请使用收集的信息在“配置丰富历史记录”对话框中构建连接字符串。构建连接字符串如下：

<publicIP>:<portNumber>/<database unique name>.<host domain name>

以下示例显示了连接字符串的样式：

123.213.85.123:1521/CustDB_iad1vm.sub05031027070.customervcnwith.oraclevcn.com

配置 OBP 中的丰富历史数据库

每个区块链网络实例都可以配置自己的丰富历史数据库，以下是执行此操作的步骤：

1. 打开区块链网络实例的控制台。

2. 点击选项按钮（右上角的汉堡图标），然后点击“配置丰富历史记录”。将打开配置对话框：

配置丰富的历史记录

1. 输入数据库的用户名和密码。

2. 在“连接字符串”字段中，输入将存储丰富历史数据的数据库的连接字符串。此输入取决于正在使用的 Oracle 数据库：

   • 如果数据库是 Oracle 自主仓库，则连接字符串类似于<用户名>adw_high。

   • 如果数据库是 OCI 的 ODCS，请按照“创建 ODCS 连接字符串”部分讨论的步骤获取连接字符串。

   • 如果您使用的是非自治数据库，并且想要使用sys用户连接数据库，则必须在连接字符串后面附加?as=sys[dba|asm|oper]，例如，123.123.123.123:1521/example.oraclevcn.com?as=sysdba。

   • 如果您使用的是 Oracle 自主数据库，则可以使用钱包文件而不是连接字符串。该文件包含客户端凭据，并且是从 Oracle 自主数据库生成的。

3. 单击“保存”按钮。

4. 要更新此配置，请重复相同的步骤。

以下截图供参考：

配置丰富历史记录

启用将数据写入丰富历史数据库的通道

在启用通道将数据写入丰富历史数据库之前，必须在实例中配置它。请按照以下步骤操作：

1. 打开区块链实例的控制台，转到通道选项卡

2. 定位通道并单击 More Options 图标

3. 要将通道添加到富历史数据库中，请从菜单中单击配置富历史选项

4. 将打开一个配置富历史对话框，里面有一个启用富历史的复选框

5. 单击复选框以添加通道，取消选中以删除通道

6. 单击保存按钮

富历史数据库的表格和列

当富历史数据库配置在一个通道上时，将在数据库中创建三张表格：历史表、状态表和最新高度。为了创建分析报告，将进行历史和状态表的查询：

富历史表格

让我们看看每一个表格及其列。

历史表

此表的名称类似于 <instance name>_<channel name>_hist。

该表包含了通道分类账的历史。以下是列及其数据类型的列表：

列	数据类型
chaincodeId	VARCHAR2 (256)
key	VARCHAR2 (1024)
txnIsValid	NUMBER (1)
value	VARCHAR2 (4000)
valueJson	CLOB
blockNo	NUMBER NOT NULL
txnNo	NUMBER NOT NULL
txnId	VARCHAR2 (128)
txnTimestamp	TIMESTAMP
txnIsDelete	NUMBER (1)

请注意 value 和 valueJson 列以相互排斥的方式使用。也就是说，当键值为有效 JSON 时，该值会被设定到 valueJson 列中。否则，该值会被设定到 value 列中。 valueJson 列在数据库中被设置为 JSON 列，这意味着用户可以使用通常的 Oracle JSON 特定扩展查询该列。

状态表

此表的名称类似于 <instance name>_<channel name>_state。

该表从状态数据库复制数据。以下是列及其数据类型的列表：

列	数据类型
chaincodeId	VARCHAR2 (256)
key	VARCHAR2 (1024)
value	VARCHAR2 (4000)
valueJson	CLOB
blockNo	NUMBER
txnNo	NUMBER

value 和 valueJson 列在历史表格中是相互排斥使用的。

最新高度表

此表的名称类似于 <instance name>_<channel name>_last。

此表由 OBP 内部用于跟踪富历史数据库中记录的块高度。这张表格无法用于分析查询。

下面是一个屏幕截图，当富历史数据库连接到 SQL Developer 工具时，您可以参考以查看先前的表格：

含有列的富历史表格

摘要

企业不断寻找有效和高效的方法来利用区块链技术，以及它们的 SaaS、BPM 和其他应用。BaaS 使他们能够实现这一目标。本章提供了对 OBP 的一瞥。本章重点介绍了与 OBP 构造相一致的解决方案的设计。本章涵盖了示例业务网络拓扑、网络构件以及解决方案和部署架构。本章还深入探讨了定义并创建基于创始人的业务网络实例以及向其中添加参与者。通过本章获得的知识将帮助您在下一章中管理区块链网络，并作为在上一章中描述的 OBP 解决方案开发的基础性里程碑。接下来的章节将让您深入了解 OBP 的管理方面，并教您在 OBP 上翻译网络拓扑。它深入探讨了对等体、排序和通道配置。它还提供了有关 REST 配置和 REST 接口管理的详细信息。随后的章节将更多地涵盖 OBP，并突出了 Oracle BaaS 平台的强大功能。

第五章：在 Oracle 区块链平台上管理解决方案

上一章涵盖了商业场景，并允许我们探索 Oracle 区块链平台 (OBP)。使用 OBP 管理解决方案非常简单；它允许您实践而不是阅读实践，并通过示例有效地展示实践。本章提供了关于 OBP 的深入知识，并允许您具备 OBP 的实际知识。通过本章，您将深入了解将网络拓扑映射到 OBP 上、创建网络利益相关者以及配置 OBP 实例的实际操作。这份知识的账本说明了设置交易基础设施、将参与者加入业务网络、访问控制、向业务网络添加智能性（链码）以及使用 REST 代理配置将链码暴露给 dApps。在很大程度上，OBP SDK 和 Oracle Cloud 上的 OBP 在功能上相似，除了让您创建 OBP 实例的步骤。这两个选项之间的差异不大，也很容易理解。本章主要涵盖了将网络拓扑转换为 OBP、为 OBP 网络增加业务智能和使用管理 REST 接口。

将网络拓扑映射到 OBP 上

本节描述如何在 OBP 上创建网络实例。如 第四章 区块链平台的商业案例 的 设计解决方案 部分所述，区块链网络需要以下业务实体：

• Oracle 帝国大学 (OEU) 作为创始者实体

• Oracle 红校 (ORS) 和 证书查看器/验证器 (CVs) 作为参与者实体

使用 OBP 实例创建网络利益相关者

构建 OBP 解决方案的基础步骤包括为利益相关者实体创建 OBP 实例。按照以下步骤执行，以便为用例创建必要的 OBP 实例：

1. 启动并登录到 OBP 供应控制台。参考 第四章 区块链平台的商业案例 的 设置 OBP SDK 部分，获取 OBP 供应控制台的详细信息。

2. 登录后，通过填写实例详细信息开始创建 OBP 实例。

3. 下面的截图显示了创建实例的示例值。请注意这两个重要点：

   • 创始人复选框只能对创始者实例进行选择。

   • 为启动端口提供不同 OBP 实例的值。确保这些端口值相距较远，因为 OBP 在内部将多个值连续分配给起始端口，如下截图所示：

创建一个实例

1. 一旦我们的用例的所有 OBP 实例被创建（并激活），它们将显示在供应控制台上，如下截图所示：

创始人和参与者实例的摘要

1. 单击每个 OBP 实例的上下文菜单，并选择 Console URL，导航到相应实例的 OBP 仪表板。我们案例中 OBP 网络创建的下一步是通过 OBP 仪表板完成的：

OBP 实例的上下文菜单

由于 oeu 是创始组织，它将拥有比其他参与者 OBP 实例更多的 OBP 系统组件。此外，作为创始组织，oeu 是一个自给自足的组织，因此在仪表板上还有不同的可视化元素。一旦我们完成了参与者实例的网络设置，我们也将在仪表板上获得类似的可视化效果。

以下表格给出了 OBP 工件下的默认值：

OBP 工件	创始人 (OEU)	参与者 (ORS 或 CVs)
通道	1	0
对等点	2	2
排序器	1	0
CA	1	1
REST 代理	2	2

以下截图显示了 oeu 仪表板，这是创始组织 (oeu) 的仪表板：

OBP 创始人仪表板

查看 ors 仪表板。ors 和 cvs 仪表板具有相似的外观：

OBP 参与者仪表板

配置 OBP 网络基础设施

创建 OBP 实例后，构建 OBP 解决方案的下一步是在这些实例之间建立区块链交易网络。本节将带您完成连接所有 OBP 实例并启用底层共享账本基础设施的步骤。

以下部分阐述了步骤。

导出/导入参与者证书

导出参与者 (ors 和 cvs) 组织/实例证书并导入到创始人 OBP 实例。步骤如下：

1. 导出参与者组织证书

2. 将参与者组织证书导入创始组织

第一步是导出参与者组织证书。您可以通过以下两种选项之一导出参与者的 OBP 实例证书：

• 选项 1：使用仪表板向导，如下截图所示：

OBP 参与者导出证书流程

• 选项 2：从参与者 (ors 和 cvs) 的 OBP 仪表板的网络选项卡下的组织上下文菜单：

OBP 参与者网络摘要

参与者证书是包含其管理员、证书机构 (CA) 和 传输层安全性 (TLS) 的证书密钥及其签名的 JSON 文件。以下截图提供了参与者证书之一的一瞥：

OBP 参与者证书快照

第二步是将参与者组织证书导入到创始者组织中。按照以下步骤将参与者证书导入到创始者组织中：

1. 转到创始者仪表板（oeu），以导入这些参与者的证书。这可以通过在 oeu 页面的网络标签下选择添加组织选项来实现。以下截图中展示了这些步骤。

2. 通过导入 ors 和 cvs 的参与者证书添加一个组织：

导入参与者证书

创始者的网络标签允许我们导入参与者证书：

创始者网络摘要

订单者配置

设置 OBP 网络的下一组步骤是从创始者到参与者导入订购者配置。

由于订单者与基础设施级别的创始者实例相关联，因此执行此设置变得必要。这确保了由参与者对等体提交的任何区块链提案（交易）被同一订购者进行验证，并在最终写入共享账本之前对账本块进行排序。

以下步骤提供了如何完成订单者配置设置的逐步说明：

1. 使用导出订购者设置选项在网络标签下导出创始者实例的订购者设置：

导出创始者实例的订购者设置

从技术上讲，OBP 中的订购者设置也以 JSON 文件的形式表示和存储，并包含创始者证书、签名和订购者端点。您还会收到一个类似的订购者的 JSON 文件，如下截图所示：

订单者设置的 JSON 文件

1. 将订单者设置导入到每个参与者（ors 和 cvs），如下几个截图所示。

2. 单击 ors 仪表板的网络标签下的订购者设置导入选项：

订购者设置的 JSON 文件

1. 上传从 oeu 实例导出的订购者文件：

将订购者设置导入到参与者

1. 订单者设置导入完成后，您可以选择查看订单者设置选项来验证订单者详情。请注意，以下订单者地址实例与从创始者导出的订单者设置 JSON 文件中的订单者端点相同：

匹配订购者设置

配置 OBP 交易基础设施

在上一节中设置了基本的 OBP 网络基础设施后，现在是设置 OBP 交易基础设施的时候了。主要是在系统配置中定义共享账本，并将能够读/写账本的参与方（OBP 实例）相关联。

对于我们的用例，这将涉及与 OEU（创始人）建立频道，并将 ORS、CVs 和 OBP 实例添加到同一频道。有关更多详细信息，请参阅第四章中的网络拓扑和频道部分，参与区块链平台的业务案例。

正如其名称所示，频道是 OBP 中的逻辑或配置构造，允许两个或多个网络利益相关者共享数据。此数据共享通过共享账本完成。因此，OBP 中的每个频道本质上也表示与之关联的基础共享账本。

频道设置

让我们为用例继续进行必要的频道创建：

1. 转到 oeu 仪表板的 频道 选项卡，然后单击创建新频道。

2. 更新以下字段：

   • 频道名称：为频道提供一个名称。

     请注意，当进行链码调用时，您将需要它。

   • 选择 ors 和 cvs 实例的复选框。

   • 选择一个或多个 oeu 的对等节点加入频道，如下图所示：

创建频道

频道创建成功后，您可以在 oeu 仪表板上看到相应的通知，并且新创建的频道将显示在现有的频道列表中。 **oeu **频道选项卡将类似于以下屏幕截图：

创建频道摘要

将参与者节点加入频道

使用 OEU 的 OBP 实例创建频道后，将参与者的对等节点 ORS 和 CVS 添加到同一频道。通过这样做，我们确保由各自 OBP 实例的应用客户端提交的任何交易都将被对等节点接受，并添加到频道进行验证、链码执行和 RWSet 创建。然后，此 RWSet 将提交给订购者以排序分类帐块。

您可以通过以下任一选项将参与者的对等节点添加到频道：

• 使用参与者 OBP 仪表板的 节点 选项卡下的对等节点的上下文菜单，如下图所示：

节点摘要

• 使用参与者 OBP 仪表板的 频道 选项卡下的频道的上下文菜单，如下图所示：

频道摘要

继续选择选项 2，您将被要求选择加入频道的对等节点选项。您可以选择一个或多个实例的对等节点加入：

加入频道

一旦参与方节点加入通道，OBP 实例节点的拓扑视图应该如下所示的截图所示。

创始者节点摘要

以下截图显示创始组织的节点摘要：

创始者节点摘要

参与者（ors）节点摘要

以下截图显示了 ors 组织的节点摘要：

参与者节点摘要

参与者（cvs）节点摘要

以下截图显示了另一个参与者（cvs）组织的节点摘要：

参与者节点摘要

另外，请验证 OEU、ORS 和 CV 的网络拓扑视图是否显示如下截图所示的可视化效果。

创始者网络摘要

以下截图显示了创始组织（oeu）的网络摘要：

创始者网络摘要

参与者（ors）网络摘要

以下截图显示了参与组织的网络摘要之一：

参与者（ors）网络摘要

参与者（cvs）网络摘要

以下截图显示了其他参与组织（cvs）的网络摘要：

参与者（cvs）网络摘要

向 OBP 网络添加智能性

随后的章节广泛涵盖了通过链码开发向 OBP 网络添加业务智能性，并将链码功能暴露给客户应用程序。以下部分提供了其 sneak preview。

开发链码以向 OBP 网络添加智能性

完成配置 OBP 网络的步骤后，下一步的实施集合涉及向其添加智能性。通常，这意味着将我们的用例业务逻辑添加为智能合约或链码。它涉及在网络实例的所有节点上安装和实例化链码。

本书的下一章涵盖了为我们的用例实现链码和相关网络构件。 第六章，在 Oracle 区块链平台上开发解决方案，涵盖了开发、部署和实例化链码，以满足用例需求。关于网络构件设计的更多细节，请参考第四章，参与区块链平台上的业务案例，中的网络构件部分。

通过 REST 代理配置公开链码

这些配置通常包括定义，以将链码功能暴露给客户端应用程序（如 dApp）。为了保持连续性，请参考第六章中的链码部署部分，在 Oracle 区块链平台上开发解决方案，了解 REST 代理配置的详细信息。

OBP 的 REST 接口

设置和管理您的 OBP 网络的所有管理和配置步骤（如前文所述）也可以使用 OBP 的管理 REST 服务来执行。这些服务对于需要以下情况非常有用：

• 减少这些活动的手动模式

• 实施自动化方式（例如 DevOps 流水线）设置和管理 OBP 网络

• 以自定义方式表示 OBP 管理信息

这些管理 REST 接口包括与组织、节点、渠道和链码相关的服务。此外，OBP 还提供了一系列 OBP 统计 REST 服务。

以下是 OBP 管理 REST 服务列表：

• 组织 REST 端点：在组织 REST 端点下，以下是服务列表：

  • 获取组织证书

  • 获取组织管理员凭证

  • 获取创始组织中的订购服务设置

  • 将一个新组织加入到创始组织

  • 将订购服务设置给参与者组织

• 节点 REST 端点：在节点 REST 端点下，以下是服务列表：

  • 获取节点列表

  • 获取特定渠道上的节点列表

  • 获取特定链码的节点列表

  • 添加对等节点

  • 启动/停止对等节点

  • 移除对等节点

  • 获取/设置对等节点属性

  • 将节点加入到渠道中

  • 导出/导入节点

  • 启动/停止订购者

  • 获取/设置订购者属性

  • 启动/停止 CA 节点

  • 获取/设置 CA 的属性

  • 启动/停止 REST 代理

  • 获取/设置 REST 代理的配置

• 渠道 REST 端点：在渠道 REST 端点下，以下是服务列表：

  • 创建一个渠道

  • 获取渠道列表

  • 获取链码的频道列表

  • 获取对等方的渠道列表

  • 更新渠道配置

  • 获取渠道信息

  • 通过块 ID 获取账本块

  • 通过 ID 范围获取块

  • 通过时间范围获取块

• 链码 REST 端点：在链码 REST 端点下，以下是服务列表：

  • 获取已安装链码列表

  • 获取特定对等方上的链码列表

  • 获取渠道上的链码列表

  • 安装链码

  • 实例化链码

  • 获取链码信息

• 统计 REST 端点：在统计 REST 端点下，以下是服务列表：

  • 当前存在的渠道列表以及每个渠道上加入的对等点列表

  • 指定对等方当前已加入的渠道数量和列表

  • 指定对等方上当前已安装的链码数量和列表

  • 指定渠道上已实例化链码的当前数量

  • 指定代理或所有代理的配置链码列表

  • 节点健康状态

  • 与节点使用相关的指标（CPU、内存、磁盘使用情况）

  • 总异步调用次数

  • 计费交易数

  • 区块数量

  • 提交次数

  • 背书数量

  • 总同步调用次数

  • 用于对等方或通道或整个网络的用户事务数量

有关这些服务的更多详细信息，请参阅 OBP 文档。

摘要

本章主要涵盖了对 OBP 解决方案进行实验的第一组步骤。我们已经涵盖了将网络拓扑转换为 OBP，配置 OBP 网络基础设施，配置 OBP 事务基础设施，向 OBP 网络添加业务智能，REST 代理配置以及管理 REST 接口。

下一章探讨了链码开发，例如语言部分、开发工具和开发环境设置。它还涵盖了链码从开发到更新的完整生命周期，包括安装、初始化、测试和版本控制。它展示了一个使用 Go 和 Node.js 构建的代码库的完整链码。它还说明了背书策略、私有数据收集、通过 shim 和 REST 端点进行链码测试，以及使用 SDK、REST 和事件将客户端应用程序与业务网络集成。

第六章：在 Oracle 区块链平台上开发解决方案

前一章让您有机会实践而不是仅仅阅读，因为它有效地演示了开发示例。前面的章节提供了关于Oracle 区块链平台（OBP）的深入信息，并教授了在 OBP 上转换网络拓扑、创建网络利益相关者和配置 OBP 实例的实用性。本章探讨了链码，并包括链码开发的详细信息，包括语言部分、开发工具和开发环境设置。本章还着重于映射资产模型、操作以及开发链码的功能和接口。它详细描述了链码的完整生命周期，从开发到更新，包括安装、初始化、测试和版本控制。它还演示了基于 Go 和 Node.js 构建的完整链码代码库。背书政策、私有数据集以及它们与链码协作的工作也得到了阐述。本章还演示了通过 shim 和 REST 终点进行链码测试，并使用 SDK、REST 和事件将客户端应用程序与业务网络集成。最后，它通过实验监控链码日志和通道日志来总结了对链码、交易和通道的见解。该章涵盖了设置链码开发、链码开发、链码部署、测试链码以及将客户应用程序与区块链集成的主题。

设置链码开发

在这一部分，您将学习如何为我们在前几章中使用的大学场景开发链码。

选择开发语言（GO、Node.js 或 Java）

编程技能对于编写链码非常重要。由于区块链具有分布式账本，因此在Hyperledger Fabric（HLF）的初始版本中仅支持 Go 语言。然而，随着 HLF 的发展，它现在支持多种语言，并计划在将来添加更多语言。在 Fabric 版本 1.3 中，它支持使用 Go、Node.js 和 Java 编写链码。要探索其中的每一种，您可以在 OBP 实例控制台的开发工具选项卡下下载示例文件。

OBP 解决方案开发工具

这一部分为您提供了开发工具和开发环境的详细信息。

开发环境

OBP 以 HLF 作为其基础，因此在编写有效的链码时使用 HLF 文档进行帮助。所有的链码文件都应打包成 ZIP 文件并安装在 OBP 上。如果链码是用 Go 语言开发的，并且只有一个名为.go的文件，那么打包是可选的。一个独立的文件可以安装在 OBP 上。

开发工具

从 HLF 或 OBP 都没有具体推荐的工具。开发者可以使用任何工具，例如文本编辑器或 IDE，如 NetBeans、VS Code 等。工具的选择取决于开发者的兴趣和为链码开发选择的语言。最好使用 IDE 进行开发，以避免语法错误，将代码格式化为易于阅读的形式，并使开发变得轻松。

针对本书中示例用例的链码开发是使用VS Code（简称Visual Studio Code）进行的。VS Code 是微软推出的一款源代码编辑器，适用于 Windows、Linux 和 macOS。它包括开发、调试、版本控制、语法高亮、智能代码补全和重构等功能支持。

以下是在 VS Code 中链码文件的一些截图供参考：

• 这是源代码窗口：

VS Code 源代码窗口

• 需要直接安装的插件：

VS Code 插件直接安装

• VS Code 上有多个可安装的插件供选择的语言：

VS Code：插件

资产模型映射

链码导致在账本上创建资产（键值对），因为 HLF 将资产表示为键值对。资产状态变化记录为通道账本上的交易。有几种表示资产的方式——二进制或 JSON 形式。对于本书中的大学用例，定义了两种资产：

• 一个用于学生信息

• 另一个用于生成的证书

本章包括创建基本资产和链码，以便快速学习开发过程。随着用例模型本身的建模，更多资产和全面的操作集的包含可能会导致时间投入增加。稍后，当您对用例进行更多实验时，可以为其增加更多复杂性。

使用 Go 语言，以下是两种资产的定义：

1. 用于定义证书接收者的资产：

参数	描述
assetType	资产类型，例如，接收者
receiver_id	接收者/学生的 ID
receiver_name	接收者/学生的名称
upload_org	上传证书的组织/部门

1. 用于定义证书的资产：

参数	描述
assetType	资产类型，例如，证书。
Cert_id	证书的 ID。
Cert_no	证书的编号。
Cert_name	证书的名称。
Cert_receiver	证书的接收者。这将根据给定的Cert_receiver_id参数从分类帐中获取。
Cert_receiver_id	被分配此证书的接收者/学生的 ID。
Cert_issuer	证书的颁发者。
Cert_industry	证书所属行业/部门。
Cert_create_time	证书创建时间。
Cert_update_time	如果有任何更改，证书的更改时间。
Cert_remark	证书的备注或注释，如果有的话。
Cert_url_image	证书图片 URL。
Cert_learning_processing	证书学习进行中。
Cert_status	证书的状态。

链码是定义资产并允许对资产进行修改（也称状态变更）的软件程序（一组智能合约）或业务逻辑。任何交易（按照链码允许的）都会导致一组新的资产键值对的形成，或者修改资产的键值对，或者删除资产的键值对。

映射操作

链码（智能合约）生成的交易会分发到网络中的每个对等节点。经过共识后，它们将被不可变地记录在分类账的本地副本中。用户使用客户端应用程序或 dApp 调用这类交易（又称操作）。

这个表格集中讨论调用操作/交易的实现：

操作	描述
initReceiver	创建证书接收者（学生）的条目
queryReceiverById	通过给定的接收者 ID 获取接收者详情
insertCertificateInfo	创建证书条目
queryCertificateBytId	通过给定的证书 ID 获取证书详情
getHistoryForRecord	获取接收者（学生）信息或证书变更的历史记录
queryAllCertificates	获取所有证书
approveCertificate	更改证书的状态
del	在接收者或证书上进行标记删除

查看第三章，“深入了解 Hyperledger Fabric”，了解更多有趣的方面，例如并发检查、交易类型（如分类账查询和分类账更新交易）、交易流程以及交易涉及的各种其他组件。

解密链码开发的技艺

在 HLF 中，链码必须使用以下任一种语言实现链码接口：Go、Node.js 或 Java。链码开发人员可以选择其中任何一种编程语言进行开发。Fabric 的 shim 包（github.com/hyperledger/fabric/core/chaincode/shim）在链码开发中至关重要。

它支持以前的所有语言。该包有两个接口，在链码中发挥着关键作用。这些接口及其方法的语法可能会根据语言的不同而发生变化，但它们的目的是相同的。

当收到交易时，这些链码接口被调用。首先，当链码接收到交易请求时，Init方法被调用。这允许初始化应用程序状态。随后，当接收到调用事务时，将调用Invoke方法来处理任何交易提案。用于修改分类帐的其他接口，允许链码之间的调用，包括称为ChaincodeStubInterface的链码 shim API。

链码接口

链码接口是实现具有两个方法的链码的必备条件：

• Init():此方法在链码的生命周期中仅被调用一次，即在链码被实例化或升级时。此方法有助于设置分类帐的初始状态，例如初始化任何序列号。它期望将ChaincodeStubInterface对象作为输入，并返回peer.Response对象。

语法：Init(stub ChaincodeStubInterface)

• Invoke():此方法将帮助调用用户事务。您的代码中可能有多个操作，但当客户端发送请求到链码时，它只会到达Invoke()方法，从这里，此方法将派发到相应的事务。此方法还接受ChaincodeStubInterface对象的输入，并返回peer.Response对象。

语法：Invoke(stub ChaincodeStubInterface)

链码存根接口

Stub 接口提供了通过对对等体的调用来访问历史和分类帐状态的函数。每个事务都会调用Invoke()方法，并将函数和参数作为客户端请求的stub输入传递。这个接口促进了许多与分类帐交互的功能，并使链码开发变得简单。

链码函数

ChaincodeStub由fabric-shim库实现。它提供给ChaincodeInterface，并封装了链码实现和 Fabric 对等体之间的 API。

尽管stub有许多函数，但本节列出了一些经常使用的函数：

• getFunctionAndParameters() (string, []string):此方法有助于从stub中获取函数和参数。此方法返回两个值：作为字符串的函数名称和作为字符串数组的参数。

• getState(key string) ([]byte, error): 此方法通过给定的键从状态分类帐中获取数据。它不会读取尚未提交的分类帐中的数据。如果有任何错误，它将返回数据作为字节数组和错误信息。

• putState(key string, value []byte) (error): 此方法将给定值放入交易的写入集作为提案。直到交易有效且成功提交之前，它不会影响分类帐。这个决定将由 Orderer 做出。分类帐中的所有交易数据都仅存储为键值对。此方法接受两个参数：key——用于数据的唯一字符串值，value——要存储在分类帐中的数据的字节数组。如果在执行过程中出现任何错误，则此方法返回错误参数。相同的方法可以用于插入和更新。

• delState(key string) error: 此方法从分类帐中删除给定键的值。由于区块链分类帐中的数据不能永久删除，因此此方法标记数据已删除，区块仍然保留在分类帐中。此方法的输入是一个键，如果有错误则返回错误。

• getHistoryForKey(key string) (HistoryQueryIteratorInterface, error): 这是一个只读方法，用于获取分类帐中给定键的已提交交易的历史记录，以及交易 ID 和时间戳。此方法以键作为输入，并返回历史记录和错误的迭代器，如果有的话。

• getQueryResult(query string) (StateQueryIteratorInterface, error): 此方法针对状态数据库执行一个丰富查询。仅支持支持丰富查询的状态数据库，例如 Oracle、ATP 或 ADW。此方法的输入是基础状态数据库的本机语法中的查询字符串。如果有任何错误，则此方法返回结果和错误的迭代器。

• setEvent(name string, payload []byte) error: 这将事件设置为要包含在交易中的响应中的提案。无论交易的有效性如何，事件都将在已提交的交易块中可用。

除了链码中早期重要且常用的方法外，存根还具有以下方法：

getArgs() [][]byte

getStringArgs() []string

getArgsSlice() ([]byte, error)

getTxID() string

invokeChaincode(chaincodeName string, args [][]byte, channel string) 
pb.Response

getStateByRange(startKey, endKey string) (StateQueryIteratorInterface, error)

getStateByPartialCompositeKey(objectType string, keys []string) (StateQueryIteratorInterface, error)

createCompositeKey(objectType string, attributes []string) (string, error)

splitCompositeKey(compositeKey string) (string, []string, error)

getCreator() ([]byte, error)

getTransient() (map[string][]byte, error)

getBinding() ([]byte, error)

getSignedProposal() (*pb.SignedProposal, error)

getTxTimestamp() (*timestamp.Timestamp, error)

开发链码

此部分涵盖了在 Golang 中的实现。以下链码是使用 Go 语言开发的，用于在上一节中描述的操作/交易，使用上一节中的映射资产模型映射操作。

Go 语言中的链码

让我们看看 Go 语言中用于讨论的用例的链码开发：

1. import: 此部分导入所需的库：

import (
  "bytes"
  "encoding/json"
  "fmt"
  "strconv"
  "time"
  "github.com/hyperledger/fabric/core/chaincode/shim"
  "github.com/hyperledger/fabric/protos/peer"
)

1. type: 这将定义所需的资产结构：

// Chaincode implementation
type EducationChaincode struct {

}

// receiver/student struct
type Receiver struct {
  ObjectType string `json:"docType"` //docType is used to distinguish the various types of objects in state database
  Receiver_id string `json:"receiver_id"`
  Receiver_name string `json:"receiver_name"`
  Upload_org string `json:"upload_org"`
}

// certificate data struct
type Certificate struct {
  ObjectType string `json:"docType"` //docType is used to distinguish the various types of objects in state database
  Cert_id string `json:"cert_id"`
  Cert_no string `json:"cert_no"`
  Cert_name string `json:"cert_name"`
  Cert_receiver string `json:"cert_receiver"` // student name
  Cert_receiver_id string `json:"cert_receiver_id"` // student id
  Cert_issuer string `json:"cert_issuer"` // org name
  Cert_industry string `json:"cert_industry"`
  Cert_create_time string `json:"cert_create_time"`
  Cert_update_time string `json:"cert_update_time"`
  Cert_remark string `json:"cert_remark"`
  Cert_url_image string `json:"cert_url_image"`
  Cert_status string `json:"cert_status"`
}

1. main: 这是main方法开始执行的地方：

// main - Start execution
func main() {
  err := shim.Start(new(EducationChaincode))
  if err != nil {
    fmt.Printf("Error starting Xebest Trace chaincode: %s", err)
  }
}

1. Init: 此方法用于初始化链码，同时实例化链码：

// Init initializes chaincode
func (t *EducationChaincode) Init(stub shim.ChaincodeStubInterface) peer.Response {
  return shim.Success(nil)
}

1. Invoke: 此方法用于绕过或执行用户事务：

// Invoke - Invoking user transactions
func (t *EducationChaincode) Invoke(stub shim.ChaincodeStubInterface) peer.Response {
  function, args := stub.GetFunctionAndParameters()
  fmt.Println("invoke is running " + function)

  // Handle different functions
  if function == "insertReceiver" { //create a new Receiver or student
    return t.insertReceiver(stub, args)
  } else if function == "queryReceiverById" { // query a receiver by id, stupid name - -!
    return t.queryReceiverById(stub,args)
  } else if function == "insertCertificate" { //insert a cert
    return t.insertCertificate(stub, args)
  } else if function == "queryCertificateById" { // query a certificate
    return t.queryCertificateById(stub, args)
  } else if function == "getRecordHistory"{ //query hisitory of one key for the record
    return t.getRecordHistory(stub,args)
  } else if function == "queryAllCertificates"{ // query all of all students
    return t.queryAllCertificates(stub,args)
  } else if function == "approveCertificate" { // change status
    return t.approveCertificate(stub,args) 
  }else if function == "deleteRecord" { // delete student or certificate
    return t.deleteRecord(stub, args)
  }

  fmt.Println("invoke did not find func: " + function) //error
  return shim.Error("Received unknown function invocation")
}

1. insertReceiver：此方法用于将学生或证书接收者插入链码状态：

// initReceiver - insert a new Receiver into chaincode state
func (t *EducationChaincode) insertReceiver(stub shim.ChaincodeStubInterface, args []string) peer.Response {
  var err error

  if len(args) != 3 {
    return shim.Error("Incorrect number of arguments. Expecting 3")
  }

  fmt.Println("start insert receiver")

  receiver_id := args[0]
  receiver_name := args[1]
  upload_org := args[2]

  // Check if the receiver already exists with the id
  receiverAsBytes, err := stub.GetState(receiver_id)
  if err != nil {
    return shim.Error("Failed to get receiver: " + err.Error())
  } else if receiverAsBytes != nil {
    fmt.Println("This receiver already exists: " + receiver_id)
    return shim.Error("This receiver already exists: " + receiver_id)
  }

  // Create receiver object and marshal to JSON 
  objectType := "receiver"
  receiver := &Receiver{objectType, receiver_id, receiver_name,upload_org}
  receiverJSONasBytes, err := json.Marshal(receiver)
  if err != nil {
    return shim.Error(err.Error())
  }

  fmt.Println("receiver: ")
  fmt.Println(receiver)
  // Save the receiver to ledger state
  err = stub.PutState(receiver_id, receiverJSONasBytes)
  if err != nil {
    return shim.Error(err.Error())
  }

  // receiver saved and indexed. Return success
  fmt.Println("End init receiver")
  return shim.Success(nil)

}

1. queryReceiverById：此方法通过给定的 ID 获取接收者记录：

// queryReceiverById - read data for the given receiver from the chaincode state
func (t *EducationChaincode) queryReceiverById(stub shim.ChaincodeStubInterface, args []string) peer.Response {
  var recev_id, jsonResp string
  var err error

  if len(args) != 1 {
    return shim.Error("Incorrect number of arguments. Expecting receiver_id to query")
  }

  recev_id = args[0]
  //Read the Receiver from the chaincode state
  valAsbytes, err := stub.GetState(recev_id) 
  if err != nil {
    jsonResp = "{\"Error\":\"Failed to get state for " + recev_id + "\"}"
    return shim.Error(jsonResp)
  } else if valAsbytes == nil {
    jsonResp = "{\"Error\":\"receiver does not exist: " + recev_id + "\"}"
    return shim.Error(jsonResp)
  } 
  return shim.Success(valAsbytes)
}

1. insertCertificate：此方法用于将新证书信息插入账本状态：

// insertCertificate - insert a new certificate information into the ledger state
func (t *EducationChaincode) insertCertificate(stub shim.ChaincodeStubInterface, args []string) peer.Response {

  if len(args) != 11 {
    return shim.Error("Incorrect number of arguments. expecting 11 args")
  }

  cert_id := args[0]
  cert_no := args[1]
  cert_name := args[2] 
  cert_receiver_id := args[3]
  cert_issuer := args[4]
  cert_industry := args[5]
  cert_create_time := args[6]
  cert_update_time := args[7]
  cert_remark := args[8]
  cert_url_image := args[9]
  cert_status := args[10]

  // check if receiver exists
  ReceAsBytes, err := stub.GetState(cert_receiver_id)
  if err != nil {
    return shim.Error("Failed to get Receiver:" + cert_receiver_id + "," + err.Error())
  } else if ReceAsBytes == nil {
    fmt.Println("Receiver does not exist with id: " + cert_receiver_id )
    return shim.Error("Receiver does not exist with id: " + cert_receiver_id )
  }

  //Fetch receiver name from the state
  receiver := &Receiver{}
  err = json.Unmarshal([]byte(ReceAsBytes), &receiver)
  if err != nil {
    return shim.Error(err.Error())
  }
  cert_receiver :=receiver.Receiver_name;
  fmt.Println("cert_receiver: "+cert_receiver)

  objectType := "certificate"
  certificate := &Certificate{objectType,cert_id,cert_no,cert_name,cert_receiver,cert_receiver_id,cert_issuer,cert_industry,cert_create_time,cert_update_time,cert_remark,cert_url_image,cert_status}
  certificateJSONasBytes, err := json.Marshal(certificate)
  if err != nil {
    return shim.Error(err.Error())
  }

  // insert the certificate into the ledger
  err = stub.PutState(cert_id, certificateJSONasBytes)
  if err != nil {
    return shim.Error(err.Error())
  }

  // certificate saved - Return success 
  return shim.Success(nil)
}

1. queryCertificateById：此方法通过给定的证书 ID 从账本状态中获取证书详细信息：

// queryCertificateById - read a certificate by given id from the ledger state
func (t *EducationChaincode) queryCertificateById(stub shim.ChaincodeStubInterface, args []string) peer.Response {
  var cert_id, jsonResp string
  var err error

  if len(args) != 1 {
    return shim.Error("Incorrect number of arguments. Expecting id of the certificate to query")
  }

  cert_id = args[0]
  //Read the certificate from chaincode state
  valAsbytes, err := stub.GetState(cert_id) 
  if err != nil {
    jsonResp = "{\"Error\":\"Failed to get state for " + cert_id + "\"}"
    return shim.Error(jsonResp)
  } else if valAsbytes == nil {
    jsonResp = "{\"Error\":\"certificate does not exist: " + cert_id + "\"}"
    return shim.Error(jsonResp)
  }

  return shim.Success(valAsbytes)
}

1. approveCertificate：此方法用于由授权机构批准证书：

// approveCertificate - approve the certificate by authority
func (t *EducationChaincode) approveCertificate(stub shim.ChaincodeStubInterface, args []string) peer.Response {

  var err error
  // check args
  if len(args) != 3 {
    return shim.Error("Incorrect number of arguments. Expecting 3")
  }
  if len(args[0]) <= 0 {
    return shim.Error("1st argument must be a non-empty string")
  }
  if len(args[1]) <= 0 {
    return shim.Error("2nd argument must be a non-empty string")
  }
  if len(args[2]) <= 0 {
    return shim.Error("3rd argument must be a non-empty string")
  }

  cert_id := args[0]
  status := args[1]
  update_time := args[2]

  //Read certificate details from the ledger
  valAsbytes, err := stub.GetState(cert_id) 
    if err != nil {
      return shim.Error(err.Error())
    } else if valAsbytes == nil {
      return shim.Error("certificate not exist")
    }

  certificate := &Certificate{}
  err = json.Unmarshal([]byte(valAsbytes), &certificate)
  if err != nil {
    return shim.Error(err.Error())
  }
  certificate.Cert_status = status
  certificate.Cert_update_time = update_time

  valAsbytes, err = json.Marshal(certificate)
  if err != nil {
    return shim.Error(err.Error())
  }
  //Update the certificate in the ledger
  err = stub.PutState(cert_id, valAsbytes)
  if err != nil {
    return shim.Error(err.Error())
  }

  return shim.Success(nil)
}

1. queryAllCertificates：此方法用于从账本状态查询所有证书：

// queryAllCertificates - Query all certificates from the ledger state
func (t *EducationChaincode) queryAllCertificates(stub shim.ChaincodeStubInterface, args []string) peer.Response {

  queryString := "{\"selector\":{\"docType\":\"certificate\"}}"

  queryResults, err := getQueryResultForQueryString(stub, queryString)
  if err != nil {
    return shim.Error(err.Error())
  }
  return shim.Success(queryResults)
}

1. getRecordHistory：此方法获取给定记录的关键状态转换的历史记录：

// getRecordHistory - Fetches the historical state transitions for a given key of a record
func (t *EducationChaincode) getRecordHistory(stub shim.ChaincodeStubInterface, args []string) peer.Response {

  if len(args) < 1 {
    return shim.Error("Incorrect number of arguments. Expecting an id of Receiver or Certificate")
  }

  recordKey := args[0]

  fmt.Printf("Fetching history for record: %s\n", recordKey)

  resultsIterator, err := stub.GetHistoryForKey(recordKey)
  if err != nil {
    return shim.Error(err.Error())
  }
  defer resultsIterator.Close()

  // buffer is a JSON array containing historic values for the key/value pair
  var buffer bytes.Buffer
  buffer.WriteString("[")

  bArrayMemberAlreadyWritten := false
  for resultsIterator.HasNext() {
    response, err := resultsIterator.Next()
    if err != nil {
      return shim.Error(err.Error())
    }
    // Add a comma before array members, suppress it for the first array member
    if bArrayMemberAlreadyWritten == true {
      buffer.WriteString(",")
    }
    buffer.WriteString("{\"TxId\":")
    buffer.WriteString("\"")
    buffer.WriteString(response.TxId)
    buffer.WriteString("\"")

    buffer.WriteString(", \"Value\":")
    // if it was a delete operation on given key, then we need to set the
    //corresponding value null. Else, we will write the response.Value
    //as-is (as the Value itself a JSON goods)
    if response.IsDelete {
      buffer.WriteString("null")
    } else {
      buffer.WriteString(string(response.Value))
    }

    buffer.WriteString(", \"Timestamp\":")
    buffer.WriteString("\"")
    buffer.WriteString(time.Unix(response.Timestamp.Seconds, int64(response.Timestamp.Nanos)).String())
    buffer.WriteString("\"")

    buffer.WriteString(", \"IsDelete\":")
    buffer.WriteString("\"")
    buffer.WriteString(strconv.FormatBool(response.IsDelete))
    buffer.WriteString("\"")

    buffer.WriteString("}")
    bArrayMemberAlreadyWritten = true
  }
  buffer.WriteString("]")

  fmt.Printf("Result of getHistoryForRecord :\n%s\n", buffer.String())

  return shim.Success(buffer.Bytes())
}

1. getQueryResultForQueryString：如果需要，此方法在账本状态上执行给定的rich查询：

// getQueryResultForQueryString executes the passed in query string.
// Result set is built and returned as a byte array containing the JSON results.

func getQueryResultForQueryString(stub shim.ChaincodeStubInterface, queryString string) ([]byte, error) {

  fmt.Printf("getQueryResultForQueryString queryString:\n%s\n", queryString)

  resultsIterator, err := stub.GetQueryResult(queryString)
  if err != nil {
    return nil, err
  }
  defer resultsIterator.Close()

  // buffer is a JSON array containing QueryRecords
  var buffer bytes.Buffer
  buffer.WriteString("[")

  bArrayMemberAlreadyWritten := false
  for resultsIterator.HasNext() {
    queryResponse, err := resultsIterator.Next()
    if err != nil {
      return nil, err
    }
    // Add a comma before array members, suppress it for the first array member
    if bArrayMemberAlreadyWritten == true {
      buffer.WriteString(",")
    }
    buffer.WriteString(string(queryResponse.Value))
    bArrayMemberAlreadyWritten = true
  }
  buffer.WriteString("]")

  fmt.Printf("getQueryResultForQueryString queryResult:\n%s\n", buffer.String())

  return buffer.Bytes(), nil
}

1. deleteRecord：此方法将以给定的键标记记录为已删除：

// deleteRecord - Mark the record deleted by given key

func (t *EducationChaincode) deleteRecord(stub shim.ChaincodeStubInterface, args []string) peer.Response {

  if len(args) != 1{
    return shim.Error("Incorrect number of arguments. Expecting 1")
  }

  id := args[0]
  err := stub.DelState(id)
  if err != nil {
    return shim.Error(err.Error())
  }

  return shim.Success(nil)
}

在本书引用的 GitHub 存储库中也可以下载前述链码。文件名为education.go。

Node.js 中的链码

让我们来看看使用 Node.js 开发链码的流程：

• 使用fabric-shim包创建一个 Node.js 文件

• 创建一个包含 Node.js 文件和依赖项详情的package.json文件（如果有的话）

• 将所有文件打包到一个 ZIP 文件中，包括package.json、主 Node.js 文件以及其他 JavaScript 或配置文件或依赖项（如果有的话）

• 在 OBP 的Chaincode选项卡下部署该包（参考链码部署部分）

注意：您只需创建一个package.json文件；无需运行npm命令来安装node_modules，因为 OBP 会在内部为您执行此操作。

名为education.js的示例 Node.js 文件。

使用fabric-shim包创建一个 Node.js 文件：

const shim = require('fabric-shim');
const Chaincode = class {
    async Init(stub) {
        return shim.success();
    }
    async Invoke(stub) {
        let ret = stub.getFunctionAndParameters();
        let method = this[ret.fcn];
        console.log("Inside invoke. Calling method: " + ret.fcn);
        if (!method) {
            shim.error(Buffer.from('Received unknown function ' + ret.fcn + ' invocation'));
        }
        try {
            let payload = await method(stub, ret.params);
            return shim.success(payload);
        } catch (err) {
            console.log(err);
            return shim.error(err);
        }
    }

    //Method to save or update a user review to a product

    async insertReceiver(stub, args) {
        console.log("inside insertReceiver: " + JSON.stringify(args));
        if (args.length != 3) {
            throw 'Incorrect number of arguments. Expecting ID,Name and Org.';
        }
        var receiver = {};
                             receiver.ObjectType = "receiver";
        receiver.Receiver_id = args[0];
        receiver.Receiver_name = args[1];
        receiver.Upload_org = args[2];
        await stub.putState(receiver.Receiver_id, Buffer.from(JSON.stringify(receiver)));
    }//End of method
}

shim.start(new Chaincode());

名为package.json的示例 JSON 文件。

创建一个包含 Node.js 文件和依赖项详情的package.json文件（如果有的话）：

{
  "name": "education",
  "version": "1.0.0",
  "description": "Chaincode implemented in node.js",
  "engines": {
    "node": ">=8.9.0",
    "npm": ">=5.5.0"
  }, 
  "scripts": { 
    "start" : "node education.js"
  },
  "engine-strict": true,
  "license": "Apache-2.0",
  "dependencies": { 
    "fabric-shim": "~1.3.0"
  } 
}

可以从本书引用的 GitHub 存储库中下载带有package.json文件的示例 Node.js 代码。

向链码添加事件

链码还可以发布事件，以通知订阅应用程序进一步处理客户端操作。例如，在链码匹配采购订单、发票和交货记录后，它可以发布事件，以便订阅应用程序可以处理相关付款并更新内部 ERP 系统。

OBP 支持以下类型的事件，可以通过 REST 代理订阅：

• transaction：事务 ID 的事件

• txOnChannel：通道上每个新事务的事件

• txOnNetwork：整个网络中每个新事务的事件

• blockOnChannel：特定通道上每个区块的事件

• blockOnNetwork：整个网络中新区块的事件

• chaincodeEvent：链码逻辑发出的自定义事件

发布事件

在这里，我们将看到如何从链码触发事件。使用 ChaincodeStubInterface 的 SetEvent() 方法，链码可以触发事件。在 approveCertificate() 方法中添加以下代码以在证书状态更改后发出事件：

var testEventValue []byte

testEventValue=[]byte("Certificate "+cert_id+" status is changed to "+status)

stub.SetEvent("testEvent",testEventValue)

订阅事件

事件可以通过 REST 代理或 HLF SDK 进行订阅。以下是通过 REST 代理订阅的步骤：

• REST 端点：<主机名>:<端口>/<REST 代理>/bcsgw/rest/v1/event/subscribe

• REST 方法：POST

• 标头：

  • 内容类型：application/json

  • 授权：<基本授权>

  • 接受字符集：UTF-8：

• 传递给 REST API 的 JSON 输入：

{
  "requests":[
  {
    "eventType":"chaincodeEvent",
    "callbackURL": "--- call back webhook url---",
    "callbackTlsCerts":{
      "caCert":" -- mandatory field which is the callback server's CA certificate in PEM format. It will be verified by REST proxy",
      "clientCert": "--Optional field which refers to the REST proxy certificate should use during callback --",
      "keyPassword": "--clientCert's encrypted private key in base64 encoded"
    },
    "expires": "1m",
    "channel": "channeleducation",
    "chaincode": "cceducation",
    "eventName": "testEvent"
  }
  ]
}

• 响应为 subid。

取消订阅事件

事件也可以取消订阅。要执行此操作，请按照订阅的相同步骤操作，但将端点和输入替换为以下内容：

• REST 端点：<主机名>:<端口>/<REST 代理>/bcsgw/rest/v1/event/unsubscribe

• JSON 输入：

{

    "request":{

    "subid": "---subscription id received---"
  }

}

链码部署

链码部署是一个多步骤的过程。它包括链码部署（快速或高级方法）、链码实例化、在 REST 代理中启用链码以及升级链码。在 OBP 上部署链码的先决条件包括具有部署链码的 OBP 实例的管理访问权限。链码可以由通道的创建者或参与者从任何实例安装和实例化。一旦它被实例化，通道的其他实例只需要安装链码。该实例化将自动应用于这些实例。在本节中，我们将从创建者实例部署链码。

部署链码

OBP 提供了两种不同的部署选项。一种是一步链码部署的快速部署选项，另一种是高级部署选项。快速启动部署选项推荐用于链码测试，而高级部署选项允许您指定各种高级部署设置，例如选择要安装链码的对等方、要使用的背书策略等。本节展示了两种部署选项。

部署链码的步骤如下：

1. 导航到 链码 选项卡：

链码部署

1. 单击 部署新链码 按钮。将打开以下屏幕，其中包含两个部署选项：

链码部署选项

1. 快速部署：一步链码部署选项使用默认设置，并在所选的 REST 代理中启用。然而，我们将在本节中使用 高级部署 选项来部署我们的链码。以下是您可以参考的 快速部署 屏幕：

快速链码部署

1. 高级部署提供了一个多步骤向导，用于安装、实例化和启用链码的 REST 代理。从部署链码菜单中选择此选项。将打开逐步向导，第一步如下，您将提供链码的详细信息，如链码名称、版本、应部署链码的目标对等方以及实际链码包。 （如果是单个.go文件，则不需要包。可以选择单个文件，但如果有多个文件或代码是用 Node.js 或 Java 编写的，则将所有文件打包成 ZIP 文件。）填写以下屏幕截图中显示的字段，然后单击下一步。请记住，安装链码后不能更改这些值：

详细页面

1. 安装Install过程成功后，向导将显示第二步，即Instantiate。每个通道每个版本只会实例化一次链码。在此步骤中，您指定应将链码应用于哪个通道；参与的对等方；初始参数数组（如果有）要传递给链码中的Init()方法；背书策略（如果有的话，请参阅下一节以了解背书策略的详细信息）；以及私有数据集合（请参阅下一节以了解详细信息）。填写表单如下并单击下一步；可能需要一段时间才能进入下一步：

高级链码部署

1. 链码成功实例化后，向导将显示第 3 步，即在 REST 代理中启用链码。OBP 提供多个 REST 代理。您可以选择多个 REST 代理以启用链码。按照以下字段填写并单击下一步：

REST 代理

1. 在向导的所有步骤完成之后，最后，您将看到此成功屏幕。单击关闭：

部署完成消息

1. 到目前为止，您已在创建者实例中部署了链码。您需要在所有参与者实例中部署链码。重复我们刚刚看到的部署过程；但是，您只需要部署链码——实例化将自动应用，因为它是从通道的创建者中完成的。因此，在高级部署向导中，在第 1 步安装完成后，在第 2 步屏幕上，单击关闭按钮。

2. 转到通道选项卡。您将发现链码已实例化。请查看以下参考资料。

以下是安装链码前的通道：

安装链码前通道

以下屏幕截图显示了安装链码后的通道：

安装链码后通道

一个通道上可以安装多个链码。此外，一个链码可以在多个 REST 代理上启用。

更新链码

HLF 支持链码版本控制和升级。当智能合约需要更改、业务逻辑发生变化或链码需要任何更改时，您可以更新链码。只要保持相同的链码名称，就可以将链码升级到新版本，否则将被视为不同的链码。

更新是区块链网络上的一个交易，它导致将链码的新版本绑定到通道上。旧版本的链码会发生什么情况？绑定到以前（旧）版本链码的所有其他通道可以继续执行旧版本。您向通道提交链码升级交易。因此，只有一个通道受到影响，您已经执行了升级交易的通道。所有其他通道，在这些通道上未执行升级交易的情况下，将继续运行旧版本。调用链码时，只会执行最新实例化的版本。

更新链码的过程如下所示：

1. 转到链码选项卡。

2. 对链码选择升级选项，位于更多操作下。将打开一个多步向导。

3. 在第 1 步：选择版本中，选择目标对等方并浏览链码源包。然后点击下一步：

升级链码-选择版本

1. 在第 2 步：升级中，提供通道名称、对等方、初始参数（如果有）和背书策略（如果有）。然后点击下一步：

升级链码-实例化信息

1. 链码成功升级后，您将看到以下屏幕。点击关闭，然后为其他参与方重复相同的过程：

链码升级

背书策略

背书策略指定了必须在链码交易被添加到块并提交到账本之前正确批准或背书链码交易的具有对等方的组织。您可以在链码部署过程中的第 2 步实例化链码时在 OBP 中添加背书策略。背书保证交易的合法性。如果未指定背书策略，则使用默认背书策略，该策略从网络上的任何对等方获取背书。

组织的背书对等方必须在通道上拥有读写权限。当处理交易时，每个背书对等方都返回一个读写集，然后客户端将这些背书对等方与它们的签名捆绑在一起，并将所有内容发送到排序服务，排序并提交交易到区块，然后到账本。

在下面的屏幕截图中，您可以在实例化链码时看到背书策略配置。您可以简单地在 Signed by 字段中指定有多少人必须参与背书，或者通过选择高级选项，也可以通过表达式指定这一点。在我们的用例中，我们正在使用默认的背书策略：

背书策略

私有数据集合

OBP 版本 19.1.3 及更高版本具有用于指定背书、提交或在通道上查询私有数据的组织子集的功能——私有数据集合。私有数据集合对于希望在通道上共享数据并防止通道上的其他组织看到数据的组织组是有用的。在链码实例化时可以关联一个或多个私有数据集合，如下所示。此外，您应该指定一个瞬态映射，以将客户端的私有数据传递给节点以进行背书。

下面的屏幕截图显示了私有数据集合在链码实例化时的情况：

测试链码

可以在 OBP 上本地测试链码，而无需安装它。有两种测试链码的方式：使用模拟的 shim 和使用 REST 端点。

使用 shim 测试链码

让我们看看如何在本地开发的 Go 语言中测试之前的链码。在此之前，请注意以下要点：

• 在本地计算机上安装 Go 语言。

• 此测试文件名应采用此形式：<Go file name>_test.go。

例如：如果链码名称为education.go，那么此测试文件名应为education_test.go。

• 将两个文件放在同一个文件夹中。

• 将 GOPATH 设置为该文件夹。

• 如果找不到链码中使用的依赖包，请安装它们。

例如：go get github.com/hyperledger/fabric/protos/peer

go get github.com/hyperledger/fabric/core/chaincode/shim.C

• 代码片段文件 education_test.go 位于 GIT 存储库 (github.com/PacktPublishing/Oracle-Blockchain-Quick-Start-Guide)，是一个仅包含一个方法initReceiver()的测试用例，附带解释。同样，您可以为所有其他方法编写测试用例。

• 每个测试用例都应以Test<function name>为前缀。

  例如：TestInitReceiver。

• 测试用例准备好后，使用以下命令进行测试：

go test -run <<function name>>

例如：go test -run Education。

这里，Education是测试用例名称。

要测试一个函数，使用 NewMockStub() 创建一个存根。该存根有一个MockInvoke()函数，它调用链码的实际函数。

例如，stub.MockInvoke("001",[][]byte{[]byte("insertReceiver "), []byte(key),[]byte("Anand Yerrapati"), []byte("Blockchain")})。

这里，001 是要在测试成功后返回的交易 ID，insertReceiver 是要在 education.go 文件中调用的函数。其余参数是要传递给 insertReceiver 函数的参数。

请参考 GIT 仓库中的文件 'education_test.go'，GIT 仓库网址为 "https://github.com/PacktPublishing/Oracle-Blockchain-Quick-Start-Guide-"。

用于测试链码的测试文件名为 (education.go)，测试文件名为 "education_test.go"。在本节中，此文件用于通过 shim 测试链码。

这个测试案例是为了测试流程，从插入接收方、查询接收方、插入证书、验证证书、批准证书，再查询证书，最后验证更改。在执行 go test -run Education 命令后，以下是早前测试案例的结果：

D:\Anand\OBP\chaincode\testing\go>go test -run Education
 Inside TestEducation
 invoke is running insertReceiver
 start insert receiver
 receiver:
 &{receiver std1231 Anand Y Blockchain}
 End init receiver
 Result insertReceiver:
 {200 [] {} [] 0}
 invoke is running queryReceiverById
 Result queryReceiverById:
 &{receiver std1231 Anand Y Blockchain}
 invoke is running insertCertificate
 cert_receiver: Anand Y
 {200 [] {} [] 0}
 Result insertCertificate:
 {200 [] {} [] 0}
 invoke is running queryCertificateById
 Result queryCertificateById:
 &{certificate cert123 12345 ORU Blockchain Certificate Anand Y std1231 ORU IT 06/04/2019 06/04/2019 Blockchain course completed Active}
 invoke is running approveCertificate
 {200 [] {} [] 0}
 Result approveCertificate:
 {200 [] {} [] 0}
 invoke is running queryCertificateById
 Result queryCertificateById:
 &{certificate cert123 12345 ORU Blockchain Certificate Anand Y std1231 ORU IT 06/04/2019 06/04/2019 10:41:50 Blockchain course completed Approved}
 PASS
 ok _/D_/Anand/OBP/chaincode/testing/go 3.921s

虚拟存根不支持每个功能。无法实现 GetQueryResult 和 GetHistoryForKey 方法。

从 REST 端点测试链码

OBP 提供一个 REST 代理以通过 REST 端点连接链码。希望通过 REST 服务执行的任何链码应配置在相应的 REST 代理上。可以在本章 链码部署 部分中查看此配置。在本节中，我们将看到如何调用 REST 端点，如何连接到所需的函数，以及如何传递参数。

有两个可用的 REST 端点：

• 查询：执行从分类帐查询数据的任何功能：

语法：<主机名>:<端口>/<restproxy>/bcsgw/rest/v1/transaction/query

• 调用：执行保存数据到分类帐或从分类帐查询数据的任何功能。也可以从此端点执行查询，不过，获取和返回数据的速度会较慢。因此，在从分类帐提取数据时建议使用查询端点：

语法：<主机名>:<端口>/<restproxy>/bcsgw/rest/v1/transaction/invocation

对于这两个端点，请求输入相同，即为一个 JSON 请求，以下是一个典型的 JSON 请求结构：

{
"channel":<channel name>,
"chaincode":<chaincode name>,
"method": <method name>,
"args":[<arguments separated by comma>]
}

可以在单个 REST 代理中配置多个链码。因此，输入 JSON 中的 通道 和 链码 参数有助于将请求分发到相应的链码。两个端点都是 POST 调用。每次调用都应传递两个标头，授权 和 内容类型。

我们正在使用 OBP SDK，其具有默认的用户名和密码：customertenant@oracle.com/ 和 Welcome1。

标头应如下所示：

• 授权：Basic Y3VzdG9tZXJ0ZW5hbnRAb3JhY2xlLmNvbTpXZWxjb21lMSA=

• 内容类型：application/json

• 目标端点：https://<主机名>:<端口>/<restproxy>/bcsgw/rest/v1/transaction/<invocation 或 query>

这些是用于从 Postman 测试早期链码的参考（您可以在此处使用任何 REST 客户端进行测试）。以下是目标端点调用的输入 -

• 目标终点 - 插入接收方的调用：

  • 目标终点：/invocation

  • 目标方法：insertReceiver

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"insertReceiver","args":["std123", "Anand Yerrapati", "Blockchain"]}

• 目标终点 - 查询按接收者 ID 查询：

  • 目标终点：/query

  • 目标方法：queryReceiverById

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"queryReceiverById","args":["std123"]}

• 目标终点 - 插入证书的调用：

  • 目标终点：/invocation

  • 目标方法：insertCertificate

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"insertCertificate","args":["cert1234","1234","ORU Blockchain Certificate","std123","ORU","IT","6/5/2019","","Blockchain Course Completed","","","Issued"]}

• 目标终点 - 通过 ID 查询证书的调用：

  • 目标终点：/query

  • 目标方法：queryCertificateById

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"queryCertificateById","args":["cert1234"]}

• 目标终点 - 批准证书的调用：

  • 目标终点：/invocation

  • 目标方法：approveCertificate

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"approveCertificate","args":["cert1234","Approved","6/5/2019 05:04:45 PM"]}

• 目标终点 - 通过 ID 查询证书的调用：

  • 目标终点：/query

  • 目标方法：queryCertificateById

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"queryCertificateById","args":["cert1234"]}

• 目标终点 - 查询所有证书的调用：

  • 目标终点：/query

  • 目标方法：queryAllCertificates

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"queryAllCertificates","args":[]}

• 目标终点 - 查询端点以获取记录历史的调用：

  • 目标终点：/query

  • 目标方法：getRecordHistory

  • 输入 JSON：{"channel":"channeleducation","chaincode":"cceducation","method":"getRecordHistory","args":["cert1234"]}

以下是getRecordHistory的响应：

响应消息

链代码日志

链码中给出的系统生成的打印语句的日志可供查看。在 OBP 中，这些日志可以下载或内联查看。此外，我们可以选择所选对等方的日志或所选链码版本的日志。您可以访问部署了链码的对等方上的链码执行的日志文件。以下是打开日志文件的步骤：

1. 转到链码选项卡并找到您想要查看日志的链码。

2. 展开链码。

3. 单击您想要的链码版本 - 将显示版本信息

4. 在已安装在对等方选项卡上，找到对等方

5. 单击日志链接，将打开查看链码日志对话框

6. 您还可以通过选择节点选项卡下指定对等方的日志选项卡来打开日志文件，如下图所示：

链码日志

通道账本

账本是区块链网络所有交易区块的最终存储。每个通道都有自己的账本，对通道中的所有组织都是公共的。组织可以对账本拥有读取、写入或两者权限来处理交易。账本只能通过链码进行查询或更新。OBP 在其控制台中提供了一个选项，可以查看通道上的账本上的区块。账本上的每个区块都存储了交易 ID、链码名称、状态、函数名称、交易的发起者、背书人和参数列表。您还可以看到总区块数和总用户交易数的计数。

通过按照这个步骤，您可以查看通道账本上的数据：

1. 转到通道选项卡。

2. 定位您想要的通道并单击通道名称。

3. 在账本选项卡下，您可以查看通道的所有区块交易。

4. 选择任何交易以查看其详细信息，如下面的屏幕截图所示：

将客户端应用程序与区块链集成

到目前为止，我们已经探索了 OBP 并对在 OBP 上开发、部署和测试链码进行了实验。本节是第三章中深入探讨 Hyperledger Fabric节的复习，以下集成架构图突出了与 OBP 的三种集成选项：REST、SDK 和事件。

当使用 REST API 与 OBP 构建和集成客户端时——参考从 REST 端点测试链码部分*——了解使用 REST 端点调用链码事务的用途是很有帮助的。REST 端点可以与客户端应用程序集成，并通过传递相应的头部（例如授权、内容类型以及包括强制性频道名称和链码名称字段以及所需参数在内的输入 JSON）来执行它们。响应也是 REST JSON，应该在客户端应用程序中处理。对于使用客户端 SDK 连接区块链，OBP 提供了 REST API。REST API 允许灵活地调用、查询和查看交易的状态。但是，如果应用程序需要更加精细的操作，那么 HLF SDK 是一种替代方法：

集成架构

参考第三章的深入研究 Hyperledger Fabric中的集成架构部分，了解应用程序与区块链的基于样本的集成策略。

运行端到端流程

本节是本章学习的快速回顾：

端到端流程

以下是在探索大学用例并与 OBP 合作尝试在 OBP 上开发流程中执行的步骤列表：

• 确定了区块链网络的创始人（在我们的案例中，是 OEU）

• 发现了网络的参与者组织（在我们的案例中是 CVS 和 ORS）

• 在 OBP 中创建了一个创始人和两个参与者实例

• 导出了创始人的 Orderer 证书

• 将 Orderer 证书导入到两个参与者组织的网络选项卡中

• 导出了每个参与者组织的网络证书

• 将两个组织的证书添加到创始人网络中

• 在创始人中为所有三个组织创建了一个通道，channeleducation。

• 在创始人和参与者中的通道中加入了对等体

• 导出了每个参与者的对等体，并将其导入到创始人中（这可能需要您查看网络所有对等体的综合拓扑视图；然而，此步骤对于参与背书的组织是必需的）

• 在创始人中安装和实例化链码（链码名称：cceducation）

• 在其他参与者中安装了链码

• 启用/配置 REST 代理以访问所有组织的链码

• 使用各自组织的 REST 端点连接到客户端应用程序

总结

本章介绍了链码开发的详细信息，如语言部分、开发工具和开发环境设置。它详细描述了链码的完整生命周期，从开发到更新，其中包括安装、初始化、测试和版本控制。它展示了基于 Go 和 Node.js 构建的完整链码代码库。它说明了背书策略和私有数据集以及它们与链码协同运作的方式。它通过 shim 和 REST 端点对链码进行了测试，并使用 SDK、REST 和事件将客户端应用程序与业务网络集成。最后，通过实验监控业务的链码日志和通道日志，对链码、交易和通道进行了深入的洞察。

这本知识总账的创建是基于这样一个信念，即我们共同将积极地促进区块链技术的发展，并不断地激励他人分享他们的经验，并进一步影响其他人这样做。因此，火炬传递给了你，通过分享继续影响，因为分享就是关怀，而我们共同致力于创造一个更智慧的世界。