Hyperledger Fabric 1.3 官方文档翻译（三）关键概念 (Key Concepts) - 3.7 对等节点 (Peers)

以你之姓@ 2022-05-09 06:16 175阅读 0赞

### 文章目录 ###

*  对等节点（Peers）
 *   *  术语（A word on terminology）
     *  账本与链代码（Ledgers and Chaincode）
     *   *  多账本（Multiple Ledgers）
         *  多链代码（Multiple Chaincodes）
     *  应用程序与对等节点（Applications and Peers）
     *  对等节点与通道（Peers and Channels）
     *  对等节点和组织（Peers and Organizations）
     *  对等节点与身份（Peers and Identity）
     *  对等节点与排序节点（Peers and Orderers）
     *   *  阶段1：提案（Phase 1: Proposal）
         *  阶段2：包装（Phase 2: Packaging）
         *  阶段3：验证（Phase 3: Validation）
         *  排序节点与共识（Orderers and Consensus）

# 对等节点（Peers） #

A blockchain network is comprised primarily of a set of peer nodes (or, simply, peers). Peers are a fundamental element of the network because they host ledgers and smart contracts. Recall that a ledger immutably records all the transactions generated by smart contracts (or chaincode). Smart contracts and ledgers are used to encapsulate the shared processes and shared information in a network, respectively. These aspects of a peer make them a good starting point to understand a Hyperledger Fabric network.  
区块链网络主要由一组对等节点（或简称为peers）组成。 对等节点是网络的基本要素，因为他们托管账本和智能合约。 回想一下，账本不可变地记录智能合约（或链代码）生成的所有交易。 智能合约和帐本分别用于封装网络中的共享过程和共享信息。对等节点的这些方面使他们成为了解Hyperledger Fabric网络的良好起点。

Other elements of the blockchain network are of course important: ledgers and smart contracts, orderers, policies, channels, applications, organizations, identities, and membership, and you can read more about them in their own dedicated sections. This section focusses on peers, and their relationship to those other elements in a Hyperledger Fabric network.  
区块链网络的其他元素当然很重要：帐本和智能合约、排序、策略、通道、应用程序、组织、身份和成员，你可以在他们自己的专门章节中阅读更多相关信息。 本节重点介绍对等节点及其与Hyperledger Fabric网络中其他元素的关系。

![Peer1][]

*A blockchain network is comprised of peer nodes, each of which can hold copies of ledgers and copies of smart contracts. In this example, the network N consists of peers P1, P2 and P3, each of which maintain their own instance of the distributed ledger L1. P1, P2 and P3 use the same chaincode, S1, to access their copy of that distributed ledger.*  
*区块链网络由对等节点组成，每个对等节点可以保存账本副本和智能合约副本。 在该示例中，网络N由对等节点P1、P2和P3组成，每个对等节点保持它们自己的分布式帐本L1的实例。 P1、P2和P3使用相同的链代码S1来访问其分布式帐本的副本。*

Peers can be created, started, stopped, reconfigured, and even deleted. They expose a set of APIs that enable administrators and applications to interact with the services that they provide. We’ll learn more about these services in this section.  
可以创建、启动、停止、重新配置甚至删除对等节点。 它们公开了一组API，使管理员和应用程序能够与他们提供的服务进行交互。 我们将在本节中详细了解这些服务。

## 术语（A word on terminology） ##

Hyperledger Fabric implements smart contracts with a technology concept it calls **chaincode** — simply a piece of code that accesses the ledger, written in one of the supported programming languages. In this topic, we’ll usually use the term chaincode, but feel free to read it as **smart contract** if you’re more used to that term. It’s the same thing!  
Hyperledger Fabric使用一种技术概念实现智能合约，叫作**链代码** \- 只是一段访问账本的代码，用一种支持的编程语言编写。 在本主题中，我们通常会使用术语链代码，但请随意将其视为**智能合约**，如果你更习惯这个术语。 这是同一件事！

## 账本与链代码（Ledgers and Chaincode） ##

Let’s look at a peer in a little more detail. We can see that it’s the peer that hosts both the ledger and chaincode. More accurately, the peer actually hosts instances of the ledger, and instances of chaincode. Note that this provides a deliberate redundancy in a Fabric network — it avoids single points of failure. We’ll learn more about the distributed and decentralized nature of a blockchain network later in this section.  
让我们更详细地看一下对等节点。 我们可以看到它是托管帐本和链代码的。 更准确地说，对等节点实际上托管帐本的实例和链代码的实例。 请注意，这在Fabric网络中提供了有意的冗余 - 它避免了单点故障。 我们将在本节后面详细了解区块链网络的分布式和分散性。

![Peer2][]

*A peer hosts instances of ledgers and instances of chaincodes. In this example, P1 hosts an instance of ledger L1 and an instance of chaincode S1. There can be many ledgers and chaincodes hosted on an individual peer.*  
*对等节点托管帐本实例和链代码实例。 在此示例中，P1托管帐本L1的实例和链代码S1的实例。 可以在单个对等节点上托管许多帐本和链代码。*

Because a peer is a host for ledgers and chaincodes, applications and administrators must interact with a peer if they want to access these resources. That’s why peers are considered the most fundamental building blocks of a Hyperledger Fabric network. When a peer is first created, it has neither ledgers nor chaincodes. We’ll see later how ledgers get created, and how chaincodes get installed, on peers.  
由于对等节点是帐本和链代码的主机，因此应用程序和管理员必须与对等节点进行交互才能访问这些资源。 这就是为什么对等节点被认为是Hyperledger Fabric网络最基本的构建块。 对等节点首次创建时，它既没有账本，也没有链代码。 稍后我们将看到如何在对等节点上创建帐本以及如何安装链代码。

### 多账本（Multiple Ledgers） ###

A peer is able to host more than one ledger, which is helpful because it allows for a flexible system design. The simplest configuration is for a peer to manage a single ledger, but it’s absolutely appropriate for a peer to host two or more ledgers when required.  
对等节点能够托管多个帐本，这很有用，因为它允许灵活的系统设计。 最简单的配置是让对等节点管理单个帐本，但对于对等节点来说，在需要时托管两个或多个帐本也绝对合适。

![Peer3][]

