Fabric官方教程（release 2.2）翻译及总结——MSP以及私有数据

1关键概念

1.1 MSP

为什么需要MSP

由于 Fabric 是一个许可网络，区块链参与者需要一种方法来向网络的其余部分证明他们的身份，以便在网络上进行交易。如果您通读了有关身份的文档，您就会看到公钥基础设施 (PKI) 如何通过信任链提供可验证的身份。区块链网络如何使用信任链？

证书颁发机构通过生成公钥和私钥来发布身份，公钥和私钥形成可用于证明身份的密钥对。由于私钥永远不能公开共享，因此需要一种机制来启用 MSP 所在的证明。例如，peer使用其私钥对交易进行数字签名或背书。排序服务上的 MSP 包含peer方的公钥，然后用于验证附加到交易的签名是否有效。私钥用于在交易上生成签名，只有作为 MSP 一部分的相应公钥才能匹配该签名。因此，MSP 是一种机制，允许该身份被网络的其余部分信任和识别，而不会泄露成员的私钥。

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

这种将可验证身份转换为角色的能力是 Fabric 网络运作方式的基础，因为它允许组织、节点和通道建立 MSP，以确定允许谁在组织、节点和通道级别执行什么操作。

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

考虑一个运营区块链网络的银行财团。每家银行都操作peer节点和排序节点，peer节点对提交给网络的交易进行背书。然而，每家银行也会有部门和账户持有人。账户持有者属于每个组织，但不会在网络上运行节点。他们只会从他们的移动或 Web 应用程序与系统交互。那么网络是如何识别和区分这些身份的呢？ CA 用于创建身份，但就像卡片示例一样，这些身份不能只是颁发，它们需要被网络识别。 MSP 用于定义被网络成员信任的组织。 MSP 也是在网络中为成员提供一组角色和权限的机制。由于定义这些组织的 MSP 为网络成员所知，因此它们可用于验证尝试执行操作的网络实体是否被允许。

最后，考虑一下如果你想加入一个现有的网络，你需要一种方法来将你的身份变成网络可以识别的东西。 MSP 是一种机制，使您能够参与许可的区块链网络。要在 Fabric 网络上进行交易，成员需要：

1. 拥有由网络信任的 CA 颁发的身份。
2. 成为网络成员认可的组织的一个成员。 MSP 是将身份与组织成员联系起来的方式。 成员资格是通过将成员的公钥（也称为证书、签名证书或签名证书）添加到组织的 MSP 来实现的。
3. 将 MSP 添加到网络上的联盟或通道。
4. 确保 MSP 包含在网络上的策略定义中。

什么是MSP

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

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

但是 MSP 的力量不仅仅是简单地列出谁是网络参与者或通道成员。 MSP 通过识别参与者在节点或通道上拥有的特定特权将身份转变为角色。请注意，当用户向 Fabric CA 注册时，必须将 admin、peer、client、orderer 或 member 角色与用户关联。例如，以“peer”角色注册的身份自然应该提供给peer。同样，以“管理员”角色注册的身份应提供给组织管理员。我们将在本主题后面深入探讨这些角色的重要性。

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

MSP 域

MSP 出现在区块链网络的两个域中：

• 在参与者节点本地**（local MSP）**
• 在通道配置中**（cahnnel MSP）**

本地 MSP 和通道 MSP 之间的主要区别不在于它们的功能——两者都将身份转换为角色——而是它们的范围。 每个 MSP 都列出了特定管理级别的角色和权限。

local MSPS

本地 MSP 是为客户端和节点（perer节点和排序节点）定义的。本地 MSP 定义节点的权限（例如，谁是可以操作该节点的peer管理员）。客户的本地 MSP（上述银行场景中的帐户持有人）允许用户作为通道成员在其交易中鉴别自己（例如在链代码交易中）或作为特定角色（例如作为组织管理员）的所有者进入系统进行身份验证，例如，在配置事务中。

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

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

Channel MSP

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

​ 来自包含两个组织 MSP 的通道 config.json 文件的片段。

