Hyperledger Fabric 专题 - Peers

区块链网络主要由一组对端节点 (peer nodes, or simply, peers) 组成。对端节点是网络的基本元素，因为它们托管帐本和智能合约。回想一下，账本一成不变地记录了智能合约生成的所有交易 (Hyperledger Fabric 中的交易包含在链码中，稍后会详细介绍)。智能合约和账本分别用于封装网络中的共享过程 (shared process) 和共享信息 (shared information)。对端节点的这些方面使它们成为了解 Fabric 网络的良好起点。

区块链网络的其他元素当然很重要：帐本和智能合约，交易排序器，策略，通道，应用程序，组织，身份标识和成员资格服务提供商，你可以在其专用部分中阅读有关它们的更多信息。本节重点介绍对端节点及其与 Fabric 网络中其他元素的关系。

image

区块链网络由对端节点组成，每个对端节点可以保存账本的副本和智能合约的副本。在此示例中，网络 N 由对端节点 P1，P2 和 P3 组成，每个对端节点 P1，P2 和 P3 维护自己的分布式账本 L1 实例。 P1，P2 和 P3 使用相同的链码 S1 来访问其分布式账本的副本。

可以创建，启动，停止，重新配置甚至删除对端节点。它们公开了一组 API，使管理员和应用程序可以与其提供的服务进行交互。我们将在本节中详细了解这些服务。

1. 术语

Fabric 通过称为链码 (chaincode) 的技术概念来实现智能合约(smart contract) - 只是访问账本的一段代码，以受支持的编程语言中的任一种编写。在本主题中，我们通常使用术语“链码”，但是如果你更习惯智能合约这个术语，可以随时将其作为智能合约来阅读。这是同一件事！如果你想了解有关链码和智能合约的更多信息，请查看我们关于智能合约和链码的文档。

2. 分布式账本和链码

让我们再详细一点。我们可以看到，同时托管帐本和链码的是对端节点。更准确地说，对端节点实际上是托管帐本实例和链码实例的宿主。请注意，这在 Fabric 网络中提供了有意的冗余 - 避免了单点故障。在本节的后面，我们将详细了解区块链网络的分布式和去中心化性质。

[图片上传失败...(image-4d3467-1573120639360)]

对端节点托管账本实例和链码实例。在此示例中，P1 承载帐本 L1 的实例和链码 S1 的实例。单个对端节点主机上可以托管许多帐本和链码。

由于对端节点是帐本和链码的宿主，因此应用程序和管理员如果要访问这些资源，必须与对端节点进行交互。这就是为什么将对等方视为Fabric网络的最基本组成部分。首次创建同位体时，既没有分类帐，也没有链码。稍后我们将介绍如何在同级上创建分类帐以及如何安装链码。

2.1 多个账本

对端节点可以承载多个帐本，这很有用，因为它允许灵活的系统设计。最简单的配置是让对端节点管理一个帐本，但是对端节点在需要时托管两个或多个帐本绝对是合适的。

image

承载多个帐本的对端节点。对端节点主机托管一个或多个帐本，每个帐本具有应用于它们的零个或多个链码。在此示例中，我们可以看到对端节点 P1 承载帐本 L1 和 L2。使用链码 S1 访问帐本 L1。另一方面，可以使用链码 S1 和 S2 访问帐本 L2。

尽管对端节点完全有可能托管一个账本实例，而不托管任何访问该账本的链码，但很少有对端节点是以这种方式配置的。绝大多数对端节点将至少安装一个链码，可以查询或更新对等点的分类帐实例。值得一提的是，无论用户是否安装了供外部应用程序使用的链码，对端节点也都始终存在着特殊的系统链码 (system chaincode)。在本主题中不会详细讨论这些内容。

2.2 多个链码

对端节点拥有的账本数量与可以访问该账本的链码数量之间没有固定的关系。一个对端节点可能有许多可用的链码和帐本。

image

上图是一个对端节点托管多个链码的示例。每个帐本可以有许多访问它的链码。在此示例中，我们可以看到对端节点 P1 承载帐本 L1 和 L2，其中 L1 由链码 S1 和 S2 访问，而 L2 由 S1 和 S3 访问。我们可以看到 S1 可以访问 L1 和 L2。