*A peer hosting multiple ledgers. Peers host one or more ledgers, and each ledger has zero or more chaincodes that apply to them. In this example, we can see that the peer P1 hosts ledgers L1 and L2. Ledger L1 is accessed using chaincode S1. Ledger L2 on the other hand can be accessed using chaincodes S1 and S2.*  
*一个托管多个帐本的对等节点。 对等节点托管一个或多个帐本，每个帐本具有零个或多个适用于它们的链代码。 在这个例子中，我们可以看到对等节点P1托管账本L1和L2。 使用链代码S1访问帐本L1。 另一方面，可以使用链代码S1和S2访问Ledger L2。*

Although it is perfectly possible for a peer to host a ledger instance without hosting any chaincodes which access that ledger, it’s rare that peers are configured this way. The vast majority of peers will have at least one chaincode installed on it which can query or update the peer’s ledger instances. It’s worth mentioning in passing that, whether or not users have installed chaincodes for use by external applications, peers also have special system chaincodes that are always present. These are not discussed in detail in this topic.  
尽管对等节点完全有可能在没有托管任何访问该帐本的链代码的情况下托管帐本实例，但很少有对等节点以这种方式配置。 绝大多数对等节点将至少安装一个链代码，可以查询或更新对等节点的帐本实例。 值得一提的是，无论用户是否安装了外部应用程序使用的链代码，对等节点还具有始终存在的特殊系统链代码。 本主题中未详细讨论这些内容。

### 多链代码（Multiple Chaincodes） ###

There isn’t a fixed relationship between the number of ledgers a peer has and the number of chaincodes that can access that ledger. A peer might have many chaincodes and many ledgers available to it.  
对等节点拥有的账本数量与可以访问该账本的链代码数量之间没有固定的关系。 对等节点可能有许多链代码和许多账本。

![Peer4][]

*An example of a peer hosting multiple chaincodes. Each ledger can have many chaincodes which access it. In this example, we can see that peer P1 hosts ledgers L1 and L2, where L1 is accessed by chaincodes S1 and S2, and L2 is accessed by S1 and S3. We can see that S1 can access both L1 and L2.*  
*托管多个链代码的对等节点的示例。 每个帐本都可以有许多访问它的链代码。 在这个例子中，我们可以看到对等节点P1托管账本L1和L2，其中L1由链代码S1和S2访问，L2由S1和S3访问。 我们可以看到S1可以访问L1和L2。*

We’ll see a little later why the concept of **channels** in Hyperledger Fabric is important when hosting multiple ledgers or multiple chaincodes on a peer.  
我们稍后会看到为什么在对等节点上托管多个账本或多个链代码时，Hyperledger Fabric中**通道**的概念很重要。

## 应用程序与对等节点（Applications and Peers） ##

We’re now going to show how applications interact with peers to access the ledger. Ledger-query interactions involve a simple three-step dialogue between an application and a peer; ledger-update interactions are a little more involved, and require two extra steps. We’ve simplified these steps a little to help you get started with Hyperledger Fabric, but don’t worry — what’s most important to understand is the difference in application-peer interactions for ledger-query compared to ledger-update transaction styles.  
我们现在将展示应用程序如何与对等节点交互以访问帐本。帐本查询交互涉及应用程序和对等节点之间的简单三步对话；帐本更新交互涉及更多，需要两个额外的步骤。我们已经简化了这些步骤以帮助你开始使用Hyperledger Fabric，但不要担心 - 最重要的是要理解应用程序与对等节点在帐本查询与帐本更新的交易方式中的差异。

Applications always connect to peers when they need to access ledgers and chaincodes. The Hyperledger Fabric Software Development Kit (SDK) makes this easy for programmers — its APIs enable applications to connect to peers, invoke chaincodes to generate transactions, submit transactions to the network that will get ordered and committed to the distributed ledger, and receive events when this process is complete.  
应用程序在需要访问帐本和链代码时始终连接到对等节点。 Hyperledger Fabric软件开发工具包（SDK）使程序员易于使用 - API使应用程序能够连接到对等节点，调用链代码以生成交易，并向网络提交交易，这些交易将被排序并提交到分布式帐本，以及在这个过程完成时接收事件。

Through a peer connection, applications can execute chaincodes to query or update a ledger. The result of a ledger query transaction is returned immediately, whereas ledger updates involve a more complex interaction between applications, peers and orderers. Let’s investigate this in a little more detail.  
通过与对等节点连接，应用程序可以执行链代码来查询或更新帐本。帐本查询交易的结果立即返回，而帐本更新涉及应用程序、对等节点和排序节点之间更复杂的交互。让我们更详细地研究一下。

![Peer6][]

1.  A连接P1
2.  A调用链代码（提案）  
    2.1. P1为了提案调用S1  
    2.2.S1生成查询或更新L1的提案响应
3.  P1返回提案响应
4.  A向O1请求交易排序  
    4.1. O1交易发送到P1  
    4.2.P1用交易区块更新账本
5.  P1向A发送账本更新事件

*Peers, in conjunction with orderers, ensure that the ledger is kept up-to-date on every peer. In this example, application A connects to P1 and invokes chaincode S1 to query or update the ledger L1. P1 invokes S1 to generate a proposal response that contains a query result or a proposed ledger update. Application A receives the proposal response and, for queries, the process is now complete. For updates, A builds a transaction from all of the responses, which it sends it to O1 for ordering. O1 collects transactions from across the network into blocks, and distributes these to all peers, including P1. P1 validates the transaction before applying to L1. Once L1 is updated, P1 generates an event, received by A, to signify completion.*  
*对等节点与排序节点一起确保账本与每个对等节点保持同步。在此示例中，应用程序A连接到P1并调用链代码S1来查询或更新帐本L1。 P1调用S1以生成包含查询结果或建议帐本更新的提案响应。应用程序A接收提案响应，对于查询，该过程就已完成。对于更新，A从所有响应构建一个交易，并将其发送给O1进行排序。 O1将来自网络的交易收集到区块中，并将这些区块分发给所有对等节点，包括P1。 P1在申请提交到L1之前验证交易。 L1更新后，P1会生成又A接收的事件，表示完成。*