通道 MSP 确定谁在通道级别拥有权限。 通道 MSP 定义了通道成员（它们本身就是 MSP）的身份与通道级别策略的实施之间的关系。 通道 MSP 包含通道成员组织的 MSP。

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

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

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

下图说明了本地 MSP 和通道 MSP 如何在网络上共存：

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

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

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

组织与其 MSP 之间的排他关系使得以组织命名 MSP 是明智之举，您会发现大多数策略配置都采用了这种约定。例如，组织 ORG1 可能有一个称为 ORG1-MSP 之类的 MSP。在某些情况下，组织可能需要多个成员资格组 - 例如，在组织之间使用通道执行截然不同的业务功能的情况下。在这些情况下，拥有多个 MSP 并相应地命名它们是有意义的，例如 ORG2-MSP-NATIONAL 和 ORG2-MSP-GOVERNMENT，反映了与 GOVERNMENT 监管通道相比，ORG2 中 NATIONAL 销售通道中不同的成员信任根。

组织单位与MSP

一个组织也可以分为多个组织单位，每个单位都有一定的职责，也称为从属关系。 将 OU 视为组织内部的一个部门。 例如，ORG1 组织可能同时拥有 ORG1.MANUFACTURING 和 ORG1.DISTRIBUTION OU 来反映这些单独的业务线。 当 CA 颁发 X.509 证书时，证书中的 OU 字段指定身份所属的业务线。 像这样使用 OU 的一个好处是，这些值可以用于策略定义以限制访问或用于基于属性的访问控制的智能合约。 否则，需要为每个组织创建单独的 MSP。

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

节点OU 角色和MSPs

此外，还有一种特殊类型的 OU，有时称为Node OU，可用于将角色授予身份。 这些节点 OU 角色在 $FABRIC_CFG_PATH/msp/config.yaml 文件中定义，并包含组织单位列表，其成员被视为该 MSP 代表的组织的一部分。 当您希望将组织成员限制为持有身份（由 MSP 指定的 CA 之一签名）且其中具有特定节点 OU 角色的成员时，这尤其有用。 例如，使用节点 OU，您可以实施更细化的背书策略，要求 Org1 peer节点背书交易，而不是 Org1 的任何成员。

为了使用节点 OU 角色，必须为网络启用“身份分类”功能。 当使用基于文件夹的 MSP 结构时，这是通过在位于 MSP 文件夹根目录的 config.yaml 文件中启用“节点 OU”来实现的：

NodeOUs:Enable: trueClientOUIdentifier:Certificate: cacerts/ca.sampleorg-cert.pemOrganizationalUnitIdentifier: clientPeerOUIdentifier:Certificate: cacerts/ca.sampleorg-cert.pemOrganizationalUnitIdentifier: peerAdminOUIdentifier:Certificate: cacerts/ca.sampleorg-cert.pemOrganizationalUnitIdentifier: adminOrdererOUIdentifier:Certificate: cacerts/ca.sampleorg-cert.pemOrganizationalUnitIdentifier: orderer

在上面的示例中，MSP 有 4 个可能的节点 OU 角色：

• client
• peer
• admin
• orderer

此约定允许您通过 X509 证书的 CommonName 属性中存在的 OU 来区分 MSP 角色。 上面的例子说任何由 cacerts/ca.sampleorg-cert.pem 颁发的证书，其中 OU=client 将被标识为客户端，OU=peer 将标识为peer等。从 Fabric v1.4.3 开始，还有一个 OU 对于订购者和admins。 新的 admins 角色意味着您不再需要明确地将证书放在 MSP 目录的 admincerts 文件夹中。 相反，用户的签名证书中存在的管理员角色将身份授权为管理员用户。

当使用 Fabric CA 或 SDK 向 CA 注册用户时，这些角色和 OU 属性会分配给一个身份。 随后的 enroll user 命令在用户的 /msp 文件夹中生成证书。

