本文主要对Hyperledger Fabric中的英文资料进行翻译和整理，原英文文档地址为：https://github.com/hyperledger/fabric/blob/release-1.2/docs/source/peers/peers.md

对等体（peers）

1.1对等体

区块链网络主要由一组对等节点（或简称为对等节点）组成。对等体是网络的基本要素，因为他们主持分类账和智能合约。回想一下，分类账可以不可避免地记录智能合约（或链码）生成的所有交易。智能合约和分类帐分别用于封装网络中的共享进程和共享信息。对等体的这些方面使他们成为了解Hyperledger Fabric网络的良好起点。

注意：图中的上下位置，表示访问顺序，在每个对等体上，智能合约S1可以访问分类账L1

区块链网络的其他元素当然很重要：分类帐和智能合约，订购者(orders)，政策(policies)，渠道(channels)，应用程序(applications)，组织(organizations)，身份(identities)和成员资格(membership)，您可以在它们的专门章节中相关信息。本节重点介绍对等体及其与Hyperledger Fabric网络中其他元素的关系。

区块链网络由对等节点组成，每个对等节点可以保存分类账的副本和智能合约的副本。如图1-1所示，网络N由对等体P1，P2和P3组成，每个对等体保持它们自己的分布式分类帐L1的实例。 P1，P2和P3使用相同的链码S1来访问其分布式分类帐的副本。

对等体(peers)可以被创建，启动，停止，重新配置甚至被删除。它们公开了一组API，使管理员和应用程序能够与他们提供的服务进行交互。我们将在本节中详细了解这些服务。

术语:Hyperledger Fabric采用一种称为链码（chaincode）的技术概念，实现智能合约，它只是一段用支持的编程语言编写的，访问分类账的代码。在本主题中，我们通常使用术语链代码，但如果您更习惯智能合约，请随意将其作为智能合约阅读。

1.2分类账（Ledgers）和链码（Chaincode）

让我们更详细地看一下一个对等体（peer）。我们可以看到这个对等体，可以托管(host)分类帐和链代码。更准确地说，对等体实际上托管分类帐和链代码的实例。请注意，这在Fabric网络中，有意的提供了冗余，从而为了避免单点故障。我们将在本节后面详细了解区块链网络的分布式和去中心化。

对等体托管分类帐实例和链代码实例。如图1-2所示，P1承载分类帐L1的实例和链代码S1的实例。在单个对等体上可以托管多个分类帐和链代码。

由于一个对等体是分类帐和链代码的主机，所以如果应用程序（application）和管理员（administrator）想访问这些资源，必须与对等体进行交互。这就是为什么对等体(peers)被认为是Hyperledger Fabric网络最基本的构建块，当一个对等体首次被创建的时候，它既没有分类账，也没有链码。接下来我们将看到如何在对等体上创建分类帐（Ledger）以及如何安装链代码（chaincode）。

1.2.1多个分类账（Multiple Ledgers）

对等体能够托管多个分类帐，这在系统的灵活设计上很有用。最简单的配置就是让单个对等体管理单个分类帐，但对于对等体来说，当需要的时候，一个对等体托管两个或者两个以上也是绝对合适的。

托管多个分类帐的对等体。对等体托管一个或多个分类帐，每个分类帐具有零个或多个适用于它们的链代码。如图1-3所示，我们可以看到对等体P1托管分类账L1和L2。使用链码S1访问分类帐L1。另一方面，可以使用链码S1和S2访问分类账 L2。

尽管对等体完全有可能托管一个没有链码的分类帐实例，但是对等体很少这样配置。绝大多数对等体将至少安装一个链代码，用来查询或更新对等体的分类帐实例。值得一提的是，无论用户是否安装了外部应用程序使用的链代码，对等体上始终存在着，特殊的系统链代码。本主题中未详细讨论这些内容.

1.2.1多个链码（Multiple Chaincodes）

对等体拥有的分类账数量与可以访问该分类账的链代码数量之间没有固定的关系。对等体可以有许多链码和许多分类账。