A peer can return the results of a query to an application immediately since all of the information required to satisfy the query is in the peer’s local copy of the ledger. Peers never consult with other peers in order to respond to a query from an application. Applications can, however, connect to one or more peers to issue a query; for example, to corroborate a result between multiple peers, or retrieve a more up-to-date result from a different peer if there’s a suspicion that information might be out of date. In the diagram, you can see that ledger query is a simple three-step process.  
对等节点可以立即将查询结果返回给应用程序，因为满足查询所需的所有信息都在对等节点的帐本本地副本中。对等节点从不咨询其他对等节点以响应来自应用程序的查询。但是，应用程序可以连接到一个或多个对等节点以发出查询；例如，在多个对等节点之间确认结果，或者如果怀疑信息可能已过期，则从另一个对等节点检索更新的结果。在图中，你可以看到帐本查询是一个简单的三步过程。

An update transaction starts in the same way as a query transaction, but has two extra steps. Although ledger-updating applications also connect to peers to invoke a chaincode, unlike with ledger-querying applications, an individual peer cannot perform a ledger update at this time, because other peers must first agree to the change — a process called **consensus**. Therefore, peers return to the application a **proposed** update — one that this peer would apply subject to other peers’ prior agreement. The first extra step — step four — requires that applications send an appropriate set of matching proposed updates to the entire network of peers as a transaction for commitment to their respective ledgers. This is achieved by the application using an **orderer** to package transactions into blocks, and distribute them to the entire network of peers, where they can be verified before being applied to each peer’s local copy of the ledger. As this whole ordering processing takes some time to complete (seconds), the application is notified asynchronously, as shown in step five.  
更新交易以与查询交易相同的方式启动，但还有两个额外步骤。虽然帐本更新应用程序也连接到对等节点以调用链代码，但与帐本查询应用程序不同，单个对等节点此时无法执行帐本更新，因为其他对等节点必须首先同意更改 - 这个过程称为**共识**。因此，对等节点向应用程序返回**已提议**更新 - 该对等节点将根据与其他对等节点先前的协议申请更新。第一个额外步骤 - 第四步 - 要求应用程序向整个对等网络发送一组适当的匹配的已提议更新，作为对其各自帐本交易的承诺。这是通过应用程序使用\*\* 排序节点\*\*将交易打包成区块，并将它们分发到整个对等节点的网络来实现的，在应用于每个对等节点的本地副本之前，可以对它们进行验证。由于整个排序处理需要一些时间才能完成（秒级），因此将异步通知应用程序，如步骤5所示。

Later in this section, you’ll learn more about the detailed nature of this ordering process — and for a really detailed look at this process see the [Transaction Flow][] topic.  
在本节的后面部分，你将了解更多有关此排序流程的详细信息 - 有关此流程的详细信息，请参阅[排序流程][Transaction Flow] 主题。

## 对等节点与通道（Peers and Channels） ##

Although this section is about peers rather than channels, it’s worth spending a little time understanding how peers interact with each other, and with applications, via channels — a mechanism by which a set of components within a blockchain network can communicate and transact privately.  
虽然这一部分是关于对等节点而不是渠道，但是值得花些时间了解对等节点如何相互交互，以及通过通道与应用程序进行交互 - 区块链网络中的一组组件可以通过这种机制进行私有交流和交易。

These components are typically peer nodes, orderer nodes and applications and, by joining a channel, they agree to collaborate to collectively share and manage identical copies of the ledger associated with that channel. Conceptually, you can think of channels as being similar to groups of friends (though the members of a channel certainly don’t need to be friends!). A person might have several groups of friends, with each group having activities they do together. These groups might be totally separate (a group of work friends as compared to a group of hobby friends), or there can be some crossover between them. Nevertheless, each group is its own entity, with “rules” of a kind.  
这些组件通常是对等节点，排序节点和应用程序，并且通过加入通道，他们同意协作以共同共享和管理与该通道相关联的同一个帐本的副本。 从概念上讲，你可以将通道视为与朋友群相似（尽管通道成员当然不需要成为朋友！）。 一个人可能有几朋友群，每个群都有他们一起做的活动。 这些群可能是完全独立的（一群相同爱好朋友对比与一群工作朋友），或者他们之间可能存在一些交叉。 然而，每个群都是自己的实体，具有一种“规则”。

![Peer5][]

*Channels allow a specific set of peers and applications to communicate with each other within a blockchain network. In this example, application A can communicate directly with peers P1 and P2 using channel C. You can think of the channel as a pathway for communications between particular applications and peers. (For simplicity, orderers are not shown in this diagram, but must be present in a functioning network.)*  
*通道允许一组特定的对等节点和应用程序在区块链网络中相互通信。 在此示例中，应用程序A可以使用通道C直接与对等节点P1和P2通信。你可以将通道视为特定应用程序和对等节点之间通信的途径。 （为简单起见，此图中未显示排序节点，但它必须存在于正常运行的网络中。）*

We see that channels don’t exist in the same way that peers do — it’s more appropriate to think of a channel as a logical structure that is formed by a collection of physical peers. It is vital to understand this point — peers provide the control point for access to, and management of, channels.  
我们看到通道的存在方式与对等节点不同 - 将通道视为由物理对等节点集合形成的逻辑结构更为合适。 了解这一点至关重要 - 对等节点提供了访问和管理通道的控制点。

## 对等节点和组织（Peers and Organizations） ##

Now that you understand peers and their relationship to ledgers, chaincodes and channels, you’ll be able to see how multiple organizations come together to form a blockchain network.  
现在你了解了对等节点及其与账本、链代码和通道的关系，接下来你将能够看到多个组织如何聚集在一起形成区块链网络。

Blockchain networks are administered by a collection of organizations rather than a single organization. Peers are central to how this kind of distributed network is built because they are owned by — and are the connection points to the network for — these organizations.  
区块链网络由一组组织而不是一个组织管理。 对等节点是如何构建这种分布式网络的核心，因为它们由这些组织所拥有，并且是网络的连接点。

![Peer8][]

*Peers in a blockchain network with multiple organizations. The blockchain network is built up from the peers owned and contributed by the different organizations. In this example, we see four organizations contributing eight peers to form a network. The channel C connects five of these peers in the network N — P1, P3, P5, P7 and P8. The other peers owned by these organizations have not been joined to this channel, but are typically joined to at least one other channel. Applications that have been developed by a particular organization will connect to their own organization’s peers as well as those of different organizations. Again, for simplicity, an orderer node is not shown in this diagram.*  
*多组织区块链网络中的对等节点。区块链网络由不同组织拥有和贡献的对等节点构建。在此示例中，我们看到有四个组织贡献了八个对等节点组成网络。通道C连接网络N中P1、P3、P5、P7和P8这五个对等节点。这些组织拥有的其他对等节点尚未加入此通道，但通常会加入至少一个其他通道。由特定组织开发的应用程序将连接到自己组织以及不同组织的对等节点。同样，为简单起见，此图中未显示排序节点。*

