超级账本相关概念-翻译

英文水平有限，仅供参考学习使用。

区块链网络

**目标读者：**架构师、管理员、开发者

本主题将在概念层面上描述超账本结构如何允许组织在区块链网络的形成中进行协作。如果您是架构师、管理员或开发人员，您可以使用这个主题来深入了解超级分类帐结构区块链网络中的主要结构和流程组件。本主题将使用一个可管理的工作示例，介绍区块链网络中的所有主要组件。

阅读本主题并理解策略的概念之后，您将对组织需要做出的决策有一个坚实的理解，以建立控制已部署的超分类帐结构网络的策略。您还将了解组织如何使用声明性策略管理网络演化—这是超分类结构的一个关键特性。简单地说，您将了解超级账本结构的主要技术组件以及组织需要对此做出的决策。

区块链网络是什么？

区块链网络是一种为应用程序提供分类账和智能合约(链码)服务的技术基础设施。智能契约主要用于生成交易，这些交易随后被分发到网络中的每个对等节点，并在每个节点的分类账副本上记录下来。应用程序的用户可能是使用客户端应用程序的最终用户或区块链网络管理员。

在大多数情况下，多个组织联合起来形成网络，它们的权限由一组策略决定，这些策略是在网络最初配置时由联合商定的。此外，网络策略可以随着时间的推移而改变，这取决于联盟中的组织的协议，我们将在讨论修改策略的概念时发现这一点。

网络示例

在开始之前，让我们向您展示一下我们的目标!这是一个表示示例网络的最终状态的图。

不要担心这看起来会很复杂!当我们通过这个主题时，我们将一点一点地构建网络，这样您就可以看到组织R1、R2、R3和R4如何为网络贡献基础设施来帮助它的形成。此基础结构实现了区块链网络，并且由组成网络的组织(例如，可以添加新组织的组织)同意的策略对其进行治理。您将了解应用程序如何使用区块链网络提供的分类账和智能契约服务。

四个组织，R1, R2, R3和R4已经共同决定，并写入了一份协议，他们将建立和利用一个超级账本结构网络。R4被指定为网络启动器——它被赋予了设置网络初始版本的权力。R4不打算在网络上执行业务事务。R1和R2需要在整个网络中进行私有通信，R2和R3也是如此。Organization R1有一个客户端应用程序，它可以在通道C1中执行业务事务。组织R2有一个客户机应用程序，它可以在通道C1和C2中执行类似的工作。组织R3有一个客户端应用程序可以在通道C2上实现这一点。对等节点P1维护一个与C1相关联的L1分类账副本。对等节点P2维护一个与C1关联的分类帐L1副本和一个与C2关联的分类帐L2副本。对等节点P3维护与C2相关的L2分类账副本。网络根据网络配置NC4中指定的策略规则进行治理，网络受组织R1和R4的控制。通道C1根据通道配置CC1中指定的策略规则进行治理;该通道由组织R1和R2控制。通道C2按照通道配置CC2中指定的策略规则进行治理;这个频道由R2和R3这两个组织控制。有一个订购服务O4作为N的网络管理点，并使用系统通道。订购服务还支持应用程序通道C1和C2，以便将事务排序为块进行分发。这四个组织都有一个首选的证书颁发机构。

创建网络

让我们从创建网络的基础开始:

当一个定序程序启动时，网络就形成了。在我们的示例网络N中，包含单个节点O4的订购服务根据网络配置NC4进行配置，该网络配置将管理权限授予组织R4。在网络级别，证书颁发机构CA4用于向R4组织的管理员和网络节点分配身份。

我们可以看到，定义网络N的第一个东西是订购服务O4。将订购服务视为网络的初始管理点是有帮助的。如前所述，O4最初由组织R4中的管理员配置和启动，并托管在R4中。配置NC4包含描述网络管理功能初始集的策略。最初，这个设置只授予R4网络上的权限。这将会改变，我们稍后会看到，但是现在R4是网络中唯一的成员。

证书颁发机构

您还可以看到证书颁发机构CA4，它用于向管理员和网络节点颁发证书。CA4在我们的网络中起着关键作用，因为它分发了X.509证书，这些证书可用于标识属于组织R4的组件。核证机关签发的证书也可以用来签署交易，以表明某个组织认可交易结果——这是将交易结果记入分类账的前提条件。让我们更详细地研究一下CA的这两个方面。

首先，区块链网络的不同组件使用证书相互标识自己来自某个特定组织。这就是为什么支持区块链网络的CA通常不止一个——不同的组织经常使用不同的CA。我们将在网络中使用四个CAs;每个组织一个。的确，CA是如此重要，以至于Hyperledger Fabric为您提供了一个内置的CA(称为Fabric-CA)来帮助您进行工作，尽管在实践中，组织将选择使用它们自己的CA。

证书到成员组织的映射是通过一个称为成员服务提供者(MSP)的结构实现的。网络配置NC4使用一个命名的MSP来识别CA4颁发的证书的属性，CA4将证书持有者与组织R4关联起来。然后，NC4可以在策略中使用这个MSP名称来授予来自R4的参与者对网络资源的特殊权限。这种策略的一个例子是识别R4中可以向网络添加新成员组织的管理员。我们没有在这些图中显示MSPs，因为它们会使它们变得混乱，但是它们非常重要。

其次，稍后我们将看到ca颁发的证书如何成为事务生成和验证过程的核心。具体来说，X.509证书用于客户端应用程序事务建议和对数字签名事务的智能契约事务响应。随后，持有分类帐副本的网络节点在接受分类帐上的交易之前验证交易签名是否有效。

让我们回顾一下示例区块链网络的基本结构。有一个资源，网络N，由一组由证书颁发机构CA4定义的用户访问，这些用户对网络N中的资源拥有一组权限，这些权限由网络配置NC4中包含的策略描述。当我们配置并启动订购服务节点O4时，所有这些都变成了现实。

添加网络管理员

最初将NC4配置为只允许R4用户对网络拥有管理权限。在下一阶段，我们将允许组织R1用户管理网络。让我们看看网络是如何发展的:

组织R4更新网络配置，使组织R1也成为管理员。在这一点之后，R1和R4对网络配置具有同等的权限。

我们看到添加了一个新的组织R1作为管理员—R1和R4现在在网络上具有相同的权限。我们还可以看到已经添加了证书颁发机构CA1——它可以用来识别来自R1组织的用户。在此之后，R1和R4的用户都可以管理网络。

虽然orderer节点O4运行在R4的基础设施上，但是R1对它共享管理权限，只要它能够获得网络访问。这意味着R1或R4可以更新网络配置NC4，使R2组织成为网络操作的子集。通过这种方式，即使R4正在运行订购服务，并且R1对其拥有完全的管理权限，R2创建新财团的权限也是有限的。

在其最简单的形式中，订购服务是网络中的单个节点，这就是您在示例中看到的。订购服务通常是多节点的，可以将其配置为在不同的组织中具有不同的节点。例如，我们可以在R4中运行O4并将其连接到组织R1中的一个单独的orderer节点O2。这样，我们就有了一个多站点、多组织的管理结构。

我们将在本主题的后面部分讨论订购服务，但是现在只将订购服务看作一个管理点，它为不同的组织提供对网络的控制访问。

定义一个联盟

虽然现在可以由R1和R4管理网络，但是几乎没有什么可以做的。我们需要做的第一件事是定义一个盟。这个词的字面意思是“有着共同命运的一群人”，所以对于区块链网络中的一组组织来说，这是一个合适的选择。

让我们看看如何定义一个盟:

网络管理员定义一个包含两个成员的联合体X1，即组织R1和R2。此联合定义存储在网络配置NC4中，将在网络开发的下一阶段使用。CA1和CA2分别是这些组织的证书颁发机构。

由于NC4的配置方式，只有R1或R4可以创建新的联合。这个图显示了一个新的联合体X1的添加，它将R1和R2定义为其组成组织。我们还可以看到CA2被添加到R2中来识别使用者。请注意，一个联合体可以有任意数量的组织成员——我们只展示了两个，因为这是最简单的配置。

为什么财团很重要?我们可以看到，一个联合体定义了网络中的一组组织，这些组织都需要与彼此进行交易——在本例中是R1和R2。如果组织有一个共同的目标，那么将它们组织在一起是很有意义的，而这正是正在发生的事情。

该网络虽然由一个组织启动，但现在由一组更大的组织控制。我们可以这样开始，R1、R2和R4共享控制，但是这种构建使它更容易理解。

我们现在将使用consortium X1来创建一个非常重要的超账本结构区块链- a通道。

为联盟创建通道

因此，让我们创建这个关键部分的区块链网络-通道。通道是一个主要的通信机制，通过它，联盟的成员可以互相通信。网络中可以有多个通道，但是现在，我们先从一个开始。

让我们看看第一个频道是如何添加到网络的:

使用联合体定义X1为R1和R2创建了通道C1。通道由通道配置CC1控制，完全独立于网络配置。CC1由R1和R2管理，它们对C1具有相同的权限。R4在CC1中没有任何权限。

通道C1为联合X1提供了私有通信机制。我们可以看到通道C1已经连接到订购服务O4，但是没有其他连接到它。在网络开发的下一阶段，我们将连接客户端应用程序和对等节点等组件。但在这一点上，通道代表了未来连接的潜力。

尽管C1通道是网络N的一部分，但它与网络N有很大的区别。还要注意，组织R3和R4不在此通道中—它用于R1和R2之间的事务处理。在前面的步骤中，我们了解了R4如何授予R1创建新财团的权限。值得一提的是，R4也允许R1创建通道!在这个图中，创建通道C1的可能是组织R1或R4。同样，请注意一个通道可以有任意数量的组织连接到它—我们已经展示了两个，因为它是最简单的配置。

同样，请注意通道C1如何具有与网络配置NC4完全独立的配置(CC1)。CC1包含控制R1和R2在通道C1上的权限的策略——正如我们所看到的，R3和R4在这个通道上没有权限。R3和R4只有在由R1或R2添加到通道配置CC1中的适当策略时才能与C1交互。一个例子是定义谁可以向通道添加新组织。特别要注意的是，R4不能将自己添加到通道C1中——它必须而且只能由R1或R2授权。

为什么通道如此重要?通道是有用的，因为它们提供了一种机制，用于联盟成员之间的私有通信和私有数据。通道提供来自其他通道和网络的隐私。在这方面，Hyperledger Fabric是强大的，因为它允许组织共享基础设施，同时保持其私密性。这里不存在矛盾—网络中的不同协会需要适当地共享不同的信息和流程，而通道提供了实现这一点的有效机制。通道提供高效的基础设施共享，同时维护数据和通信隐私。

我们还可以看到，一旦一个通道被创建，它在一个非常真实的意义上“从网络中解放出来”。只有在通道配置中明确指定的组织才能对其进行控制，从现在到将来都是如此。同样，此后对网络配置NC4的任何更新都不会对通道配置CC1产生直接影响;例如，如果更改了联合定义X1，则不会影响通道C1的成员。因此，通道是有用的，因为它们允许组成通道的组织之间的私人通信。此外，通道中的数据与网络的其他部分(包括其他通道)完全隔离。

另外，还定义了一个特殊的系统通道供订购服务使用。它的行为与常规通道完全相同，因此有时称为应用程序通道。我们通常不需要担心这个通道，但是我们将在本主题的后面对此进行更多的讨论。

节点和账本

现在让我们开始使用该通道将区块链网络和组织组件连接在一起。在网络发展的下一个阶段，我们可以看到我们的网络N刚刚获得了两个新的组件，即一个对等节点P1和一个分类帐实例L1。

对等节点P1已加入通道C1。P1物理上托管一个L1分类账的副本。P1和O4可以使用通道C1进行通信。

对等节点是承载区块链分类账副本的网络组件!最后，我们开始看到一些可识别的区块链组件!P1在网络中的目的纯粹是为了存放L1账本的副本，供他人访问。我们可以将L1视为物理上驻留在P1上，但逻辑上驻留在C1通道上。当我们向通道中添加更多的对等点时，我们会更清楚地看到这个想法。

P1配置的一个关键部分是CA1发布的X.509标识，它将P1与组织R1相关联。一旦P1启动，它就可以使用orderer O4连接通道C1。当O4接收到这个连接请求时，它使用通道配置CC1来确定P1在这个通道上的权限。例如，CC1确定P1是否可以读取和/或将信息写入L1分类账。

请注意对等节点是如何由拥有它们的组织连接到通道的，尽管我们只添加了一个对等节点，但我们将看到网络中的多个通道上如何有多个对等节点。稍后我们将看到对等点可以扮演的不同角色。