我们稍后将看到当在对端节点上托管多个帐本或多个链码时，Fabric 中的通道概念为什么如此重要的原因。

3. 应用程序和对端节点

现在我们将解释应用程序是如何通过与对端节点交互来访问账本的。账本查询交互涉及一个应用程序和一个对端节点之间简单的三步对话。账本更新交互稍微复杂一点，需要两个额外的步骤。我们将简化这些步骤一点点地帮助你开始使用 Fabric，但不要担心 - 最重要的是理解应用程序和对端节点交互在账本查询和账本更新之间的差异。

当应用程序需要访问帐本和链码时，它们总是连接到对端节点。Fabric 的软件开发套件 (Software Development Kit, SDK) 使程序员可以轻松实现它 - 其 API 使应用程序可以连接到对端节点，调用链码以生成交易，将交易提交到网络 (该交易将被排序并提交到分布式帐本) 以及当此过程完成时接收事件。

通过与一个对端节点连接，应用程序可以执行链码来查询或更新帐本。帐本查询交易的结果将立即返回，而帐本更新涉及应用程序，对端节点和交易排序器之间更复杂的交互。让我们更详细地研究一下。

image

上图显示，对端节点通过与交易排序器连接以确保每个对端节点上的账本都是最新的。在此示例中，应用程序 A 连接到 P1 并调用链码 S1 以查询或更新帐本 L1。P1 调用 S1 以生成包含查询结果或帐本更新提案的响应。应用程序 A 收到提案响应，并且对于查询该过程现在已完成。为了进行更新，A 根据所有响应构建一个交易，然后将其发送给 O1 进行交易排序。 O1 将整个网络中的交易收集到多个区块中，并将其分配给所有的对端节点，包括 P1。 P1 在将交易应用到 L1 之前先进行验证。一旦 L1 更新，P1 就会生成一个事件，该事件由 A 接收，表示整个流程已经完成。

对端节点可以立即将查询结果返回给应用程序，因为满足查询所需的所有账本信息都在对端节点的本地副本中。对端节点从不需要与其他对端节点协商以响应来自应用程序的查询。但是，应用程序可以连接到一个或多个对端节点以发出查询。例如，以在多个对端节之间证实其结果，或如果怀疑信息有可能过时则可以从不同的对端节点获取最新结果。在上图中，你可以看到帐本查询是一个简单的三步过程。

更新交易以与查询交易相同的方式启动，但有两个额外的步骤。尽管更新帐本的应用程序也连接到对端节点以调用链码，但与帐本查询应用程序不同，单个对端节点此时无法执行帐本更新，因为其他对端节点必须首先同意更改，这一过程称为共识。因此，对端节点向应用程序返回了一项提案 (proposed) 的更新 - 该对端节点将在其他对端节点事先同意的情况下应用该更新。第一个额外的步骤 (第四步) 要求应用程序将一组适当的匹配的提案更新集发送到整个网络，以作为对端节点对各自账本的承诺的交易。这是通过应用程序使用交易排序器将交易打包成区块并将其分发到整个网络来实现的，在将它们应用于每个对端节点的本地帐本副本之前，可以在其中进行验证。由于整个交易排序器过程需要一些时间 (几秒钟) 才能完成，因此将异步通知应用程序，如步骤 5 所示。

在本节的后面，你将了解有关此交易排序器过程的详细特性的更多信息 - 有关此过程的详细信息，请参见 交易流 主题。

4. 对端节点和通道

尽管本节的重点是对端节点而不是通道，但值得花一些时间来了解对端节点如何通过通道与彼此以及与应用程序进行交互。通过通道，区块链网络中的一组组件可以进行私下通信和交易。

这些组件通常是对端节点，交易排序器节点和应用程序，并且通过加入通道，它们同意协作以共同共享和管理与该通道关联的帐本的相同副本。从概念上讲，你可以将通道视为与朋友组相似 (尽管通道的成员当然不需要成为朋友！)。一个人可能有几组朋友，每组都有他们一起做的活动。这些小组可能是完全独立的 (一群工作朋友，而不是一群爱好朋友)，或者它们之间可能会有一些交叉。但是，每个组都是其自己的实体，具有某种“规则”。

