Hyperledger Fabric 二三事 - Peer 节点
from https://hyperledger-fabric.readthedocs.io/zh_CN/release-2.2/peers/peers.html
Peer 节点
区块链网络是由 Peer 节点组成的,每个节点都保存着账本和智能合约的副本。在这个例子中,网络 N 是由节点 P1、P2 和 P3 组成的,每个节点都维护这他们自己的分布式账本 L1。P1、P2 和 P3 使用相同的链码 S1 来访问他们的分布式账本的副本。如下图:
Peer 节点可以被创建、启动、停止、重新配置甚至删除。他们暴露了一系列的 API,这就可以让管理者和应用程序同这些 API 提供的服务互动。
Peer 节点维护着账本及链码的实例。如下图:
Peer 节点是账本及链码的宿主,应用程序及管理员如果想要访问这些资源,他们必须要和 Peer 节点进行交互。这就是为什么 Peer 节点被认为是 Hyperledger Fabric 网络最基本的组成模块。当 Peer 节点被第一次创建的时候,它并没有账本也没有链码。
多账本
一个 Peer 节点可以维护多个账本,这是很有用的,因为它能够进行很灵活的系统设计。最简单的配置就是一个 Peer 节点管理一个账本,但是当需要的时候,一个 Peer 节点维护两个或者更多的账本也是非常适合的。如下图:
一个 Peer 节点维护多个账本。Peer 节点维护着一个或者多个账本,并且每个账本具有零个或者多个链码使用账本。在这个例子中,我们能够看到 Peer 节点 P1 维护着账本 L1 和 L2。账本 L1 通过链码 S1 来访问。账本 2 通过链码 S1 和 S2 访问。有必要说明一下,无论用户是否安装了外部应用使用的链码,Peer 节点总是会有一个特殊的系统链码。
多链码
账本数量和访问账本的链码的数量之间没有固定的关系。一个 Peer 节点可能会有很多链码和账本。
这是一个运行着多个链码的 Peer 节点。每个账本可以拥有多个访问它的链码。在这个例子中,我们能够看到 Peer 节点 P1 维护着账本 L1 和 L2,L1 可以通过链码S1 和 S2 来访问,账本 L2 可以由 S1 和 S3 来访问。我们能够看到链码 S1 既能访问 L1 也能访问 L2。
应用程序和 Peer 节点
现在我们要展示应用程序是如何通过跟 Peer 节点交互来访问账本的。查询账本的操作涉及到应用程序和 Peer 节点之间的一个简单的三步对话;更新账本的操作会涉及到更多的步骤,需要额外的两步。
当应用程序需要访问账本和链码的时候,他们总是需要连接到 Peer 节点。Hyperledger Fabric SDK 将这个操作变得非常简单,它的 API 使应用程序能够连接到 Peer 节点,调用链码生成交易,提交交易到网络,在网络中交易会被排序并且提交到分布式账本中,并且在这个流程结束的时候接收到事件。
通过连接 Peer 节点,应用程序能够执行链码来查询或者更新账本。对账本的查询结果马上会返回,但是对账本的更新会在应用程序、Peer 节点以及排序节点之间有更复杂的交互。让我们更详细地研究一下。
Peer 节点和排序节点,确保了账本在每个 Peer 节点上都具有最新的账本。在这个例子中,应用程序 A 连接到了 P1 并且调用了链码 S1 来查询或者更新账本 L1。P1 调用了链码 S1 来生成提案响应,这个响应包含了查询结果或者账本更新的提案。应用程序 A 接收到了提案的响应,对于查询来说,流程到这里就结束了。对于更新来说,应用程序 A 会从所有的响应中创建一笔交易,它会把这笔交易发送给排序节点 O1 进行排序。O1 会搜集网络中的交易并打包到区块中,然后将这些区块分发到所有 Peer 节点上,包括 P1。P1 在把交易提交到账本 L1 之前对交易进行验证。当 L1 被更新之后,P1 会生成一个事件,该事件会被 A 接收到,来标识这个过程结束了。
Peer 节点可以马上将查询的结果返回给应用程序,因为满足这个查询的所有信息都保存在 Peer 节点本地的账本副本中。Peer 节点从来不会为了应用程序的查询返回结果而去询问其他 Peer 节点的。但是应用程序还是能够连接到一个或者多个 Peer 节点来执行一个查询;比如,为了协调在多个 Peer 节点间的一个结果,或者当怀疑数据不是最新的时候,需要从不同的 Peer 节点获得更新的结果。
更新交易和查询交易起点相同,但是有两个额外的步骤。尽管更新账本的应用程序也会连接到 Peer 节点来调用链码,但是不像查询账本的应用程序,一个独立的 Peer 节点目前是不能进行账本更新的,因为其他的 Peer 节点必须首先要同意这个变动(即达成共识)。因此,Peer 节点会返回给应用程序一个被提案过的更新,这个 Peer 节点会依据其他节点之前的协议来应用这个更新。第一个额外的步骤,也就是第四步,要求应用程序将响应的提案过的更新发送到网络中,网络中的 Peer 节点会将交易提交到它们相应的账本中。应用程序会收到排序节点打包了交易的区块,然后将他们分发到网络中所有的 Peer 节点,在区块被更新到每个 Peer 节点本地账本的副本中之前,这些区块都需要被验证。
Peer 节点和通道
通道允许区块链网络中特定的一些 Peer 节点以及应用程序来彼此交互。在这个例子中,应用程序 A 能够直接同 Peer 节点 P1 和 P2 使用通道 C 进行沟通。你可以把通道想象为在某些应用程序和 Peer 节点之间进行通信的小路。(排序节点没有显示在这个图中,但是在工作网络中它必须存在。)
Peer 节点和组织
区块链网络是由多个组织来管理的,而不是单个组织。对于如何构建这种类型的分布式网络,Peer 节点是核心,因为他们是由这些组织所有,也是这些组织同这个网络的连接点。
区块链网络中的 Peer 节点和多个组织。区块链网络是由不同的组织所拥有并贡献的 Peer 节点构成的。在这个例子中,我们看到由四个组织贡献了八个 Peer 节点组成一个网络。在网络 N 中,通道 C 连接了这些 Peer 节点中的五个:P1、P3、P5、P7 和 P8。这些组织拥有的其他节点并没有加入该通道,但是通常会加入至少一个其他通道。某个组织开发的应用程序将会连接到他们自己组织的 Peer 节点,其他组织也一样。为了简化,排序节点没有在这个图中表示出来。
Peer 节点和身份
Peer 节点会有一个身份信息被分给他们,这是通过一个特定的证书认证机构颁发的数字证书来实现的。你可以在本指南的其他地方阅读更多的关于 X.509 数字证书是如何工作的,但是,现在,就把数字证书看成是能够为 Peer 节点提供可验证信息的身份证。在网络中的每个 Peer 节点都会被所属组织的管理员分配一个数字证书。
当 Peer 节点连接到一个通道的时候,它的数字证书会通过通道 MSP 来识别它的所属组织。在这个例子中,P1 和 P2 具有由 CA1 颁发的身份信息。通道 C 通过在它的通道配置中的策略来决定来自 CA1 的身份信息应该使用 ORG1.MSP 被关联到 Org1。类似的,P3 和 P4 由 ORG2.MSP 识别为 Org2 的一部分。
Peer 节点和排序节点
一个更新的交易和一个查询的交易区别很大,因为一个单独的 Peer 节点不能够由它自己来更新账本——更新需要网络中其他节点的同意。在一个账本的更新被应用到 Peer 节点的本地账本之前, Peer 节点会请求网络中的其他 Peer 节点来批准这次更新。这个过程被称为共识,这会比一个简单的查询花费更长的时间来完成。但是当所有被要求提供批准的节点都提供了批准,并且这笔交易被提交到账本的时候,Peer 节点会通知它连接的应用程序账本已经更新了。
特别的是,想要更新账本的应用程序会被引入到一个三阶段的流程,这确保了在一个区块链网络中所有的 Peer 节点都彼此保持着一致的账本。
让我们稍微详细一点地研究一下应用程序和 Peer 节点对于一个分布式的和重复的账本是如何使用排序节点来生成账本更新的。
-
阶段1:提案
交易提案会被 Peer 节点独立地执行,Peer 节点会返回经过背书的提案响应。在这个例子中,应用程序 A1 生成了交易 T1 和提案 P,应用程序会将交易及提案发送给通道 C 上的 Peer 节点 P1 和 Peer 节点 P2。P1 使用交易 T1 和 提案 P 来执行链码 S1,这会生成对交易 T1 的响应 R1,它会提供背书 E1。P2 使用交易 T1 提案 P 执行了链码 S1,这会生成对于交易 T1 的响应 R2,它会提供背书 E2。应用程序 A1 对于交易 T1 接收到了两个背书响应,称为 E1 和 E2。 -
阶段2:排序和将交易打包到区块
-
阶段3:验证和提交
在第二阶段末尾,我们看到了排序节点需要负责这个简单但是重要的搜集提案的交易变更,将他们排序,并且打包到区块中,让他们准备好分发给 Peer 节点的整个流程。
这个交易流程的最后一个阶段是分发以及接下来的对于从排序节点发送给 Peer 节点的区块的验证工作,这些区块最终会提交到账本中。具体来说,在每个 Peer 节点上,区块中的每笔交易都会被验证,以确保它在被提交到账本之前,已经被所有相关的组织一致地背书过了。失败的交易会被留下来方便审计,但是不会被提交到账本中。
排序节点的第二个角色是将区块分发给 Peer 节点。在这个例子中,排序节点 O1 将区块 B2 分发给了 Peer 节点 P1 和 Peer 节点 P2。Peer P1 处理了区块 B2,产生了一个会被添加到 P1 的账本 L1 中的新区块。同时,peer P2 处理了区块 B2,产生了一个会被添加到 P2 的账本 L1 中的新区块。当这个过程结束之后,账本 L1 就会被一致地更新到了 Peer 节点 P1 和 P2 上,他们也可能会通知所连接的应用程序关于这笔交易已经被处理过的消息。