应用和智能合约链码

既然通道C1上有一个分类帐，我们就可以开始连接客户端应用程序，以使用分类帐的主力(对等方)提供的一些服务了!

注意网络是如何发展的:

一个智能合约S5已经安装到P1上。组织R1中的客户端应用程序A1可以使用S5通过对等节点P1访问分类帐。A1、P1、O4都连接到C1频道，即都可以使用该频道提供的通讯设施。

在网络开发的下一阶段，我们可以看到客户端应用程序A1可以使用通道C1连接到特定的网络资源——在这种情况下，A1可以同时连接到对等节点P1和订货节点O4。再次，查看通道如何成为网络和组织组件之间通信的中心。与对等点和订单点一样，客户机应用程序将具有将其与组织关联起来的标识。在我们的示例中，客户端应用程序A1与组织R1相关联;虽然它在Fabric区块链网络之外，但它通过通道C1与之连接。

现在看来，A1可以通过P1直接访问L1分类账，但实际上，所有的访问都是通过一个叫做智能契约链码S5的特殊程序来管理的。可以把S5看作是定义了对分类帐的所有通用存取模式;S5提供了一组定义良好的方法，通过这些方法可以查询或更新分类帐L1。简而言之，客户端应用程序A1必须通过smart contract S5才能到达分类帐L1!

每个组织中的应用程序开发人员可以创建智能契约来实现联盟成员共享的业务流程。智能契约用于帮助生成事务，这些事务随后可以分发到网络中的每个节点。我们稍后再讨论这个想法;网络越大，理解起来就越容易。现在，需要理解的重要一点是，要达到这一点，smart契约必须执行两个操作;它必须安装在对等节点上，然后在通道上定义。

超级账本结构用户经常交替使用smart contract和chaincode这两个术语。通常，智能合约定义事务逻辑，事务逻辑控制包含在世界状态中的业务对象的生命周期。然后，它被打包成一个链代码，然后部署到区块链网络。可以将智能契约视为治理事务，而chaincode则治理如何将智能契约打包以进行部署。

安装链码包

在开发了智能契约S5之后，组织R1中的管理员必须创建一个chaincode包并将其安装到对等节点P1上。这是一个简单的操作;一旦完成，P1对S5就有了充分的了解。具体来说，P1可以看到S5的实现逻辑——它用来访问L1分类账的程序代码。我们将其与S5接口进行对比，S5接口只描述S5的输入和输出，而不考虑其实现。

当一个组织在一个通道中有多个对等点时，它可以选择安装智能契约的对等点;它不需要在每个同行上都安装智能 合约。

链码定义

尽管chaincode安装在各个组织的对等节点上，但它是在通道范围内进行管理和操作的。每个组织都需要批准chaincode定义，这是一组参数，用于确定如何在通道上使用chaincode。一个组织必须批准一个链码定义，以便使用安装的智能合同来查询分类账和批准交易。在我们的示例中，只有一个对等节点P1，组织R1中的管理员必须批准S5的chaincode定义。

在将chaincode定义提交给通道并用于与通道分类账交互之前，需要有足够多的组织批准chaincode定义(默认情况下是大多数组织)。因为通道只有一个成员，R1的管理员可以将S5的chaincode定义提交给通道C1。一旦提交了定义，S5现在就可以被客户端应用程序A1调用了!

注意，尽管通道上的每个组件现在都可以访问S5，但是它们不能看到它的程序逻辑。这对于安装了它的节点来说仍然是私有的;在我们的例子中是P1。从概念上讲，这意味着定义并提交给通道的是智能契约接口，而不是安装的智能契约实现。强化这一观点;安装智能契约表明我们如何认为它是物理上托管在对等节点上的，而在通道上定义的智能契约则表明我们如何从逻辑上考虑它是由通道托管的。

背书策略

在chaincode定义中提供的最重要的信息是背书策略。它描述了哪些组织必须在交易被其他组织接受之前批准这些交易并将其记录在总账上。在我们的样本网络中，交易只有在R1或R2背书的情况下才能被接受到L1分类账上。

将链码定义提交给通道，将背书策略放置在通道分类账上;它使通道的任何成员都可以访问它。您可以在事务流主题中阅读关于背书策略的更多信息。

调用智能合约

一旦在对等节点上安装了智能契约并在通道上定义了它，客户机应用程序就可以调用它。客户端应用程序通过向smart contract背书策略指定的组织所属的对等点发送事务建议来实现这一点。事务建议作为smart contract的输入，smart contract使用它来生成已认可的事务响应，该响应由对等节点返回给客户机应用程序。

这些事务响应与事务建议打包在一起，形成一个完全支持的事务，可以将其分发到整个网络。我们稍后将对此进行更详细的讨论，这足以理解应用程序如何调用智能契约来生成经过认可的事务。

在网络开发的这个阶段，我们可以看到组织R1完全参与了网络。它的应用程序——从A1开始——可以通过smart contract S5访问L1分类账，生成将被R1背书的交易，因此可以被分类账接受，因为它们符合背书策略。

完整的网络

回想一下，我们的目标是为X1 -组织R1和R2创建一个通道。在网络开发的下一阶段，组织R2将其基础设施添加到网络中。

让我们看看网络是如何演变的:

通过增加R2组织的基础设施，网络得到了发展。具体地说，R2已经添加了对等节点P2和链码S5，节点P2承载着一份L1分类账的副本。R2批准与R1相同的chaincode定义。P2也加入了通道C1，应用程序A2也是如此。A2和P2是使用CA2的证书来识别的。所有这些意味着应用程序A1和A2都可以使用对等节点P1或P2在C1上调用S5。

我们可以看到组织R2在通道C1上添加了一个对等节点P2。P2也有L1和smart contract S5的副本。我们可以看到，R2还添加了客户端应用程序A2，它可以通过通道C1连接到网络。为了实现这一点，R2组织中的管理员创建了对等节点P2并将其连接到通道C1，其方式与R1中的管理员相同。管理员还必须批准与R1相同的chaincode定义。

我们已经建立了我们的第一个运营网络!在网络开发的这个阶段，我们有一个通道，R1和R2组织可以在这个通道中完全地相互协作。具体来说，这意味着应用程序A1和A2可以使用通道C1上的智能契约S5和分类帐L1生成事务。

生成和接受事务

与对等节点(总是承载一份分类帐副本)相反，我们看到有两种不同类型的对等节点;有智能合约的，也有没有的。在我们的网络中，每个对等节点都承载一份智能契约，但是在更大的网络中，会有更多的对等节点不承载一份智能契约。对等方只能在安装了智能契约的情况下运行它，但是它可以通过连接到通道来了解智能契约的接口。

您不应该认为没有安装智能契约的对等节点是劣等的。更确切地说，具有智能契约的对等节点具有一种特殊的能力——帮助生成事务。请注意，所有对等节点都可以验证并随后在其L1分类账副本上接受或拒绝交易。然而<u>，只有安装了智能契约的对等节点才能参与事务背书过程，而事务背书是有效事务生成的核心</u>。

在本主题中，我们不需要担心事务是如何生成、分发和接受的确切细节—只要了解我们有一个区块链网络，其中组织R1和R2可以作为账本捕获的事务共享信息和流程，这就足够了。我们将在其他主题中学习更多关于交易、分类账、智能合同的内容。

节点类型

在超级分类帐结构中，虽然所有的对等点都是相同的，但它们可以根据网络的配置方式承担多个角色。我们现在已经对典型的网络拓扑有了足够的了解来描述这些角色。

提交节点：通道中的每个对等节点都是一个提交对等节点。它接收生成的事务块，这些事务块随后经过验证，然后将其作为附加操作提交到对等节点的分类帐副本。

背书节点：如果安装了智能合约，每个拥有智能合约的对等方都可以成为背书的对等方。然而，要实际成为一个认可的对等点，客户端应用程序必须使用对等点上的智能契约来生成数字签名的事务响应。“认可同伴”一词是对这一事实的明确引用。

智能合同的背书策略确定了组织的对等方应该对生成的交易进行数字签名，然后才能将其接收到提交的对等方的总账副本。

这是同伴的两种主要类型;同伴还可以扮演其他两个角色:

领导节点：当一个组织在一个通道中有多个对等点时，一个leader对等点是一个节点，它负责将事务从定序者分发到组织中其他提交对等点。同伴可以选择参与静态或动态的领导选择。

因此，从领导的角度来考虑两组同伴是有帮助的，一组是静态的领导者选择，另一组是动态的领导者选择。对于静态集，可以将零个或多个对等点配置为leader。对于动态集合，一个peer将被该集合选举为leader，并且在动态集合中，如果一个leader peer失败，那么剩下的peer将重新选举一个leader。

这意味着一个组织的同行可以有一个或多个连接到订购服务的领导者。这有助于提高处理大量事务的大型网络的弹性和可伸缩性。

锚节点：如果一个对等点需要与另一个组织中的对等点通信，那么它可以使用在该组织的通道配置中定义的一个锚对等点。组织可以为其定义零个或多个锚点对等点，锚点对等点可以帮助处理许多不同的跨组织通信场景。

请注意，对等点可以同时是提交对等点、支持对等点、领导对等点和锚点对等点!只有锚点对等点是可选的——对于所有实际目的，总是会有一个领导对等点和至少一个支持对等点和至少一个承诺对等点。

通道中增加组织和节点

当R2加入通道时，组织必须将smart contract S5安装到它的对等节点P2上。这是显而易见的——如果应用程序A1或A2希望在对等节点P2上使用S5来生成事务，则必须首先提供S5;安装是实现这一过程的机制。此时，对等节点P2拥有smart契约和分类帐的物理副本;与P1一样，它可以在其L1分类帐副本上生成和接受事务。

为了使用智能合同S5, R2必须批准与R1相同的链码定义。因为组织R1已经将chaincode定义提交给了通道，所以只要组织批准了chaincode定义并安装了chaincode包，R2就可以使用chaincode。提交事务只需要发生一次。一个新的组织可以使用链码，只要他们批准的链码参数得到通道的其他成员的同意。因为对chaincode定义的批准发生在组织级，所以R2可以只批准一次chaincode定义，并将安装了chaincode包的多个节点连接到通道。但是，如果R2想要更改chaincode定义，R1和R2都需要为它们的组织批准一个新的定义，然后其中一个组织需要将这个定义提交给通道。

在我们的网络中，我们可以看到通道C1连接两个客户机应用程序、两个对等节点和一个订购服务。由于只有一个通道，所以这些组件与之交互的逻辑台账只有一个。对等节点P1和P2具有相同的分类帐L1副本。smart contract S5的副本通常使用相同的编程语言进行相同的实现，但如果不是这样，它们在语义上必须是相同的。

我们可以看到，小心地向网络中添加对等点可以帮助支持增加的吞吐量、稳定性和弹性。例如，网络中更多的对等点将允许更多的应用程序连接到它;组织中的多个对等点将在计划内或计划外停机的情况下提供额外的弹性。

这一切都意味着可以配置支持各种操作目标的复杂拓扑——网络的大小没有理论上的限制。此外，单个组织内的对等节点有效地发现和彼此通信的技术机制(闲话协议)将容纳大量对等节点来支持这种拓扑。

谨慎地使用网络和通道策略甚至可以使大型网络得到良好的治理。组织可以自由地向网络中添加对等节点，只要它们符合网络商定的策略。网络和渠道政策创造了自治和控制之间的平衡，这是去中心化网络的特征。

简化视觉词汇表

现在，我们将简化用来表示示例区块链网络的视觉词汇表。随着网络规模的增长，最初用来帮助我们理解信道的那些行将变得很麻烦。想象一下，如果我们添加另一个对等点或客户端应用程序或另一个通道，我们的关系图将会多么复杂?

这就是我们马上要做的，在这之前，我们先来简化一下视觉词汇。以下是我们迄今为止开发的网络的一个简化表示:

该图显示了与网络N中的通道C1相关的事实，如下所示:客户端应用程序A1和A2可以使用通道C1与对等点P1和P2进行通信，以及orderer O4。对等节点P1和P2可以使用通道C1的通信服务。订购服务O4可以使用C1通道的通信服务。通道配置CC1适用于通道C1。

注意，通过用连接点替换通道线来简化网络图，连接点显示为包含通道号的蓝色圆圈。没有任何信息丢失。这种表示更具有可伸缩性，因为它消除了交叉行。这使我们能够更清晰地表示更大的网络。我们通过关注组件和通道之间的连接点而不是通道本身来实现这种简化。