一个托管多个链代码的对等体的示例。每个分类帐都可以有许多访问它的链代码。如上图所示，我们可以看到对等体P1托管分类账L1和L2，其中L1由链代码S1和S2访问，L2由S1和S3访问。我们可以看到S1可以访问L1和L2。

稍后我们会看到在Hyperledger Fabric网络中，当在一个对等体上托管多个分类账或者链码的时候，为什么通道（channels）的概念很重要。

1.3应用程序（Applications）和对等体（Peers）

我们将展示应用程序如何与对等体进行交互，从而达到访问分类帐的目的。分类帐查询涉及到应用程序和对等体之间的简单三步对话。分类帐更新，需要两个额外的步骤。我们已经简化了这些步骤以帮助您开始使用Hyperledger Fabric，但不要担心 - 最重要的是要理解的分类账查询和分类账更新，应用程序与对等体之间交互的差异。

当应用程序需要访问分类帐和链代码时的时候，它必须一直连接到对等体上。 Hyperledger Fabric软件开发工具包（SDK）使程序员易于使用 - 它的API使应用程序能够连接到对等体，调用（invoke）链式代码以生成事物(transaction)，提交事务到网络，在网络上交易将被订购并提交给分布式账本，以及接收此过程完成时的事件。

通过与对等体连接，应用程序可以执行链代码来查询或更新分类帐。分类帐查询事务的结果立即返回，而分类帐更新涉及应用程序、对等体和订购者之间更复杂的交互。让我们更详细地研究一下。

对等体与排序一起确保分类账与每个对等体保持同步。如上图所示中，应用程序A连接到P1并调用链代码S1来查询或更新分类帐L1。 P1调用S1以生成包含查询结果或建议的分类帐更新的提议响应。应用程序A接收提议响应，对于查询，该过程现在已完成。对于更新，A从所有响应中构建一个事务，并将其发送给O1进行排序。 O1将来自网络的事务收集到块中，并将这些事务分发给所有对等体，包括P1。 P1在申请L1之前验证交易。更新L1后，P1会生成A收到的事件，表示完成。

对等体可以立即将查询结果返回给应用程序，因为满足查询所需的所有信息都在对等体的分类帐本地副本中。对等体从不咨询其他对等体响应来自应用程序的查询。但是，应用程序可以连接到一个或多个对等体发出查询;例如，在多个对等体之间确认结果，或者如果怀疑信息可能已过期，则从另一个对等体检索更新的结果。在图中，您可以看到分类帐查询是一个简单的三步过程。

更新事务和查询事务以相同的方式启动，但还有两个额外步骤。虽然分类帐更新应用程序也连接到对等体从而调用链代码，但与分类帐查询应用程序不同，单个对等体此时无法执行分类帐更新，因为其他对等体必须首先同意此更改即称为共识的过程。因此，对等体向应用程序返回提议的更新 - 该对等体将根据与其他对等体先前的协议应用该更新。第一个额外步，第四步---要求应用程序向整个对等网络发送一组适当的匹配建议更新，作为对其各自分类账的承诺交易。这是通过应用程序使用orderer将事务打包到块中，并将它们分发到整个对等网络来实现的，在应用于每个对等体的本地副本之前，可以对它们进行验证。由于整个排序处理需要一些时间才能完成（秒），因此将异步通知应用程序，如步骤5所示。

1.3.1对等体（Peers）和通道（Channels）

虽然这一部分是讲的是对等体而不是通道，但是值得花一点时间了解对等体之间以及对等体与应用程序之间如何交互。它们之间是通过通道来进行交互的。这个通道是一种机制，即在区块链网络中通过一组组件可以进行私密的通信和交易。