It’s really important that you can see what’s happening in the formation of a blockchain network. The network is both formed and managed by the multiple organizations who contribute resources to it. Peers are the resources that we’re discussing in this topic, but the resources an organization provides are more than just peers. There’s a principle at work here — the network literally does not exist without organizations contributing their individual resources to the collective network. Moreover, the network grows and shrinks with the resources that are provided by these collaborating organizations.  
在区块链网络的形成过程中，你可以看到正在发生的事情，这一点非常重要。该网络由为其提供资源的多个组织形成和管理。对等节点是我们在本主题中讨论的资源，但组织提供的资源不仅仅是对等节点。这里有一个原则 - 如果没有组织将其个人资源贡献给集体网络，网络就不存在。此外，网络随着这些合作组织提供的资源而增长和缩小。

You can see that (other than the ordering service) there are no centralized resources — in the [example above][], the network, **N**, would not exist if the organizations did not contribute their peers. This reflects the fact that the network does not exist in any meaningful sense unless and until organizations contribute the resources that form it. Moreover, the network does not depend on any individual organization — it will continue to exist as long as one organization remains, no matter which other organizations may come and go. This is at the heart of what it means for a network to be decentralized.  
你可以看到（除了排序服务之外）没有集中的资源 - 在[上面的示例][example above]中，如果组织没有贡献他们的对等节点，网络\*\* N \*\*就不会存在。这反映了这样一个事实，即网络不存在于任何意义，除非并且直到组织贡献形成它的资源。此外，网络不依赖于任何单个组织 - 只要有一个组织仍然存在，它将继续存在，无论其他组织可能来还是去。这是网络分散化的核心所在。

Applications in different organizations, as in the [example above][], may or may not be the same. That’s because it’s entirely up to an organization as to how its applications process their peers’ copies of the ledger. This means that both application and presentation logic may vary from organization to organization even though their respective peers host exactly the same ledger data.  
不同组织中的应用程序，如[上面的示例][example above]，可能相同也可能不同。这是因为它完全取决于组织如何处理其对等节点的账本副本。这意味着应用程序和表示逻辑可能因组织而异，即使它们各自的对等节点托管完全相同的帐本数据。

Applications connect either to peers in their organization, or peers in another organization, depending on the nature of the ledger interaction that’s required. For ledger-query interactions, applications typically connect to their own organization’s peers. For ledger-update interactions, we’ll see later why applications need to connect to peers representing every organization that is required to endorse the ledger update.  
应用程序可以连接到组织中的对等节点，也可以连接到其他组织中的对等节点，具体取决于所需的帐本交互的性质。对于帐本查询交互，应用程序通常连接到自己组织的同级。对于帐本更新交互，我们稍后会看到为什么应用程序需要连接到代表每个需要支持帐本更新的组织的对等节点。

## 对等节点与身份（Peers and Identity） ##

Now that you’ve seen how peers from different organizations come together to form a blockchain network, it’s worth spending a few moments understanding how peers get assigned to organizations by their administrators.  
既然你已经看到来自不同组织的对等节点如何聚集在一起形成区块链网络，那么值得花一些时间了解管理员如何将同事分配给组织。

Peers have an identity assigned to them via a digital certificate from a particular certificate authority. You can read lots more about how X.509 digital certificates work elsewhere in this guide but, for now, think of a digital certificate as being like an ID card that provides lots of verifiable information about a peer. *Each and every peer in the network is assigned a digital certificate by an administrator from its owning organization.*  
对等节点通过来自特定证书颁发机构的数字证书为其分配身份。 你可以阅读更多有关X.509数字证书如何在本指南的其他地方工作的内容，但是，现在，将数字证书视为一张ID卡，它提供了许多关于对等节点的可验证信息。 *管理员从其所属组织为网络中的每个对等节点分配一个数字证书。*

![Peer9][]

*When a peer connects to a channel, its digital certificate identifies its owning organization via a channel MSP. In this example, P1 and P2 have identities issued by CA1. Channel C determines from a policy in its channel configuration that identities from CA1 should be associated with Org1 using ORG1.MSP. Similarly, P3 and P4 are identified by ORG2.MSP as being part of Org2.*  
*当对等节点连接到通道时，通道的数字证书通过通道MSP识别其拥有的组织。在此示例中，P1和P2具有由CA1发布的身份。通道C根据其通道配置中的策略确定来自CA1的身份应使用ORG1.MSP与Org1相关联。同样，ORG2.MSP将P3和P4识别为Org2的一部分。*

Whenever a peer connects using a channel to a blockchain network, a policy in the channel configuration uses the peer’s identity to determine its rights. The mapping of identity to organization is provided by a component called a Membership Service Provider (MSP) — it determines how a peer gets assigned to a specific role in a particular organization and accordingly gains appropriate access to blockchain resources. Moreover, a peer can be owned only by a single organization, and is therefore associated with a single MSP. We’ll learn more about peer access control later in this section, and there’s an entire section on MSPs and access control policies elsewhere in this guide. But for now, think of an MSP as providing linkage between an individual identity and a particular organizational role in a blockchain network.  
每当对等节点使用通道连接到区块链网络时，通道配置中的策略使用对等节点的身份来确定其权限。身份到组织的映射由称为成员服务提供者（MSP）的组件提供 - 它确定如何将对等节点分配给特定组织中的特定角色，从而获得对区块链资源的适当访问。此外，对等节点只能由单个组织拥有，因此与单个MSP相关联。我们将在本节后面详细了解对等节点访问控制，本指南的其他部分有关于MSP和访问控制策略的完整部分。但就目前而言，将MSP视为在区块链网络中提供单个身份与特定组织角色之间的联接。

To digress for a moment, peers as well as *everything that interacts with a blockchain network acquire their organizational identity from their digital certificate and an MSP*. Peers, applications, end users, administrators and orderers must have an identity and an associated MSP if they want to interact with a blockchain network. *We give a name to every entity that interacts with a blockchain network using an identity — a principal*. You can learn lots more about principals and organizations elsewhere in this guide, but for now you know more than enough to continue your understanding of peers!  
离题了片刻，对等节点以及*与区块链网络交互的一切都从他们的数字证书和MSP获得他们的组织身份*。对等节点、应用程序、最终用户、管理员和排序节点如果想与区块链网络交互，都必须拥有身份和相关的MSP。 *我们给与区块链网络交互的每个实体使用的身份起了个名字，叫作委托人（principal）*。你可以在本指南的其他地方了解更多有关委托人和组织的内容，但是现在你已经了解了足够多以继续理解对等节点！

