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.
区块链网络主要由一组peer节点（或简单地说是peers）组成。 peers是网络的基本元素，因为他们持有账簿和智能合约。 回想一下，总账不变地记录了智能合约（或链码）产生的所有交易。 智能合同和总账分别用于将共享流程和共享信息封装在网络中。 peer的这些方面使他们成为了解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.
区块链网络的其他元素当然也很重要：总账和智能合约，orderers，策略，管道(channel)，应用程序，组织，身份和会员资格，您可以在自己的专门章节阅读更多关于它们的内容。 本节主要讨论peer方及其与Hyperledger 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节点组成，每个节点都可以存放总账和副本的智能合约副本。 在这个例子中，网络N由peers P1，P2和P3组成，每个peer维护其自己的分布式总账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.
peers可以被创建，启动，停止，重新配置，甚至删除。 他们公开了一组允许管理员和应用程序与他们提供的服务进行交互的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使用一种称为链码的技术概念实现智能合约，链码- 只是访问总账的一段代码，用一种支持的编程语言编写。 在这个话题中，我们通常会使用术语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实际上承载了总账的实例和链式代码的实例。 请注意，这在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.
peer持有总账实例和链码实例。 在这个例子中，P1持有总账L1的实例和一个链码S1的实例。 一个独立的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 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.
由于一个peer持有总账和链码，因此如果要访问这些资源，应用程序和管理员必须与peer进行交互。 这就是为什么peers被视为Hyperledger 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.
一个peer能够持有多个总账，这很有帮助，因为它助于设计灵活的系统。 最简单的配置是让peer管理单个总账，但在需要时，一个peer持两个或更多总账是绝对合适的。
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持有多个总账。 peers拥有一个或多个总账，每个总账有零个或多个适用于他们的链码。 在这个例子中，我们可以看到peer P1拥有总账L1和L2。 使用链码S1访问Ledger 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.
尽管一个peer完全可能持有一个总账实例，而没有持有任何访问该总账的链码，但很少去这样配置peers。 绝大多数peers至少会安装一个链码，可以查询或更新peer上账本实例。 值得一提的是，无论用户是否已经安装了供外部应用程序使用的链码，peers也都有特殊的系统链码，这些链码始终存在。 这些不在本主题中详细讨论。
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.
一个peer持有多个链码的例子。 每个总账可以有很多链码访问它。 在这个例子中，我们可以看到peer 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中管道(channel)的概念是非常重要的，当一个peer持有多个总账或多个链接码。
Applications and Peers/应用程序和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.
现在我们将展示应用程序如何与peers进行交互以访问总账。总账查询交互涉及应用程序和一个peers之间的简单三步对话;总账更新交互涉及更多一点，并且需要两个额外的步骤。我们已经简化了这些步骤，以帮助您开始使用Hyperledger Fabric，但不用担心 - 最重要的是要理解的是，与总账更新交易样式相比，总账查询的application-peer 交互中存在差异。
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.
当他们需要访问总账和链锁码时，应用程序总是连接到peers。Hyperledger 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和订单之间更复杂的交互。让我们更详细地调查一下。
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.
peers和orderers 一起确保总账在每个peer中都保持最新。在这个例子中，应用程序A连接到P1并调用链码S1来查询或更新总账L1。 P1调用S1来生成包含查询结果或“提议的总账更新”的提议响应。应用程序A接收提议响应，并且对于查询，该过程已完成。对于更新，A根据所有响应构建一个交易，并将它发送给O1进行排序。 O1将整个网络中的交易收集到块中，并将这些交易分发给所有peers，包括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.
一个peer可以立即将查询结果返回给应用程序，因为满足查询所需的所有信息均位于peer的本地总账副本中。为了响应来自应用程序的查询，peers不会咨询其他对的peers。但是，应用程序可以连接到一个或多个peers来发出查询;例如，确认多个peers之间的结果，或者如果怀疑信息可能过期，则从一个不同的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 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.
更新交易与查询交易以相同的方式启动，但有两个额外的步骤。尽管总账更新应用程序也连接到peers以调用链代码，但与总账查询应用程序不同，一个独立的peer目前无法执行总账更新，因为其他peers必须首先同意这一更改 - 一个称为共识的过程。因此，peers向应用程序返回提议的更新 – (To Check:)one that this peer would apply subject to other peers’ prior agreement。额外的第一步 - 第四步 – 要求应用程序向整个peers构成的网络发送一组适当的拟议更新作为一个交易，(To Check)为了恪守承诺 于各自总账。这是通过应用程序使用orderer将交易打包成块来实现的，并将它们分发到peers的整个网络，在应用到每个peer的总账本地副本之前，可以对其进行验证。由于整个排序处理需要一些时间才能完成（秒），因此应用程序会异步通知，如步骤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.
在本节稍后的部分，您将详细了解此ordering 流程的详细内容 - 有关此流程的详细信息，请参阅Transaction Flow主题。
Peers and Channels/peers和管道(channel)
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.
虽然本节讲述的是peers而不是管道(channel)，但值得花一点时间了解peers如何与peers、应用程序，通过管道(channel)进行交互 – 一种机制，通过该机制区块链网络中的一组组件可以私密交流和交易。
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 节点和应用程序，并且通过加入管道(channel)，他们同意合作共同共享和管理与该管道(channel)相关联的总账的相同副本。从概念上讲，您可以将管道(channel)视为与朋友群相似（尽管管道(channel)的成员当然不需要成为朋友！）。一个人可能有几个朋友群，每个群都有他们一起做的活动。这些群体可能是完全独立的（与一群业余爱好朋友相比，这是一群工作的朋友），或者他们之间可能存在一些交叉。尽管如此，每个团体都是自己的实体，拥有一种“规则”。
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.)
管道(channel)允许特定的一组peers和应用程序在区块链网络中相互通信。 在本例中，应用程序A可以使用管道(channel)C直接与peersP1和P2通信。您可以将该管道(channel)视为特定应用程序和peers之间通信的途径。 （为简单起见，orderers 未在本图中显示，但必须存在于功能正常的网络中。）
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.
我们发现管道(channel)的存在方式与peers不同 - 将管道(channel)视为由一系列物理peers形成的逻辑结构更为合适。 了解这一点至关重要 - peers提供了访问和管理管道(channel)的控制点。
Peers and Organizations/Peers和组织
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.
既然您了解peers及其与总账，链码和管道(channel)的关系，就能看到多个组织如何聚集在一起形成区块链网络。
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.
在多个组织的区块链网络中的peers。区块链网络由不同组织所拥有和贡献的peers建立。在这个例子中，我们看到有四个组织贡献八个peers组成一个网络。管道(channel)C连接网络N中的peers中的五个peers-P1，P3，P5，P7和P8。这些组织所拥有的其他peers尚未加入此管道(channel)，但通常会加入至少一个其他管道(channel)。由特定组织开发的应用程序将连接到他们自己的组织中的peers以及这些不同组织。同样，为了简单起见，orderer 节点未在此图中显示。
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.
能够看到区块链网络形成过程中发生的事情非常重要。该网络由多个为其提供资源的组织形成和管理。peers是我们在这个主题中讨论的资源，但组织提供的资源不仅仅是peers。这里有一个原则 – 如果没有组织向集体网络贡献他们的个人资源，这个网络就不存在了。而且，网络随着这些合作组织提供的资源的增长/缩小而增长/缩小。
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.
您可以看到（ordering 服务除外）没有集中的资源 - 在上面的示例中，如果组织不贡献他们的节点，则网络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.
如上例所示，不同组织中的应用程序可能相同，也可能不相同。这是因为它完全取决于一个组织的应用程序如何处理其peers的账本副本。这意味着应用程序和表示逻辑可能因组织而异，即使它们各自的peers拥有完全相同的总账数据。
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，或者连接到另一个组织中的peers，具体取决于所需的总账交互性质。对于总账查询交互，应用程序通常连接到他们自己的组织的peers。对于总账更新交互，我们稍后会看到为什么应用程序需要连接到代表每个需要批准总账更新的组织的peers。
Peers and Identity/Peers和身份
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如何聚集在一起形成区块链网络，因此值得花一点时间了解管理员如何将peers分配给组织。
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有一个身份标识，通过特定证书颁发机构发布的数字证书分配给他们。 您可以在本指南的其它地方阅读更多关于X.509数字证书如何工作的信息，但现在，考虑把数字证书认为就像身份证，它提供了关于peer许多可验证信息。 网络中的每个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.
当一个节点连接到一个管道(channel)时，它的数字证书将通过一个管道(channel)MSP识别其拥有的组织。在这个例子中，P1和P2具有由CA1发布的身份。管道(channel)C根据其管道(channel)配置中的策略确定来自CA1的身份应使用ORG1.MSP与Org1相关联。同样，P3和P4被ORG2.MSP识别为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.
当peer使用管道(channel)连接区块链网络时，管道(channel)配置中的策略就会使用peer的身份来确定其权限。身份到组织的映射由称为会员服务提供商（MSP）的组件提供 – 它确定如何将peer分配给特定组织中的特定角色，并因此获得对区块链资源的适当访问。而且，一个peer只能由一个单独的组织拥有，因此peer与单个MSP相关联。本节后面的内容将详细介绍peer访问控制，在本指南的其它部分还有一个完整的章节介绍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!
离题一下，peers以及与区块链网络交互的一切都通过其数字证书和MSP获取其组织身份。如果他们想要与区块链网络进行交互，则peers，应用程序，最终用户，管理员和orderers必须拥有身份，以及与之相关联的MSP。我们给每个使用身份（主体）与区块链网络进行交互的实体命名。您可以在本指南的其他地方了解更多关于主体和组织的信息，但现在您知道的东西已经足够让您继续了解peers！
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.
最后，请注意，peer在物理上位于何处并不重要 - 它可以位于云中，也可以位于其中一个组织拥有的数据中心或本地计算机上 - 与其关联的身份标识为由特定组织拥有。在我们上面的示例中，P3可以托管在Org1的数据中心中，但只要与其相关的数字证书由CA2发布，那么它就由Org2拥有。
Peers and Orderers/Peers和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.
我们已经看到，peers构成了区块链网络的基础，持有总账和链码，其可以通过连接的peer应用程序进行查询和更新。然而，应用程序和peers彼此交互以确保每个peer的总账保持一致的机制是由称为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.
更新交易与查询交易完全不同，因为单个peer本身不能更新总账 – 更新需要网络中其他peers的同意。一个peer需要网络中的其他peers批准总账更新，然后才能将其应用于其本地总账。这个过程被称为共识，这比完成简单的查询要花费更长的时间。但是当批准交易的
所有peers都这样做，并且交易提交更新到总账时，peers将通知他们的连接的应用程序总账已更新。本节中，您将会看到更多有关peers和orderers如何管理共识流程的详细信息。
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.
具体而言，需要更新总账的应用程序涉及3阶段流程，这可确保区块链网络中的所有peers保持其总账彼此一致。在第一阶段，应用程序与批准的peers的一个子集一起工作，每个peer都向应用程序提供一个“提议的总账更新”的认可，但不会将提议的更新应用于其总账副本。在第二阶段，这些单独的认可被作为交易收集在一起并打包成块。在最后阶段，将这些块分发回每个peer，每个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.
正如您将看到的那样，orderer节点对于此流程至关重要，因此让我们稍微详细地调查一下应用程序和peers如何使用orderers生成总账更新，这些总账更新可以始终适用于分布式复制总账。
Phase 1: Proposal/阶段1：提议
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.
交易工作流程的第一阶段涉及应用程序和一组peers之间的交互 - 它不涉及orderers。 阶段1只关注一个应用程序，要求不同组织的持赞同观点的peers同意所提议的链码调用的结果。
To startphase 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.
为了开始第一阶段，应用程序生成一个交易提议，并将其发送给每个需要的peers进行认可。 这些认可的peers中的每一个然后独立地使用交易提议来执行链码（智能合约）以生成交易提议响应。 它不会将此更新应用于总账，而只是简单地签署并将其返回给应用程序。 一旦应用程序收到足够数量的已签名提议响应，交易流程的第一阶段即告完成。 我们来仔细研究一下这个阶段。
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.
交易提议由返回认可提议的响应的peers独立执行。在这个例子中，应用程序A1生成交易T1提议P，它在管道(channel)C上发送给peer P1和peer 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.
最初，应用程序选择一组peers来生成一组“提议的总账更新”。应用程序选择了哪些peers？那么，这取决于背书(endorsement)策略（为链码定义），该策略定义了一类组织，该类组织需要认可提议的总账更改才能被网络接受。这实际上意味着达成共识 – 每个重要的组织都必须认可提议的总账更改，然后其它任何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产生了特定的回应。在我们的例子中，如果peer P1由组织Org1拥有，则认可E1对应于数字证明“在总账L1上的交易T1的响应R1已由Org1的同级P1！提供”。
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在应用程序收到来自足够peers的已签名提议响应时结束。我们注意到，不同的peers可以针对相同的交易提议返回不同的交易响应，并因此返回不一致的交易响应。这可能仅仅是因为结果是在不同时期，具有不同状态的总账的不同的peers上产生的，在这种情况下，应用程序可以简单地请求一个更新的提议响应。不太可能，但更严重的是，结果可能会不同，因为链码是非确定性的。非确定性是链码和总账的敌人，如果它出现，则表明交易建议存在严重问题，因为不一致的结果显然不适用于总账。个别的peers无法知道他们的交易结果是非确定性的 - 在检测到非确定性之前，必须收集交易响应以进行比较。 （严格地说，即使这还不够，但我们将此讨论推迟到交易部分，详细讨论非确定性问题。）
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: Packaging/阶段2：包装
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.
交易流程的第二阶段是包装阶段。 orderer对此流程至关重要 - 它接收来自许多应用程序的包含认可交易提议响应的交易。 它将每个交易相对于其他交易进行排序，并将批量交易打包为块，以准备分发回与orderer相连的所有peers，包括原始的peers。
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.)
orderer 节点的第一个角色是打包“提议的总账更新”。在这个例子中，应用程序A1将一个被E1和E2认可的交易T1发送给排序点O1。同时，应用程序A2将由E1认可的交易T2发送给排序点O1。 O1将来自应用程序A1的交易T1和来自应用程序A2的交易T2与来自网络中的其他应用程序的其它交易一起打包到块B2中。我们可以看到，在B2中，交易顺序是T1，T2，T3，T4，T6，T5 - 这可能不是这些交易到达orderer 节点的顺序！ （这个例子显示了一个非常简化的orderer配置。）
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.
orderer在特定管道(channel)上从网络中的许多不同应用程序同时接收“提议的总账更新”。它的工作是将这些提议的更新安排到一个明确定义的序列中，并将它们打包成块用于后续分发。这些区块将成为区块链的区块！一旦orderer生成了所需大小的数据块，或者经过最大限度的时间后，它将被发送到在特定管道(channel)上连接到它的所有peers。我们将看到这个块如何在阶段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.
值得注意的是，一个区块中交易的顺序不一定与交易到达orderer的顺序相同！交易可以按任意顺序打包到一个块中，并且这个顺序成为执行顺序。重要的是有严格的顺序，而不是那个顺序是什么。
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中，这种情况不会发生 - 由一组orderer生成的数据块被认为是最终的，因为一旦交易被写入到一个数据块中，其在总账中的位置确定不会变化。 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.
我们也可以看到，虽然peers持有总账和链码，但orderers绝对不会持有总账和链码。每一次到达orderer的交易都被机械地封装在一个区块中 - orderer对交易的价值不做任何判断，只是将其打包。这是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.
在第二阶段结束时，我们看到orderers承担了一个简单但至关重要的过程，在这个过程中收集提议交易更新，对它们进行排序，将它们打包成块，随时分发。
Phase 3: Validation/阶段3：验证
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.
交易工作流程的最后阶段涉及从orderer到peers的分发和随后块的验证，在peers处可以将这些块应用于总账。 具体而言，在每个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.
orderer 节点的第二个角色是将块分发给peers。在这个例子中，orderer O1将块B2分发给peer P1和P2。peer P1处理块B2，将产生新的块添加到P1上的总账L1。并行地，peer P2处理块B2，将产生新块添加到P2上的总账L1。一旦这个过程完成，总账L1在peerP1和P2上进行了一致更新，并且每个可以通知连接的应用程序交易已被处理。
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从orderer向连接到它的所有peers分发块开始。peers连接到管道(channel)上的orderers，以便当生成新的块时，连接到orderer的所有peers将被发送（接收到）新块的副本。每个peer都将独立处理此块，但与管道(channel)上的其他每个peer完全相同。通过这种方式，我们将看到总账可以保持一致。同样值得注意的是，并非每个peer都需要与orderer连接 – peer可以使用gossip协议将数据块级联到其他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将根据产生该交易的链码的背书(endorsement)策略验证交易是否已由所需组织认可。例如，某些交易可能只需要由单个组织认可，而其他交易可能需要多个认可才能被视为有效。验证过程验证所有相关组织都产生了相同的输出或结果。还请注意，此验证与第1阶段中的认可检查不同，在阶段1中， 应用程序从认可的peers处接收响应并作出发送提议交易的决定。如果应用程序通过发送错误的交易来违反背书(endorsement)策略，那么peer仍然能够在阶段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.
如果交易已被正确认可，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块与从orderer接收的块几乎完全相同，除了块中每个交易的有效或无效指示符外。
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中完成，这很重要。这意味着链码只能在认可（认可）节点上可用，而不能在整个区块链网络中使用。这通常是有帮助的，因为它将链码的逻辑保密,仅限于认可的组织知道。这与链码的输出（交易提议响应）形成对比，不管他们是否认可交易，这些输出都与管道(channel)中的每个对象共享。背书(endorsing) peers的这种专业化旨在帮助提高可伸缩性。
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就会生成一个适当的事件。块事件包括完整的块内容，而块交易事件仅包含摘要信息，例如块中的每个交易是否已被验证或失效。链码执行产生的Chaincode事件也可以在这个时候发布。应用程序可以注册这些事件类型，以便它们在发生时得到通知。这些通知结束了交易工作流程的第三个也是最后一个阶段。
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看到orderer生成的块始终应用于总账。块中严格的交易排序允许每个peer验证交易更新始终适用于整个区块链网络。
Orderers and Consensus/Orderers和共识
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.
整个交易工作流程过程被称为共识，因为所有peers都已经在由orderers调解的过程中就交易的顺序和内容达成一致。共识是一个多步骤的流程，当流程完成时，应用程序只会通知总账更新 – 这可能会在不同的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.
我们将在未来的orderer主题中更详细地讨论orderers，但现在，将orderers视为收集和分发来自应用程序的“提议的总账更新”的节点，以便peers验证和包括在总账上。
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.
就是这些！我们现在已经完成了对我们的peers和其他与Hyperledger Fabric相关的组件的介绍。我们已经看到，peers在很多方面是最基本的元素 - 它们形成网络，持有链码和总账，处理交易提议和响应，并通过持续向其应用交易更新来使总账保持最新状态。