这些组件通常是对等体节点，排序节点和应用程序，并且通过加入通道，他们通过共同协作，共享和管理与通道相关的分类账的相同副本。从概念上讲，您可以将通道类比于朋友圈（尽管通道成员不需要朋友）。一个人可能有几个朋友圈，每个圈都有他们一起做的活动。这些群体可能是完全独立的（例如一组爱好朋友圈，一组工作朋友圈），或者这些朋友圈，他们之间可能存在一些交叉。然而，每个圈都是自己的实体，具有一种“规则”。

在一个区块链网络中，通道允许一组特定的对等体和应用程序进行彼此间的通信。如上图所示，应用程序A可以使用通道C直接与对等体P1和P2。你可以把通道理解为特定的应用程序和对等体之间进行通信的路径（为了简单起见，未在图中画出排序，但是它必须存在于正常的网络中）。

我们看到通道的存在方式与对等体不同，通道可以看做由一群物理对等体形成的逻辑结构。理解这一点很重要，对等体提供了访问和管理通道的控制点。

1.3.2对等体（Peers）和组织（Organization）

现在您了解了对等体与分类账、链码和通道的关系，接下来您将看到多个组织如何聚集到一起，形成区块链网络。

区块链网络是由一群组织而不是单个组织来进行管理的，对等体是如何构建这种分布式网络的核心，因为它们被这些组织所拥有，并且是这个网络的连接点。

对等体存在于一个多组织组成的区块链网络中。区块链网络由不同的对等体构建而成，这些对等体隶属于不同的组织。如上图1-7所示，我们可以看到4个组织贡献了8个对等体，形成了一个网络。在区块链网络N中，通道C连接了P1、P3、P5、P7和P8五个对等体。这些组织拥有的其它对等体尚未加入通道C，但通常它们会加入至少一个其它通道。由特定组织开发的应用程序，将连接到自己组织的对等体以及不同组织的对等体。同样，为了简单期间，排序节点在图中没有显示。

在区块链网络的形成过程中，您可以看到正在发生的事情，这一点非常重要。该网络由为其提供资源的多个组织形成和管理。对等体是我们在本主题中讨论的资源，但组织提供的资源不仅仅是对等体。这里有一个原则 - 如果没有组织将其个人资源贡献给集体网络，网络就不存在。此外，网络随着这些合作组织提供的资源而增长和缩小。（个人理解：个人或者组织闲置资源的一个二次集合，后面可以进行二次资源的集中出售，或者功能的出售，但是这种出售又是去中心化的，中间没有中介的。）

您可以看到（除了排序服务之外），区块链网络中没有中心化资源，如上面的例子中，如果组织没有贡献他们的对等体，网络N将不存在。这反映了这样一个事实，即网络不存在于任何意义，除非或者直到组织贡献资源形成它。此外，网络不依赖于任何单个组织，只要一个组织仍然存在，它将继续存在，无论其他组织去或者留。这是网络去中心化的核心所在。

如上例所示，不同组织的应用程序可以相同也可以不同。这是因为它完全取决于组织如何处理其对等体的分类账副本。这意味着应用程序和表示逻辑可能因组织而异，即使它们各自的对等体托管完全相同的分类帐数据。

应用程序既可以连接到组织中的对等体，也可以连接到其他组织中的对等方，具体取决于所需的分类帐交互的特性。对于分类帐查询交互，应用程序通常连接到自己组织的对等体。对于分类帐更新交互，我们稍后会看到为什么应用程序需要连接到代表每个组织中，需要认可分类帐更新的对等体。

1.3.3对等体（Peers）和身份（Identity）

既然您已经看到来自不同组织的对等体如何聚集在一起形成区块链网络，那么值得花一些时间了解管理员如何将对等体分配给组织。

对等体通过来自特定证书颁发机构的数字证书为其分配身份。您可以有关X.509数字证书如何在本指南的其他地方工作的内容，但是，现在，将数字证书视为一张ID卡，它提供了许多关于对等体的可验证信息。管理员从其拥有的组织为网络中的每个对等方分配一个数字证书。

