Hyperledger Fabric v1.4(LTS) 系列(3.7)：关键概念-Peers

译文目录：

Hyperledger Fabric v1.4(LTS) 系列译文总目录

Key Concepts-Peers

• Introduction
• Hyperledger Fabric Functionalities
• Hyperledger Fabric Model
• Blockchain network
• Identity
• Membership
• Peers
  A word on terminology
  Ledgers and Chaincode
  Applications and Peers
  Peers and Channels
  Peers and Organizations
  Peers and Identity
  Peers and Orderers
• Smart Contracts and Chaincode
• Ledger
• The Ordering Service
• Private data
• Use Cases

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.
区块链网络主要由一组对等节点（略作节点）组成。对等节点是网络的基本元素，因为它们是分类账和智能合约的宿主。回想一下，分类账不可变地记录智能合约生成的所有交易（在Hyperledger Fabric中，这些交易包含在链码中，稍后详细介绍）。智能合约和分类账分别将共享的流程和信息封装在网络中。对等节点的这些方面使它们成为了解Fabric网络的最佳起点。

译注
这里peer nodes simplified by peers，但是中文正好又相反，对等节点会略写为节点，去掉的是peer而不是nodes。
确实，peer nodes的核心是peer，强调节点间的平等关系，但是中文又不能缩写为对等，没办法，只有缩写为节点了。

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.
区块链网络的其他元素也很重要：分类账和智能合约、排序节点、策略、通道、应用程序、组织、身份和成员资格，您可以在各自专门的章节中了解更多。本节重点介绍对等网络及其与结构网络中其他元素的关系。

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

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使用一个技术概念链码来实现智能合约，简单说它就是一段用所支持的编程语言之一编写的访问分类账的代码。在本主题中，我们通常使用术语链码，但如果您更习惯智能合约也可以，这是相同的。如果您想了解链码和智能合约的更多信息，查看[智能合约和链码文档](https://hyperledger fabric.readthedocs.io/en/release-1.4/peers/smartcontract/smartcontract.html)。

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网络中提供了刻意设计的冗余—它避免了单点故障。我们将在本节稍后了解区块链网络的分布式和去中心特性。

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 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.
因为对等节点是分类帐和链码的宿主机，所以如果应用程序和管理员想要访问这些资源，他们必须与对等节点进行交互。这就是为什么对等节点被认为是构建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.
一个对等节点能够承载多个分类账这一点很有用，因为它带来灵活的系统设计。最简单的配置是让一个对等节点管理单独的一个分类账，但是当需要时，一个对等节点绝对适合承载两个或更多分类账。

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访问分类帐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.
对等节点拥有的分类账数量及可以访问该分类账的链码数量之间没有固定的关系。一个对等节点可以有许多链码及可用的分类帐。

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 Fabric is important when hosting multiple ledgers or multiple chaincodes on a 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.
现在将展示应用程序如何与对等节点交互以访问分类账。分类帐查询交互包含应用程序和对等机之间简单的三步对话；分类帐更新交互稍微复杂一些，需要两个额外的步骤。我们稍微简化了这些步骤，以帮助您开始使用Fabric，但不要担心—最重要的是要了解应用程序和对等节点在进行分类帐查询和分类帐更新事务时的差异。

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 and committed to the distributed ledger, and receive events when this process is complete.
当需要访问分类帐和链码时，应用程序需要连接到对等节点。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.
通过和对等节点的连接，应用可以执行链码来查询或更新分类帐。分类帐查询事务的结果将立即返回，而分类帐更新涉及应用、对等节点和排序节点之间更复杂的交互。我们要更详细地研究。

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.
在本节的后面部分，您将了解有关此排序流程的详细特性的更多信息—有关此流程的真正详细信息，请参阅事务流主题。

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.
这些组件通常是对等节点、排序节点和应用，通过加入一个通道，它们同意协作，共享和管理与该通道关联的分类账的相同副本。从概念上讲，你可以认为通道与朋友群相似（尽管通道的成员当然不需要成为朋友），一个人可以有多个朋友组，每个朋友组都有他们一起做的活动。这些组可能是完全独立的（如一组工作朋友与一组兴趣朋友），或者他们之间可能有一些交叉。然而，每个集团都是自己的实体，有着某种“规则”。

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.
我们看到，通道的存在方式与对等节点不同——把通道看作是由物理对等节点集合构成的逻辑结构更为恰当。理解这一点是至关重要的—对等节点提供了访问和管理通道的控制点。

译注：
即，通道是逻辑概念，是由物理的对等节点组成的，二者间关系是N:M的。访问和管理通道的物理的入口在对等节点。

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 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.
您可以看到，除了排序服务外，没有集中的资源—在上面的例子中，如果组织不贡献其对等节点，那么网络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.
不同组织中的应用，如上面的示例，可能相同，也可能不同。这是因为它完全取决于一个组织如何处理他们的对等节点的分类账副本。这意味着应用和表示逻辑可能因组织而异，即使它们各自的对等节点托管着完全相同的分类帐数据。

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数字证书如何工作的信息，现在将数字证书视为提供对等节点的大量可验证信息的身份证。网络中的每个对等节点都由其所属组织的管理员分配一个数字证书。

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关联。同样，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.
每当一个对等节点使用一个通道连接到一个区块链网络时，通道配置中的一个策略使用对等节点的身份来确定其权利。身份到组织的映射由一个名为会员服务提供商（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 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 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.
更新事务与查询事务有很大的不同，因为一个对等节点本身不能更新分类账——更新需要网络中其他对等节点的同意。对等节点要求网络中的其他对等节点批准分类帐更新，然后才能将其应用到对等节点的本地分类帐。这个过程称为共识，它比一个简单的查询需要更长的时间来完成。但是，当批准交易所需的所有对等节点都这样做，并且交易提交到分类账时，对等节点将通知其关联的应用分类账已更新。在本节中，您将看到更多关于对等节点和排序节点如何管理协商一致过程的详细信息。

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阶段的过程，这可以确保区块链网络中的所有对等节点保持其分类账彼此一致。在第一个阶段，应用与背书节点的子集一起，每个对等节点都为应用建议的分类帐更新提供背书，但不将建议的更新应用于其分类帐副本。在第二阶段，这些单独的背书作为事务收集在一起，并打包成块。在最后一个阶段，这些块被分发回每一个对等节点，每个事务在被应用到该对等节点的分类账副本之前都经过了验证。

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.
正如您将看到的，排序节点是这个过程的核心，所以让我们更详细地研究一下应用和对等节点如何使用排序节点来生成分类帐更新，这些更新可以一致地应用于分布式、复制的分类帐。

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只涉及一个应用请求不同组织的背书节点同意其发起的链码调用的结果。

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，应用生成一个事务建议，并将其发送给所需的每一组对等节点进行背书。然后，这些背书节点独立地使用事务提案独立地执行链码，生成事务提案响应。它不将此更新应用于分类帐，只是签名并将其返回给应用。一旦应用收到足够数量的已签名的提案响应，事务流的第一阶段就完成了。让我们仔细研究一下这个阶段。

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对应于“分类帐L1上的事务T1响应R1已由组织的对等节点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结束。我们注意到，对于同一个事务提案，不同的对等节点可以返回应用不同的、因此不一致的事务响应。它可能是在不同时间不同节点上生成了不同状态的分类账的结果，在这种情况下，应用可以简单地请求更新的提案响应。虽然可能性不大，但更严重的是，结果可能不同，因为链码是非确定性的。不确定性是链码和分类账的敌人，如果出现这种情况，则表明所提案的事务存在严重问题，因为不一致的结果显然不能应用于分类账。单一对等节点无法知道其事务结果是非确定性的—在检测到非确定性之前，必须将事务响应收集在一起进行比较。（严格来说，这还不够，我们推迟到事务部分再详细讨论非确定性。）

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阶段结束时，如果愿意，应用可以抛弃不一致的事务响应，从而有效地提前终止事务工作流。稍后将看到，如果应用试图使用一组不一致的事务响应来更新分类帐，将被拒绝。

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 orderes 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.
在第2阶段结束时，我们看到排序节点负责简单但重要的过程，即收集提出的事务更新、排序并将它们打包成区块，准备分发给对等节点。

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.
事务处理工作流的最后一个阶段涉及从排序节点到对等节点的区块的分发和后续验证，在对等节点这里这些区块将应用于分类帐。具体地说，在每个对等节点，一个区块中的每个事务都经过验证，以确保在将其应用到分类帐之前，所有相关组织都一致认可它。失败的交易记录保留用于审计，但不应用于分类帐。

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开始于排序节点将块分发给与其连接的所有对等节点。对等节点连接到通道上的排序节点，这样当生成新块时，所有连接到排序节点的对等节点都将收到新块的副本。每个对等节点将独立地处理此块，但实际上方式与通道上的其他对等节点完全相同。这样，我们就能看到分类账是可以保持一致的。同样值得注意的是，并非每个对等节点都需要连接到一个排序节点—对等节点间可以使用gossip协议将块级联发送到其他对等节点，后者也可以独立处理它们。我们后边讨论这一点。

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 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.
就是这样！我们现在已经学习了对等节点和他们在Fabric方面相关其他组件。我们已经看到，对等节点在许多方面都是最基础的元素——它们组成网络、承载链码和分类账，处理交易提案和响应，并通过不断向分类账应用交易更新来保持其最新状态。