增加一个团体

在网络发展的下一阶段，我们将介绍组织R3。我们将给R2和R3两个组织一个单独的应用渠道，让它们可以互相进行交易。这个应用程序通道将完全独立于前面定义的通道，因此R2和R3事务可以对它们保持私有。

让我们回到网络层，为R2和R3定义一个新的联合体X2:

来自组织R1或R4的网络管理员添加了一个新的联合体定义X2，其中包括组织R2和R3。这将用于为X2定义一个新通道。

注意，网络现在定义了两个联合:X1表示组织R1和R2, X2表示组织R2和R3。引入X2财团是为了能够为R2和R3创建一个新的通道。

新通道只能由那些在网络配置策略(NC4)中明确指定的具有适当权限的组织创建，即R1或R4。这是一个策略的例子，它将可以在网络级别管理资源的组织与可以在通道级别管理资源的组织分开。看到这些策略的作用，有助于我们理解为什么超级账本结构具有复杂的分层策略结构。

在实践中，联合体定义X2被添加到网络配置NC4中。我们将在文档的其他部分讨论此操作的具体机制。

新增一个通道

现在让我们使用这个新的联合定义X2来创建一个新通道C2。为了帮助你理解更简单的通道符号，我们使用了两种视觉样式——通道C1用蓝色的圆形端点表示，而通道C2用红色的连接线表示:

使用联合体定义X2为R2和R3创建了一个新的通道C2。通道有一个通道配置CC2，完全独立于网络配置NC4和通道配置CC1。通道C2由R2和R3管理，它们对C2具有与CC2中策略定义的相同的权限。R1和R4在CC2中没有定义任何权限。

通道C2为联合体X2提供了一种专用通信机制。再一次，请注意组织是如何联合成一个联合体的，是如何形成通道的。通道配置CC2现在包含管理通道资源的策略，通过通道C2将管理权分配给组织R2和R3。它完全由R2和R3管理;R1和R4在C2频道没有电源。例如，通道配置CC2随后可以更新以添加组织来支持网络增长，但这只能由R2或R3完成。

请注意通道配置CC1和CC2如何保持彼此完全独立，并且与网络配置NC4完全独立。我们再次看到了超账本结构网络的去中心化本质;一旦创建了通道C2，它就由组织R2和R3独立于其他网络元素进行管理。通道策略始终保持彼此独立，并且只能由授权的组织在通道中进行更改。

随着网络和通道的发展，网络和通道的配置也将发生变化。有一个过程是通过一种受控的方式来完成的——包括捕获对这些配置的更改的配置事务。每个配置更改都会生成一个新的配置块事务，在本主题的后面，我们将看到如何验证和接受这些块来分别创建更新的网络和通道配置。

网络和通道配置

在我们的示例网络中，我们看到了网络和通道配置的重要性。这些配置非常重要，因为它们封装了网络成员同意的策略，这些策略提供了控制对网络资源访问的共享引用。网络和通道配置还包含关于网络和通道组成的事实，如财团及其组织的名称。

例如，当使用订购服务节点O4首次形成网络时，其行为由网络配置NC4控制。NC4的初始配置只包含允许组织R4管理网络资源的策略。随后更新NC4以允许R1管理网络资源。一旦进行了此更改，来自组织R1或R4的任何连接到O4的管理员都将拥有网络管理权限，因为这是网络配置NC4中的策略所允许的。在内部，订购服务中的每个节点记录网络配置中的每个通道，以便在网络级别上创建每个通道的记录。

这意味着尽管订购服务节点O4是创建联合X1和X2以及通道C1和C2的参与者，但是网络的智能包含在O4所服从的网络配置NC4中。只要O4作为一个良好的参与者，并且在处理网络资源时正确地实现NC4中定义的策略，我们的网络就会按照所有组织都同意的方式运行。在许多方面，NC4可以被认为比O4更重要，因为它最终控制了网络访问。

同样的原则也适用于通道配置。在我们的网络中，P1和P2也是很好的参与者。当对等节点P1和P2与客户机应用程序A1或A2交互时，它们各自使用通道配置CC1中定义的策略来控制对通道C1资源的访问。

例如，如果A1希望访问对等节点P1或P2上的智能契约链码S5，则每个对等节点使用其CC1副本来确定A1可以执行的操作。例如，A1可能被允许根据CC1中定义的策略从L1分类账中读写数据。稍后我们将看到通道及其通道配置CC2中的参与者的相同模式。同样，我们可以看到，虽然对等点和应用程序是网络中的关键参与者，但是它们在通道中的行为更多地是由通道配置策略决定的，而不是其他因素。

最后，它有助于理解网络和信道配置是如何在物理上实现的。我们可以看到网络和通道的配置在逻辑上是单一的——一个用于网络，一个用于每个通道。这是很重要的;访问网络或通道的每个组件必须对授予不同组织的权限有一个共享的理解。

尽管在逻辑上只有一个配置，但它实际上被构成网络或通道的每个节点复制并保持一致。例如，在我们的网络对等节点P1和P2都有通道配置CC1的副本，当网络完全完成时，对等节点P2和P3都有通道配置CC2的副本。类似地，订购服务节点O4具有网络配置的副本，但是在多节点配置中，每个订购服务节点都有自己的网络配置副本。

网络和通道配置都使用相同的区块链技术保持一致，该技术用于用户事务，但用于配置事务。要更改网络或通道配置，管理员必须提交一个配置事务来更改网络或通道配置。它必须由在适当的策略中标识为负责配置更改的组织签署。这个策略称为mod_policy，稍后我们将讨论它。

事实上，订购服务节点操作一个迷你区块链，通过我们前面提到的系统通道连接。使用系统通道订购服务节点分发网络配置事务。这些事务用于协作地维护每个订购服务节点上的网络配置的一致副本。以类似的方式，应用程序通道中的对等节点可以分发通道配置事务。同样，这些事务用于在每个对等节点上维护通道配置的一致副本。

这种逻辑上的个体间的平衡，通过物理上的分布，是超级账本结构中常见的模式。例如，逻辑上是单个的网络配置之类的对象最终会在一组订购服务节点之间进行物理复制。我们还看到它与通道配置、分类账和某种程度上的智能契约一起安装在多个地方，但是它们的接口逻辑上存在于通道级别。这种模式在超级账本结构中可以反复看到，它使超级账本结构既不集中又可以同时管理。

新增一个节点

既然组织R3能够完全参与通道C2，让我们将其基础结构组件添加到通道中。与其一次只做一个组件，我们还不如同时添加一个peer，它是一个分类帐的本地副本、一个智能契约和一个客户端应用程序!

让我们看看加入了组织R3组件的网络:

图中显示了网络N中与通道C1和C2有关的事实如下:客户端应用程序A1和A2可以使用通道C1与对等点P1和P2通信，以及订购服务O4;客户端应用程序A3可以使用通道C2与P3和订购服务O4进行通信。订购服务O4可以使用通道C1和C2的通信服务。通道配置CC1适用于通道C1, CC2适用于通道C2。

首先，请注意，由于对等节点P3连接到通道C2，所以它与使用通道C1的对等节点具有不同的分类帐(L2)。分类帐L2有效地作用于通道C2。L1分类账是完全独立的;它作用域为通道C1。这是有道理的——C2通道的目的是在X2联盟的成员之间提供私有通信，而L2分类账是他们交易的私有存储。

类似地，安装在对等节点P3上、定义在通道C2上的smart contract S6用于提供对分类帐L2的受控访问。应用程序A3现在可以使用通道C2来调用smart contract S6提供的服务来生成交易，这些交易可以被网络中L2的每个副本所接受。

此时，我们有一个单独的网络，其中定义了两个完全独立的通道。这些渠道为组织之间的交易提供了独立管理的设施。这就是工作中的去中心化;我们在控制和自主之间取得了平衡。这是通过应用于由不同组织控制和影响的渠道的政策来实现的。

节点加入多个通道

在网络开发的最后阶段，让我们将重点放在组织R2上。我们可以利用R2是X1和X2联盟的成员这一事实，将其加入多个渠道:

图中显示了网络N中与通道C1和C2相关的事实如下:客户端应用程序A1可以使用通道C1与对等点P1和P2进行通信，并订购服务O4;客户应用A2可以使用通道C1与P1和P2进行通信，通道C2可以使用通道C2与P2和P3进行通信，还可以使用通道C2与订购服务O4进行通信;客户应用程序A3可以使用通道C2与对等点P3和P2通信，并订购服务O4。订购服务O4可以使用通道C1和C2的通信服务。通道配置CC1适用于通道C1, CC2适用于通道C2。

我们可以看出R2是网络中的一个特殊组织，因为它是两个应用通道中唯一的成员组织!它可以在通道C1上与组织R1进行交易，同时也可以在不同的通道C2上与组织R3进行交易。

请注意对等节点P2如何为通道C1安装了smart contract S5，为通道C2安装了smart contract S6。对等节点P2是两个通道的完全成员，同时通过不同的智能契约为不同的账本服务。

这是一个非常强大的概念——通道既提供了组织分离的机制，也提供了组织间协作的机制。一直以来，这种基础结 构都是由一组独立的组织提供和共享的。

同样重要的是，对等节点P2的行为控制非常不同，这取决于它所处理的通道。具体来说，通道配置CC1中包含的策略规定了P2在通道C1中进行交易时可用的操作，而通道配置CC2中的策略控制了P2在通道C2中的行为。

同样，这也是可取的——R2和R1同意C1频道的规则，而R2和R3同意C2频道的规则。这些规则是在各自的通道策略中捕获的——它们可以而且必须被通道中的每个组件使用，以强制执行正确的行为。

类似地，我们可以看到客户端应用程序A2现在能够在通道C1和C2上进行交易。同样，它也将由适当的通道配置中的策略控制。顺便说一句，请注意客户机应用程序A2和对等节点P2使用的是混合的可视词汇表—包括行和连接。你可以看到它们是等价的;它们是视觉上的同义词。

排序服务

细心的读者可能会注意到，订购服务节点似乎是一个集中的组件;它最初用于创建网络，并连接到网络中的每个通道。即使我们将R1和R4添加到控制orderer的网络配置策略NC4中，节点仍然在R4的基础设施上运行。在一个去中心化的世界里，这看起来是错误的!

别担心!我们的示例网络展示了最简单的订购服务配置，以帮助您理解网络管理点的概念。事实上，订购服务本身也可以完全去中心化!我们在前面提到过，订购服务可以由不同组织拥有的许多单独节点组成，因此让我们看看如何在我们的示例网络中实现这一点。

让我们来看看一个更现实的订购服务节点配置:

一个多组织的订购服务。订购服务包括订购服务节点O1和O4。O1由组织R1提供，节点O4由组织R4提供。网络配置NC4为来自组织R1和R4的参与者定义了网络资源权限。

我们可以看到这个订购服务完全去中心化了——它在组织R1中运行，在组织R4中运行。网络配置策略NC4允许R1和R4对网络资源具有同等的权限。来自组织R1和R4的客户端应用程序和对等节点可以通过连接到节点O1或节点O4来管理网络资源，因为这两个节点的行为方式相同，这是由网络配置NC4中的策略定义的。在实践中，来自特定组织的参与者倾向于使用他们的本地组织提供的基础设施，但情况并不总是如此。

分布式事务分发

另一个关键功能——它是事务的分发点。订购服务是一个组件，它从应用程序中收集经过认可的事务并将其订购到事务块中，然后将这些事务块分发到通道中的每个对等节点。在每个提交节点上，交易都会被记录下来，无论交易是有效的还是无效的，它们的本地分类账副本也会得到适当的更新。

请注意，订购服务节点O4为通道C1执行的角色与为网络n执行的角色非常不同。当在通道级别执行操作时，O4的角色是收集事务并在通道C1内分发块。它根据通道配置CC1中定义的策略执行此操作。相反，当在网络级别执行操作时，O4的角色是根据网络配置NC4中定义的策略为网络资源提供管理点。再次注意，这些角色是如何分别由通道和网络配置中的不同策略定义的。这将增强您对基于声明性策略的配置在超级分类帐结构中的重要性的认识。策略定义并用于控制联盟中每个成员的一致行为。

我们可以看到，订购服务与超级分类帐结构中的其他组件一样，是一个完全非集中化的组件。无论是作为网络管理点，还是作为通道中块的分发者，其节点都可以根据需要分布到网络中的多个组织中。

改变策略

在我们探索示例网络的过程中，我们已经看到了控制系统中参与者行为的策略的重要性。我们只讨论了一些可用的策略，但是有许多可以通过声明定义来控制行为的各个方面。这些单独的策略在文档的其他地方进行了讨论。

