Hyperledger Fabric 中文文档

Hyperledger Fabric 中文文档


Peers

一个区块链网络主要包含了一堆对等节点(peer node)。对等节点是网络中最基本的元素,因为它们包含了账本以及智能合约。请记住,账本包含了所有智能合约的交易记录且这些记录都是不可篡改的。智能合同和账本分别用于将共享流程和共享信息封装在网络中。对等节点的这些方面使他们成为了解 Hyperledger Fabric 网络的良好开端。

区块链网络的其他元素当然也很重要:账本和智能合约,共识,政策,频道,应用程序,组织,身份和会员体系,您可以在相关专题中阅读更多关于它们的内容。本主题主要讨论对等节点及节点与 Hyperledger Fabric 区块链网络中其他元素的关系。

Peers¶ - 图1

区块链网络由对等节点组成,每个节点都可以存放账本副本和智能合约副本。在这个例子中,网络 N 由节点 P1,P2 和 P3 组成。 P1,P2 和 P3 各自维护自己账本 L1 的实例。 P1, P2 和 P3 使用 chaincode S1 来访问他们的账本 L1 的副本。

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

一个关于术语的词(A word on terminology)

Hyperledger Fabric 使用它称之为 chaincode 的技术概念实现智能合约 —— 用支持的编程语言,简单的一段代码就能获取账本。在这个主题中,我们通常会使用术语 chaincode,你可以随意将它作为智能合约阅读。这是同一件事!

账本和 Chaincode(Ledgers and Chaincode)

让我们更详细地看看对等节点。我们可以看到,对等节点它承载了账本和 chaincode。更准确地说,节点实际上承载了账本的实例和 chaincode 的实例。请注意,这在 Fabric 网络中提供了故意的冗余 —— 它避免了单点故障。我们将在本主题后面详细了解区块链网络的分布式和分散式特性。

Peers¶ - 图2

对等节点托管了账本实例和 chaincode 实例。在这个例子中,P1 托管一个账本 L1 的实例和一个 chaincode S1 的实例。可以有许多账本和 chaincode 托管在个人对等体上。

由于对等节点是帐本和 chaincode 的宿主,因此如果要访问这些资源,应用程序和管理员必须与对等节点进行交互。这就是为什么对等节点被视为 Hyperledger Fabric 区块链网络的最基本的构建模块。首次创建对等体时,它既没有账本也没有 chaincode。稍后我们将会看到分类账是如何被创建的,以及 chaincode 是如何安装在同行上的。

多账本(Multiple Ledgers)

节点能够托管多个账单,这对系统的灵活性很有帮助。最简单的节点配置是拥有一个单独的帐,但对于需要时可以托管两个或更多的账本,这是绝对合适的。

Peers¶ - 图3

一个托管多个分类账的节点。节点拥有一个或多个账单,每个账单有零个或多个适用于他们的 chaincodes。在这个例子中,我们可以看到对等体 P1 拥有分类账 L1 和 L2 。使用 chaincode S1 访问 Ledger L1。另一方面,可以使用 chaincode S1 和 S2 访问 Ledger L2

尽管一个对等节点完全可能托管一个账本实例,而没有托管访问它的任何 chaincode,但通过这种方式配置对等项非常罕见。绝大多数节点至少会安装一个 chaincode,可以查询或更新节点账本实例。值得一提的是,用户是否已经安装了供外部应用程序使用的 chaincode,对等节点还有特殊的系统 chaincode,这些 chaincode 始终存在。这些不在本主题中详细讨论。

多个 Chaincode(Multiple Chaincodes)

节点所拥有的账本数量与可以访问该账本的 chaincode 的数量之间没有固定的关系。节点可能有许多 chaincode 和许多账本可用。

Peers¶ - 图4

一个托管多个 chaincode 的对等实例。每个分类帐可以有很多 chaincode 访问它。在这个例子中,我们可以看到节点 P1 拥有账单 L1 和 L2。 L1由 chaincode S1 和 S2 访问,而 L2 由 S3 和 S1 访问。我们可以看到 S1 可以访问 L1 和 L2。

稍后我们会看到为什么 Hyperldeger Fabric 中的频道概念在节点上托管多个分类帐或多个 chaincode 时很重要。

应用程序和节点(Applications and Peers)

现在我们将展示应用程序如何与节点进行交互以访问账本。账本查询交互涉及应用程序和节点之间的简单三步对话;账单更新交互涉及更多一点,并且需要两个额外的步骤。我们已经简化了这些步骤以帮助您开始使用 Hyperledger Fabric,但不用担心 —— 要理解最重要的是与账单更新相比,账本查询的应用程序节点交互中的差异。