Finally, note that it’s not really important where the peer is physically located — it could reside in the cloud, or in a data centre owned by one of the organizations, or on a local machine — it’s the identity associated with it that identifies it as being owned by a particular organization. In our example above, P3 could be hosted in Org1’s data center, but as long as the digital certificate associated with it is issued by CA2, then it’s owned by Org2.  
最后，请注意，对等节点的物理位置并不重要 - 它可以驻留在云中，也可以驻留在其中一个组织所拥有的数据中心或本地计算机中 - 它用与之关联的标识，将其标识为由特定组织拥有。在上面的示例中，P3可以托管在Org1的数据中心，但只要与之关联的数字证书由CA2发布，那么它就由Org2拥有。

## 对等节点与排序节点（Peers and Orderers） ##

We’ve seen that peers form the basis for a blockchain network, hosting ledgers and chaincode which can be queried and updated by peer-connected applications. However, the mechanism by which applications and peers interact with each other to ensure that every peer’s ledger is kept consistent is mediated by special nodes called orderers, and it’s to these nodes we now turn our attention.  
我们已经看到，对等节点构成了区块链网络的基础，托管账本和链代码，链代码可以通过对等节点连接的应用程序进行查询和更新。但是，应用程序和对等节点之间交互以确保每个对等节点的帐本保持一致的机制由称为排序（orderers）的特殊节点调解，现在我们转向注意这些节点。

An update transaction is quite different from a query transaction because a single peer cannot, on its own, update the ledger — updating requires the consent of other peers in the network. A peer requires other peers in the network to approve a ledger update before it can be applied to a peer’s local ledger. This process is called consensus, which takes much longer to complete than a simple query. But when all the peers required to approve the transaction do so, and the transaction is committed to the ledger, peers will notify their connected applications that the ledger has been updated. You’re about to be shown a lot more detail about how peers and orderers manage the consensus process in this section.  
更新交易与查询交易完全不同，因为单个对等节点本身不能更新帐本 - 更新需要网络中其他对等节点的同意。对等节点要求网络中的其他对等节点批准帐本更新，然后才能将其应用于对等节点的本地帐本。此过程称为共识，与简单查询相比，需要更长的时间才能完成。但是，当需要批准交易的所有对等节点都这样做，并且交易被提交到帐本时，对等节点将通知其连接的应用程序帐本已更新。你将在本节中更详细地了解对等节点和排序节点如何管理共识流程。

Specifically, applications that want to update the ledger are involved in a 3-phase process, which ensures that all the peers in a blockchain network keep their ledgers consistent with each other. In the first phase, applications work with a subset of endorsing peers, each of which provide an endorsement of the proposed ledger update to the application, but do not apply the proposed update to their copy of the ledger. In the second phase, these separate endorsements are collected together as transactions and packaged into blocks. In the final phase, these blocks are distributed back to every peer where each transaction is validated before being applied to that peer’s copy of the ledger.  
具体而言，想要更新帐本的应用程序涉及一个三阶段过程，这可确保区块链网络中的所有对等节点保持其帐本彼此一致。在第一阶段，应用程序使用一个背书节点的子集，每个节点提供对应用程序的帐本更新建案的背书，但不将建案的更新应用于其帐本副本。在第二阶段，这些单独的背书作为交易收集在一起并打包成区块。在最后阶段，这些区块将被分发回每个对等节点，在每个对等节点都验证每个交易，然后再应用于该对等节点的帐本副本。

As you will see, orderer nodes are central to this process, so let’s investigate in a little more detail how applications and peers use orderers to generate ledger updates that can be consistently applied to a distributed, replicated ledger.  
正如你将看到的，排序节点是此过程的核心，因此让我们更详细地研究应用程序和对等节点如何使用排序节点生成可以一致应用于分布式可复制帐本的帐本更新。

### 阶段1：提案（Phase 1: Proposal） ###

Phase 1 of the transaction workflow involves an interaction between an application and a set of peers — it does not involve orderers. Phase 1 is only concerned with an application asking different organizations’ endorsing peers to agree to the results of the proposed chaincode invocation.  
交易流程的第1阶段涉及应用程序和一组对等节点之间的交互 - 它不涉及排序节点。 第1阶段仅涉及一个应用程序要求不同组织的背书节点同意所提案的链代码的调用结果。

To start phase 1, applications generate a transaction proposal which they send to each of the required set of peers for endorsement. Each of these endorsing peers then independently executes a chaincode using the transaction proposal to generate a transaction proposal response. It does not apply this update to the ledger, but rather simply signs it and returns it to the application. Once the application has received a sufficient number of signed proposal responses, the first phase of the transaction flow is complete. Let’s examine this phase in a little more detail.  
为了启动阶段1，应用程序生成一个交易提案，并将其发送给每个需要的对等节点以进行背书。 然后，这些背书节点中的每一个使用交易提案独立地执行链代码以生成交易提案响应。 它不会将此更新应用于帐本，而是简单地对其进行签名并将其返回给应用程序。 一旦应用程序收到足够数量的签名提案响应，交易流程的第一阶段就完成了。 让我们更详细地研究这个阶段。

![Peer10][]

*Transaction proposals are independently executed by peers who return endorsed proposal responses. In this example, application A1 generates transaction T1 proposal P which it sends to both peer P1 and peer P2 on channel C. P1 executes S1 using transaction T1 proposal P generating transaction T1 response R1 which it endorses with E1. Independently, P2 executes S1 using transaction T1 proposal P generating transaction T1 response R2 which it endorses with E2. Application A1 receives two endorsed responses for transaction T1, namely E1 and E2.*  
*交易提案由返回已背书提案响应的对等节点独立执行。在该示例中，应用程序A1生成交易T1提案P，其在通道C上发送给对等P1和对等P2。P1使用交易T1提议P执行S1，生成交易T1的响应R1，它用E1背书。独立地，P2使用交易T1提议P执行S1，生成交易T1的响应R2，它用E2背书。应用程序A1收到交易T1的两个背书响应，即E1和E2。*

