官方文档：Peers

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 (which in Hyperledger Fabric are contained in a chaincode, more on this later). 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 Fabric network.

区块链网络主要由一组peer节点组成（简称peers）。peers是网络的基本元素，是因为它们托管账本和智能合约。回想一下，账本一成不变地记录了智能合约生成的所有交易。智能合约和账本分别用于封装网络中的共享程序和共享信息。peers的这些方面使它们成为了解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 Fabric network.

组成区块链网络的其他元素当然也很重要：账本和智能合约、orderers、策略、通道、应用程序、组织、身份识别，以及联盟成员，您可以在他们自己的专用部分中阅读有关它们的更多信息。本节重点介绍peers及其与Fabric网络中其他元素的关系。

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.

智能合约的网络是由peer节点构成，每个peer节点都托管账本的副本以及智能合约的副本。略。。。

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.

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

A word on terminology（术语）

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! If you want to learn more about chaincode and smart contracts, check out our documentation on smart contracts and chaincode.

Fabric通过称为链码的技术概念实现智能合约，chaincode是用一种使用Fabric支持的编程语言编写的访问账本的一段代码。在本主题中，我们通常使用chaincode一词，但如果您更习惯smart contract术语，也可以将其作为智能合约阅读。It’s the same thing! If you want to learn more about chaincode and smart contracts, check out our documentation on smart contracts and chaincode.

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.

让我们再详细的看一下peer。我们可以看到peer既托管了账本也托管了链码。更准确地说，peer实际上托管账本实例和链码实例。请注意，这在Fabric网络中提供了有意的冗余-避免了单点故障。在本节的后面，我们将详细了解区块链网络的分布式和分散式性质。

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.

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 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.

因为peer托管了账本和链码，因此应用程序和系统管理员如果想要获取这些资源必须与peer进行交互。这就是为什么将peer视为Fabric网络的最基本组成部分。当peer在一开始被创建时，它既没有账本也没有链码。我们会在后面看到在peers上账本是如何创建的以及链码是如何安装的。

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.

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.

peer托管了一个或多个账本，并且托管了0个或更多的链码

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.

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

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.

Peer拥有的账本数量与可以访问该账本的链码数量之间的关系不是固定的。一个peer可能有许多可用的链码和分类帐。

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.

如上图所示，既可以有多个链码访问同一个账本；也可以一个链码访问多个账本。

We’ll see a little later why the concept of channels in Fabric is important when hosting multiple ledgers or multiple chaincodes on a peer.

我们稍后再看到当在peer上托管多个分类帐或多个链码时，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 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.

现在，我们将展示应用程序如何与peer交互以访问账本。账本查询交互包括应用程序和peer之间简单的三步对话；账本更新的交互要复杂得多，并且需要两个额外的步骤。我们已简化了这些步骤，以帮助您开始使用Fabric，但请放心，最重要的是要了解账本查询与账本更新两种交易方式之间的应用程序和peer交互的差异。

Applications always connect to peers when they need to access ledgers and chaincodes. The 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, validated and committed to the distributed ledger, and receive events when this process is complete.

当应用程序需要访问账本和链码时总是与peer链接。Fabric的SDK让这变得简单，它的API可以让应用程序链接到peers，调用链码来生成交易，提交交易到网络并且获得排序，验证和提交到分布式账本以及当这些程序结束时接收事件。

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.

通过连接到一个peer，应用程序可以执行链码来查询或者更新账本。账本的查询交易结果将立即返回，但是账本的更新将涉及应用程序、peers和orderers之间的更复杂的的交互。让我们对此进行更详细的研究。

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 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 committing to L1. Once L1 is updated, P1 generates an event, received by A, to signify completion.

查询时有图中的1、2、3三个步骤。更新时需要额外的4、5两个步骤的操作。

• 1 应用程序链接到peer
• 2 应用程序（带着交易提议）调用链码
• 2.1 peer（带着交易提议）调用托管在peer上的链码
• 2.2 链码生成查询或更新的提议响应
• 3 peer把提议响应返回给应用程序
• 4 应用程序请求排序节点对交易进行排序
• 4.1 排序节点把排好序并打包在区块中交易发送给peers
• 4.2 peer使用交易区块更新本地的账本
• 5 peer发出账本更新的事件

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.