当对等体连接到通道时，其数字证书通过通道MSP识别其拥有的组织。如上图中，P1和P2具有由CA1发布的身份。通道C根据其通道配置中的策略，确定来自CA1的身份应使用ORG1.MSP与Org1相关联。类似地，ORG2.MSP将P3和P4识别为Org2的一部分。

每当对等体使用通道连接到区块链网络时，信道中配置的策略利用对等体的身份来决定其权限。身份到组织的映射由称为成员服务提供者（MSP）的组件提供---它决定如何将对等体分配给特定组织中的特定角色，从而获得对区块链资源的适当访问。此外，对等体只能由单个组织拥有，因此只能与单个MSP相关联。我们将在本节后面详细了解对等体访问控制，本指南的其他部分，有关于MSP和访问控制策略的完整部分。但就目前而言，将MSP视为在区块链网络中提供个人身份与特定组织角色之间的联系。

为了离题，对等体以及与区块链网络交互的所有内容，都需要从其数字证书和MSP获取其组织身份。如果对等体，应用程序，终端用户，管理员和排序想要与区块链网络进行交互，则必须拥有身份和相关的MSP。我们给每个与区块链网络交换的实体（entity）一个身份，委托人（principal）。您可以在本指南的其他地方了解更多关于委托人（principal）和组织的知识，但是现在您已经了解了足够多的知识，可以继续了解对等体。

最后，请注意，对等体的物理位置并不重要 - 它可以驻留在云中，也可以驻留在属于一个组织的数据中心，或者一个本地机器。它是与之关联的身份将其标识为由特定组织拥有。如上例所示，P3可以托管在Org1的数据中心，但只要与之关联的数字证书由CA2发布，那么它就由Org2拥有。

1.4对等体（Peers）和排序者（Orders）

我们已经看到，对等体构成了区块链网络的基础，托管分类账和链码，可以通过对等体与应用程序连接进行查询和更新。但是，应用程序和对等体之间相互交互以确保每个对等体的分类帐保持一致的机制，由称为orderers的特殊节点调解，现在我们转向注意这些节点。

更新事务（transaction）与查询事务完全不同，因为单个对等体本身不能更新分类帐，更新需要网络中其他对等体的同意。对等体要求网络中的其他对等体批准分类帐更新，然后才能将其应用于对等体的本地分类帐，这个过程称为共识。与简单查询相比，需要更长的时间才能完成。但是，当所有的对等体同意这个事务，并且事务被提交到分类帐时，对等体将通知其连接的应用程序，分类账（ledger）已经被更新。本节将详细介绍对等体与排序者如何管理共识的过程。

具体而言，应用程序想要更新分类帐，将涉及一个三阶段的过程，这可以确保区块链网络中的所有对等体保持其分类帐彼此的一致性。在第一阶段，应用程序与赞同对等体（endorsing peers）的子集合作，每个赞同对等体提供一个提议分类账的背书（endorsement），这个背书是对应用程序的建议分类帐更新的认可，但不把提议的更新应用到其分类帐副本。在第二阶段，这些分开的背书作为事务，收集在一起并打包成块。在最后阶段，这些块将被分发回到每个对等体，在每个对等体中都验证每个事务，然后再应用于该对等体的分类帐副本。

正如您将看到的，orderer节点是此过程的核心，因此让我们更详细地研究应用程序和对等体，如何使用orderers生成分类账更新，这个更新可以被一致性的应用到分布式，可复制的分类账中。

阶段一：提议

事务工作流的第一个阶段涉及到应用程序和一系列对等体之间的交互，其中没有包含到排序（Orders），第一阶段仅仅涉及一个应用程序，要求不同组织的赞同对等体同意所提议链码的调用结果。

为了启动第一阶段，应用程序生成一个交易提议，并将其发送给每个所需的对等方以进行认可。然后，每个赞同对等体独立执行链码从而生成一个交易提议响应。它不会将此更新应用于分类帐，而是简单地对其进行签名并将其返回给应用程序。一旦应用程序收到足够数量的签名提议响应，事务流程的第一阶段就完成了。让我们更详细地研究这个阶段。