Initially, a set of peers are chosen by the application to generate a set of proposed ledger updates. Which peers are chosen by the application? Well, that depends on the endorsement policy (defined for a chaincode), which defines the set of organizations that need to endorse a proposed ledger change before it can be accepted by the network. This is literally what it means to achieve consensus — every organization who matters must have endorsed the proposed ledger change before it will be accepted onto any peer’s ledger.  
最初，应用程序选择一组对等节点来生成一组帐本更新的建案。应用程序选择哪些对等节点呢？那么，这取决于背书策略（定义为链代码），该政策定义了在网络接受之前需要认可帐本变更的组织集合。这实际上是达成共识的意思 - 每个重要的组织必须在任何对等节点账本被接受之前认可账本变更的提案。

A peer endorses a proposal response by adding its digital signature, and signing the entire payload using its private key. This endorsement can be subsequently used to prove that this organization’s peer generated a particular response. In our example, if peer P1 is owned by organization Org1, endorsement E1 corresponds to a digital proof that “Transaction T1 response R1 on ledger L1 has been provided by Org1’s peer P1!”.  
对等节点通过添加其数字签名并使用其私钥对整个有效负载进行签名来背书提议响应。这种背书随后可用于证明该组织的对等节点产生了特定的响应。在我们的示例中，如果对等节点P1由组织Org1拥有，则背书E1对应于“Org1的对等节点P1已经提供了账本L1上的交易T1的响应R1！”的数字证据。

Phase 1 ends when the application receives signed proposal responses from sufficient peers. We note that different peers can return different and therefore inconsistent transaction responses to the application *for the same transaction proposal*. It might simply be that the result was generated at different times on different peers with ledgers at different states, in which case an application can simply request a more up-to-date proposal response. Less likely, but much more seriously, results might be different because the chaincode is non-deterministic. Non-determinism is the enemy of chaincodes and ledgers and if it occurs it indicates a serious problem with the proposed transaction, as inconsistent results cannot, obviously, be applied to ledgers. An individual peer cannot know that their transaction result is non-deterministic — transaction responses must be gathered together for comparison before non-determinism can be detected. (Strictly speaking, even this is not enough, but we defer this discussion to the transaction section, where non-determinism is discussed in detail.)  
当应用程序收到来自足够对等节点的签名提案响应时，阶段1结束。我们注意到，*对于相同的交易提案*，不同的对等节点可以向应用程序返回不同且因此不一致的交易响应。可能只是在不同的对等节点上，在不同状态下的账本生成结果，在这种情况下，应用程序可以简单地请求更新的提案响应。不太可能，但更严重的是，因为链代码是非确定性的，结果可能会有所不同。非确定性是链代码和账本的敌人，如果它发生，则表明提议的交易存在严重问题，因为不一致的结果显然不适用于账本。单个对等节点无法知道其交易结果是非确定性的 - 在检测到非确定性之前，必须将交易响应收集在一起进行比较。 （严格地说，即使这还不够，但我们将此讨论推迟到交易章节，其中详细讨论了非确定性。）

At the end of phase 1, the application is free to discard inconsistent transaction responses if it wishes to do so, effectively terminating the transaction workflow early. We’ll see later that if an application tries to use an inconsistent set of transaction responses to update the ledger, it will be rejected.  
在阶段1结束时，如果应用程序愿意，应用程序可以自由地丢弃不一致的交易响应，从而有效地提前终止交易流程。稍后我们将看到，如果应用程序尝试使用一组不一致的交易响应来更新帐本，它将被拒绝。

### 阶段2：包装（Phase 2: Packaging） ###

The second phase of the transaction workflow is the packaging phase. The orderer is pivotal to this process — it receives transactions containing endorsed transaction proposal responses from many applications. It orders each transaction relative to other transactions, and packages batches of transactions into blocks ready for distribution back to all peers connected to the orderer, including the original endorsing peers.  
交易工作流程的第二阶段是包装阶段。 排序节点对此过程至关重要 - 它接收来自许多应用程序的包含已背书交易提案响应的交易。 它将每个交易相对于其他交易进行排序，并将批量交易打包成区块，准备好分发回连接到排序节点的所有对等节点，包括原始的背书对等节点。

![Peer11][]

*The first role of an orderer node is to package proposed ledger updates. In this example, application A1 sends a transaction T1 endorsed by E1 and E2 to the orderer O1. In parallel, Application A2 sends transaction T2 endorsed by E1 to the orderer O1. O1 packages transaction T1 from application A1 and transaction T2 from application A2 together with other transactions from other applications in the network into block B2. We can see that in B2, the transaction order is T1,T2,T3,T4,T6,T5 – which may not be the order in which these transactions arrived at the orderer node! (This example shows a very simplified orderer configuration.)*  
*排序节点的第一个角色是打包提议的帐本更新。在该示例中，应用程序A1将由E1和E2背书的交易T1发送到排序节点O1。并行地，应用程序A2将由E1背书的交易T2发送到排序节点O1。 O1将来自应用程序A1的交易T1和来自应用程序A2的交易T2与来自网络中的其他应用程序的其他交易一起打包到区块B2中。我们可以看到，在B2中，交易的顺序是T1、T2、T3  
、T4、T6、T5 - 这可能不是这些交易到达排序节点的顺序！（此示例显示了非常简化的排序配置。）*

An orderer receives proposed ledger updates concurrently from many different applications in the network on a particular channel. Its job is to arrange these proposed updates into a well-defined sequence, and package them into blocks for subsequent distribution. These blocks will become the blocks of the blockchain! Once an orderer has generated a block of the desired size, or after a maximum elapsed time, it will be sent to all peers connected to it on a particular channel. We’ll see how this block is processed in phase 3.  
排序节点在特定通道上从网络中的许多不同应用程序同时接收提议的帐本更新。它的工作是将这些提议的更新安排到明确定义的序列中，并将它们打包成区块以供后续分发。这些区块将成为区块链的区块！一旦排序节点生成了所需大小的区块，或者在最大经过时间之后，它将被发送到在特定通道上连接到它的所有对等节点。我们将在第3阶段看到如何处理此区块。