生成的 ROLE 和 OU 属性在位于 /signcerts 文件夹中的 X.509 签名证书中可见。 ROLE 属性标识为 hf.Type 并指代参与者在其组织中的角色（例如，指定参与者是peer方)。 请参阅签名证书中的以下片段，显示角色和 OU 在证书中的表示方式。

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

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

MSP 结构

让我们探索呈现我们迄今为止描述的功能的 MSP 元素。

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

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

• config.yaml ：用于通过启用“节点 OU”并定义接受的角色来配置 Fabric 中的身份分类功能。

• cacerts：此文件夹包含此 MSP 代表的组织信任的根 CA 的自签名 X.509 证书列表。 此 MSP 文件夹中必须至少有一个根 CA 证书。 这是最重要的文件夹，因为它标识了所有其他证书必须从中派生的 CA，才能被视为相应组织的成员以形成信任链。

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

  中间 CA 可能代表组织的不同细分（如 ORG1-MANUFACTURING 和 ORG1-DISTRIBUTION 为 ORG1 所做的），或组织本身（如果商业 CA 用于组织的身份管理，则可能是这种情况）。 在后一种情况下，中间 CA 可用于表示组织细分。 您可以在此处找到有关 MSP 配置最佳实践的更多信息。 请注意，可能有一个没有中间 CA 的正常运行的网络，在这种情况下，此文件夹将为空。

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

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

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

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

• keystore：（私钥）该文件夹是为peer节点或排序节点（或在客户端的本地 MSP 中）的本地 MSP 定义的，并包含节点的私钥。此密钥用于签署数据——例如，作为背书阶段的一部分，签署交易提案响应。

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

  通道 MSP 配置不包括此文件夹，因为通道 MSP 仅旨在提供身份验证功能而不是签名功能。

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

• signcert：对于peer节点或排序节点（或在客户端的本地 MSP 中），此文件夹包含由 CA 颁发的节点证书。证书代表节点的身份，该证书对应的私钥可用于生成签名，任何拥有此证书副本的人都可以验证该签名。

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

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

• tlscacerts：此文件夹包含此组织信任的根 CA 的自签名 X.509 证书列表，用于使用 TLS 的节点之间的安全通信。 TLS 通信的一个示例是当peer方需要连接到排序节点以便它可以接收账本更新时。

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

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

  tlsintermediatecacerts：此文件夹包含由此 MSP 代表的组织信任的中间 CA 证书列表，用于使用 TLS 的节点之间的安全通信。当商业 CA 用于组织的 TLS 证书时，此文件夹特别有用。与成员资格中间 CA 类似，指定中间 TLS CA 是可选的。

  Operationscerts：此文件夹包含与 Fabric Operations Service API 通信所需的证书。

通道 MSP 包括以下附加文件夹：

• Revoked Certificates：如果actor的身份已被撤销，则有关身份的识别信息–而不是身份本身–保存在此文件夹中。 对于基于 X.509 的身份，这些标识符是称为主题密钥标识符 (SKI) 和权限访问标识符 (AKI) 的字符串对，并且在使用证书时进行检查以确保证书未被撤销。

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

如果您已阅读此文档以及我们关于身份的文档，您现在应该对身份和 MSP 在 Hyperledger Fabric 中的工作方式有了很好的了解。 您已经了解了如何使用 PKI 和 MSP 来识别在区块链网络中协作的参与者。 除了 MSP 的物理和逻辑结构之外，您还了解了证书、公钥/私钥和信任根的工作原理。

1.2 Private data

什么是私人数据？

如果某个通道上的一组组织需要使该数据与该通道上的其他组织保持私有，他们可以选择创建一个仅包含需要访问该数据的组织的新通道。 但是，在每种情况下创建单独的信道都会产生额外的管理开销（维护链码版本，策略，MSP等），并且不允许您希望所有信道参与者都看到交易同时又保留一部分交易的私人数据。

这就是为什么Fabric提供创建私有数据集合的功能的原因，它使信道上已定义的组织子集能够认可，提交或查询私有数据，而无需创建单独的信道。