交易提议被可以返回赞成提议响应的对等体独立的执行，如上图所示，应用程序A1生成事务T1提议P，并通过通道C发送给对等体P1和P2。P1利用T1的提议P执行S1，并生成事务T1的响应R1，它用E1认可。独立的，P2利用事务1的提议P执行S1，并生成事务T1的响应R2，它用E2认可，即E1和E2。

最初，应用程序选择一组对等体，来生成一组提议分类账更新请求。哪些对等体应该被选择呢？那么，这就取决于背书策略（称为链码），该策略定义了一系列组织，这些组织需要在网络接收之前，赞成一个提议分类账更改。这实际上意味着达成共识，每个重要的组织必须在任何对等体分类账被接收之前，批准所提议的分类账的变更。

对等体通过添加它的数字签名，并对整个有效负载进行签名来认可提议响应。这种认可证书，随后可以被用来证明这个组织的对等体生成了特殊的响应。如上图所示，如果对等体P1由组织Org1拥有，则认可E1对应于“Org1的对等体P1已经提供了分类账L1上的事务T1响应R1！”的数字证据。

当应用程序收到来自足够对等体的签名提议响应时，阶段1结束。我们注意到不同的对等体，可以为同一个事务提议返回不同的和不一致的事务响应。可能只是在不同的对等体上，在不同状态下的分类账生成结果，在这种情况下，应用程序可以简单地请求更新的提案响应。结果可能会有所不同，因为链码是非确定性的。非决定论是链码和分类账的敌人，如果它出现，则表明拟议交易存在严重问题，因为不一致的结果显然不适用于分类账。个体同伴不能知道他们的交易结果是非确定性的 - 必须收集交易响应以进行比较，然后才能检测到非确定性。（严格地说，即使这还不够，但我们将此讨论推迟到交易部分，其中详细讨论了非确定性。）

在阶段1结束时，如果应用程序愿意，应用程序可以自由地丢弃不一致的事务响应，从而有效地提前终止事务工作流程。稍后我们将看到，如果应用程序尝试使用一组不一致的事务响应来更新分类帐，它将被拒绝。

阶段二：打包

交易工作流程的第二阶段是包装阶段。排序者对此过程至关重要 - 它接收包含来自许多应用程序的认可交易提议响应的交易。它将每个事务相对于其他事务进行排序，并将批量事务打包成块，准备好分发回连接到订货人的所有对等方，包括原始认可对等方。

订货人节点的第一个角色是打包提议的分类帐更新。在该示例中，应用程序A1将由E1和E2认可的事务T1发送到订购者O1。并行地，应用程序A2将由E1认可的事务T2发送到订购者O1。 O1将来自应用程序A1的事务T1和来自应用程序A2的事务T2与来自网络中的其他应用程序的其他事务一起打包到块B2中。我们可以看到，在B2中，交易订单是T1，T2，T3，T4，T6，T5 - 这可能不是这些交易到达订货人节点的顺序！（此示例显示了非常简化的订购者配置。）

订购者在特定渠道上从网络中的许多不同应用程序同时接收提议的分类帐更新。它的工作是将这些建议的更新安排到明确定义的序列中，并将它们打包成块以供后续分发。这些块将成为区块链的块！一旦订购者生成了所需大小的块，或者在最大经过时间之后，它将被发送到在特定信道上连接到它的所有对等体。我们将在第3阶段看到如何处理此块。

值得注意的是，块中交易的顺序不一定与订货人交易的到达顺序相同！事务可以按任何顺序打包到一个块中，而这个序列就成了执行的顺序。重要的是，有一个严格的秩序，而不是那个顺序。

块内事务的这种严格排序使Hyperledger Fabric与其他区块链略有不同，其他区块链可以将相同的事务打包到多个不同的块中。在Hyperledger Fabric中，这不可能发生 - 由订单集合生成的块被认为是最终的，因为一旦事务被写入块，它在分类账中的位置是不可避免的。 Hyperledger Fabric的最终结果意味着不会发生称为分类账分叉的灾难性事件。一旦在块中捕获事务，就不能在将来的时间点为该事务重写历史记录。