It’s worth noting that the sequencing of transactions in a block is not necessarily the same as the order of arrival of transactions at the orderer! Transactions can be packaged in any order into a block, and it’s this sequence that becomes the order of execution. What’s important is that there is a strict order, rather than **what** that order is.  
值得注意的是，区块中交易的顺序不一定与交易到达排序节点的顺序相同！交易可能按任何顺序打包到一个区块中，而这个序列就成了执行的顺序。重要的是有一个严格的命令，而不是那个命令是**什么**。

This strict ordering of transactions within blocks makes Hyperledger Fabric a little different from other blockchains where the same transaction can be packaged into multiple different blocks. In Hyperledger Fabric, this cannot happen — the blocks generated by a collection of orderers are said to be **final** because once a transaction has been written to a block, its position in the ledger is immutably assured. Hyperledger Fabric’s finality means that a disastrous occurrence known as a **ledger fork** cannot occur. Once transactions are captured in a block, history cannot be rewritten for that transaction at a future point in time.  
区块内交易的这种严格排序使Hyperledger Fabric与其他区块链略有不同，其他区块链可以将相同的交易打包到多个不同的块中。在Hyperledger Fabric中，这不可能发生 - 由排序节点集合生成的区块被认为是**最终**，因为一旦交易被写入区块，它在账本中的位置是确定不可变化的。Hyperledger Fabric的最终结果意味着不会发生称为**帐本分叉**的灾难性事件。一旦交易被捕获到一个区块中，就不能在将来的时间点为该交易重写历史记录。

We can see also see that, whereas peers host the ledger and chaincodes, orderers most definitely do not. Every transaction that arrives at an orderer is mechanically packaged in a block — the orderer makes no judgement as to the value of a transaction, it simply packages it. That’s an important property of Hyperledger Fabric — all transactions are marshalled into a strict order — transactions are never dropped or de-prioritized.  
我们也可以看到，虽然对等节点托管账本和链代码，但排序节点绝对不做这个。到达排序节点的每个交易都是机械地打包在一个区块中 - 排序节点不会对交易的价值做出判断，它只是打包它。这是Hyperledger Fabric的一个重要属性 - 所有交易都被编组成严格的顺序 - 交易永远不会丢失或去优先级。

At the end of phase 2, we see that orderers have been responsible for the simple but vital processes of collecting proposed transaction updates, ordering them, packaging them into blocks, ready for distribution.  
在第2阶段结束时，我们看到排序节点负责收集提议的更新交易，排序它们，将它们打包进去块，准备分发的简单但至关重要的过程。

### 阶段3：验证（Phase 3: Validation） ###

The final phase of the transaction workflow involves the distribution and subsequent validation of blocks from the orderer to the peers, where they can be applied to the ledger. Specifically, at each peer, every transaction within a block is validated to ensure that it has been consistently endorsed by all relevant organizations before it is applied to the ledger. Failed transactions are retained for audit, but are not applied to the ledger.  
交易流程的最后阶段涉及从排序节点到对等节点的区块分发和后续验证，这些对等节点可以把交易应用到帐本。具体而言，在每个对等节点中，区块中的每个交易都经过验证，以确保在将其应用到帐本之前始终得到所有相关组织的认可。 保留失败的交易以进行审计，但不会应用于帐本。

![Peer12][]

*The second role of an orderer node is to distribute blocks to peers. In this example, orderer O1 distributes block B2 to peer P1 and peer P2. Peer P1 processes block B2, resulting in a new block being added to ledger L1 on P1. In parallel, peer P2 processes block B2, resulting in a new block being added to ledger L1 on P2. Once this process is complete, the ledger L1 has been consistently updated on peers P1 and P2, and each may inform connected applications that the transaction has been processed.*  
*排序节点的第二个角色是将区块分发到对等节点。在该示例中，排序节点O1将区块B2分发给对等节点P1和对等节点P2。对等节点P1处理区块B2，导致在P1上将新区块添加到帐本L1。并行地，对等节点P2处理区块B2，导致在P2上将新区块添加到账本L1。完成此过程，就是已在对等节点P1和P2上持续地更新了帐本L1，并且每个帐本可以通知连接的应用程序已处理该交易。*

Phase 3 begins with the orderer distributing blocks to all peers connected to it. Peers are connected to orderers on channels such that when a new block is generated, all of the peers connected to the orderer will be sent a copy of the new block. Each peer will process this block independently, but in exactly the same way as every other peer on the channel. In this way, we’ll see that the ledger can be kept consistent. It’s also worth noting that not every peer needs to be connected to an orderer — peers can cascade blocks to other peers using the gossip protocol, who also can process them independently. But let’s leave that discussion to another time!  
阶段3开始于排序节点将区块分配给连接到它的所有对等节点。对等节点被连接到通道上的排序节点，这样当生成新区块时，连接到排序节点的所有对等节点将被发送新区块的副本。每个对等节点将独立处理此块，但其方式与通道上的每个其他对等节点完全相同。通过这种方式，我们看到帐本可以保持一致。值得注意的是，不是每个对等节点都需要连接到一个排序节点 - 对等节点可以使用流言协议将区块级联到其他对等节点，这协议也可以独立处理它们。但是让我们把这个讨论留给另一个时间！

Upon receipt of a block, a peer will process each transaction in the sequence in which it appears in the block. For every transaction, each peer will verify that the transaction has been endorsed by the required organizations according to the endorsement policy of the chaincode which generated the transaction. For example, some transactions may only need to be endorsed by a single organization, whereas others may require multiple endorsements before they are considered valid. This process of validation verifies that all relevant organizations have generated the same outcome or result. Also note that this validation is different than the endorsement check in phase 1, where it is the application that receives the response from endorsing peers and makes the decision to send the proposal transactions. In case the application violates the endorsement policy by sending wrong transactions, the peer is still able to reject the transaction in the validation process of phase 3.  
收到一个块后，对等节点将按照它在区块中出现的顺序处理每个交易。对于每个交易，每个对等节点将根据生成交易的链代码的背书策略来验证交易是否已被所需组织认可。例如，某些交易可能只需要由单个组织认可，而其他交易可能需要多个认可才能被视为有效。此验证过程验证所有相关组织是否已生成相同的成果或结果。另请注意，此验证与第1阶段中的背书检查不同，在第1阶段，应用程序接收来自背书对等节点的响应，并决定发送交易提案。如果应用程序通过发送错误的交易违反了背书策略，则对等节点仍然能够在阶段3的验证过程中拒绝该交易。