image

上图显示，通道允许一组特定的对端节点和应用程序在区块链网络内相互通信。在此示例中，应用程序 A 可以使用通道 C 直接与对端节点 P1 和 P2 通信。你可以将通道视为特定应用程序和对端节点之间进行通信的路径。 (为简单起见，交易排序器未在此图中显示，但必须存在于正常运行的网络中。)

我们发现通道的存在方式与对端节点不同，因此将通道视为由一组物理对端节点形成的逻辑结构更为合适。理解这一点至关重要 - 对端节点提供访问和管理通道的控制点。

5. 对端节点和组织

既然你了解了对端节点及其与帐本，链码和通道的关系，现在你将能够看到多个组织如何一起组成一个区块链网络。

区块链网络由组织的集合而不是单个组织管理。对端节点对于这种分布式网络的构建至关重要，因为对端节点网络由这些组织拥有，并且是这些组织的网络连接点。

image

上图显示了，具有多个组织的区块链网络中的对端节点。区块链网络是由拥有不同的对端节点的组织建立和贡献的。在此示例中，我们看到四个组织贡献了八个对端节点组成一个网络。通道 C 连接网络 N 中的五个对端节点 - P1，P3，P5，P7 和 P8。这些组织拥有的其他对端节点尚未加入此通道，但通常已加入至少一个其他通道。由特定组织开发的应用程序将连接到其各自组织的对端节点以及不同组织的对端节点。同样，为简单起见，该图中未显示交易排序器节点。

了解区块链网络的形成过程非常重要。网络由向其贡献资源的多个组织组成和管理。对端节点是我们在本主题中讨论的资源，但是组织提供的资源不仅仅是对端节点。这里有一个原则在起作用 - 如果组织没有将各自的资源投入到集体网络中，那么网络实际上就不存在。而且，网络随着这些协作组织提供的资源而增长和收缩。

在上面的示例中，你可以看到 (除了交易排序器服务之外) 没有集中式资源 - 如果组织不提供对端节点资源，则网络 N 将不存在。这反映了这样一个事实：除非有组织提供构成该网络的资源，否则该网络不存在任何意义。此外，网络不依赖于任何单个组织，只要一个组织存在，它就会继续存在，无论其他组织可能来去去去。这是网络去中心化意味着什么的核心。

如上例所示，不同组织中的应用程序可能相同也可能不同。那是因为这完全取决于组织的应用程序如何处理其对端节点的帐本副本。这意味着应用程序和表示逻辑在组织之间可能会有所不同，即使它们各自的对端节点托管的账本数据完全相同。

应用程序可以连接到其组织中的对端节点，也可以连接到另一个组织中的对端节点，具体取决于所需的账本交互的性质。对于账本查询交互，应用程序通常会连接到其组织的对端节点。对于账本更新交互，我们将在后面看到为什么应用程序需要连接到代表背书 (endorse) 账本更新所需的每个组织的对端节点。

6. 对端节点和身份标识

既然你已经了解了来自不同组织的对端节点如何组成一个区块链网络，那么值得花一些时间来了解如何将其对端节点由管理员分配给组织。

对端节点具有通过特定证书颁发机构通过数字证书分配给他们的身份标识。你可以在本指南的其他地方阅读有关 X.509 数字证书如何工作的更多信息，但就目前而言，数字证书就像是 ID 卡，可以提供有关对端节点的大量可验证信息。网络中的每个对端节点都由其所属组织的管理员分配了数字证书。

image

当对端节点连接到一个通道，它的数字证书通过通道 MSP 标识其所属的组织。在此示例中，P1 和 P2 是由有 CA1 颁发的身份标识。通道 C 根据其通道配置中的策略，确定应该使用 ORG1.MSP 将来自 CA1 的身份标识与 Org1 关联。同样，P3 和 P4 被 ORG2.MSP 标识为 Org2 的一部分。