当他们需要访问分类账和连锁码时,应用程序总是连接到节点。Hyperledger Fabric软件开发工具包(SDK)使程序员可以轻松实现这一点 —— 它的API使应用程序能够连接到节点,调用 chaincode 来生成事务,将交易提交给网络,该网络将对交易进行排序并提交给分布式账本,并在此步骤完成时接收事件通知。

通过节点连接,应用程序可以执行 chaincodes 来查询或更新账单。账本查询事务的结果会立即返回,而账本更新涉及应用程序,对等节点和排序节点之间更复杂的交互。让我们来仔细研究一下。

Peers¶ - 图5

对等节点和排序节点一起工作来确保账本在每个节点中都保持最新。在这个例子中,应用程序 A 连接到 P1 并调用 chaincode S1 来查询或更新账单 L1。 P1 调用 S1 来生成包含查询结果或建议账本更新的提案响应。应用程序 A 收到提案响应,对于查询,过程现在已完成。 O1 将整个网络中的交易收集到块中,并将这些交易分发给所有节点,包括P1。P1 在处理 L1 之前会先验证交易。一旦 L1 被更新, P1 产生一个由 A 接收的事件来表示完成。

节点可以立即将查询结果返回给应用程序,因为满足查询所需的所有信息都位于节点的账单本地副本中。节点不会咨询其他节点,以便将查询返回给应用程序。但是,应用程序可以连接到一个或多个节点来发出查询 —— 例如以证实多个对等节点之间的结果,或者如果怀疑信息可能过期,则从不同的节点检索更新结果。在图中,您可以看到分类账查询是一个简单的三步过程。

更新事务与查询事务比较相似,但有两个额外的步骤。虽然账本更新应用程序也连接到节点以调用 chaincode,与账单查询应用程序不同,单个节点无法执行账单更新,因为其他节点必须首先同意这种操作 —— 这就是共识的过程。因此,节点向应用程序返回更新提议 —— 这个节点将先获得其他节点的同意。第一个额外的步骤 —— 也即第四步 —— 要求应用程序发送一组适当的更新提议到整个节点网络中,该交易需要被整个网络节点所同意。这是通过应用程序使用排序节点将事务打包进区块来实现的,并将它们分发到节点的整个网络,以便在应用到每个节点的账本副本之前,可以对其进行验证。由于整个共识处理需要一些时间才能完成(秒),因此应用程序会异步通知,如步骤5所示。

在本主题的后面,您将详细了解此共识流程的详细性质 — 有关此流程的详细信息,请参阅 Transaction Flow 主题。

对等节点和排序节点(Peers and Orderers)

我们已经看到,节点形成区块链网络,托管账本和 chaincode(智能合约),可以通过与对等节点连接来进行应用程序查询和更新合同。然而,应用程序和对等节点之间相互作用以确保每个对等节点帐本保持一致的机制是由称为 orderers 的特殊节点保障的,并且这些节点是我们现接下来要重点讨论的。

更新事务与查询事务完全不同,因为单个对等节点本身不能更新账本 —— 它需要网络其他节点的同意。对等节点需要网络中的其他对等节点批准账本更新,然后才能将其应用于节点的本地账本。这个过程称为共识 —— 并且比查询花费更长的时间来完成。当其他的节点都同意了事务之后,交易才能被提交到账本中,此时连接节点的应用程序会被通知。您将会看到更多有关对等节点和排序节点如何管理本节中的共识流程的详细信息。

具体而言,需要更新账本的应用程序涉及3阶段流程,这可确保区块链网络中的所有对等节点都保持其账本彼此一致 。在第一阶段,应用程序与批准节点的一个子集一起工作,每个节点都提供了对应用程序的建议账本更新的认可,但不会将提议的更新应用于其本地账本的副本。在第二阶段,这些单独的认可被作为交易收集在一起并打包成块。在最后阶段,将这些块分发回每个对等节点,每个对等节点在应用到该对等节点的分类账副本之前对每个交易进行验证。

正如您将看到的那样,排序节点对于此流程至关重要 —— 因此让我们稍微详细地调查一下应用程序和对等节点如何使用排序节使得账本更新,这些账本更新可以始终适用于分布式复制分类账。

阶段1:提案(Phase 1: Proposal)

交易工作流程的第一阶段涉及应用程序和一组节点之间的交互 ​​—— 它不涉及排序节点。阶段1只涉及一个应用程序,要求不同组织的确认所提议的 Chaincode 调用的结果。

为了启动第一阶段,应用程序生成一个交易提案,并将其发送给每个需要的节点进行确认。然后,每个对等节点使用交易提议独立执行 chaincode,以生成交易提议响应。它不会将此更新应用于账本,而是由对等节点签署并返回给应用程序。一旦应用程序收到足够数量的已签名提议响应,交易流程的第一阶段即告完成。我们来仔细研究一下这个阶段。

Peers¶ - 图6