我们也可以看到，虽然同行主持分类账和链码，但最有可能没有。到达订货人的每个交易都是机械地打包在一个区块中 - 订货人不会对交易的价值做出判断，只是将其打包。这是Hyperledger Fabric的一个重要特性 - 所有交易都被编组成严格的订单 - 交易永远不会被删除或取消优先级。

在第2阶段结束时，我们看到订货人负责收集建议的交易更新，订购它们，将它们打包成块，准备分发的简单但至关重要的过程。

阶段三：验证

事务工作流的最后阶段涉及从订货人到对等方的块的分发和后续验证，其中它们可以应用于分类帐。具体而言，在每个对等方中，块中的每个事务都经过验证，以确保在将其应用于分类帐之前始终得到所有相关组织的认可。保留失败的事务以进行审计，但不会应用于分类帐。

orderer节点的第二个角色是将块分发给对等体。在该示例中，订货人O1将块B2分配给对等体P1和对等体P2。对等P1处理块B2，导致在P1上将新块添加到分类帐L1。并行地，对等体P2处理块B2，导致在P2上将新块添加到分类账L1。一旦完成该过程，就在对等体P1和P2上持续更新分类账L1，并且每个分类账可以通知连接的应用程序已经处理了该事务。

阶段3开始于订货人将块分配给连接到它的所有对等体。对等体连接到通道上的订购者，这样当生成新块时，连接到订购者的所有对等体将被发送新块的副本。每个对等体将独立处理此块，但其方式与通道上的每个其他对等体完全相同。通过这种方式，我们可以看到分类帐可以保持一致。值得注意的是，不是每个对等体都需要连接到一个命令者 - 对等体可以使用八卦协议将块级联到其他对等体，这些协议也可以独立处理它们。但是让我们把这个讨论留给另一个时间！

收到一个块后，对等体将按照它在块中出现的顺序处理每个事务。对于每个交易，每个对等方将根据生成交易的链码的认可政策来验证交易是否已被所需组织认可。例如，某些交易可能只需要由单个组织认可，而其他交易可能需要多次认可才能被视为有效。此验证过程验证所有相关组织是否已生成相同的结果或结果。另请注意，此验证与第1阶段中的认可检查不同，在第1阶段，应用程序接收来自支持对等方的响应，并决定发送提案事务。如果应用程序通过发送错误的事务违反了认可策略，则对等体仍然能够在阶段3的验证过程中拒绝该事务。

如果事务已正确认可，则对等方将尝试将其应用于分类帐。为此，对等方必须执行分类帐一致性检查，以验证生成建议更新时分类帐的当前状态是否与分类帐的状态兼容。即使交易已得到完全认可，这也可能并非总是可行。例如，另一个事务可能已更新分类帐中的相同资产，使得事务更新不再有效，因此无法再应用。通过这种方式，每个对等方的分类帐副本在整个网络中保持一致，因为它们各自遵循相同的验证规则。

在对等方成功验证每个单独的事务后，它会更新分类帐。失败的交易不会应用于分类帐，但会将其保留用于审计目的，成功的交易也是如此。这意味着对等块几乎与从订货人接收的块完全相同，除了块中每个事务的有效或无效指示符。

我们还注意到阶段3不需要运行链码 - 这只在第1阶段进行，这很重要。这意味着只需在背书节点上提供链码，而不是整个区块链网络。这通常是有帮助的，因为它使链码的逻辑保密以支持组织。这与链路的输出（交易提议响应）形成对比，链路输出与信道中的每个对等方共享，无论它们是否认可交易。这种支持对等体的专业化旨在帮助实现可伸缩性。