最重要的是，Hyperledger Fabric提供了一种独特的强大策略，允许网络和渠道管理员管理策略变化本身!其基本理念是，政策变化是恒定的，无论它发生在组织内部或组织之间，还是由外部监管机构强制实施。例如，新组织可能加入一个通道，或者现有组织可能增加或减少其权限。让我们进一步研究一下更改策略是如何在超级分类帐结构中实现的。

理解的关键点是策略更改是由策略本身内部的策略管理的。修改策略(简称mod_policy)是网络或通道配置中管理更改的第一类策略。让我们举两个简单的例子来说明我们是如何使用mod_policy来管理网络中的变化的!

第一个例子是网络最初建立的时候。此时，只允许组织R4管理网络。实际上，这是通过使R4成为在网络配置NC4中定义的惟一具有网络资源权限的组织来实现的。而且，NC4的mod_policy只提到了R4组织，只允许R4更改这个配置。

然后，我们将网络N演化为允许组织R1管理网络。R4通过将R1添加到通道创建和联合创建的策略中实现了这一点。由于这个更改，R1能够定义联合X1和X2，并创建通道C1和C2。R1在网络配置中对通道和联合体策略具有同等的管理权限。

但是，R4可以通过网络配置为R1授予更多的权力!R4可以将R1添加到mod_policy中，这样R1也可以管理网络策略的变化。

第二个功能比第一个功能强大得多，因为R1现在可以完全控制网络配置NC4!这意味着R1原则上可以从网络中删除R4的管理权限。在实践中，R4将配置mod_policy，以便R4也需要批准更改，或者mod_policy中的所有组织都必须批准更改。可以灵活地使mod_policy尽可能复杂，以支持所需的任何更改过程。

这就是mod_policy的作用——它允许基本配置优雅地演变成复杂的配置。所有这一切都是在所有有关组织的同意下发生的。mod_policy的行为与网络或通道配置中的其他策略一样;它定义了一组允许更改mod_policy本身的组织。

在本小节中，我们只讨论了策略的作用和mod_policy的作用的皮毛。在策略主题中有更详细的讨论，但是现在让我们回到我们完成的网络!

全网络形成

让我们用一致的视觉词汇来概括一下我们的网络。我们稍微重新组织了它使用我们更紧凑的视觉语法，因为它更好地适应更大的拓扑:

在这个图中，我们看到Fabric区块链网络由两个应用程序通道和一个订购通道组成。组织R1和R4负责订购通道，R1和R2负责蓝色应用通道，R2和R3负责红色应用通道。客户端应用程序A1是organization R1的一个元素，而CA1是它的证书颁发机构。请注意，R2组织的对等点P2可以使用蓝色和红色应用程序通道的通信设施。每个应用程序通道都有自己的通道配置，在本例中是CC1和CC2。系统通道的通道配置是网络配置的一部分，即NC4。

我们已经完成了构建一个示例超级分类帐结构区块链网络的概念之旅。我们已经创建了一个包含两个通道和三个对等节点、两个智能契约和一个订购服务的四个组织网络。它由四个证书颁发机构支持。它为三个客户端应用程序提供分类账和智能合同服务，这些客户端应用程序可以通过这两个渠道与它交互。花点时间在图表中浏览一下网络的细节，然后随意地回顾一下主题来巩固你的知识，或者转到更详细的主题。

网络组件概述

下面是我们讨论过的网络组件的快速总结:

• 账本、通道组成区块链和世界状态组成

• 智能合约(又名链码)

• 对等节点

• 排序服务

• 通道

• 证书颁发机构

• 网络摘要

  在本主题中，我们了解了不同的组织如何共享它们的基础设施，以提供一个集成的超级分类帐结构区块链网络。我们已经看到如何将集体基础设施组织成提供独立管理的私有通信机制的通道。我们已经看到了如何通过使用来自各自证书颁发机构的证书来识别来自不同组织的参与者(如客户端应用程序、管理员、对等点和订购者)。反过来，我们也看到了策略对于定义这些组织参与者对网络和渠道资源拥有的一致同意的权限的重要性。

身份

身份是什么？

区块链网络中的不同参与者包括对等点、排序节点、客户机应用程序、管理员等。这些参与者中的每一个——能够消费服务的网络内外的活动元素——都有一个封装在X.509数字证书中的数字身份。这些身份非常重要，因为它们决定了参与者在区块链网络中对资源和信息的访问权限。

此外，数字标识还具有一些附加属性，Fabric使用这些属性来确定权限，并为标识和相关属性的联合提供了一个特殊的名称—principal。主体与userid或groupid类似，但更灵活一些，因为它们可以包含参与者身份的广泛属性，例如参与者的组织、组织单元、角色，甚至参与者的特定身份。当我们讨论主体时，它们是决定其权限的属性。

要使身份可验证，它必须来自可信的权威机构。会员服务提供者(MSP)是Fabric中受信任的权威。更具体地说，MSP是一个组件，它定义了管理该组织的有效身份的规则。Fabric中的默认MSP实现使用X.509证书作为身份，采用传统的公钥基础设施(PKI)层次结构模型(稍后将详细介绍PKI)。

一个简单的场景解释身份

想象你去超市买东西。在结账处，你会看到一个牌子，上面写着只接受Visa卡、万事达卡和美国运通卡。如果你想用另一张卡支付——我们称它为“ImagineCard”——不管这张卡是否真实，你的账户里是否有足够的资金。它将不会被接受。

有一张有效的信用卡是不够的，它还必须被商店接受!PKIs和MSPs以相同的方式一起工作——PKI提供身份列表，MSP表示其中哪些是某个组织的成员，该组织参与了网络。

KI证书颁发机构和MSPs提供了类似的功能组合。PKI就像一个卡供应商——它提供许多不同类型的可验证身份。另一方面，MSP类似于商店接受的信用卡提供者列表，确定哪些身份是商店支付网络的可信成员(参与者)。MSPs将可验证的身份转换为区块链网络的成员。

让我们更详细地研究一下这些概念。

PKI是什么？

公钥基础设施(PKI)是在网络中提供安全通信的internet技术的集合。是PKI将S放到了HTTPS中——如果您在web浏览器上阅读这篇文档，那么您可能正在使用PKI来确保它来自一个经过验证的源。

公开密码匙基础建设(PKI)的要素。PKI由向各方(如服务的用户、服务提供者)颁发数字证书的证书颁发机构组成，这些机构随后使用这些证书在其环境中交换的消息中对自己进行身份验证。CA的证书撤销列表(CRL)构成不再有效的证书的引用。撤销证书的原因有很多。例如，证书可能会被撤销，因为与该证书关联的加密私有材料已经被公开。

虽然区块链网络不仅仅是一个通信网络，它还依赖PKI标准来确保各种网络参与者之间的安全通信，并确保在区块链上发布的消息得到正确的验证。因此，了解PKI的基础知识以及为什么MSPs如此重要是很重要的。

公开密码匙基础建设有四个要素:

• 数字证书

• 公钥和私钥

• 证书颁发机构

• 证书撤销列表

让我们快速描述一下这些PKI基础知识，如果您想了解更多细节，可以从Wikipedia开始。

数字证书

数字证书是持有一组与证书持有者相关属性的文档。最常见的证书类型是符合X.509标准的证书，该标准允许在其结构中对一方的标识细节进行编码。

例如，密歇根州底特律市Mitchell Cars公司制造部门的Mary Morris可能拥有一个主题属性为C=US、ST=Michigan、L=Detroit、O=Mitchell Cars、OU=Manufacturing、CN=Mary Morris /UID=123456的数字证书。玛丽的证书与她的政府身份证类似，提供了有关玛丽的信息，她可以用这些信息来证明有关她的关键事实。在X.509证书中还有许多其他属性，但是现在让我们只关注这些属性。

描述一个叫玛丽·莫里斯的聚会的数字证书。玛丽是证书的主题，突出显示的主题文本显示了关于玛丽的关键事实。如您所见，证书还包含更多的信息。最重要的是，Mary的公钥分布在她的证书中，而她的私钥没有。这个签名密钥必须保持私有。

重要的是，可以使用一种称为密码学的数学技术(字面意思是“秘密写作”)来记录玛丽的所有属性，这样篡改就会使证书失效。只要另一方信任证书颁发方，即所谓的证书颁发机构(CA)，加密技术允许Mary向其他人提供证书来证明自己的身份。只要CA安全地保留某些加密信息(即它自己的私有签名密钥)，任何阅读证书的人都可以确信关于Mary的信息没有被篡改——它将始终具有Mary Morris的那些特定属性。可以将Mary的X.509证书看作是无法更改的数字身份证。

身份验证、公钥和私钥

身份验证和消息完整性是安全通信中的重要概念。身份验证要求交换消息的各方确信创建特定消息的身份。对于具有“完整性”的消息，意味着在其传输期间不能被修改。例如，您可能希望确保正在与真正的Mary Morris进行通信，而不是与模拟人员进行通信。或者，如果玛丽给你发了一条消息，你可能想要确认它在传输过程中没有被任何人篡改。

传统的身份验证机制依赖于数字签名，顾名思义，数字签名允许一方对其消息进行数字签名。数字签名还为签名消息的完整性提供了保证。

从技术上讲，数字签名机制要求每一方持有两个以密码方式连接的密钥:一个作为身份验证锚点广泛使用的公钥，以及一个用于在消息上生成数字签名的私钥。数字签名消息的接收方可以通过检查附加签名在预期发送方的公钥下是否有效来验证接收到的消息的来源和完整性。

私钥和各自的公钥之间的独特关系是使安全通信成为可能的密码术。密钥之间独特的数学关系使得私钥可以用于生成只有对应的公钥可以匹配的消息的签名，并且只能与相同的消息匹配。

在上面的例子中，Mary使用她的私钥对消息进行签名。任何使用她的公钥查看签名消息的人都可以验证签名。

证书颁发机构

正如您所看到的，参与者或节点能够通过系统信任的权威机构为其颁发的数字身份参与到区块链网络中。在最常见的情况下，数字身份(或简单的身份)采用加密验证的数字证书形式，这些证书符合X.509标准，由证书颁发机构(CA)颁发。

ca是internet安全协议的一个常见部分，您可能听说过一些更流行的协议:赛门铁克(原Verisign)、GeoTrust、DigiCert、GoDaddy和Comodo等。

证书颁发机构将证书分发给不同的参与者。这些证书由CA进行数字签名，并将参与者与参与者的公钥绑定在一起(还可以选择使用一个完整的属性列表)。因此，如果信任CA(并且知道它的公钥)，则可以通过验证CA在参与者的证书上的签名来信任特定的参与者绑定到证书中包含的公钥，并拥有包含的属性。

证书可以广泛传播，因为它们既不包括参与者的私钥，也不包括CA的私钥。因此，它们可以用作对来自不同参与者的消息进行身份验证的信任的锚。

CAs也有一个证书，可以广泛使用。这允许给定CA颁发的身份的使用者通过检查证书只能由相应私钥(CA)的持有者生成来验证它们。

在区块链设置中，希望与网络交互的每个参与者都需要一个身份。在这种情况下，您可能会说可以使用一个或多个ca从数字的角度定义组织的成员。CA为组织的参与者提供了一个可验证的数字身份的基础。

根cas、中间cas和信任链

CAs有两种:根CAs和中间CAs。由于Root ca(赛门铁克、Geotrust等)必须向internet用户安全分发数亿个证书，因此有必要将此过程扩展到所谓的中间ca。这些中间CA的证书由根CA或其他中间机构颁发，允许为链中的任何CA颁发的任何证书建立“信任链”。这种能力来追踪回根CA不仅让CAs量表,同时仍然提供安全的功能,允许使用证书的组织使用中间中科院有信心——它限制了根CA的接触,,如果妥协,会危及整个链的信任。另一方面，如果一个中间的CA被破坏，将会有一个小得多的暴露。

在根CA和一组中间CA之间建立信任链，只要为每个中间CA颁发证书的CA是根CA本身，或者是与根CA有信任链。

当涉及到跨多个组织颁发证书时，中间ca提供了巨大的灵活性，这对于经过许可的区块链系统(如Fabric)非常有帮助。例如，您将看到不同的组织可能使用不同的根CA，或者相同的根CA具有不同的中间CA—这确实取决于网络的需要。cale在仍然提供安全性的同时——允许使用证书的组织放心地使用中间CA——它限制了根CA的暴露，如果暴露，将危及整个信任链。另一方面，如果一个中间的CA被破坏，将会有一个小得多的暴露。