交易提案由返回节点独立执行并响应提案回复。在这个例子中,应用程序 A1 生成事务 T1 建议 P,它在频道 C 上发送给对等节点 P1 和对等节点 P2 两者。P1 使用事务 T1 交易提议 P 执行 S1 chaincode,生成事务 T1 响应 R1 并带上 E1 的确认。独立地,P2 使用事务 T1 交易提议 P 执行 S1 chaincode,生成事务 T1 响应 R2 并带上 E2 的确认。应用程序 A1 收到交易 T1 的两笔 认可答复,即 E1 和 E2。

最初,应用程序选择一组节点来进行账单更新提议。哪些节点会被应用程序选中呢?这取决于确认政策(被 chaincode 所定义),该政策定义了需要确认账本更改提议以被网络接受的一组组织。这就是共识表面的意思 —— 每个重要的组织都必须已经批准账本更改提议,然后才能将其应用到任何节点的账本中。

节点通过添加其数字签名来支持提案响应,并使用其私钥对整个负载数据进行签名。这种认可可以随后用于证明这个组织的节点确实产生了特定的回应。在我们的例子中,如果节点 P1 由组织 Org1 拥有,则认可结果 E1 对应于数字证明“在分类帐 L1 上的交易 T1 响应 R1 已由 Org1 的节点 P1 提供”。

阶段1在应用程序收到来自足够多的节点签名提议响应时结束。我们注意到,不同的节点可以针对相同的交易提案返回不同的交易响应。也可能响应结果是不同的节点里的状态不一的账本或是不同的时间 —— 在这种情况下,应用程序可以简单地请求更新的提案回复。不太可能,但更严重的是,因为 chaincode 产生的结果是非确定性的,导致响应结果也可能会不同。非确定性对 chaincode 和账本是致命的,如果它出现,则表明交易提案存在严重问题,因为不一致的结果显然不能应用于账本。单独的节点是无法知道交易结果是非确定性的 —— 只有收集交易响应以进行比较,才能检测到非确定性。(严格地说,即使这还不够,我们将在交易章节谈到这点,其中详细讨论了非确定性问题。)

在第一阶段结束时,如果应用程序希望这样做,应用程序可以随意的放弃不一致的事务响应,从而高效的终止事务工作流。稍后我们会看到,如果应用程序尝试使用不一致的事务响应集来更新账本,它将被拒绝。

阶段2:打包(Phase 2: Packaging)

交易流程的第二阶段是打包阶段。排序节点是这一过程的关键 —— 它接收来自许多应用程序的包含确认提议响应的交易。它将事务进行排序,并将批量事务打包到块中,以准备分发回与排序节点连接的所有对等节点,包括那些的交易确认节点。

Peers¶ - 图7

排序节点的首要角色就是打包更新账本提案。在这个例子中,程序 A1 发送被 E1 E2 确认过的事务 T1 给排序节点 O1。同时,应用 A2 也发送被 E1 确认过的事务 T2 给排序节点 O1。 O1 一起把事务 T1 T2 打包进了区块 B2 中。我们可以看到在 B2 中,交易顺序是 T1, T2, T3, T4, T5 —— 这可能并不是按照事务到达排序节点的时间排序!(这个例子显示了一个非常简化的排序者配置)

排序节点在特定频道网络中的不同应用程序中并发的接收账本更新提案。它的工作是将这些更新提案安排到一个明确定义的序列中,并将它们打包成块用于后续分发。这些区块将成为区块链的区块!一旦排序节点生成了确定大小的数据块,或者经过最长时间后,它将被发送到在特定频道上所有已连接的对等节点。我们将看到这个区块如何在阶段 3 中处理。

值得注意的是,一个区块中的交易顺序不一定与事务到达排序节点的顺序相同!事务可以按任意顺序打包到一个块中,并且这个顺序成为执行顺序。重要的是有严格的顺序,而不用管具体的顺序是怎样排列的。

这种块内交易的严格排序使得 Hyperledger Fabric 与其他一些区块链稍有不同,别的区块链可能同一个事务可以打包到多个不同的区块。在 Hyperleger Fabric 中,这是不可能发生的 —— 由一组排序节点生成的数据块被认为是最终固定的,因为一旦事务被写入到一个数据块中,那么它在账本中的位置就是不可变的。这意味着在 Hyperledger Fabric 中,永远不可能发生账本分叉的灾难性事件!一旦在一个区块中存储了事务,那么在未来的任何时间里,该交易事务都不可能被改写。

我们也可以看到,虽然对等节点包含了账本和 chaincode,但排序节点绝对不会。每次到达排序节点的事务都被机械式的打包在区块中 —— 排序节点对交易的价值不作任何判断,只是简单的将其包装。这是 Hyperledger Fabric 的一个重要行为 —— 所有交易都按照严格的顺序编组 —— 交易永远不会被丢弃或取消优先级。