peer可以马上把查询结果返回给应用程序是因为查询的所有信息都存在于peer节点的本地账本副本中。Peers从不与其他peer协商以响应来自应用程序的查询。但是应用程序可以链接一个或多个peer来发出查询，例如，在多个peer之间确认结果，或者如果怀疑信息可能已过时，则从另一个peer检索最新结果。

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 by using an orderer to package transactions into blocks, and distributing 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.

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.

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.

尽管本部分介绍的是peer而不是通道，但是值得花一些时间来了解peer如何通过通道与其他peer以及应用程序进行交互。通道是一种机制，区块链网络中的一组组件可以通过该机制进行私下通信和交易。

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.

这些组件通常是peer节点，orderer节点和应用程序，通过加入通道，它们同意协作以共同共享和管理与该通道关联的账本的相同副本。从概念上讲，您可以将通道视为与朋友组相似。一个人可能有多组朋友，每组都有他们一起做的活动。这些组可能完全分开，它们之间也可能会有交叉。但是，每个组都是其自己的实体，具有某种“规则”。

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.)

在区块链网络中通道允许指定的一组peer和应用程序进行通信。

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.

通道是一组物理peer的逻辑结构，peer提供了对通道的访问与管理权限。

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.

区块链网络由多个组织管理，而不是单个组织管理。peers对于这种分布式网络的构建至关重要因为他们属于他们的组织，并且他们是他们组织的网络连接点。

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.

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.

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.

如上例所示，不同组织中的应用程序可能相同，也可能不同。

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.

应用程序可以连接到自己组织的peer节点，也可以连接到其他组织的peer节点，具体取决于所需的账本交互的性质。对于账本查询交互，应用程序通常会连接到自己组织的peer节点。对于账本更新交互，我们将在后面看到为什么应用程序需要连接到代表认可账本更新所需的每个组织的peer。

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.

Peers具有通过特定证书颁发机构通过数字证书分配给他们的身份。***。网络中的每个peer节点都由其所属组织的管理员分配的数字证书。

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.

当peer连接到通道时，其数字证书通过通道MSP标识其归属的组织。

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.

每当peer使用通道连接到区块链网络时，通道配置中的策略都会使用peer的身份来确定其权利。***

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!

Peers以及与区块链网络交互的所有事物均从其数字证书和MSP获取其组织身份。***

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 digital certificate 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.

最后，注意peer的物理位置不是很重要，它可以部署在云上，也可以部署在本地物理机上；不管它在哪里，之相关联的数字证书将其标识为特定组织所拥有。***

Peers and Orderers

We’ve seen that peers form the basis for a blockchain network, hosting ledgers and smart contracts 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 with each other is mediated by special nodes called orderers, and it’s to these nodes we now turn our attention.

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.

更新交易与查询交易是有很大区别的，因为单独的peer不可以自己完成更新账本的工作。更新账本的操作需要网络中其他peer的同意。peer需要网络中的其他peer批准账本更新，然后才能将其应用于peer上的本地账本。此过程称为共识，与简单的查询相比，此过程需要更长的时间才能完成。但是，当所有需要批准交易的peer节点都批准了该交易并将交易提交到账本时，peer将通知其连接的应用程序账本已更新。在本部分中，您将获得有关peers和peers如何管理共识过程的更多详细信息。

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.

具体来说，想要更新账本的应用程序需要3个阶段的过程，这确保了区块链网络中的所有peer保持账本彼此一致。

• 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.

  在第一个阶段，应用程序与一些背书peer节点一起工作，每个背书peer节点都向应用程序提供对提议的账本更新的背书，但不将提议的更新应用于其账本的副本。

• In the second phase, these separate endorsements are collected together as transactions and packaged into blocks.

  在第二阶段，这些单独的背书将作为交易收集在一起，并打包成块。

• In the third and final phase, these blocks are distributed back to every peer where each transaction is validated before being committed to that peer’s copy of the ledger.

  在第三阶段（也是最后阶段），这些区块会重新分配给每个peer节点，在此之前，每个交易均经过验证，然后再提交给该peer的账本副本。

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.

如您所见，排序者节点是此过程的核心，因此，让我们更详细地研究一下应用程序和peer如何使用排序服务来生成账本更新，该更新可始终应用于分布式复制分类帐。

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.

交易流程的第一阶段涉及应用程序与一组peer之间的交互-它不涉及排序者。第一阶段只关心应用程序要求不同组织的背书节点同意提议的链码调用的结果。

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.

