Peers
区块链网络主要由一组peers节点组成。 peers是网络的基本要素，因为他们主持分类账和智能合约。 回想一下，分类账不可变地记录智能合约产生的所有交易。 智能合约和分类帐分别用于封装网络中的共享进程和共享信息。 peers的这些方面使他们成为理解Hyperledger Fabric网络的良好起点。
区块链网络的其他元素当然很重要：分类账和智能合约，orderer，policies(策略)，channels(渠道)，applications(应用程序)，organizations(组织)，identities(身份)和membership(成员资格)，您可以在他们自己的相关专题中阅读更多相关信息。 本主题重点介绍peers及其与Hyperledger Fabric区块链网络中其他元素的关系。
区块链网络由peer节点组成，每个peer节点可以保存分类账的副本和智能合约的副本。 在该示例中，网络N由peer节点 P1，P2和P3形成。 P1，P2和P3各自保持其自己的分类帐L1的实例。 P1，P2和P3使用链码S1访问其分类帐L1的副本。
可以创建，启动，停止，重新配置甚至删除peer节点。 它们公开了一组API，使管理员和应用程序能够与他们提供的服务进行交互。 我们将在本主题中详细了解这些服务。
A word on terminology(关于一个词的术语)
Hyperledger Fabric采用一种技术概念实现智能合约，它称之为链码 - 只是一段访问分类账的代码，用一种支持的编程语言编写。 在本主题中，我们通常会使用术语链码，但如果您更习惯这个术语，请随意将其作为智能合约阅读。 这是同一件事！
Ledgers and Chaincode(分类账和链码)
让我们更详细地看一下peer。 我们可以看到它是托管分类帐和链代码的peer。 更准确地说，peer实际上托管分类帐的实例和链代码的实例。 请注意，这在Fabric网络中提供了有意的冗余 - 它避免了单点故障。 我们将在本主题后面的内容中详细了解区块链网络的分布式和分散性。
peer托管分类帐实例和链代码实例。 在此示例中，P1承载分类帐L1的实例和链代码S1的实例。 可以在单个peer节点上托管许多分类帐和链代码。
由于peer是分类帐和链代码的主机，因此应用程序和管理员必须与peer进行交互才能访问这些资源。 这就是为什么peer被认为是Hyperledger Fabric区块链网络最基本的构建块。 首次创建peer时，它既没有分类账，也没有链码。 稍后我们将看到如何创建分类帐，并在peer上安装链代码。
Multiple Ledgers(多个分类帐)
peer能够托管多个分类帐，这很有用，因为它允许灵活的系统设计。 最简单的peer配置是使用单个分类帐，但是在需要时，peer可以托管两个或多个分类帐。
托管多个分类帐的peer节点。 peer托管一个或多个分类帐，每个分类帐具有零个或多个适用于它们的链代码。 在这个例子中，我们可以看到peer节点P1托管分类账L1和L2。 使用链码S1访问分类帐L1。 另一方面，可以使用链码S1和S2访问分类帐 L2。
尽管peer完全可以托管分类帐实例而不托管访问它的任何链代码，但是以这种方式配置peer节点是非常罕见的。 绝大多数peer将至少安装一个链代码，可以查询或更新peer的分类帐实例。 值得一提的是，无论用户是否安装了供外部应用程序使用的链代码，peer还具有始终存在的特殊系统链代码。 本主题中未详细讨论这些内容。
Multiple Chaincodes(多个链码)
peer拥有的分类账数量与可以访问该分类账的链代码数量之间没有固定的关系。 peer可能有许多链码和许多分类账。
托管多个链代码的peer的示例。 每个分类帐都可以有许多访问它的链代码。 在这个例子中，我们可以看到对等体P1托管分类账L1和L2。 L1由链码S1和S2访问，而L2由S3和S1访问。 我们可以看到S1可以访问L1和L2。
稍后我们会看到为什么Hyperldeger Fabric中的通道概念在同级托管多个分类帐或多个链代码时很重要。
Applications and Peers(应用和peers)
我们现在将展示应用程序如何与peer交互以访问分类帐。分类帐查询交互涉及应用程序和peer之间的简单三步对话;分类帐更新交互涉及更多，需要两个额外的步骤。我们已经简化了这些步骤以帮助您开始使用Hyperledger Fabric，但不要担心 -需要理解的最重要的是，与ledger-update事务样式相比，ledger-query的application-peer交互有什么不同。
peers与orderers一起确保分类账与每个peer保持同步。在此示例中，应用程序A连接到P1并调用链码S1来查询或更新分类帐L1。 P1调用S1以生成包含查询结果或分类帐更新的建议的提议响应。应用程序A接收提议响应，对于查询，该过程现在已完成。对于更新，A从所有响应构建一个事务，并将其发送给O1进行排序。 O1将来自网络的事务收集到块中，并将这些事务分发给所有peer节点，包括P1。 P1在申请L1之前验证交易。更新L1后，P1会生成A收到的事件，表示完成。
peer可以立即将查询结果返回给应用程序，因为满足查询所需的所有信息都在peer的分类帐本地副本中。peer不与其他peer节点协商以便将查询返回给应用程序。但是，应用程序可以连接到一个或多个peer节点以发出查询 - 例如，在多个peer节点之间确认结果，或者如果怀疑信息可能不在，则从不同的peer检索更新的结果日期。在图中，您可以看到分类帐查询是一个简单的三步过程。
更新事务和查询事务以相同的方式启动，但还有两个额外步骤。虽然分类帐更新应用程序也连接到peer以调用链代码，但与分类帐查询应用程序不同，单个peer此时无法执行分类帐更新，因为其他peer必须首先同意此更改 - 这一过程称为共识的过程。因此，peer向应用程序返回一个提议的更新- 该peer将根据与其他peer先前的协议应用该更新。第一个额外步骤 - 四 - 要求应用程序向整个对等网络发送一组适当的匹配更新建议，作为对其各自分类帐事务/交易的承诺。这是通过应用程序使用orderer将事务/交易打包到块中，并将它们分发到整个peer网络来实现的，在应用于每个peer的本地副本之前，可以对它们进行验证。由于整个排序处理需要一些时间才能完成（秒），因此将异步通知应用程序，如步骤5所示。
在本主题的后面部分，您将了解有关此排序过程的详细性质的更多信息 - 有关此过程的详细信息，请参阅“事务流程”主题。
Peers and Channels
虽然这个主题是关于peer而不是渠道，但是值得花一点时间了解peer如何通过渠道相互交互，以及应用程序通过渠道 - 区块链网络中的一组组件可以通过这种机制进行私密交流和交易。
这些组件通常是peer节点，orderer节点和应用程序，并且通过加入渠道，他们同意聚集在一起以共同共享和管理该渠道的分类帐的相同副本。 从概念上讲，您可以将渠道视为与朋友群体相似（尽管频道成员当然不需要成为朋友！）。 一个人可能有几组朋友，每组都有他们一起做的活动。 这些群体可能是完全独立的（与一群爱好朋友相比，一群工作朋友），或者他们之间可能存在交叉。 然而，每个群体都是自己的实体，具有一种“规则”。
渠道允许一组特定的peer节点和应用程序在区块链网络内相互通信。 在此示例中，应用程序A可以使用通道C直接与peers P1和P2通信。您可以将渠道视为特定应用程序和peer之间通信的途径。 （为简单起见，此图中未显示orderer，但必须存在于正常运行的网络中。）
我们看到通道的存在方式与peer不同 - 将通道视为由物理peer节点集合形成的逻辑结构更为合适。 了解这一点至关重要 - peer提供了访问和管理渠道的控制点。
Peers and Organizations
现在您了解了peer及其与分类账，链码和渠道的关系，您将能够看到多个组织如何聚集在一起形成区块链网络。
区块链网络由一组组织而不是一个组织管理。 peer是如何构建这种分布式网络的核心，因为它们由这些组织所拥有 - 并且是网络的连接点 - 这些组织.
具有多个组织的区块链网络中的peer。区块链网络由不同组织拥有和贡献的peer节点构建。在此示例中，我们看到有四个组织贡献了八个peer节点组成网络。渠道C连接网络N-P1，P3，P5，P7和P8中的这些peer中的五个。这些组织拥有的其他peer节点尚未加入此渠道，但通常会加入至少一个其他渠道。由特定组织开发的应用程序将连接到自己组织的peer以及不同组织的peer。同样，为简单起见，此图中未显示orderer节点。
在区块链网络的形成过程中，您可以看到正在发生的事情，这一点非常重要。该网络由为其提供资源的多个组织形成和管理。peer是我们在本主题中讨论的资源，但组织提供的资源不仅仅是peer。这里有一个原则 - 如果没有组织将其个人资源贡献给集体网络，网络就不存在。此外，网络随着这些合作组织提供的资源而增长和缩小。
你可以看到（除了orderer服务）没有集中的资源——在上面的例子中，如果组织没有贡献他们的peers节点，网络将不存在。这反映了这样一个事实，即网络在任何意义上都不存在，除非组织贡献出形成它的资源。此外，网络不依赖于任何单独的组织——只要一个组织存在，不管其他组织可能来来去去，它都将继续存在。这是网络分散的核心所在。
如上例所示，不同组织中的应用程序可能相同也可能不同。 这是因为它完全取决于组织如何处理其peer的分类账副本。 这意味着应用程序和表示逻辑可能因组织而异，即使它们各自的peer托管完全相同的分类帐数据。
Peers and Identity
既然您已经看到来自不同组织的同行如何聚集在一起形成区块链网络，那么值得花一些时间了解管理员如何将peers分配给他们的组织。
peers通过来自特定证书颁发机构的数字证书为其分配身份。 您可以阅读更多有关X.509数字证书如何在本指南的其他地方工作的内容，但现在将数字证书视为一张ID卡，它提供了许多关于peer的可验证信息。 管理员从其拥有的组织为网络中的每个peer分配一个数字证书。
当peer连接到频道时，其数字证书通过频道MSP识别其拥有的组织。在此示例中，P1和P2具有由CA1发布的身份。通道C根据其通道配置中的策略确定来自CA1的身份应使用ORG1.MSP与Org1相关联。类似地，ORG2.MSP将P3和P4识别为Org2的一部分。
每当peer使用渠道连接到区块链网络时，渠道配置中的策略使用peer的身份来确定其权限。身份到组织的映射由称为成员服务提供者（MSP）的组件提供 - 它确定如何将peer分配给特定组织中的特定角色，从而获得对区块链资源的适当访问。此外，peer只能由单个组织拥有，因此与单个MSP相关联。我们将在本主题后面详细了解peer的访问控制，本指南中的其他地方有关于MSP和访问控制策略的完整主题。但就目前而言，将MSP视为在区块链网络中提供个人身份与特定组织角色之间的联系。
离题一段时间，peer以及与区块链网络交互的所有内容都可以从他们的数字证书和MSP中获取他们的组织身份。peers，应用程序，最终用户，管理员或orderer如果想要与区块链网络进行交互，则必须具有身份和关联的MSP。我们使用身份 - 主体/负责人为每个与区块链网络交互的实体命名。您可以在本指南的其他地方了解更多关于负责人和组织的知识，但是现在您已经了解了足够多的知识，可以继续了解peer！
最后，请注意，peer的物理位置并不重要 - 它可以驻留在云中，也可以驻留在其中一个组织或本地计算机所拥有的数据中心中 - 它是与之关联的标识，将其标识为由特定组织拥有。在上面的示例中，P3可以托管在Org1的数据中心，但只要与之关联的数字证书由CA2发布，那么它就由Org2拥有。
Peers and Orderers
我们已经看到，peers构成了区块链网络，托管分类账和链代码，应用程序可以通过peer连接进行查询和更新。但是，应用程序和peer之间相互交互以确保每个peer的分类帐保持一致的机制由称为orderers的特殊节点调解，而这些节点现在引起我们的注意。
更新事务与查询事务完全不同，因为单个peer本身不能更新分类帐 - 它需要网络中其他peer的同意。peer要求网络中的其他peer批准分类帐更新，然后才能将其应用于peer的本地分类帐。此过程称为共识 - 与查询相比需要更长的时间才能完成。但是，当需要批准事务的所有peer都这样做，并且事务被提交到分类帐时，peer将通知其连接的应用程序已更新分类帐。您将在本节中更详细地了解peers和orderers如何管理共识流程。
具体而言，想要更新分类帐的应用程序涉及三阶段过程，这可确保区块链网络中的所有peers保持其分类帐彼此一致。在第一阶段，应用程序使用一个支持peers的子集，每个peer提供对应用程序建议的分类帐更新的认可，但不将建议的更新应用于其分类帐副本。在第二阶段，这些单独的认可作为事务/交易收集在一起并打包成块。在最后阶段，这些块将被分发回每个对等方，在每个对等方都验证每个事务/交易，然后再应用于该peer的分类帐副本。
正如您将看到的，orderer节点是此过程的核心 - 所以让我们更详细地研究应用程序和peers如何使用orderers生成可以一致地应用于分布式复制分类帐的分类帐更新
Phase 1: Proposal(阶段1:提议/建议)
事务工作流的第1阶段涉及应用程序和一组peers之间的交互 - 它不涉及orderer。 第1阶段仅涉及一个应用程序，要求不同组织认可peer同意所提议的链代码调用的结果。
为了启动阶段1，应用程序生成一个事务/交易提议，并将其发送给每个所需的peers以进行认可。 然后，每个peer使用事务/交易提议独立地执行链码以生成事务/交易提议响应。 它不会将此更新应用于分类帐，而是peer签名并返回到应用程序。 一旦应用程序收到足够数量的签名提议响应，事务流程的第一阶段就完成了。 让我们更详细地研究这个阶段。
交易提议由返回认可的提案响应的peer独立执行。在该示例中，应用程序A1生成事务T1提议P，其在渠道C上发送给peer P1和peer P2.P1使用事务T1提议P执行S1，生成事务T1响应R1，它用E1认可。独立地，P2使用事务T1提议P执行S1，生成事务T1响应R2，用E2认可。应用程序A1接收针对事务T1的两个认可的响应，即E1和E2。
最初，应用程序选择一组peers来生成一组分类帐更新的建议。应用程序选择哪些peers？那么，这取决于背书策略/认可策略（为链代码定义），该策略定义了在网络接受之前需要认可分类帐变更的组织集合。从字面上看，这实际上是达成共识意 - 每个重要的组织必须在任何peer分类账被接受之前批准提议的分类账变更。
peer通过添加其数字签名并使用其私钥对整个有效负载进行签名来认可提议响应。这种认可随后可用于证明该组织的peer产生了特定的回应。在我们的示例中，如果对等体P1由组织Org1拥有，则认可E1对应于“Org1的对等体P1已经提供了分类账L1上的事务T1响应R1！”的数字证明。
当应用程序收到来自足够peers的签名提议响应时，阶段1结束,我们注意到，不同的peer可以为同一个交易提议的应用程序返回不同的，因此不一致的事务响应。可能只是结果在不同的peer上生成了不同的时间，并且不同状态的分类账 - 在这种情况下，应用程序可以简单地请求更新的提案响应。不太可能，但更严重的是，结果可能会有所不同，因为链码是非确定性的。非决定论是链码和分类账的敌人，如果它出现，则表明拟议交易存在严重问题，因为不一致的结果显然不适用于分类账。单个peer无法知道其交易结果是非确定性的 - 在检测到非确定性之前，必须将事务响应收集在一起进行比较。 （严格来说，即使这还不够，但我们将此讨论推迟到交易主题，其中详细讨论了非确定性。）
在阶段1结束时，如果应用程序愿意，应用程序可以自由地丢弃不一致的事务响应，从而有效地提前终止事务工作流程。稍后我们将看到，如果应用程序尝试使用一组不一致的事务响应来更新分类帐，它将被拒绝。
Phase 2: Packaging(阶段2:包装)
交易/事务工作流程的第二阶段是包装阶段。 orderer在此过程至关重要 - 它接收来自许多应用程序的包含交易建议响应的交易/事务。 它将每个事务/交易相对于其他事务/交易进行排序(排序)，并将批量事务/交易打包成块(打包)，准备好分发回连接到orderer的所有peers，包括原始认可peer(发起提议的peer)。
orderer节点的第一个角色是打包提议的分类帐更新。在该示例中，应用程序A1将由E1和E2认可的事务T1发送到orderer O1。并行地，应用程序A2将由E1认可的事务T2发送到orderer O1。 O1将来自应用程序A1的事务T1和来自应用程序A2的事务T2与来自网络中的其他应用程序的其他事务一起打包到块B2中。我们可以看到，在B2中，交易订单是T1，T2，T3，T4，T6，T5 - 这可能不是这些交易/事务到达orderer节点的顺序！ （此示例显示了非常简化的orderer配置。）
orderer在特定渠道上从网络中的许多不同应用程序同时接收提议的分类帐更新。它的工作是将这些建议的更新安排到明确定义的序列中，并将它们打包成块以供后续分发。这些块将成为区块链的块！一旦orderer生成了所需大小的块，或者在最大经过时间之后，它将被发送到在特定渠道上连接到它的所有peers。我们将在第3阶段看到如何处理此块。
值得注意的是，块中交易的顺序不一定与orderer交易的到达顺序相同！事务可以按任何顺序打包到一个块中，而这个序列就成了执行的顺序。重要的是，有一个严格的秩序，而不是那个顺序。
块内事务/交易的严格排序使Hyperledger Fabric与其他一些区块链略有不同，其中同一事务可以打包到多个不同的块中。在Hyperledger Fabric中，这不可能发生 - 由orderer集合生成的块被认为是最终的，因为一旦将事务写入块，它在分类账中的位置就不可避免地得到保证。 Hyperledger Fabric的最终结果意味着不会发生称为分类账分叉的灾难性事件。一旦在块中捕获事务，就不能在将来的时间点为该事务重写历史记录。
我们也可以看到，虽然peer主持分类账和链码，orderers肯定不会。到达orderer的每个交易都是机械地打包在一个区块中 - orderer不会对交易的价值做出判断，它只是打包它。这是Hyperledger Fabric的一个重要行为 - 所有事务都按严格的顺序编组 - 事务永远不会丢失或取消优先级。
在第2阶段结束时，我们看到orderer负责收集建议的交易更新，订购它们，将它们打包成块，准备分发的简单但至关重要的过程。
Phase 3: Validation(第三阶段:验证)
事务工作流的最后阶段涉及从orderer到peer的块的分发和后续验证，其中它们可以应用于分类帐。 具体而言，在每个peer中，块中的每个事务都经过验证，以确保在将其应用于分类帐之前始终得到所有相关组织的认可。 保留失败的事务以进行审计，但不会应用于分类帐。
orderer节点的第二个角色是将块分发给peers。在该示例中，orderer O1将块B2分配给peer P1和peer P2。peer P1处理块B2，导致在P1上将新块添加到分类帐L1。并行地，对等体P2处理块B2，导致在P2上将新块添加到分类账L1。一旦完成该过程，就在对等体P1和P2上持续更新分类账L1，并且每个分类账可以通知连接的应用程序已经处理了该事务。
阶段3开始于orderer将块分配给连接到它的所有peers。peers连接到通道上的orderer，这样当生成新块时，连接到orderer的所有peers将被发送新块的副本。每个peer将独立处理此块，但其方式与通道上的每个其他peer完全相同。通过这种方式，我们可以看到分类帐可以保持一致。值得注意的是，不是每个peer都需要连接到一个orderer - peer可以使用GOSSIP协议将块连接到其他peers，这个协议也可以独立处理它们。但是让我们把这个讨论留给另一个时间！
收到一个块后，peer将按照它在块中出现的顺序处理每个事务。对于每个交易/事务，每个peer将根据生成交易的链码的认可政策/背书策略来验证交易是否已被所需组织认可。例如，某些交易可能只需要由单个组织认可，而其他交易可能需要多次认可才能被视为有效。此验证过程验证所有相关组织是否已生成相同的结果或结果。
如果事务已正确认可，则peer将尝试将其应用于分类帐。为此，peer必须执行分类帐一致性检查，以验证生成建议更新时分类帐的当前状态是否与分类帐的状态兼容。即使交易已得到完全认可，这也可能并非总是可行。例如，另一个事务可能已更新分类帐中的相同资产，使得事务更新不再有效，因此无法再应用。通过这种方式，每个peer的分类帐副本在整个网络中保持一致，因为它们各自遵循相同的验证规则。
在peer成功验证每个单独的事务后，它会更新分类帐。失败的交易/事务不会应用于分类帐，但会将其保留用于审计目的，成功的交易也是如此。这意味着,除了块中每个事务的有效或无效指示符外，peer块几乎与从orderer接收的块完全相同。
我们还注意到阶段3不需要运行链码 - 这只在阶段1中完成，这很重要。这意味着只需在背书节点/认可节点上提供链码，而不是整个区块链网络。这通常是有帮助的，因为它使链码的业务逻辑保密以支持组织。这与链码的输出（交易提议响应）形成对比，链码输出被共享给渠道中的每个peer，无论他们是否认可该交易。这种支持peers的专业化设计旨在帮助实现可伸缩性。
最后，每次将块提交给peers的分类帐时，该peer都会生成适当的事件。 块事件包括完整块内容，而块事务事件仅包括摘要信息，例如块中的每个事务是否已经过验证或无效。 链码执行产生的Chaincode事件也可以在此时发布。 应用程序可以注册这些事件类型，以便在它们发生时得到通知。 这些通知结束了事务工作流程的第三个也是最后一个阶段。
总之，阶段3看到由order生成的块始终应用于分类帐。 将事务严格排序到块中允许每个peer验证在区块链网络上一致地应用事务更新。
Orderers and Consensus
整个交易工作流程过程称为共识，因为所有peers在由orderer介导的过程中达成交易的顺序和内容的协议。共识是一个多步骤的过程，只有在流程完成时，应用程序才会通知分类帐更新 - 这可能会在不同的peers上稍微不同的时间发生。
我们将在未来的orderer主题中更详细地讨论orderer，但是现在，将orderer视为从peers的应用程序收集和分发建议的分类帐更新以验证和包含在分类帐中的节点。
而已！我们现在已经完成了对peers以及Hyperledger Fabric中与之相关的其他组件的访问。我们已经看到，peers在很多方面都是最基本的元素 - 它们构成了网络，主机链码和分类账，处理交易提议和响应，并通过始终如一地对其进行交易更新来使分类账保持最新状态。
此文来自于官方文档:http://hyperledger-fabric.readthedocs.io/en/release-1.1/peers/peers.html#phase-1-proposal