在第二阶段结束时,我们看到排序节点承担了收集交易提案更新的简单但至关重要的过程,对它们进行排序,将它们打包成块,以供分发。

阶段3:验证(Phase 3: Validation)

交易工作流程的最后阶段涉及从排序节点(orderer)到对等节点(peer node)的分发和随后的验证,可以将这些区块更新到账本中。具体来说,在每个对等节点中,块中的每个事务都需要经过验证,以确保它在应用于账本前已被所有相关组织一致认可。失败的事务将保留下来用于之后复查,但不应用于账本中。

Peers¶ - 图8

排序节点的第二个角色就是分发区块到对等节点。在这个例子中,排序节点 O1 分发了区块 B2 到 P1 以及 P2 节点中。节点 P1 处理了区块 B2,导致了其被添加到节点 P1 的账本 L1 中。同时,节点 P2 处理了区块 B2,导致了其被添加到节点 P2 的账本 L1 中。一旦这个过程处理完成,节点 P1 跟 P2 中的账本 L1 会进行相同的更新,并且都通知连接节点的应用程序该交易已经被处理。

阶段3从排序节点向连接到它的所有对等节点分发区块开始。对等节点连接到频道上的排序节点,以便当生成新的区块时,连接到排序节点的所有对等节点都会收到新区块的副本。频道上的每个对等节点都会以相同的方式处理区块。在这种方式下,我们会看到账本将会保持同步。值得注意的是,不是每个对等节点都需要连接一个排序节点 —— 对等节点可以使用 gossip 协议联动其他对等节点。该方式也可以处理账本同步。关于这点我们下次再讨论。

收到一个块后,对等节点将按照块中出现的顺序处理每个事务。对于每笔交易来说,每位对等节点将根据产生该交易的 chaincode 的认可政策,验证交易是否已获得所需组织的认可。例如,某些交易可能只需要由单个组织认可,而其他交易可能需要多次认可才能被视为有效。验证过程是验证所有相关组织都产生了相同的结果。

在交易被成功确认过后,对等节点将尝试把其应用于账本中。为此,对等节点必须执行账本一致性检查,以验证在更新提案生成时账本的状态与分类账的当前状态是否冲突。即使交易完全得到认可,不一致也是可能发生的事情。例如,另一笔交易也可能更新了账本中的同一资产,因此交易更新不再有效,且不能再应用与于账本中。通过这种方式,每个对等节点的账本副本在整个网络中保持一致,因为他们每个人都遵循相同的验证规则。

在成功验证每笔交易后,对等节点将更新账本。失败的交易不会应用于账本,但它们被保留用于审计目的,及时成功的交易也是如此。这意味着对等节点区块与从排序节点接收到的区块几乎完全相同,除了区块中每个事务的有效或无效指示符外。

我们还注意到,阶段3不需要运行 chaincodes —— 这只在第一阶段完成,这很重要。这意味着 chaincode 只会在确认节点上调用,而不会在整个区块链网络中使用。这通常是有帮助的,因为它将 chaincode 的逻辑保密给认可的组织。这与 chaincode(交易提议响应)的输出形成对比,这些响应共享给频道中的每个对等节点,无论他们是否认参与交易确认。这些被指定的确认节点被设计用来提升网络的可拓展性。

最终,每一次区块被提交到对等节点账本时,节点也会返回响应事件来作为响应(给应用程序)。块事件包括完整的块内容,而块交易事件仅包含摘要信息,例如块中的每个事务是否已被验证或无效。chaincode 执行产生的 Chaincode 事件也可以在这个时候发布。应用程序可以注册这些事件类型,以便它们在发生时得到通知。 这些通知结束了交易工作流程的第三个也是最后一个阶段。

总之,在阶段3可以看到排序节点生成的区块,会一致的应用于账本中。交易模块的严格排序保证了对等节点验证网络中的交易事务更新时的一致性。

排序节点与共识(Orderers and Consensus)

整个交易工作流程过程被称为共识,因为所有对等节点都已经在由排序节点的帮助下,就交易的顺序和内容达成一致。共识是一个多步骤的流程,当流程完成时,应用程序只会被通知账本已更新 —— 不同的节点通知的时间可能有微小的差别。

我们将在未来的排序节点主题中更详细地讨论排序节点,现在,将排序节点视为收集和分发来自应用程序的账本更新提议的节点,以便验证并应用在账本中上。

就是这些了,我们现在已经完成了我们的对等节点和其他与 Hyperledger Fabric 相关的组件。我们已经看到,对等节点在许多方面都是最基本的元素 —— 它们形成网络,chaincode 代码和账本,处理交易提议和响应,并通过持续向其应用交易更新来使账本保持最新。


© Copyright 2018, Leslie.

Built with Sphinx using a theme provided by Read the Docs.