为了开始第一阶段，应用程序生成一个交易提议，然后发送这个交易提议到每个需要背书的peer列表。然后每个背书节点使用交易提议执行链码来生成交易提议响应。它不会将此更新应用于账本，而只是对其进行签名并将其返回给应用程序。一旦应用程序收到足够数量的已签名提案响应后，交易流程的第一阶段就完成了。让我们更详细地研究这个阶段。

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.

交易提议被每个peer节点独立的执行然后返回背书提议响应。

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.

最初应用程序选择一组peer节点来生成一组提议的账本更新。应用程序会选择哪些peer节点呢？这取决于（为链码定义的）背书策略，该策略定义了一个需要在网络接受之前批准提议的账本更新的组织列表。从字面上看，这是达成共识的意思 – 每个重要的组织都必须已经批准提议的账本更新，然后该更改才会被接受到其他peer的账本中。

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!”.

peer节点通过添加数字签名来认可提议响应，并且使用它的私钥对整个负载的数据进行签名。这个背书随后可以被用于证明这个组织的peer生成了响应。***

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.)

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

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.

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

Phase 2: Ordering and packaging transactions into blocks

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, and orders the transactions into blocks. For more details about the ordering and packaging phase, check out our conceptual information about the ordering phase.

交易流程的第二个阶段是打包阶段。排序者对于此过程至关重要-它从许多应用程序接收包含背书的交易提议响应的交易，并将交易排序打包成区块。***

Phase 3: Validation and commit

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, and packaging them into blocks, ready for distribution to the peers.

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 committed 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 committed to the ledger. Failed transactions are retained for audit, but are not committed to the ledger.

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

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.

排序者节点的第二个指责是将区块分发到peer节点。

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!

第三阶段开始于排序者分发区块到链接它的所有peer节点上。peer节点链接到通道上的排序节点，这样当一个新的区块生成是，所有的链接到排序节点的peer都会收到一个新区块的副本。每个peer都使用与通道上的其他节点一样的方式来独立处理这个区块。通过这种方式账本就可以保持一致了。还值得注意的是，并非每个peer节点都需要连接到排序者 – peer节点可以使用八卦协议将块级联到其他peer，这些peer也可以独立处理区块。

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.

收到区块之后后，peer节点将按照区块块中的顺序处理每个交易。对于每笔交易，每个peer节点都将根据产生交易的链码的背书政策来验证该交易是否已被所需的组织背书。例如，某些交易可能只需要由单个组织背书，而其他交易可能需要多个背书才能被视为有效。这个验证过程验证所有相关的组织都生成相同的产物或结果。另请注意，此验证与第一阶段中的背书检查不同，第一阶段的背书检查是应用程序在接收到来自背书节点的响应并做出发送提议交易的决定。如果应用程序发送了错误的交易违反了背书策略，在第三阶段的验证程序中peer节点仍然有能力拒绝此交易。

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, the ledger is kept consistent across each peer in the channel because they each follow the same rules for validation.

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

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.

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

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 and confidentiality.

我们还注意到，第3阶段不需要运行Chaincode，这仅在第1阶段才做，这一点很重要。这意味着链码仅在背书节点上可用，而不是在整个区块链网络上可用。这通常很有用，因为它可以使背书组织的链码逻辑保持私密。这与链码的输出（交易提议响应）相反，链码的输出与通道中的每个peer节点共享，无论他们是否认可交易。这种背书节点的专业化旨在帮助提高可伸缩性和机密性。

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.

最后，每次将一个区块提交给peer节点的账本之后，该peer节点都会生成一个适当的event。

• Block events 包含所有的区块内容，
• block transaction events 只包含摘要信息（例如区块中的每笔交易是否已通过验证或无效）
• Chaincode events 链码执行时产生的Chaincode events也可以在此时发布

应用程序可以注册这些事件类型，以便在事件发生时得到通知。这些通知结束了交易流程的第三阶段也就是最后阶段。

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.

总结来说，第三阶段将看到排序者生成的区块一致的应用于账本。严格的将交易排序然后打包到区块使每个peer节点验证交易更新被一致应用到blockchain网络中。

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.

整个交易流程被称为共识，是因为在排序节点的调解下所有peer节点都已就交易的顺序和内容达成共识。共识是一个多步骤的过程，只有在该过程完成后，才将账本更新通知应用程序 – 在不同的peer上，发生时间可能略有不同。

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 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.