If a transaction has been endorsed correctly, the peer will attempt to apply it to the ledger. To do this, a peer must perform a ledger consistency check to verify that the current state of the ledger is compatible with the state of the ledger when the proposed update was generated. This may not always be possible, even when the transaction has been fully endorsed. For example, another transaction may have updated the same asset in the ledger such that the transaction update is no longer valid and therefore can no longer be applied. In this way each peer’s copy of the ledger is kept consistent across the network because they each follow the same rules for validation.  
如果交易已正确背书，则对等节点将尝试将其应用于帐本。为此，对等节点必须执行帐本一致性检查，以验证账本的当前状态是否与生成建议更新时帐本的状态兼容。即使交易已得到完全认可，这也并非总是可能的。例如，另一个交易可能已更新帐本中的相同资产，使得交易更新不再有效，因此无法再应用。通过这种方式，每个对等节点的帐本副本在整个网络中保持一致，因为它们每个都遵循相同的验证规则。

After a peer has successfully validated each individual transaction, it updates the ledger. Failed transactions are not applied to the ledger, but they are retained for audit purposes, as are successful transactions. This means that peer blocks are almost exactly the same as the blocks received from the orderer, except for a valid or invalid indicator on each transaction in the block.  
在对等节点成功验证每个单独的交易后，它会更新帐本。失败的交易不会应用于帐本，但会将其保留用于审计目的，成功的交易也是如此。这意味着对等节点的区块几乎与从排序节点接收的区块完全相同，除了区块中每个交易的有效或无效指示符。

We also note that phase 3 does not require the running of chaincodes — this is done only during phase 1, and that’s important. It means that chaincodes only have to be available on endorsing nodes, rather than throughout the blockchain network. This is often helpful as it keeps the logic of the chaincode confidential to endorsing organizations. This is in contrast to the output of the chaincodes (the transaction proposal responses) which are shared with every peer in the channel, whether or not they endorsed the transaction. This specialization of endorsing peers is designed to help scalability.  
我们还注意到阶段3不需要运行链代码 - 这仅在阶段1期间做，这很重要。这意味着只需在背书节点上提供链代码，而不是整个区块链网络。这通常是有帮助的，因为它为背书组织保守了链代码的逻辑秘密。这与链代码的输出（交易提案响应）形成对比，链代码的输出与通道中的每个对等节点共享，无论它们是否需要认可交易。这种背书对等节点的专业化旨在帮助实现可伸缩性。

Finally, every time a block is committed to a peer’s ledger, that peer generates an appropriate event. Block events include the full block content, while block transaction events include summary information only, such as whether each transaction in the block has been validated or invalidated. Chaincode events that the chaincode execution has produced can also be published at this time. Applications can register for these event types so that they can be notified when they occur. These notifications conclude the third and final phase of the transaction workflow.  
最后，每次将区块提交给对等节点的帐本时，该对等节点都会生成适当的事件。区块事件包括完整区块内容，而区块交易事件仅包括摘要信息，例如块中的每个交易是否已经生证或无效。链代码执行产生的链代码事件也可以在此时发布。应用程序可以注册这些事件类型，以便在它们发生时得到通知。这些通知结束了交易流程的第三个也是最后一个阶段。

In summary, phase 3 sees the blocks which are generated by the orderer consistently applied to the ledger. The strict ordering of transactions into blocks allows each peer to validate that transaction updates are consistently applied across the blockchain network.  
总之，阶段3看到由排序节点生成的区块一致地应用到帐本。将交易严格排序到区块中允许每个对等节点验证在区块链网络上一致地应用交易更新。

### 排序节点与共识（Orderers and Consensus） ###

This entire transaction workflow process is called consensus because all peers have reached agreement on the order and content of transactions, in a process that is mediated by orderers. Consensus is a multi-step process and applications are only notified of ledger updates when the process is complete — which may happen at slightly different times on different peers.  
整个交易流程过程称为共识，因为所有对等节点都已在排序和交易内容上达成协议，这一过程由排序节点调解。 共识是一个多步骤的过程，只有在流程完成时，应用程序才会被通知帐本更新 - 这可能会在不同的对等节点上稍微不同的时间发生。

We will discuss orderers in a lot more detail in a future orderer topic, but for now, think of orderers as nodes which collect and distribute proposed ledger updates from applications for peers to validate and include on the ledger.  
我们将在未来的排序节点主题中更详细地讨论排序节点，但是现在，将排序节点视为从对等节点的应用程序收集和分发提议的帐本更新，以验证并包含到帐本中。

That’s it! We’ve now finished our tour of peers and the other components that they relate to in Hyperledger Fabric. We’ve seen that peers are in many ways the most fundamental element — they form the network, host chaincodes and the ledger, handle transaction proposals and responses, and keep the ledger up-to-date by consistently applying transaction updates to it.  
就这样而已！ 我们现在已经完成了对等节点以及Hyperledger Fabric中与之相关的其他组件的巡视。 我们已经看到，对等节点在很多方面都是最基本的元素 - 它们构成了网络，托管链代码和账本，处理交易提案和响应，并通过一致地应用交易更新来使账本保持最新状态。

[Peer1]: /images/20220509/874c5c1fd66c4419b5b445c176f5cda0.png
[Peer2]: /images/20220509/2fd186e1ef9f49ab8713abf7f14d7c12.png
[Peer3]: /images/20220509/ef1cc3aab7f44aeaa64a302936463b8a.png
[Peer4]: /images/20220509/22d38688f4c9410995c4d7e1e87194c9.png
[Peer6]: /images/20220509/daff5b86b3b144178705fff14e06ce02.png
[Transaction Flow]: https://hyperledger-fabric.readthedocs.io/en/release-1.3/txflow.html
[Peer5]: /images/20220509/e21e3513d6964b1da9afa9550b5aa777.png
[Peer8]: /images/20220509/fc8d6e4358134d3bb76666053d2f7f13.png
[example above]: https://hyperledger-fabric.readthedocs.io/en/release-1.3/peers/peers.html#Peer8
[Peer9]: /images/20220509/7576a44924134d1a93bcb6e8a45f1cd5.png
[Peer10]: /images/20220509/e36b42d5a7a84961869a548cfe44a995.png
[Peer11]: /images/20220509/e247cdf9ec7746edadba2fdeef95fa2e.png
[Peer12]: /images/20220509/4efbad99527d430cacf86fcf36dd8cd9.png