框架证书

因为CAs非常重要，所以Fabric提供了一个内置的CA组件，允许您在自己创建的区块链网络中创建CAs。这个组件称为Fabric CA，是一个私有的根CA提供者，能够管理具有X.509证书形式的Fabric参与者的数字身份。因为Fabric CA是针对Fabric的根CA需求的自定义CA，所以它本质上不能为浏览器中的常规/自动使用提供SSL证书。但是，由于必须使用某些CA来管理身份(即使在测试环境中也是如此)，所以Fabric CA可以用于提供和管理证书。也可以使用公共/商业根或中间CA来提供身份验证，这是完全合适的。

如果您感兴趣，可以在CA文档部分阅读更多关于Fabric CA的内容。

证书撤销列表

证书撤销列表(CRL)很容易理解——它只是CA知道由于某种原因需要撤销的证书的引用列表。如果您回想一下商店场景，那么CRL就像一个被盗的信用卡列表。

当第三方想要验证另一方的身份时，它首先检查发出证书的CA的CRL，以确保证书没有被撤销。验证者不需要检查CRL，但是如果他们不这样做，他们就冒着接受一个折衷身份的风险。

使用CRL检查证书是否仍然有效。如果一个模拟程序试图将一个损坏的数字证书传递给验证方，那么可以首先根据发出证书的CA的CRL对其进行检查，以确保它不会被列为不再有效。

请注意，被撤销的证书与到期的证书非常不同。被撤销的证书还没有过期——按照其他任何标准，它们都是完全有效的证书。有关crl的更深入信息，请单击此处。

现在您已经了解了PKI如何通过信任链提供可验证的身份，下一步是了解如何使用这些身份来表示区块链网络中的可信成员。这就是会员制服务提供者(MSP)发挥作用的地方——它标识区块链网络中给定组织的成员。

要了解更多关于会员的信息，请参阅关于MSPs的概念文档。

成员服务提供商（MSP）

为什么需要MSP？

因为Fabric是一个经过许可的网络，所以区块链参与者需要一种方法向网络的其余部分证明自己的身份，以便在网络上进行交易。如果您阅读过关于身份的文档，您就会了解公钥基础设施(PKI)如何通过信任链提供可验证的身份。区块链网络如何使用这个信任链?

证书颁发机构通过生成公钥和私钥来颁发身份，公钥和私钥形成可用于证明身份的密钥对。因为私钥永远不能公开共享，所以需要一种机制来启用这个证明，这就是MSP的作用所在。例如，对等方使用其私钥对事务进行数字签名或签名。订购服务上的MSP包含对等方的公钥，然后用于验证附加到事务上的签名是否有效。私钥用于在事务上生成只有MSP中相应的公钥可以匹配的签名。因此，MSP是一种机制，它允许网络的其余部分信任和识别身份，而不需要暴露成员的私钥。

回想一下身份主题中的信用卡场景，证书颁发机构就像一个卡提供者—它分发许多不同类型的可验证身份。另一方面，MSP决定商店接受哪些信用卡提供商。通过这种方式，MSP将身份(信用卡)转换为角色(在商店购物的能力)。

这种将可验证身份转换为角色的能力是Fabric网络功能的基础，因为它允许组织、节点和通道建立msp，以确定谁可以在组织、节点和通道级别上做什么。

身份类似于你用来证明你可以支付的信用卡。MSP类似于可接受的信用卡列表。

考虑一个由经营区块链网络的银行组成的财团。每个银行操作对等节点和订购节点，并且对等节点认可提交给网络的交易。然而，每家银行也会有部门和账户持有人。帐户持有者将属于每个组织，但不会在网络上运行节点。他们只能通过移动或web应用程序与系统交互。那么网络如何识别和区分这些身份呢?CA被用来创建身份，但是就像卡的例子一样，这些身份不能直接颁发，它们需要被网络识别。MSPs用于定义网络成员信任的组织。MSPs也是向成员提供一组角色和网络权限的机制。因为定义这些组织的MSPs是网络成员所知道的，所以可以使用它们来验证尝试执行操作的网络实体是否被允许执行操作。

最后，考虑一下，如果您想加入一个现有的网络，您需要一种方法来将您的身份转换为网络可以识别的内容。MSP是一种机制，它使您能够参与到允许的区块链网络中。要在织物网络上进行交易，成员需要:

1. 拥有由网络信任的CA颁发的身份。
2. 成为网络成员认可和认可的组织的成员。MSP是如何将身份与组织的成员联系起来的。通过将成员的公钥(也称为证书、签名证书或签名证书)添加到组织的MSP来实现成员身份。
3. 将MSP添加到网络上的联合体或通道中。
4. 确保MSP包含在网络上的策略定义中。

MSP是什么？

尽管它的名字，成员服务提供商实际上不提供任何东西。相反,MSP的实现要求是一组文件夹添加到配置的网络和用于定义一个组织内部(组织决定它的管理员是谁)和外在(通过允许其他组织验证实体有权做他们正在试图做的事情)。虽然证书颁发机构生成代表身份的证书，但是MSP包含允许的身份列表。

MSP通过列出信任域成员的身份，或者通过确定哪些ca被授权为其成员颁发有效身份，来确定哪些根ca和中间ca被接受来定义信任域的成员。

但是，MSP的威力不仅仅是列出谁是网络参与者或某个通道的成员。MSP通过标识参与者在节点或通道上具有的特定特权，将身份转换为角色。请注意，当用户向Fabric CA注册时，管理员、对等方、客户端、排序方或成员的角色必须与该用户关联。例如，使用“同伴”角色注册的身份自然应该被给予同伴。类似地，用“admin”角色注册的身份应该给组织管理员。我们将在本主题的后面部分深入研究这些角色的重要性。

此外，MSP可以允许标识已撤销的身份列表(如身份文档中所讨论的)，但是我们将讨论该过程如何扩展到MSP。

MSP域

在一个区块链网络中，MSPs出现在两个域中:

• 在参与者的节点上本地(本地MSP)

• 通道配置(通道MSP)

本地和通道MSPs之间的关键区别不在于它们如何工作(两者都将身份转换为角色)，而在于它们的范围。每个MSP列出特定管理级别的角色和权限。

本地MSPs

为客户端和节点(对等点和定序点)定义了本地msp。本地MSPs定义节点的权限(例如，可以操作节点的对等管理员)。本地成员服务(上面的账户持有人在银行场景),允许用户进行身份验证本身在其交易作为一个通道(如chaincode交易),或作为一个特定的角色进入系统的所有者等组织管理,例如,在配置事务。

每个节点都必须定义一个本地MSP，因为它定义了在该级别上谁拥有管理或参与权(对等管理员不一定是通道管理员，反之亦然)。这允许在通道上下文之外对成员消息进行身份验证，并定义特定节点上的权限(例如，谁有能力在对等节点上安装chaincode)。请注意，一个组织可以拥有一个或多个节点。MSP定义了组织管理员。组织、组织的管理员、节点的管理员和节点本身都应该具有相同的信任根。

还在节点的文件系统上定义了orderer本地MSP，<u>并且只应用于该节点</u>。与对等节点一样，订货方也由单个组织拥有，因此有单个MSP来列出它信任的参与者或节点。

通道MSPs

相反，通道MSPs在渠道一级定义管理和参与权。应用程序通道上的对等节点和订购节点共享通道MSPs的相同视图，因此能够正确地对通道参与者进行身份验证。这意味着，如果组织希望加入通道，则需要在通道配置中包含包含组织成员信任链的MSP。否则，源自本组织身份的交易将被拒绝。<u>本地MSPs表示为文件系统上的文件夹结构，而通道MSPs则在通道配置中进行描述。</u>

每个节点都必须定义一个本地MSP，因为它定义了在该级别上谁拥有管理或参与权(对等管理员不一定是通道管理员，反之亦然)。这允许在通道上下文之外对成员消息进行身份验证，并定义特定节点上的权限(例如，谁有能力在对等节点上安装chaincode)。请注意，一个组织可以拥有一个或多个节点。MSP定义了组织管理员。组织、组织的管理员、节点的管理员和节点本身都应该具有相同的信任根。

还在节点的文件系统上定义了orderer本地MSP，并且只应用于该节点。与对等节点一样，排序节点也由单个组织拥有，因此有单个MSP来列出它信任的参与者或节点。

通道配置的片段。包含两个组织MSPs的json文件。

通道MSPs确定谁具有通道级别的权限。通道MSP定义了通道成员的身份(它们本身就是MSP)和通道级策略的实施之间的关系。通道MSPs包含通道成员的组织的MSPs。

每个参与渠道的组织都必须为其定义一个MSP。事实上，建议在组织和MSPs之间建立一对一的映射。MSP定义哪些成员被授权代表组织行事。这包括MSP本身的配置，以及批准组织具有角色的管理任务，例如向通道添加新成员。如果所有网络成员都是一个组织或MSP的一部分，那么数据隐私就被牺牲了。多个组织通过将分类帐数据仅隔离给通道成员来促进隐私。如果组织内需要更多的粒度，则可以将组织进一步划分为组织单元(OUs)，我们将在本主题的后面详细描述这些单元。

系统通道MSP包括参与排序服务的所有组织的MSP。排序服务可能包括来自多个组织的订购节点，这些组织共同运行排序服务，最重要的是管理组织联盟和应用程序通道继承的缺省策略。

本地msp仅在其应用到的节点或用户的文件系统上定义。因此，在物理和逻辑上，每个节点只有一个本地MSP。但是，由于通道MSPs对通道中的所有节点都可用，所以在通道配置中对它们进行了一次逻辑定义。但是，通道MSP也在通道中每个节点的文件系统上实例化，并通过consensus保持同步。因此，虽然每个节点的本地文件系统上都有每个通道MSP的副本，但从逻辑上讲，通道MSP驻留在通道或网络上并由通道或网络维护。

下面的图表说明了如何局部化

peer和orderer的MSPs是本地的，而通道(包括网络配置通道，也称为系统通道)的MSPs是全局的，在该通道的所有参与者之间共享。在该图中，网络系统通道由ORG1管理，但是另一个应用程序通道可以由ORG1和ORG2管理。对等体是ORG2的成员，由ORG2管理，而ORG1管理图的排序方。ORG1信任来自RCA1的身份，而ORG2信任来自RCA2的身份。需要注意的是，这些是管理标识，反映了谁可以管理这些组件。当ORG1管理网络时，ORG2。MSP确实存在于网络定义中。

组织在MSP中扮演什么角色?

组织是一组逻辑管理的成员。可以是像跨国公司这样的大公司，也可以是像花店这样的小公司。关于组织(或组织)，最重要的是它们在单一MSP下管理其成员。MSP允许将身份链接到组织。注意，这与前面提到的X.509证书中定义的组织概念不同。

组织与其MSP之间的排他性关系使得以组织的名称命名MSP成为一种明智的做法，在大多数策略配置中都会采用这种约定。例如，组织ORG1可能有一个MSP，称为类似于ORG1-MSP的东西。在某些情况下，组织可能需要多个成员组——例如，通道用于在组织之间执行非常不同的业务功能。在这些情况下，有多个msp并相应地命名是有意义的，例如，ORG2- msp -NATIONAL和ORG2- msp -GOVERNMENT，这反映了与政府管理渠道相比，ORG2在全国销售渠道中的信任的不同成员根。

组织单元(OUs)和MSPs

　　一个组织也可以被分成多个组织单元，每个单元都有一组特定的职责，也称为从属关系。将OU看作组织内部的一个部门。例如，ORG1组织可能同时拥有两个ORG1。制造业和ORG1。分配必须反映这些不同的业务部门。当CA发出X.509证书时，证书中的OU字段指定标识所属的业务部门。这样使用OUs的一个好处是，这些值可以用于策略定义来限制访问，或者用于基于属性的访问控制的智能契约。否则，需要为每个组织创建单独的MSPs。

　　指定OUs是可选的。如果不使用OUs，属于MSP的所有标识(由根CA和中间CA文件夹标识)都将被视为组织的成员。

节点OU角色和MSPs

此外，还有一种特殊的OU，有时称为节点OU，可用于赋予身份一个角色。这些节点OU角色在$FABRIC_CFG_PATH/msp/config中定义。yaml文件，并包含组织单元的列表，这些组织单元的成员被认为是此MSP所代表的组织的一部分。当您希望将组织的成员限制为具有特定节点OU角色的身份(由MSP指定的ca之一签名)的成员时，这尤其有用。例如，使用node OU，您可以实现一个更细粒度的背书策略，该策略要求Org1对等点背书一个事务，而不是任何Org1成员。