每当对端节点使用通道连接到区块链网络时，通道配置中的策略都会使用对端节点的身份标识来确定其权利。身份标识到组织的映射由称为成员资格服务提供商 (Membership Service Provider, MSP) 的组件提供 - 它确定如何将对端节点分配给特定组织中的特定角色，并因此获得对区块链资源的适当访问。此外，对端节点只能由单个组织拥有，因此与单个 MSP 关联。我们将在本节的后面部分详细了解对端节点访问控制，并且在本指南的其他部分中将有一个完整的关于 MSP 和访问控制策略的部分。但就目前而言，可以将 MSP 视为在区块链网络中的个人身份和特定组织角色之间提供链接。

离题一会儿，对端节点以及一切从他们的数字证书和 MSP 与区块链网络交互获取其组织的身份。对端节点，应用程序，终端用户，管理员和交易排序器，必须有一个身份标识和相关的 MSP，如果他们想与区块链网络交互。我们将使用身份标识与区块链网络交互的每个实体命名为主体 (principal)。你可以在本指南中的其他地方了解更多有关主体和组织的信息，但是到目前为止，你所了解的知识还远远不够，可以继续理解对端节点！

最后，请注意，对端节点的物理位置并不重要 - 它可以位于云中，也可以位于组织之一拥有的数据中心中，也可以位于本地计算机上 - 与之相关联的身份标识将其标识为由特定组织拥有。在上面的示例中，P3 可以托管在 Org1 的数据中心中，但是只要与它关联的数字证书由 CA2 颁发，那么它就由 Org2 拥有。

7. 对端节点和交易排序器

我们已经看到，对端节点构成了区块链网络，托管帐本和智能合约的基础，可以由对端节点连接的应用程序查询和更新。但是，应用程序和对端节点彼此交互以确保每个对端节点的帐本保持一致的机制是由称为交易排序器 (orderer) 的特殊节点来确保的，现在我们转向这些节点。

更新交易与查询交易完全不同，因为单个对端节点自身无法更新帐本 - 更新需要网络中其他对端节点的同意。对端节点要求网络中的其他对端节点批准帐本更新，然后才能将其应用于对端节点的本地帐本。此过程称为共识，与简单查询相比，此过程需要更长的时间才能完成。但是，当所有需要批准交易的对端节点都批准了该交易并将交易提交到帐本时，对端节点将通知其连接的应用程序帐本已更新。在本部分中，你将获得有关对端节点和交易排序器如何管理共识过程的更多详细信息。

具体来说，想要更新账本的应用程序涉及 3 个阶段的过程，这确保了区块链网络中的所有对端节点都保持其账本彼此一致。在第一阶段，应用程序与背书对端节点 (endosring peer) 的子集一起工作，每个背书对端节点都向应用程序提供对账本更新提案的背书，但不将提案的更新应用于其账本副本。在第二阶段，将这些单独的背书 (endorsement) 作为交易收集在一起，并打包成区块。在最后阶段，这些区块被分配回每个对端节点，在将每个交易应用于该对端节点的帐本副本之前，都已经对其进行了验证。

正如你将看到的，交易排序器节点是此过程的核心，所以让我们更详细地研究一下应用程序和对端节点如何使用交易排序器来生成账本更新，这些更新可以一致地应用于分布式复制账本。

7.1 第 1 阶段 - 提案

交易工作流程的第 1 阶段涉及应用程序和一组对端节点之间的交互 - 它不涉及交易排序器。第 1 阶段仅涉及一个应用程序，这个应用程序请求不同组织的背书对端节点 (endorsing peer) 同意提案的链码调用结果。

从第 1 阶段开始，应用程序会生成一个交易提案，然后将其发送给每个必需的对端节点组以进行背书。然后，这些背书对端节点中的每一个都使用交易提案独立执行链码以生成交易提案响应。它不会将此更新应用于帐本，而只是对其进行签名并将其返回给应用程序。一旦应用程序收到了足够数量的已签名提案响应，交易流程的第 1 阶段便完成了。让我们更详细地研究这个阶段。

image