最后，每次将块提交给对等方的分类帐时，该对等方都会生成适当的事件。块事件包括完整块内容，而块事务事件仅包括摘要信息，例如块中的每个事务是否已经过验证或无效。链码执行产生的Chaincode事件也可以在此时发布。应用程序可以注册这些事件类型，以便在它们发生时得到通知。这些通知结束了事务工作流程的第三个也是最后一个阶段。

总之，阶段3看到由订货人生成的块始终应用于分类帐。将事务严格排序到块中允许每个对等体验证在区块链网络上一致地应用事务更新。

1.4.1排序者（Orders）和一致性（Consesus）

整个交易工作流程过程称为共识，因为所有同行都已在订单和交易商内容上达成协议，这一过程由订货人调解。共识是一个多步骤的过程，只有当流程完成时，应用程序才会通知分类帐更新 - 这可能会在不同的同行上稍微不同的时间发生。

我们将在未来的orderer主题中更详细地讨论订购者，但是现在，将订购者视为从同行的应用程序收集和分发建议的分类帐更新以验证和包含在分类帐中的节点。

而已！我们现在已经完成了对同伴以及Hyperledger Fabric中与之相关的其他组件的巡视。我们已经看到同行在很多方面都是最基本的因素 - 它们形成网络，主机链码和分类账，处理交易提议和响应，并通过始终如一地对其进行交易更新来使分类账保持最新状态。

Hyperledger Fabric 之Peers介绍相关推荐

Scaling Hyperledger Fabric Using Pipelined Execution and Sparse Peers(提升fabric 6倍性能的文章翻译)
本文章是记录我对hyperledger fabric pipelined ABSTRACT 许多使用Hyperledger Fabric(允许使用的区块链平台)构建的区块链应用程序的概念证明,最近已经 ...
Hyperledger Fabric 1.3 官方文档翻译（三）关键概念 (Key Concepts) - 3.7 对等节点 (Peers)
文章目录对等节点(Peers) 术语(A word on terminology) 账本与链代码(Ledgers and Chaincode) 多账本(Multiple Ledgers) 多链代码( ...
Hyperledger Fabric v1.4(LTS) 系列(3.7)：关键概念-Peers
译文目录: Hyperledger Fabric v1.4(LTS) 系列译文总目录 Key Concepts-Peers Introduction Hyperledger Fabric Functi ...
HyperLedger Fabric Introduction——区块链超级账本介绍
介绍 HyperLedger Fabric是一个基于模块化架构的分布式账本解决方案平台,它拥有深度加密.便捷扩展.部署灵活及可插拔等特性.它设计之初的目的是支持不同组件的可插拔实现,并适应整个经济生态 ...
Hyperledger Fabric介绍
转载地址 https://blog.csdn.net/xiaonu123/article/details/81006936 简介 Hyperledger介绍超级账本(Hyperledger)项目是首 ...
【Hyperledger Fabric】学习笔记1—— 区块链介绍
目录 1. 区块链介绍 1.1 区块链技术起源 1.1.1 区块链技术 1.1.2 区块链技术发展 1.2 区块链核心技术 1.2.1 定义 1.2.2 区块链技术原理 1.2.3 区块链工作过程 1 ...
Hyperledger Fabric是区块链中联盟链架构详细介绍
区块链开源实现HYPERLEDGER FABRIC架构详解区块链开源实现HYPERLEDGER FABRIC架构详解 hyperledger fabric是区块链中联盟链的优秀实现,主要代码由IBM ...
超级账本（Hyperledger Fabric）之权限管理浅析
链客,专为开发者而生,有问必答! 此文章来自区块链技术社区,未经允许拒绝转载. 超级账本(Hyperledger Fabric)之权限管理浅析超级账本是联盟链的代表,而其相对于共链(例如比特币,以太 ...
区块链相关论文研读3- 关于超级账本Hyperledger Fabric的性能优化
这是2019年6月发表在顶会Sigmod上面的论文,论文题目为<Blurring the Lines between Blockchains and Database Systems: the ...

Hyperledger Fabric 之Peers介绍