为了使用节点OU角色，必须为网络启用“身份分类”特性。当使用基于文件夹的MSP结构时，这是通过在配置中启用“Node OUs”来实现的。位于MSP文件夹的根目录下的yaml文件:

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: orderer

在上面的例子中，MSP有4种可能的节点OU角色:

• client

• peer

• admin

• orderer

  这个约定允许您通过X509证书的CommonName属性中的OU来区分MSP角色。上面的示例说明由cacerts/ca.sampleorg-cert颁发的任何证书。在pem中，OU=client将被标识为client, OU=peer将被标识为peer，等等。从Fabric v1.4.3开始，还有一个供订货人和管理员使用的OU。新的管理员角色意味着您不再需要显式地将certs放在MSP目录的admincerts文件夹中。相反，用户的signcert中的“admin”角色将身份限定为admin用户。

  当Fabric CA或SDK用于向CA“注册”用户时，这些角色和OU属性被分配给一个标识。随后的“注册”用户命令在用户 的“/msp”文件夹中生成证书。

角色结果和OU属性在/signcerts文件夹中的X.509签名证书中可见。角色属性被标识为hf。类型和指的是参与者在组织中的角色(例如，指定参与者是对等体)。下面的签名证书片段显示了角色和ou在证书中是如何表示的

注意:对于通道MSPs，仅仅因为参与者扮演管理员的角色，并不意味着他们可以管理特定的资源。给定标识在系统管理方面的实际权力由管理系统资源的策略决定。例如，通道策略可以指定ORG1-MANUFACTURING管理员，即具有admin角色和ORG1-MANUFACTURING节点OU的身份，有权将新组织添加到通道中，而ORG1-DISTRIBUTION管理员没有这种权利。

最后，在联盟中不同的组织可以使用OUs来区分彼此。但是在这种情况下，不同的组织必须使用相同的根ca和中间ca作为它们的信任链，并分配OU字段来标识每个组织的成员。当每个组织都具有相同的CA或信任链时，这将使系统更加集中化，因此值得在区块链网络上仔细考虑。

MSP结构

让我们来研究一下呈现我们到目前为止所描述的功能的MSP元素。

本地MSP文件夹包含以下子文件夹:

上图显示了文件系统上本地MSP中的子文件夹

• 配置。yaml:通过启用“Node OUs”并定义可接受的角色来配置Fabric中的身份分类特性。

• cacerts:这个文件夹包含一个自签名的X.509证书列表，这些证书是这个MSP所代表的组织所信任的根ca的证书。在这个MSP文件夹中必须至少有一个根CA证书。

　　这是最重要的文件夹，因为它标识了其他所有证书都必须来自的ca，其他所有证书都必须从中派生，才能被认为是相应组织的成员，从而形成信任链。

• intermediatecerts:此文件夹包含组织信任的中级ca的X.509证书列表。每个证书必须由MSP中的一个根CA或任何中间CA进行签名，其发出的CA链最终会返回到一个受信任的根CA。

　中间CA可以表示组织的不同分支(如ORG1的ORG1制造和ORG1分发)，也可以表示组织本身(如利用商业CA进行组织的身份管理)。在后一种情况下，可以使用中间ca来表示组织的分支。在这里，您可以找到关于MSP配置的最佳实践的更多信息。请注意，可能有一个没有中间CA的正常网络，在这种情况下，此文件夹将为空。

　与根CA文件夹一样，此文件夹定义必须从其中颁发证书才能被视为组织成员的CA。

• admincerts(从Fabric v1.4.3及更高版本中弃用):此文件夹包含一个身份列表，其中定义了扮演组织管理员角色的参与者。通常，这个列表中应该有一个或多个X.509证书。

注意:在Fabric v1.4.3之前，管理员的定义是显式地将certs放在您的同级的本地MSP目录中的admincerts文件夹中。对于Fabric v1.4.3或更高版本，不再需要此文件夹中的证书。相反，建议在用户向CA注册时，使用admin角色来指定节点管理员。然后，身份被其signcert中的节点OU角色值识别为admin。提醒一下，为了利用管理员角色，必须在配置中启用“身份分类”功能。以上通过设置“节点OUs”使:真。稍后我们将对此进行更多的探讨。

提醒一下，对于通道MSPs，仅仅因为参与者扮演管理员的角色，并不意味着他们可以管理特定的资源。给定标识在系统管理方面的实际权力由管理系统资源的策略决定。例如，通道策略可能指定ORG1-MANUFACTURING管理员有向通道添加新组织的权利，而ORG1-DISTRIBUTION管理员没有这样的权利。

• keystore:(私钥)此文件夹是为对等点或订制者节点(或客户端的本地MSP)的本地MSP定义的，并包含节点的私钥。此键用于对数据进行签名——例如，作为背书阶段的一部分，对事务建议响应进行签名。

此文件夹对于本地MSPs是必需的，并且必须恰好包含一个私钥。显然，对该文件夹的访问必须仅限于对对等方负有管理责任的用户的身份。

通道MSP配置不包括此文件夹，因为通道MSP的唯一目标是提供身份验证功能，而不是签名功能。

注意:如果您使用硬件安全模块(HSM)进行密钥管理，则此文件夹为空，因为私钥是由HSM生成并存储在HSM中。

• signcert:对于对等节点或订单节点(或客户端的本地MSP)，此文件夹包含节点的签名密钥。此密钥以密码方式与节点标识文件夹中包含的节点标识匹配，并用于对数据进行签名——例如，作为背书阶段的一部分，对事务建议响应进行签名。

　　此文件夹对于本地MSPs是必需的，并且必须恰好包含一个公钥。显然，对该文件夹的访问必须仅限于对对等方负有管理责任的用户的身份。

通道MSP的配置不包括此文件夹，因为通道MSP的唯一目标是提供身份验证功能，而不是签名功能。

• tlscacerts:此文件夹包含本组织信任的根ca的自签名X.509证书列表，用于在使用TLS的节点之间进行安全通信。TLS通信的一个例子是，当一个对等点需要连接到一个定序器，以便它能够接收分类帐更新。

MSP TLS信息与网络内的节点相关——即节点和订购者，换句话说，而不是使用网络的应用程序和管理。

此文件夹中必须至少有一个TLS根CA证书。有关TLS的更多信息，请参见使用传输层安全性(TLS)保护通信。

• tlsintermediatecacerts:此文件夹包含一个中间CA证书列表，这些证书由MSP表示的组织信任，用于使用TLS在节点之间进行安全通信。当一个组织的TLS证书使用商业ca时，此文件夹特别有用。与成员中间CAs类似，指定中间TLS CAs是可选的。

• operationscerts:此文件夹包含与Fabric操作服务API通信所需的证书。

一个通道MSP包括以下额外的文件夹:

• 已撤销的证书:如果某个参与者的身份已被撤销，有关该身份(而不是身份本身)的标识信息将保存在此文件夹中。对于基于x .509的身份，这些标识符是称为主题键标识符(SKI)和权限访问标识符(AKI)的字符串对，每当使用证书时，都会检查这些标识符，以确保证书没有被撤销。

　　此列表在概念上与CA的证书撤销列表(Certificate Revocation list, CRL)相同，但它也涉及从组织中撤销成员资格。因此，通道MSP的管理员可以通过发布CA更新后的CRL，从组织中快速撤销参与者或节点。这个“列表中的列表”是可选的。它只会在证书被撤销时才会被填充。

　　如果你已经阅读了这个文档以及我们关于身份的文档，你现在应该对身份和msp如何在超账本结构中工作有了很好的理解。您已经了解了如何使用PKI和MSPs来识别在区块链网络中协作的参与者。除了学习了MSPs的物理和逻辑结构之外，您还了解了证书、公钥/私钥和信任根是如何工作的。

策略

**目标读者：**架构师、开发者、管理员

在本主题中，我们将讨论:

• 什么是策略

• 为什么需要策略

• 如何在整个Fabric中实现策略

• 结构策略域

• 如何在Fabric中编写策略

• 织物chaincode生命周期

• 覆盖策略定义

策略是什么？

在最基本的层次上，策略是一组规则，它们定义了如何决策和实现特定结果的结构。为此，策略通常描述谁和什么，例如个人对资产的访问权或权利。我们可以看到，策略在我们的日常生活中被用来保护对我们有价值的资产，从汽车租赁、健康、我们的家，以及更多。

例如，保险单定义了保险支付的条件、条款、限制和到期期限。本保险单经投保人和保险公司同意，并规定了双方的权利和责任。

在超级账本结构中，保单用于风险管理，而保单是用于基础设施管理的机制。Fabric策略表示成员如何就接受或拒绝对网络、通道或智能契约的更改达成一致。当网络最初配置时，策略由联盟成员同意，但是它们也可以随着网络的发展而修改。例如，它们描述了从通道添加或删除成员的标准、更改块的形成方式或指定签署智能契约所需的组织数量。所有这些操作都由一个策略描述，该策略定义了谁可以执行这些操作。简单地说，您想在Fabric网络上做的所有事情都由策略控制。

为什么策略是必须的？

策略是使超级账本结构不同于其他区块链如Ethereum或比特币的因素之一。在这些系统中，可以由网络中的任何节点生成和验证事务。管理网络的策略在任何时候都是固定的，并且只能使用管理代码的相同进程来更改。由于Fabric是经过许可的区块链，其用户得到底层基础设施的认可，因此这些用户能够在网络启动之前决定对其进行治理，并更改正在运行的网络的治理。

策略允许成员决定哪些组织可以访问或更新Fabric网络，并提供执行这些决策的机制。策略包含可以访问给定资源(如用户或系统链码)的组织的列表。它们还指定需要多少组织就更新资源(如通道或智能契约)的建议达成一致。一旦它们被编写，策略将评估附加到事务和提案的签名集合，并验证签名是否满足网络同意的治理

如何在整个Fabric中实现策略

策略在Fabric网络的不同级别上实现。每个策略域管理网络操作的不同方面。

Fabric策略层次结构的可视化表示。

系统通道配置

每个网络都从一个订购系统通道开始。对于订购服务，必须有一个订购系统通道，并且它是要创建的第一个通道。系统通道还包含订购服务的成员组织(订购组织)和通过网络进行交易的组织(联盟组织)。

订购系统通道配置块中的策略控制订购服务使用的一致性，并定义如何创建新块。系统渠道还管理着允许联合体的哪些成员创建新渠道。

应用程序通道配置

应用程序通道用于在联合体中的组织之间提供私有通信机制。

应用程序通道中的策略控制从通道中添加或删除成员的能力。应用程序通道还控制了在使用Fabric chaincode的生命周期定义和提交chaincode到通道之前，需要哪些组织批准chaincode。在最初创建应用程序通道时，默认情况下，它将从orderer系统通道中继承所有订购服务参数。但是，可以在每个通道中定制这些参数(以及控制它们的策略)。

访问控制列表(acl)

网络管理员将对acl的结构使用特别感兴趣，acl提供了通过将这些资源与现有策略关联来配置对资源的访问的能力。这些“资源”可以是系统链码上的函数(例如，“qscc”系统链码上的“GetBlockByNumber”)或其他资源(例如，谁可以接收块事件)。acl引用在应用程序通道配置中定义的策略，并扩展它们以控制其他资源。Fabric acl的默认集在configtx中是可见的。在Application: &ApplicationDefaults部分中的yaml文件，但是它们可以并且应该在生产环境中被覆盖。configtx中命名的资源列表。yaml是Fabric当前定义的所有内部资源的完整集合。

在该文件中，acl使用以下格式表示:

# ACL policy for chaincode to chaincode invocation
peer/ChaincodeToChaincode: /Channel/Application/Readers

其中，peer/ChaincodeToChaincode表示被保护的资源，/Channel/Application/Readers表示必须满足的策略，关联事务才能被认为是有效的。

要更深入地研究acl，请参阅关于acl的操作指南中的主题。

智能合约签注政策

chaincode包中的每个智能契约都有一个背书策略，该策略指定属于不同通道成员的多少个对等点需要根据给定的智能契约执行和验证一个事务，以使该事务被认为是有效的。因此，背书策略定义了那些必须“背书”的组织(通过他们的同伴)。建议的执行。

修改政策

最后一种类型的策略对策略在Fabric中的工作方式至关重要，即修改策略。修改策略指定签署(批准)任何配置更新所需的身份组。定义如何更新策略的是策略。因此，每个通道配置元素都包含一个对策略的引用，该策略控制其修改。