交易提案由返回提案响应背书的对端节点独立执行。在此示例中，应用程序 A1 生成交易 T1 提议 P，并将其发送到通道 C 上的对端节点 P1 和对端节点 P2。P1 使用交易 T1 提案 P 执行 S1 生成交易 T1 响应 R1 并由 E1 背书。P2 独立地使用交易 T1 提案 P 执行 S1，并生成交易 T1 响应 R2，并由 E2 背书。应用程序 A1 收到两个对交易 T1 的响应背书，即 E1 和 E2。

在初始化阶段，应用程序选择一组对端节点以生成一组提案的账本更新。应用程序选择了哪些对端节点？好吧，这取决于背书策略 (为链码定义)，背书策略 (endorsement policy) 定义了需要在网络接受之前对提案的账本更改进行背书的组织集合。从字面上看，这就是达成共识的意思 - 每个重要组织都必须已批准提案的帐本更改，然后才能将其接受到任何对端节点的帐本中。

对端节点通过添加其数字签名并使用其私钥对整个有效负载进行签名来背书提案响应。此背书可以随后用于证明该组织的对端节点产生了特定的响应。在我们的示例中，如果对端节点 P1 由组织 Org1 拥有，则背书 E1 对应于一个数字证明，即 “由 Org1 的对端节点 P1 提供了账本 L1 上的交易 T1 的响应 R1！”。

当应用程序收到足够的对端节点签署的提案响应时，第 1 阶段结束。我们注意到，对于同一个交易提案，不同的对端节点可以向应用程序返回不同的因此不一致的交易响应。可能只是结果是在不同时间使用不同状态的帐本在不同的对端节点上生成的，在这种情况下，应用程序可以简单地请求更新的提案响应。虽然出现这种结果的可能性较小，但更严重的是结果可能会有所不同，因为链码是不确定的。非确定性是链码和账本的敌人，如果发生，则表明提案的交易存在严重问题，因为显然不能将不一致的结果应用于账本。单个对端节点无法知道他们的交易结果是不确定的，因此必须先收集交易响应以进行比较，然后才能检测到不确定性。(严格来说，这还不够，但是我们将讨论推迟到交易部分，在此部分将详细讨论不确定性。)

在第 1 阶段结束时，应用程序可以随意丢弃不一致的交易响应，从而有效地尽早终止交易工作流。稍后我们将看到，如果应用程序尝试使用一组不一致的交易响应来更新帐本，则它将被拒绝。

7.2 第 2 阶段 - 将交易排序和打包成区块

交易工作流程的第 2 阶段是打包阶段。交易排序器对于此过程至关重要 - 它从许多应用程序接收包含交易提案响应背书的交易，并将交易排序进区块。有关排序和打包阶段的更多详细信息，请查看我们有关 排序阶段的概念性信息。

7.3 第 3 阶段 - 验证和提交

在第 2 阶段结束时，我们看到交易排序器负责简单但至关重要的过程，这些过程包括收集提案的交易更新，进行排序并将它们打包成区块，以便分发给对端节点。

交易工作流程的最后阶段涉及从交易排序器到对端节点的区块分发和后续验证，在这里可以将它们应用于帐本。具体来说，在每个对端节点，对一个区块中的每个交易都进行验证，以确保在将其应用于账本之前，所有相关组织都一致认可该交易。失败的交易将保留以进行审核，但不会应用于帐本。

image

交易排序器节点的第二个作用是将区块分配给对端节点。在该示例中，交易排序器 O1 将区块 B2 分配给对端节点 P1 和对端节点 P2。对端节点 P1 处理区块 B2，从而将新区块添加到 P1 上的帐本 L1。并行地，对端节点 P2 处理区块 B2，导致将新区块添加到 P2 上的帐本 L1。一旦该过程完成，账本 L1 就已在对端节点 P1 和 P2 上进行了一致更新，并且每个账本可以通知连接的应用程序交易已被处理。

第 3 阶段从交易排序器将区块分配给与其连接的所有对端节点开始。对端节点通过通道连接到交易排序器，以便在生成新区块时，将向连接到交易排序器的所有对端节点发送新区块的副本。每个对端节点将独立地但与通道上的每个其他对端节点以完全相同的方式处理此区块。这样，我们将看到帐本可以保持一致。还值得注意的是，并非每个对端节点都需要连接到交易排序器，对端节点可以使用 gossip 协议将区块级联到其他对端节点，后者(?)也可以独立处理它们。但是，让我们将讨论留给其他时间！