什么是私人数据集合

集合是两个元素的组合：

1. 实际的私有数据，通过gossip协议点对点发送到仅授权查看该数据的组织。此数据存储在授权组织peer的私有状态数据库中，可以从这些授权peer上的链码进行访问。此处不涉及排序服务，并且看不到私有数据。请注意，由于gossip会在授权组织之间分配peer私有数据，因此需要引导通道上的锚点peer，并在每个peer上配置CORE_PEER_GOSSIP_EXTERNALENDPOINT，以引导跨组织通信。
2. 该数据的哈希值，已得到认可，排序和写入通道中每个peer的账本中。散列值用作交易的证据，并用于状态验证，并可用于审计目的。

下图说明了被授权拥有私有数据的peer的帐本内容，以及没有私有数据的账本内容。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aMYWmVSF-1634268920955)(file://C:/Users/62483/AppData/Roaming/Typora/typora-user-images/image-20210513172348149.png?lastModify=1621323966)]

如果集合成员发生争议或想要将资产转让给第三方，则集合成员可以决定与其他方共享私人数据。 然后，第三方可以计算私有数据的哈希值，并查看其是否与通道账本上的状态匹配，从而证明该状态在某个时间点存在于集合成员之间。

在某些情况下，您可能会决定拥有一组集合，每个集合都由一个组织组成。 例如，一个组织可以将私人数据记录在他们自己的集合中，以后可以与其他信道成员共享并在链码交易中引用。 我们将在下面的共享私人数据主题中查看此示例。

When to use a collection within a channel vs. a separate channel

• 当整个交易（和账本）必须在属于该信道成员的组织间保持机密时使用信道。
• 当必须在一组组织之间共享交易（和账本）时，但是当这些组织的子集应有权访问交易中的某些（或全部）数据时，请使用集合。 另外，由于私有数据是点对点而不是通过块进行分发的，因此当必须对来自排序服务节点交易数据保密时，使用私有数据集合。

实际案例

考虑一个在信道上交易产品的五个组织：

1. 一位农民在国外出售商品
2. 分销商将货物移至国外
3. 托运人在各方之间移动货物
4. 批发商从分销商处购买商品
5. 零售商从托运人和批发商那里购买商品

分销商可能希望与农民和托运人进行私下交易，以使批发商和零售商对交易条款保密（以免暴露他们收取的加价费）。

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

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

可以定义多个私有数据集合（PDC），以在以下之间共享私有数据：

PDC1：分销商，农民和托运人

PDC2：分销商和批发商

PDC3：批发商，零售商和托运人

而不是为这些关系中的每个定义许多小信道。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D4tpYQC3-1634268920956)(file://C:/Users/62483/AppData/Roaming/Typora/typora-user-images/image-20210513174033960.png?lastModify=1621323966)]

使用此示例，分发者拥有的peer将在其账本中拥有多个私有数据库，其中包括来自分发者，农民和托运人关系以及分发者和批发商关系的私有数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KkyYehtA-1634268920957)(file://C:/Users/62483/AppData/Roaming/Typora/typora-user-images/image-20210513174135405.png?lastModify=1621323966)]

带有私人数据的交易流

当在链码中引用私有数据集合时，交易流程略有不同，以便在提议，认可并提交给账本的交易时保护私有数据的机密性。

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

1. 客户端应用程序提交提案请求以调用链码功能（读取或写入私有数据）给背书的peer，这些peer是集合的授权组织的一部分。 私有数据或用于以链码生成私有数据的数据在提案的transient字段中发送。
2. 背书peer模拟交易并将私有数据存储在transient data store（peer本地的临时存储）中。 他们根据收集策略通过gossip将私有数据分发给授权的peer。
3. 背书节点将提案响应发送回客户端。 提案响应包括认可的读/写集，其中包括公共数据，以及任何私有数据键和值的哈希。 没有私有数据发送回客户端。 有关认可如何处理私人数据的更多信息，请单击此处。
4. 客户端应用程序将交易（包括带有私有数据哈希的提案响应）提交给排序服务。 带有私有数据散列的交易正常包含在块中。 具有私有数据哈希的块将分配给所有peer。 这样，通道上的所有peer都可以以一致的方式用私有数据的哈希值验证交易，而无需知道实际的私有数据。
5. 在块提交时，授权peer使用集合策略来确定他们是否有权访问私有数据。 如果这样做，他们将首先检查其本地“瞬态数据存储”，以确定在链码认可时是否已接收到私有数据。 如果没有，他们将尝试从另一个授权peer获取私有数据。 然后，他们将根据公共块中的哈希来验证私有数据，并提交交易和该块。验证/提交后，私有数据将移至其私有状态数据库和私有写入集存储的副本。 然后，将私有数据从瞬态数据存储中删除。

共享私有数据

在许多情况下，一个集合中的私有数据键/值可能需要与其他信道成员或其他私有数据集合共享，例如，当您需要与未包含在在原始的私人数据集合中的一个信道成员或一组信道成员进行私有数据交易时，接收方通常会希望根据链上的作为交易的一部分的散列来验证私有数据。

私有数据收集有几个方面可以实现私有数据的共享和验证：

• 首先，只要符合背书政策，您不必一定要成为集合的成员才能写入集合中的键。 背书策略可以在链码级别，密钥级别（使用基于状态的认可）或集合级别（从Fabric v2.0开始）中定义。
• 其次，从v1.4.2开始，有一个链码API GetPrivateDataHash（）允许非成员节点上的链码读取私钥的哈希值。 正如您稍后将看到的那样，这是一个重要的功能，因为它允许链码根据从先前私有数据交易创建的链上哈希值来验证私有数据。

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

私人数据共享模式

在为每个组织的私人数据集合建模时，可以使用多种模式来共享或传输私人数据，而无需定义许多多边集合的开销。 以下是在链码应用程序中可以利用的一些共享模式：

• 使用相应的公共密钥来跟踪公共状态-您可以选择匹配的公共密钥来跟踪公共状态（例如，资产属性，当前所有权等），对于每个应该访问资产的相应私有数据的组织，您都可以在每一个组织的私有数据集合中创建一个私有的键/值 。
• **链码访问控制-**您可以在链码中实现访问控制，以指定哪些客户端可以查询集合中的私有数据。 例如，为私有数据集合密钥或密钥范围，存储访问控制列表，然后在链码中获取客户端提交者的凭据（使用GetCreator（）链码API或CID库API GetID（）或GetMSPID（）），并返回私有数据前进行验证他们是否有权。 同样，为了访问私有数据，您可能需要客户端将密码短语传递到链码中，该密码必须与存储在密钥级别的密码短语匹配。 注意，此模式也可以用于限制客户端对公共状态数据的访问。
• 链外共享私有数据-作为脱链选项，您可以与其他组织带外共享私有数据，他们可以使用GetPrivateDataHash（）链码API对键/值进行哈希处理，以验证其是否与链上哈希匹配 。 例如，一个希望从您那里购买资产的组织可能希望在同意购买之前，通过检查链上的哈希值来验证资产的属性以及您是合法所有者。
• 与其他集合共享私有数据-您可以使用链码在链上“共享”私有数据，从而在另一个组织的私有数据集合中创建匹配的键/值。 您可以通过瞬时字段将私有数据键/值传递给链码，并且链码可以使用GetPrivateDataHash（）确认所传递的私有数据的哈希值与您集合中的链上哈希值匹配，然后将私有数据写入到其他组织的私人数据收集。
• 将私人数据转移到其他集合-您可以使用链码“转移”私人数据，该链码会删除您集合中的私人数据密钥，并在另一个组织的馆藏中创建它。 再次，使用瞬态字段在调用链码时传递私有数据，并在链码中使用GetPrivateDataHash（）确认数据存在于私有数据集合中，然后再从集合中删除密钥并在另一个组织的集合中创建密钥 。 为确保交易始终从一个集合中删除并添加到另一个集合中，您可能需要要求其他方的认可，例如监管者或审计师。
• 使用私人数据进行交易批准-如果您想在交易完成之前获得交易对手的批准（例如，链上记录，他们同意以一定价格购买资产），链码可以要求他们“预先通过向其私有数据集合或您的集合中写入私钥来“批准”交易，然后链码将使用GetPrivateDataHash（）对其进行检查。实际上，这与内置生命周期系统chaincode用来确保组织在将其提交给信道之前就已同意chaincode定义时使用的机制完全相同。从Fabric v2.0开始，此模式通过集合级别的背书策略变得更加强大，以确保链码在集合所有者自己的受信任peer上执行和认可。或者，可以使用具有密钥级别认可策略的共同商定的密钥，然后使用预先批准的条款对其进行更新，并由所需组织的同级认可。
• 保持交易者的私密性-更改先前的模式还可以消除指定交易的交易者泄漏。 例如，买家表示同意购买自己的收藏集，然后在随后的交易中，卖家在自己的私有数据集中引用了买家的私有数据。 带有散列引用的交易证明记录在链上，只有买卖双方知道他们是交易者，但是如果需要知道，他们可以显示前镜像，例如在后续与其他可以验证哈希的交易者交易时。

结合上述模式，值得注意的是，可以将具有私有数据的交易绑定到与常规通道状态数据相同的条件，特别是：

• 密钥级交易访问控制-您可以在私有数据值中包含所有权凭证，以便后续交易可以验证提交者具有共享或传输数据的所有权特权。 在这种情况下，链码将获得提交者的凭据（例如，使用GetCreator（）链码API或CID库API GetID（）或GetMSPID（）），将其与传递给链码的其他私有数据结合起来，对其进行哈希处理，然后使用GetPrivateDataHash （）进行交易之前，先验证它是否与链上哈希匹配。
• 关键级别的认可政策-与常规信道状态数据一样，您也可以使用基于状态的认可来指定哪些组织必须认可共享或传输私有数据的交易，例如使用SetPrivateDataValidationParameter（）链码API，例如指定仅所有者的 组织peer，托管人的组织peer或其他第三方必须认可此类交易。

示例场景：使用私有数据集合进行资产转移

上述私有数据共享模式可以组合起来，以支撑基于功能强大的链码的应用程序。例如，考虑如何使用每个组织的私有数据集合来实现资产转移方案：

• 可以通过处于公共链码状态的UUID密钥来跟踪资产。仅记录资产的所有权，关于资产的其他信息则一无所知。
• 链码将要求任何转移请求都必须来自拥有者的客户，并且密钥和受基于状态的要求所有者组织和监管者组织的peer必须背书任何转移请求的背书策略绑定。
• 资产所有者的私有数据集合包含有关资产的私有详细信息，以UUID的哈希值作为关键字。其他组织和排序服务将仅看到资产详细信息的哈希。
• 让我们假设监管者也是每个集合的成员，因此保留了私有数据，尽管并非必须如此。

一项交易资产的交易将展开如下：

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

可以将基本资产转移方案扩展为其他考虑因素，例如，转移链码可以验证付款记录可用于满足付款与交付要求，或者在转移链码前验证银行在执行该付款之前已提交了信用证。 而且，代替交易者的直接主节点，他们可以通过监管组织进行交易。

清除私有数据

对于非常敏感的数据，即使是共享私有数据的各方也可能希望-或政府法规可能要求-定期“清除”其peer节点上的数据，而在区块链上留下数据的哈希以用作私人数据的一成不变的证据。

在某些情况下，私有数据仅需要存在于peer的私有数据库中，直到可以将其复制到peer区块链外部的数据库中为止。 数据也可能只需要存在于peer上，直到完成链码业务流程（交易结算，合同履行等）。

为了支持这些用例，如果尚未针对可配置数量的块进行修改，则可以清除私有数据。 无法从链码中查询已清除的私有数据，并且其他请求peer也无法使用。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！