Fabric策略域

虽然Fabric策略是灵活的，可以进行配置以满足网络的需求，但是策略结构自然会导致由订购服务组织或联盟成员控制的域之间的划分。在下面的关系图中，您可以看到默认策略是如何实现对Fabric策略域的控制的。

更详细地查看由定序组织和联盟组织治理的策略域。

一个功能齐全的组织网络可以包含许多不同职责的组织。通过允许订购服务的创建者能够建立初始规则和联盟的成员关系，域提供了将不同的特权和角色扩展到不同组织的能力。它们还允许加入联盟的组织创建专用的应用程序通道，管理它们自己的业务逻辑，并限制对放在网络上的数据的访问。

系统通道配置和每个应用程序通道配置的一部分为订购组织提供了对哪些组织是联合成员、如何将块交付给通道以及订购服务节点使用的协商一致机制的控制。

系统通道配置为联盟成员提供了创建通道的能力。应用程序通道和acl是财团组织用于从通道添加或删除成员并限制对通道上的数据和智能契约的访问的机制。

结构中编写策略

如果您希望更改Fabric中的任何内容，则与资源关联的策略将描述需要批准它的人员，可以使用来自个人的显式签名，也可以使用组的隐式签名。在保险领域，一个明确的签字可以是业主保险代理集团的一个单一成员。暗示性的批准类似于需要得到业主保险集团大多数管理成员的批准。这特别有用，因为该组的成员可以随时间改变，而不需要更新策略。在超账本结构中，策略中的显式签名使用签名语法表示，隐式签名使用隐式元语法表示。

策略签名

签名策略定义特定类型的用户，这些用户必须签名才能满足策略，如Org1。对等或Org2.Peer。这些策略被认为是最通用的，因为它们允许构造非常具体的规则，比如:“一个org A的管理员和2个其他管理员，或者6个组织管理员中的5个”。语法支持AND、OR和NOutOf的任意组合。例如，可以使用AND (Org1, Org2)轻松地表示策略，这意味着需要来自至少一个Org1成员和一个Org2成员的签名才能满足策略。

隐藏签名

ImplicitMeta策略只在基于配置树中策略层次结构的通道配置上下文中有效。ImplicitMeta策略在配置树的更深处聚合策略的结果，配置树最终由签名策略定义。它们是隐式的，因为它们是隐式地基于通道配置中的当前组织构造的，它们是元的，因为它们的评估不是针对特定的MSP主体，而是针对配置树中低于它们的其他子策略。

下图演示了为应用程序分层政策结构通道和显示了ImplicitMeta通道配置管理员政策,名叫/通道/管理员,下面解决当sub-policies命名管理员在配置层次结构满足每个复选标记代表sub-policy的条件被满足。

如上图所示，ImplicitMeta policy, Type = 3，使用了不同的语法，“<ANY|ALL|MAJORITY> <SubPolicyName>”，例如:

MAJORITY sub policy: Admins

该图显示了一个子策略管理员，它在配置树中引用它下面的所有管理员策略。您可以创建自己的子策略并随意命名它们，然后在每个组织中定义它们。

如上所述，ImplicitMeta策略(如多数管理员)的一个主要好处是，当您向通道添加一个新的管理组织时，您不必更新通道策略。因此，随着联盟成员的变化，隐含元策略被认为更加灵活。当添加新成员或现有成员离开时，订单方的联盟可以更改，但不需要进行策略更新。回想一下，ImplicitMeta策略最终会在配置树中解析它们下面的签名子策略，如图所示。

您还可以定义一个应用程序级隐式策略来跨组织(例如，在一个通道中)进行操作，并要求满足其中任何一个需求，满足所有需求，或者满足大多数需求。这种格式可以提供更好的、更自然的默认值，因此每个组织都可以决定它对于有效的背书意味着什么。

如果在组织定义中包含NodeOUs，则可以实现进一步的粒度和控制。组织单元(OUs)是在Fabric CA客户端配置文件中定义的，在创建时可以与标识相关联。在Fabric中，NodeOUs提供了在数字证书层次结构中对身份进行分类的方法。例如，一个启用了特定节点的组织可能需要一个“对等点”签名才能成为有效的背书，而没有“对等点”的组织可能只要求任何成员都可以签名。

例子：通道策略

理解策略首先要检查configtx。其中定义了通道策略。我们可以使用configtx。以查看这两种策略语法类型的示例。我们将检查configtx。用于织物样品/测试网络样品的yaml文件。

文件的第一部分定义了网络的组织。在每个组织定义中都有该组织、读者、作者、管理员和背书的默认策略，尽管您可以随意命名策略。每个策略都有一个类型来描述策略是如何表示的(签名或隐含元)和一个规则。

下面的测试网络示例显示了系统通道中的Org1组织定义，其中策略类型为Signature，背书策略规则定义为“OR('Org1MSP.peer')”。此策略指定需要是Org1MSP成员的对等方进行签名。这些签名策略成为隐含元策略所指向的子策略。

 - &Org1
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org1MSP

        # ID to load the MSP definition as
        ID: Org1MSP

        MSPDir: crypto-config/peerOrganizations/org1.example.com/msp

        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org1MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org1MSP.peer')"

下一个示例显示了configtxt .yaml的应用程序部分中使用的ImplicitMeta策略类型。这些策略集位于/通道/应用程序/路径上。如果使用默认的Fabric acl集，这些策略将定义应用程序通道的许多重要特性的行为，例如谁可以查询通道分类帐、调用chaincode或更新通道配置。这些策略指向为每个组织定义的子策略。在上述部分中定义的Org1包含由应用程序部分中的Reader、Writer和Admin子策略评估的Reader、Writer和Admin ImplicitMeta策略。因为测试网络是使用默认策略构建的，所以您可以使用示例Org1来查询通道分类账、调用chaincode并批准您所创建的任何测试网络通道的通道更新。

################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults

    # Organizations is the list of orgs which are defined as participants on
    # the application side of the network
    Organizations:

    # Policies defines the set of policies at this level of the config tree
    # For Application policies, their canonical path is
    #   /Channel/Application/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

账本链码生命周期

在Fabric 2.0版本中，引入了一个新的chaincode生命周期过程，其中使用了一个更民主的过程来管理网络上的chaincode。新流程允许多个组织在链码在渠道上使用之前，对链码的操作方式进行投票。这一点非常重要，因为正是这个新的生命周期流程和在该流程中指定的策略的组合决定了整个网络的安全性。关于流的更多细节可以在Fabric chaincode lifecyle概念主题中找到，但是出于本主题的目的，您应该了解如何在此流中使用策略。新流包括两个指定策略的步骤:当组织成员批准chaincode时，以及当它提交到通道时。

configtx的应用程序部分。yaml文件包含默认的chaincode生命周期背书策略。在生产环境中，您可以为自己的用例定制这个定义。

################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults

    # Organizations is the list of orgs which are defined as participants on
    # the application side of the network
    Organizations:

    # Policies defines the set of policies at this level of the config tree
    # For Application policies, their canonical path is
    #   /Channel/Application/<PolicyName>
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

• 生命周期cle背书策略管理谁需要批准链式代码定义。

• 背书策略是chaincode的默认背书策略。下面将对此进行详细介绍。

Chaincode支持政策

当使用Fabric chaincode生命周期(即，一个背书策略覆盖与chaincode关联的所有状态)批准并提交给通道时，为chaincode指定背书策略。背书策略可以通过引用通道配置中定义的背书策略来指定，也可以通过显式指定签名策略来指定。

如果背书政策没有显式地指定在批准步骤中,默认支持政策“多数支持”这意味着多数同行属于不同的渠道成员(组织)需要执行和验证一个事务对chaincode为了交易被认为是有效的。这个默认策略允许加入通道的组织自动添加到chaincode背书策略中。如果您不想使用默认的背书策略，那么可以使用签名策略格式来指定更复杂的背书策略(例如要求一个组织对一个chaincode进行背书，然后在通道上对另一个组织进行背书)。

签名策略还允许您包含一些主体，它们只是将身份与角色匹配的一种方式。主体与用户id或组id类似，但它们更通用，因为它们可以包含参与者身份的广泛属性，例如参与者的组织、组织单元、角色，甚至参与者的特定身份。当我们讨论主体时，它们是决定其权限的属性。主体被描述为“MSP”。角色'，其中MSP表示所需的MSP ID(组织)，而角色表示所接受的四个角色之一:成员、管理员、客户端和同级。当用户注册一个CA时，角色与标识相关联。您可以自定义Fabric CA上可用的角色列表。

以下是一些有效的原则:

• “Org0。管理:一个管理员的Org0 MSP

• “Org1。成员:组织MSP的成员

• “Org1。客户端:Org1 MSP的客户端

• “Org1。同伴:一个MSP的同伴

• “OrdererOrg。Orderer ': OrdererOrg MSP中的一个Orderer

在某些情况下，特定的状态(换句话说，特定的键值对)可能需要使用不同的背书策略。这种基于状态的背书允许指定键的不同策略覆盖默认的chain代码级背书策略。

要更深入地了解如何编写背书策略，请参考操作指南中有关背书策略的主题。

注意:根据您使用的是哪种版本的Fabric，策略的工作方式会有所不同:

在2.0之前的Fabric版本中，chaincode背书策略可以在chaincode实例化期间或通过使用chaincode生命周期命令进行更新。如果在实例化时未指定，背书策略默认为“通道中组织的任何成员”。例如，具有“Org1”和“Org2”的通道的默认背书策略是“OR(' Org1 ')”。”、“Org2.member”)”。

从Fabric 2.0开始，Fabric引入了新的chaincode生命周期过程，允许多个组织在chaincode在通道上使用之前就如何操作它达成一致。新流程要求组织同意定义链代码的参数，如名称、版本和链代码背书策略。

覆盖策略定义

Hyperledger Fabric包含了默认的策略，这些策略对于区块链的启动、开发和测试都是有用的，但是它们必须在生产环境中进行定制。您应该知道configtx中的默认策略。yaml文件。除了config .yaml中的默认读取器、写入器和管理员之外，通道配置策略可以使用任意谓词进行扩展。当您通过编辑configtx来覆盖默认策略时，orderer系统和应用程序通道会通过发出配置更新来覆盖。用于orderer系统通道或configtx的yaml。一个特定通道的yaml。

有关更多信息，请参阅有关更新通道配置的主题。

私有数据

什么是私有数据？

在某个通道上的一组组织需要对该通道上的其他组织保持数据私有的情况下，它们可以选择创建一个新通道，其中只包含需要访问数据的组织。但是，在每种情况下创建单独的通道会产生额外的管理开销(维护chaincode版本、策略、MSPs等)，并且不允许在保持部分数据私有的情况下，希望所有通道参与者都看到事务的用例。

​ 这就是为什么Fabric提供了创建私有数据集合的功能，它允许通道上定义的组织子集在不必创建单独通道的情况下支持、提交或查询私有数据。

什么是私有数据集合？

集合是两个元素的组合:

1. 实际的私有数据，通过gossip协议发送到只有被授权查看它的组织的点对点。此数据存储在授权组织的对等点上的私有状态数据库中，可以从这些授权对等点上的chaincode访问这些数据库。这里不涉及排序服务，也看不到私有数据。注意，由于gossip将私有数据点对点分发到授权的组织中，因此需要在通道上设置锚点，并在每个节点上配置CORE_PEER_GOSSIP_EXTERNALENDPOINT，以便引导跨组织通信。
2. 该数据的一个散列，它被认可、排序并写入到通道上每个对等点的总账中。散列用作事务的证据，用于状态验证，可用于审计目的。

下图说明了被授权拥有私有数据的对等方和没有被授权拥有私有数据的对等方的分类账内容。

如果集合成员陷入争端或希望将资产转移给第三方，则他们可以决定与其他方共享私有数据。然后，第三方可以计算私有数据的散列，并查看它是否与通道分类账上的状态匹配，从而证明在某个时间点上集合成员之间存在状态。

在某些情况下，您可能决定拥有一组集合，每个集合由单个组织组成。例如，一个组织可能在其自己的集合中记录私有数据，这些数据稍后可以与其他通道成员共享，并在chaincode事务中引用。我们将在下面的共享私有数据主题中看到这样的例子。

什么时候在通道内使用集合，什么时候使用单独的通道

• 当整个交易(和总账)必须在一组属于渠道成员的组织中保密时，使用渠道。