收到区块后，对端节点将按照它出现在区块中的顺序处理每个交易。对于每笔交易，每个对端节点将根据生成交易的链码的背书策略，验证该交易是否已被所需的组织背书。例如，某些交易可能只需要由单个组织背书，而其他交易可能需要多次背书才能被视为有效。此验证过程将验证所有相关组织均已产生相同的输出或结果。还要注意，此验证与第 1 阶段中的背书检查不同，在第 1 阶段中，应用程序是从背书对端节点接收响应并做出发送提案交易的决定。如果应用程序通过发送错误的交易违反了背书策略，则对端节点仍然可以在第 3 阶段的验证过程中拒绝交易。

如果交易已正确背书，则对端节点将尝试将其应用于帐本。为此，对端节点必须执行帐本一致性检查，以验证生成提案更新时帐本的当前状态与帐本的状态兼容。即使交易已得到完全认可，这也不总是可能的。例如，另一笔交易可能已更新账本中的同一资产，因此该交易更新不再有效，因此无法再应用。这样，由于每个对端节点遵循相同的验证规则，因此它们在整个网络中保持一致。

对端节点成功验证了每个单独的交易后，它将更新帐本。失败的交易不应用于帐本，但保留它们以进行审核，与成功的交易一样。这意味着对端节点区块几乎与从交易排序器接收到的区块完全相同，除了该区块中每个交易的有效或无效指示符。

我们还注意到，第 3 阶段不需要运行链码 - 仅在第 1 阶段已经完成，这很重要。这意味着链码仅在背书节点上可用，而不是在整个区块链网络上可用。这通常很有用，因为它可以使链码的逻辑对背书组织保密。这与链码的输出 (交易提案响应) 相反，链码的输出与通道中的每个对端节点共享，无论他们是否背书交易。支持对端节点的这种专业化旨在帮助实现可伸缩性。

最后，每次将一个区块提交给对端节点的帐本时，该对端节点都会生成一个适当的事件。区块事件包括完整的区块内容，而区块交易事件仅包含摘要信息，例如区块中的每个交易是否已验证或无效。链码执行产生的链码事件也可以在此时发布。应用程序可以注册这些事件类型，以便在事件发生时得到通知。这些通知结束了交易工作流的第 3 阶段即最后阶段。

总而言之，第 3 阶段将看到由交易排序器生成的区块始终应用于帐本。严格按顺序将交易划分为区块，每个对端节点都可以验证交易更新是否在整个区块链网络中得到一致应用。

7.4 交易排序器和共识

交易流程的整个过程称为共识，因为在交易排序器的调解下，所有对端节点都已就交易的顺序和内容达成了共识。共识是一个多步骤的过程，仅当过程完成时才通知应用程序账本更新，这可能在不同的对端节点上略有不同。

我们将在以后的交易排序器主题中更详细地讨论交易排序器，但现在，将交易排序器视为从应用程序收集和分发提案的账本更新以供对端节点验证并包含在账本中的节点。

就是这样！现在，我们已经完成了对对端节点及其与 Fabric 相关的其他组件的浏览。我们已经看到，在许多方面，对端节点是最基本的元素 - 它们形成网络，托管链码和帐本，处理交易提案和响应，并通过始终向其应用交易更新来使帐本保持最新。

Reference

• Docs » Key Concepts » Peers, https://hyperledger-fabric.readthedocs.io/en/release-1.4/peers/peers.html
• Docs » Key Concepts » Smart Contracts and Chaincode, https://hyperledger-fabric.readthedocs.io/en/release-1.4/smartcontract/smartcontract.html
• Docs » Architecture Reference » Transaction Flow, https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html
• Docs » Key Concepts » The Ordering Service, https://hyperledger-fabric.readthedocs.io/en/release-1.4/orderer/ordering_service.html#phase-two-ordering-and-packaging-transactions-into-blocks

项目源代码

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

Contributor

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