• 当事务(和分类账)必须在一组组织之间共享，但只有这些组织的一个子集可以访问事务中的部分(或全部)数据时，使用集合。此外，由于私有数据是通过点对点(而不是通过块)传播的，所以当必须对订购服务节点的事务数据保密时，应该使用私有数据集合。

解释集合的用例

假设有五个组织在一个渠道上交易产品:

• 一个农民把他的货物卖到国外

• 将货物运往国外的分销商

• 在双方之间运送货物的托运人

• 批发商从分销商那里购买商品

• 向托运人和批发商购买货物的零售商

分销商可能希望与农场主和发货人进行私人交易，以对批发商和零售商保密交易条款(以免暴露他们收取的加价)。

分销商可能还希望与批发商建立单独的私有数据关系，因为它向批发商收取的价格比零售商低。

批发商可能还希望与零售商和托运人建立私有数据关系。

不是为每个关系定义许多小通道，而是可以定义多个私有数据集合(PDC)来在以下之间共享私有数据:

• 分销商、农民和发货人

• 分销商和批发商

• 批发商、零售商和发货人

使用此示例，分销商拥有的对等点将在其分类帐中拥有多个私有数据库，其中包括来自分销商、农民和托运人关系以及分销商和批发商关系的私有数据。

带有私有数据的事务流

当在chaincode中引用私有数据集合时，为了保护私有数据的机密性，在交易被提议、认可并提交到分类帐时，交易流略有不同。

有关不使用私有数据的事务流的详细信息，请参阅我们关于事务流的文档。

1. 客户端应用程序提交一个调用chaincode函数(读取或写入私有数据)的建议请求，以支持作为集合的授权组织一部分的对等点。私有数据，或用于在chaincode中生成私有数据的数据，被发送到提案的一个临时字段中。
2. 背书的对等点模拟事务并将私有数据存储在一个临时数据存储中(一个对对等点本地的临时存储)。他们根据收集策略，通过信道将私有数据分发给授权的对等方。
3. 认可方将提案响应发送回客户端。提案响应包括已批准的读/写集，其中包括公共数据，以及任何私有数据键和值的散列。没有将私有数据发送回客户机。有关背书如何处理私有数据的更多信息，请单击此处。
4. 客户端应用程序将事务(其中包括带有私有数据散列的建议响应)提交给排序服务。具有私有数据哈希的事务像往常一样包含在块中。带有私有数据哈希的块被分发给所有的对等点。通过这种方式，通道上的所有对等点都可以用私有数据的散列以一致的方式验证事务，而不需要知道实际的私有数据。
5. 在块提交时，被授权的对等点使用收集策略来确定它们是否被授权访问私有数据。如果他们这样做了，他们将首先检查他们的本地暂态数据存储，以确定他们是否已经在chaincode背书时收到了私有数据。如果没有，它们将尝试从另一个已授权的对等点获取私有数据。然后，他们将根据公共块中的散列验证私有数据，并提交事务和块。在验证/提交之后，私有数据被移动到私有状态数据库和私有写集存储的副本中。然后从暂态数据存储中删除私有数据。

共享私有数据

在许多场景中私有数据键/值在一个集合可能需要与其他渠道成员或与其他共享私有数据集合,例如当您需要办理私人数据与渠道成员或集团的渠道成员并不包括在原来的私人数据收集。作为事务的一部分，接收方通常希望根据链上散列验证私有数据。

有几个方面的私人数据收集，使共享和验证的私人数据:

• 首先，只要满足背书策略，您不必成为集合的成员才能向集合中的键写入。背书策略可以在chaincode级别、关键级别(使用基于状态的背书)或集合级别(从Fabric v2.0开始)定义。

• 其次，从v1.4.2开始，有一个chaincode API GetPrivateDataHash()，它允许非成员对等节点上的chaincode读取私钥的散列值。这是一个重要的特性，稍后您将看到，因为它允许chaincode根据在以前事务中从私有数据创建的链上散列来验证私有数据。

  在设计应用程序和相关的私有数据集合时，应该考虑这种共享和验证私有数据的能力。虽然您当然可以创建一组多边私有数据集合，以便在通道成员的各种组合之间共享数据，但是这种方法可能会导致需要定义大量的集合。或者，考虑使用较少数量的私有数据集合(例如，每个组织一个集合，或者每个组织对一个集合)，然后根据需要与其他通道成员或其他集合共享私有数据。从Fabric v2.0开始，隐式的特定于组织的集合可用于任何chaincode，因此在部署chaincode时甚至不必定义这些针对每个组织的集合。

私有数据共享模式

在对每个组织的私有数据收集建模时，可以使用多个模式来共享或传输私有数据，而不需要定义许多多边收集。下面是一些可以在chaincode应用程序中使用的共享模式:

• 使用一个对应的公钥来跟踪公共状态——您可以选择使用一个匹配的公钥来跟踪公共状态(例如，资产属性、当前所有权)。等等)，对于每个应该访问资产的相应私有数据的组织，您可以在每个组织的私有数据集合中创建一个私有密钥/值。

• Chaincode访问控制——可以在Chaincode中实现访问控制，以指定哪些客户端可以查询集合中的私有数据。例如，存储私有数据收集键或键范围的访问控制列表，然后在chaincode中获取客户端提交者的凭据(使用GetCreator() chaincode API或CID库API GetID()或GetMSPID())，并在返回私有数据之前验证它们具有访问权。类似地，为了访问私有数据，您可以要求客户端将一个口令传递给chaincode，而chaincode必须与存储在密钥级别的口令匹配。注意，此模式还可用于限制客户端对公共状态数据的访问。

• 共享带外私有数据——作为一个off-chain选项，您可以与其他组织共享带外私有数据，并且他们可以使用GetPrivateDataHash() chaincode API对键/值进行散列，以验证它是否与链上散列匹配。例如，希望从您那里购买资产的组织可能希望在同意购买之前，通过检查链上散列来验证资产的属性，并确认您是合法的所有者。

• 与其他集合共享私有数据——您可以使用chaincode在其他组织的私有数据集合中创建匹配的键/值来“共享”链上的私有数据。您可以通过瞬态字段将私有数据键/值传递给chaincode，而chaincode可以使用GetPrivateDataHash()确认传递的私有数据的散列与来自您的集合的on-chain散列匹配，然后将私有数据写入另一个组织的私有数据集合。

• 将私有数据传输到其他集合——您可以使用chaincode“传输”私有数据，从而删除集合中的私有数据键，并在另一个组织的集合中创建它。同样，在调用chaincode时使用transient字段来传递私有数据，在chaincode中使用GetPrivateDataHash()来确认数据存在于您的私有数据集合中，然后从您的集合中删除密钥并在另一个组织的集合中创建密钥。为了确保交易总是从一个集合中删除并添加到另一个集合中，您可能希望要求来自其他方(如监管机构或审计机构)的认可。

• 使用私有数据事务审批——如果你想要一个交易对手方的批准之前完成(例如一个链上记录,他们同意购买资产在一定价格),chaincode可以要求他们提前审批事务,通过私钥写入他们的私人数据收集或收集,chaincode将然后检查使用GetPrivateDataHash ()。实际上，这与内建的生命周期系统chaincode用于确保组织在提交给通道之前同意chaincode定义的机制完全相同。从Fabric v2.0开始，此模式通过集合级别的背书策略变得更加强大，以确保链代码在集合所有者自己的可信对等节点上执行和背书。或者，可以使用具有键级背书策略的相互同意的密钥，然后使用预先批准条款对其进行更新，并对来自所需组织的对等节点进行背书。

• 保持事务私有——先前模式的变体还可以消除给定事务的事务泄漏。例如，买方表示同意在其自己的收集上购买，然后在随后的交易中，卖方在其自己的私有数据收集中引用买方的私有数据。使用散列引用的交易证明被记录在链上，只有买方和卖方知道他们是交易方，但是如果出现需要知道的情况，他们可以显示预先图像，例如在随后与另一方进行的交易中，另一方可以验证散列。

结合上面的模式，值得注意的是，使用私有数据的事务可以绑定到与常规通道状态数据相同的条件，具体来说:

• 关键级别的事务访问控制——您可以在私有数据值中包含所有权凭证，以便后续事务可以验证提交者拥有共享或传输数据的所有权特权。在这种情况下,chaincode会提交者的凭证(例如使用GetCreator () chaincode API或CID库API GetID()或GetMSPID()),把它与其他私人数据传递到chaincode,散列,并使用GetPrivateDataHash()来验证它与链上散列在继续之前的交易。

• 关键水准的支持策略,并与正常通道状态数据,您可以使用基于状态支持指定哪个组织必须支持事务共享或转移私有数据,使用SetPrivateDataValidationParameter () chaincode API,例如指定只有一个所有者的组织同行,托管人的组织同行或其他第三方必须支持此类交易。

示例场景:使用私有数据集合的资产转移

可以将上面提到的私有数据共享模式组合起来，以支持强大的基于链式代码的应用程序。例如，考虑如何使用每个组织的私有数据集合实现资产转移场景:

• 资产可以通过公共链码状态下的UUID键进行跟踪。只有资产的所有权被记录下来，对资产的其他信息一无所知。

• 链码要求任何转移请求必须来自拥有它的客户端，密钥由基于状态的背书约束，要求来自所有者组织和监管机构组织的对等方必须认可任何转移请求。

• 资产所有者的私有数据集合包含关于资产的私有详细信息，由UUID的散列键控。其他组织和订购服务将只看到资产详细信息的散列。

让我们假设调控器也是每个集合的成员，因此保留私有数据，尽管不一定是这样。

交易该资产的交易将如下展开:

1. 链外，所有者和一个潜在的买家达成交易，以一定的价格交易资产。
2. 卖方提供其所有权的证明，方法是将私有详细信息传递给带外，或者向买方提供凭据来查询其节点或监管节点上的私有数据。
3. 买方验证私有详细信息的散列与链上的公共散列匹配。
4. 买方调用chaincode在自己的私有数据收集中记录他们的投标细节。链码在买方的同行上调用，如果收集背书策略需要，可能在监管机构的同行上调用。
5. 当前所有者(卖方)调用chaincode来出售和转让资产，并传递私有细节和投标信息。对卖方、买方和监管机构的对等方调用chaincode，以满足公钥的背书策略，以及买方和卖方私有数据收集的背书策略。
6. chaincode验证提交的客户端是否是所有者，根据卖方集合中的散列验证私有细节，根据买方集合中的散列验证投标细节。然后，chaincode为公钥写入建议的更新(将所有权设置为买方，并将背书策略设置为买方的组织和监管机构)，将私有详细信息写入买方的私有数据收集，并可能从卖方的收集中删除私有详细信息。在最终背书之前，背书方确保将私有数据分发给卖方和监管机构的任何其他授权方。
7. 卖方提交带有公共数据和私有数据散列的事务用于订购，并将其分发给一个块中的所有通道对等方。
8. 每个对等方的块验证逻辑将一致地验证背书策略是否满足(买方、卖方、监管者均已背书)，并验证链码中读取的公共和私有状态自链码执行以来未被任何其他事务修改。
9. 所有对等点都将事务提交为有效的，因为它通过了验证检查。如果买方对等方和监管对等方在背书时没有收到私有数据，它们将从其他授权对等方检索私有数据，并将私有数据保存在它们的私有数据状态数据库中(假设私有数据与事务的散列匹配)。
10. 交易完成后，资产已被转移，其他对资产感兴趣的通道成员可以查询公钥的历史以了解其来源，但是将无法访问任何私有细节，除非所有者在需要知道的基础上共享它。

资产转移的基本场景可以扩展到其他的考虑,例如chaincode转移可以确认一个付款记录和交付要求,满足付款或确认银行提交信用证,之前的执行chaincode转移。而且，他们可以通过运行对等点的托管组织进行交易，而不是直接托管对等点。

清除隐私数据

对于非常敏感的数据，即使共享私有数据的各方可能希望(或政府法规可能要求)定期“清除”其对等方的数据，在区块链上留下数据散列，作为私有数据的不可变证据。

在某些情况下，私有数据只需要存在于对等的私有数据库中，直到可以将其复制到对等的区块链外部的数据库中。在chaincode业务流程完成之前(交易结算、合同履行等)，数据可能只需要存在于对等节点上。

为了支持这些用例，如果私有数据没有被修改为可配置数量的块，那么可以清除它。清除的私有数据不能从chaincode查询，并且对其他请求的对等方不可用。

如何定义私有数据集合

有关集合定义的更多详细信息，以及关于私有数据和集合的其他低级信息，请参阅私有数据引用主题。

来源：oschina

链接：https://my.oschina.net/u/2277392/blog/3211851