Hyperledger Fabric v1.4(LTS) 系列(3.6)：关键概念-成员

译文目录：

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

Key Concepts-Membership

• Introduction
• Hyperledger Fabric Functionalities
• Hyperledger Fabric Model
• Blockchain network
• Identity
• Membership
• Peers
• Smart Contracts and Chaincode
• Ledger
• The Ordering Service
• Private data
• Use Cases

Membership

If you’ve read through the documentation on identity you’ve seen how a PKI can provide verifiable identities through a chain of trust. Now let’s see how these identities can be used to represent the trusted members of a blockchain network.
如果您已经阅读了身份的文档，那么您已经了解了PKI如何通过信任链提供可验证的身份。现在让我们看看如何使用这些身份来表示区块链网络的可信成员。

This is where a Membership Service Provider (MSP) comes into play — it identifies which Root CAs and Intermediate CAs are trusted to define the members of a trust domain, e.g., an organization, either by listing the identities of their members, or by identifying which CAs are authorized to issue valid identities for their members, or — as will usually be the case — through a combination of both.
这就是会员服务提供者(MSP)开始发挥作用的地方–它标识可被信任用于定义可信域的成员，来标识信任域成员（如组织）的可信根CA和中间CA，或者就像通常情况一样通过两者的结合。

The power of an MSP goes beyond simply listing who is a network participant or member of a channel. An MSP can identify specific roles an actor might play either within the scope of the organization the MSP represents (e.g., admins, or as members of a sub-organization group), and sets the basis for defining access privileges in the context of a network and channel (e.g., channel admins, readers, writers).
MSP的功能不仅仅是列出谁是网络参与者或渠道成员。MSP可以识别特定的角色参与者可以在MSP所代表的组织范围内（例如，管理员，或作为子组织组的成员）发挥作用，并设置在网络和通道上下文中定义访问权限的基础（例如，通道管理员、读卡器、编写器）。

The configuration of an MSP is advertised to all the channels where members of the corresponding organization participate (in the form of a channel MSP). In addition to the channel MSP, peers, orderers, and clients also maintain a local MSP to authenticate member messages outside the context of a channel and to define the permissions over a particular component (who has the ability to install chaincode on a peer, for example).
MSP的配置通告给相应组织成员参与的所有通道（以通道MSP的形式）。除了通道MSP之外，对等端、订购方和客户机还维护一个本地MSP，用于在通道上下文之外对成员消息进行身份验证，并定义对特定组件的权限（例如，该组件能够在对等端上安装链码）。

In addition, an MSP can allow for the identification of a list of identities that have been revoked — as discussed in the Identity documentation — but we will talk about how that process also extends to an MSP.
此外，MSP可以允许识别已撤销的标识列表，如[标识]文档（https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html）中所述，但我们将讨论该过程如何扩展到MSP。

We’ll talk more about local and channel MSPs in a moment. For now let’s see what MSPs do in general.
稍后我们将进一步讨论本地和频道MSP。现在，让我们看看MSP通常做什么。

Mapping MSPs to Organizations

An organization is a managed group of members. This can be something as big as a multinational corporation or a small as a flower shop. What’s most important about organizations (or orgs) is that they manage their members under a single MSP. Note that this is different from the organization concept defined in an X.509 certificate, which we’ll talk about later.
一个组织是一个受管理的成员组。大到跨国公司，小到花店。对组织（或缩写orgs）最重要的是，它们在单一的MSP下管理自己的成员。注意这与X.509证书中定义的组织概念不同，稍后我们将讨论X.509证书。

The exclusive relationship between an organization and its MSP makes it sensible to name the MSP after the organization, a convention you’ll find adopted in most policy configurations. For example, organization ORG1 would likely have an MSP called something like ORG1-MSP. In some cases an organization may require multiple membership groups — for example, where channels are used to perform very different business functions between organizations. In these cases it makes sense to have multiple MSPs and name them accordingly, e.g., ORG2-MSP-NATIONAL and ORG2-MSP-GOVERNMENT, reflecting the different membership roots of trust within ORG2 in the NATIONAL sales channel compared to the GOVERNMENT regulatory channel.
组织与其MSP之间的排他关系使得更适宜将MSP按组织名称来命名，这是在大多数策略配置中都采用的一种约定。例如，组织“ORG1”会有一个名为“ORG1-MSP”的MSP。在某些情况下，一个组织可能需要多个成员组，例如，使用渠道在组织之间执行非常不同的业务功能。在这些情况下，有多个MSP并对其进行相应命名是有意义的，例如“org2-msp-national”和“org2-msp-government”，这反映了与“政府”监管渠道相比，“国家”销售渠道中“org2”内不同成员信任的根源。

Two different MSP configurations for an organization. The first configuration shows the typical relationship between an MSP and an organization — a single MSP defines the list of members of an organization. In the second configuration, different MSPs are used to represent different organizational groups with national, international, and governmental affiliation.
一个组织的两种不同的MSP配置。第一个配置显示了MSP和组织之间的典型关系——单个MSP定义了组织成员的列表。在第二种配置中，不同的MSP用于表示具有国家、国际和政府隶属关系的不同组织团体。

Organizational Units and MSPs

An organization is often divided up into multiple organizational units (OUs), each of which has a certain set of responsibilities. For example, the ORG1 organization might have both ORG1-MANUFACTURING and ORG1-DISTRIBUTION OUs to reflect these separate lines of business. When a CA issues X.509 certificates, the OU field in the certificate specifies the line of business to which the identity belongs.
一个组织通常被划分为多个组织单元（OU），每个组织单元都有一组特定的职责。例如，“ORG1”组织可能同时拥有“ORG1-MANUFACTURING”和“ORG1-DISTRIBUTION”两个OU以反映这些单独的业务线。当CA颁发X.509证书时，证书中的“OU”字段指定身份所属的业务线。

We’ll see later how OUs can be helpful to control the parts of an organization who are considered to be the members of a blockchain network. For example, only identities from the ORG1-MANUFACTURING OU might be able to access a channel, whereas ORG1-DISTRIBUTION cannot.
我们后边会看到OU如何帮助控制组织作为区块链网络成员的部分特征。例如，只有来自“ORG1-MANUFACTURING”的身份才能访问通道，而“ORG1-DISTRIBUTION”不能。

Finally, though this is a slight misuse of OUs, they can sometimes be used by different organizations in a consortium to distinguish each other. In such cases, the different organizations use the same Root CAs and Intermediate CAs for their chain of trust, but assign the OU field to identify members of each organization. We’ll also see how to configure MSPs to achieve this later.
最后，OU可以让一个联合体中的不同组织区分彼此，虽然这有点算对OU的轻度滥用。在这种情况下，不同的组织使用相同的根CA和中间CA构成其信任链，但分配“OU”字段来标识组织的每个成员。稍后我们还会看到如何配置MSP来实现这一点。

Local and Channel MSPs

MSPs appear in two places in a blockchain network: channel configuration (channel MSPs), and locally on an actor’s premise (local MSP). Local MSPs are defined for clients (users) and for nodes (peers and orderers). Node local MSPs define the permissions for that node (who the peer admins are, for example). The local MSPs of the users allow the user side to authenticate itself in its transactions as a member of a channel (e.g. in chaincode transactions), or as the owner of a specific role into the system (an org admin, for example, in configuration transactions).
MSP出现在区块链网络中的两个地方：通道配置（channel MSPs），以及本地的参与者前提（local MSP）。本地MSPs是为客户端（用户）和节点（对等方和排序节点）定义的）。节点本地MSPs定义该节点的权限（例如节点管理员是谁）。用户的本地MSPs允许用户端作为通道成员在其事务中（例如在链码事务中）证明自己身份，或作为系统中特定角色的所有者（例如，在配置事务中的组织管理者）。

译注：
locally on an actor’s premise这句确实没弄明白，云计算的on premise意指按计划预置的设施，是相对on demand而言。但是on an actor’s premise没弄明白。

Every node and user must have a local MSP defined, as it defines who has administrative or participatory rights at that level (peer admins will not necessarily be channel admins, and vice versa).

每个节点和用户都必须定义本地MSP，因为它定义了谁在该级别具有管理或参与权限（节点管理员不一定是通道管理员，反之亦然）。

In contrast, channel MSPs define administrative and participatory rights at the channel level. Every organization participating in a channel must have an MSP defined for it. Peers and orderers on a channel will all share the same view of channel MSPs, and will therefore be able to correctly authenticate the channel participants. This means that if an organization wishes to join the channel, an MSP incorporating the chain of trust for the organization’s members would need to be included in the channel configuration. Otherwise transactions originating from this organization’s identities will be rejected.
相反，通道MSPs在通道层面上定义了管理和参与权利。每个参与通道的组织都必须为其定义MSP。通道上的对等节点和排序节点都将共享通道MSPs的相同视图，因此能够正确地验证通道参与者。这意味着，如果一个组织希望加入通道，那么需要在通道配置中包含一个包含该组织成员信任链的MSP。否则，来自此组织标识的事务将被拒绝。

The key difference here between local and channel MSPs is not how they function — both turn identities into roles — but their scope.
本地和通道MSPs之间的关键区别不在于它们的工作方式—两者都将身份转变为角色—而是它们的作用域。

Local and channel MSPs. The trust domain (e.g., the organization) of each peer is defined by the peer’s local MSP, e.g., ORG1 or ORG2. Representation of an organization on a channel is achieved by adding the organization’s MSP to the channel configuration. For example, the channel of this figure is managed by both ORG1 and ORG2. Similar principles apply for the network, orderers, and users, but these are not shown here for simplicity.
本地和通道MSPs。每个节点的信任域（例如，组织）由节点的本地MSP（例如，ORG1或ORG2）定义。通过将组织的MSP添加到通道配置中，实现组织在通道上的表示。例如，图中通道由ORG1和ORG2管理。类似的原则也适用于网络、排序节点和用户，简单起见，此处不显示这些。

You may find it helpful to see how local and channel MSPs are used by seeing what happens when a blockchain administrator installs and instantiates a smart contract, as shown in the diagram above.
您应已发现，通过查看区块链管理员如上图所示安装和实例化智能合约时发生的情况，对了解如何使用本地和通道MSP很有帮助。

An administrator B connects to the peer with an identity issued by RCA1 and stored in their local MSP. When B tries to install a smart contract on the peer, the peer checks its local MSP, ORG1-MSP, to verify that the identity of B is indeed a member of ORG1. A successful verification will allow the install command to complete successfully. Subsequently, B wishes to instantiate the smart contract on the channel. Because this is a channel operation, all organizations on the channel must agree to it. Therefore, the peer must check the MSPs of the channel before it can successfully commit this command. (Other things must happen too, but concentrate on the above for now.)
管理员“B”使用“RCA1”颁发的标识连接到节点，并存储在节点本地MSP中。当“B”尝试在节点上安装智能合约时，节点会检查其本地MSP“ORG1-MSP”，以验证“B”的身份确实是“ORG1”的成员。成功验证允许安装命令成功完成。随后，“B”希望在通道上实例化智能合约。因为这是一个通道操作，所以通道上的所有组织都必须同意。因此，在成功提交此命令之前，节点必须检查通道的MSP。（其他事情也必须发生，但现在要专注于以上内容。）

Local MSPs are only defined on the file system of the node or user to which they apply. Therefore, physically and logically there is only one local MSP per node or user. However, as channel MSPs are available to all nodes in the channel, they are logically defined once in the channel configuration. However, a channel MSP is also instantiated on the file system of every node in the channel and kept synchronized via consensus. So while there is a copy of each channel MSP on the local file system of every node, logically a channel MSP resides on and is maintained by the channel or the network.
本地MSPs仅在其应用的节点或用户的文件系统上定义。因此，在物理和逻辑上，每个节点或用户只有一个本地MSP。但是，由于通道MSP对通道中的所有节点都可用，因此逻辑上通道配置中只定义一次。但是，通道MSP也在通道中每个节点的文件系统上实例化，并通过共识机制保持同步。因此，尽管每个节点的本地文件系统上都有每个通道MSP的副本，但从逻辑上讲，通道MSP驻留在通道或网络上并由通道或网络维护。

MSP Levels

The split between channel and local MSPs reflects the needs of organizations to administer their local resources, such as a peer or orderer nodes, and their channel resources, such as ledgers, smart contracts, and consortia, which operate at the channel or network level. It’s helpful to think of these MSPs as being at different levels, with MSPs at a higher level relating to network administration concerns while MSPs at a lower level handle identity for the administration of private resources. MSPs are mandatory at every level of administration — they must be defined for the network, channel, peer, orderer, and users.
通道和本地MSPs的分离反映了组织管理其本地资源（如对等节点或排序节点）的需要，以及在通道或网络级别运行的通道资源（如分类账本、智能合约和联合体）。将这些MSPs分不同的级别看待是很有用的，其中与网络管理相关的MSPs处于较高级别，而用于处理私有资源管理中认证的MSPs位于较低级别。MSPs在每个管理级别中都是强制性的—必须为网络、通道、对等节点、排序节点和用户定义MSP。

MSP Levels. The MSPs for the peer and orderer are local, whereas the MSPs for a channel (including the network configuration channel) are shared across all participants of that channel. In this figure, the network configuration channel is administered by ORG1, but another application channel can be managed by ORG1 and ORG2. The peer is a member of and managed by ORG2, whereas ORG1 manages the orderer of the figure. ORG1 trusts identities from RCA1, whereas ORG2 trusts identities from RCA2. Note that these are administration identities, reflecting who can administer these components. So while ORG1 administers the network, ORG2.MSP does exist in the network definition.
＊MSP级别。对等节点和排序节点的MSPs是本地的，而通道（包括网络配置通道）的MSPs在该通道的所有参与者之间共享。如上图，网络配置通道由ORG1管理，但是另一个应用程序通道可以由ORG1和ORG2管理。对等节点是ORG2的成员并由ORG2管理，而ORG1管理图中的排序节点。ORG1信任来自RCA1的身份，而ORG2信任来自RCA2的身份。请注意，这些是管理用标识，反映了谁可以管理这些组件。因此，当ORG1管理网络时，ORG2.MSP确实存在于网络定义中。*

• Network MSP: The configuration of a network defines who are the members in the network — by defining the MSPs of the participant organizations — as well as which of these members are authorized to perform administrative tasks (e.g., creating a channel).
  ***网络MSP:**网络配置通过定义参与者组织的MSP来定义谁是网络中的成员，以及哪些成员被授权执行管理任务（例如创建通道）。

• Channel MSP: It is important for a channel to maintain the MSPs of its members separately. A channel provides private communications between a particular set of organizations which in turn have administrative control over it. Channel policies interpreted in the context of that channel’s MSPs define who has ability to participate in certain action on the channel, e.g., adding organizations, or instantiating chaincodes. Note that there is no necessary relationship between the permission to administrate a channel and the ability to administrate the network configuration channel (or any other channel). Administrative rights exist within the scope of what is being administrated (unless the rules have been written otherwise — see the discussion of the ROLE attribute below).

• 通道MSP: 通道必须单独维护其成员的MSPs。一个通道在一组特定的组织之间提供私有通信，而这些组织又对其具有管理控制权。在该通道的MSP上下文中解释的通道策略定义了谁有能力参与通道上的某些操作，如添加组织或实例化链码。请注意，管理通道的权限和管理网络配置通道（或任何其他通道）的能力之间没有必要的关系。管理权存在于所管理的范围内（除非规则另有规定——见下文“角色”属性的讨论）。

• Peer MSP: This local MSP is defined on the file system of each peer and there is a single MSP instance for each peer. Conceptually, it performs exactly the same function as channel MSPs with the restriction that it only applies to the peer where it is defined. An example of an action whose authorization is evaluated using the peer’s local MSP is the installation of a chaincode on the peer.

• 对等节点MSP: 此本地MSP定义在每个对等节点的文件系统上，每个对等节点都有一个单独的MSP实例。从概念上讲，它执行与通道MSP完全相同的功能，唯一的限制是它只作用于定义它的对等节点。使用对等节点的本地MSPs评估其认证的操作的一个示例是在对等节点上安装链码。

• Orderer MSP: Like a peer MSP, an orderer local MSP is also defined on the file system of the node and only applies to that node. Like peer nodes, orderers are also owned by a single organization and therefore have a single MSP to list the actors or nodes it trusts.

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

MSP Structure

So far, you’ve seen that the most important element of an MSP are the specification of the root or intermediate CAs that are used to establish an actor’s or node’s membership in the respective organization. There are, however, more elements that are used in conjunction with these two to assist with membership functions.
到目前为止，您已经看到了MSP最重要的元素是根CA或中间CA的规范，这些规范用于建立参与者或节点在各自组织中的成员资格。但还有更多的元素与这两个元素结合使用，以实现成员功能。

The figure above shows how a local MSP is stored on a local filesystem. Even though channel MSPs are not physically structured in exactly this way, it’s still a helpful way to think about them.
上图显示了本地MSP是如何存储在本地文件系统上的。尽管通道MSP的物理结构并非完全如此，但本图有助于你思考。

As you can see, there are nine elements to an MSP. It’s easiest to think of these elements in a directory structure, where the MSP name is the root folder name with each subfolder representing different elements of an MSP configuration.
如图，MSP有九个元素。可以按目录结构去考虑这些元素，其中MSP名称是根文件夹名称，每个子文件夹表示MSP配置的不同元素。

Let’s describe these folders in a little more detail and see why they are important.

让我们详细描述一下这些文件夹，看看它们为什么重要。

• Root CAs: This folder contains a list of self-signed X.509 certificates of the Root CAs trusted by the organization represented by this MSP. There must be at least one Root CA X.509 certificate in this MSP folder.

• 根CAs: 此文件夹包含由此MSP表示的组织所信任的根CA的自签名X.509证书的列表。此MSP文件夹中必须至少有一个根CA的X.509证书。

  This is the most important folder because it identifies the CAs from which all other certificates must be derived to be considered members of the corresponding organization.
  这是最重要的文件夹，因为加入相应组织的成员所需的证书必须由一些CA派生，而这些都由Root CAs认证。

• Intermediate CAs: This folder contains a list of X.509 certificates of the Intermediate CAs trusted by this organization. Each certificate must be signed by one of the Root CAs in the MSP or by an Intermediate CA whose issuing CA chain ultimately leads back to a trusted Root CA.

• 中间CAs: 此文件夹包含此组织信任的中间CA的X.509证书列表。每个证书必须由MSP中的一个根CA或可以最终通过CA链回溯到信任的根CA的中间CA签名。

  An intermediate CA may represent a different subdivision of the organization(like ORG1-MANUFACTURING and ORG1-DISTRIBUTION do for ORG1), or the organization itself (as may be the case if a commercial CA is leveraged for the organization’s identity management). In the latter case intermediate CAs can be used to represent organization subdivisions. Here you may find more information on best practices for MSP configuration. Notice, that it is possible to have a functioning network that does not have an Intermediate CA, in which case this folder would be empty.
  中间CA可以代表组织的不同分支（如“ORG1-MANUFACTURING”和“ORG1-DISTRIBUTION”和“ORG1”的关系），也可以代表组织本身（如果用商业CA管理组织的身份）。在后一种情况下，中间CA可以用来表示组织的分支。此处有MSP配置最佳实践的更多信息。注意，有可能拥有一个没有中间CA的正常工作的网络，在这种情况下，这个文件夹将是空的。
  Like the Root CA folder, this folder defines the CAs from which certificates must be issued to be considered members of the organization.
  与根CA文件夹一样，此文件夹定义了必须从中颁发证书才能被视为组织成员的CA。

• Organizational Units (OUs): These are listed in the $FABRIC_CFG_PATH/msp/config.yaml file and contain a list of organizational units, whose members are considered to be part of the organization represented by this MSP. This is particularly useful when you want to restrict the members of an organization to the ones holding an identity (signed by one of MSP designated CAs) with a specific OU in it.

• 组织单元（OUs）: 这些单位列在“$FABRIC_CFG_PATH/msp/config.yaml”文件中，包含组织单元列表，其成员被视为该MSP所代表组织的一部分。当您希望将组织的成员限制为拥有包含特定OU的标识（由MSP指定的CA之一签署）的成员时，这尤其有用。

  Specifying OUs is optional. If no OUs are listed, all the identities that are part of an MSP — as identified by the Root CA and Intermediate CA folders — will be considered members of the organization.
  指定OU是可选项。如果没有列出OU，则属于MSP的所有身份（由根CA和中间CA文件夹认证）将被视为组织的成员。

• Administrators: This folder contains a list of identities that define the actors who have the role of administrators for this organization. For the standard MSP type, there should be one or more X.509 certificates in this list.

• 管理员： 此文件夹包含定义具有此组织管理员角色的参与者的标识列表。对于标准的MSP类型，此列表中应该有一个或多个X.509证书。

  It’s worth noting that just because an actor has the role of an administrator it doesn’t mean that they can administer particular resources! The actual power a given identity has with respect to administering the system is determined by the policies that manage system resources. For example, a channel policy might specify that ORG1-MANUFACTURING administrators have the rights to add new organizations to the channel, whereas the ORG1-DISTRIBUTION administrators have no such rights.
  值得注意的是，仅仅因为参与者具有管理员的角色，并不意味着他们可以管理特定的资源！给定标识在管理系统方面的实际权限由管理系统资源的策略确定。例如，通道策略指定“ORG1-MANUFACTURING”管理员有权向通道中添加新组织，而“ORG1-DISTRIBUTION”管理员没有此类权限。

  Even though an X.509 certificate has a ROLE attribute (specifying, for example, that an actor is an admin), this refers to an actor’s role within its organization rather than on the blockchain network. This is similar to the purpose of the OU attribute, which — if it has been defined — refers to an actor’s place in the organization.
  尽管X.509证书具有“角色”属性（例如，指定参与者是“管理员”），但这指的是参与者在其组织内而不是在区块链网络上的角色。这类似于“OU”属性的用途，它的定义，表示参与者在组织中的位置。

  The ROLE attribute can be used to confer administrative rights at the channel level if the policy for that channel has been written to allow any administrator from an organization (or certain organizations) permission to perform certain channel functions (such as instantiating chaincode). In this way, an organizational role can confer a network role.

角色 属性 可以 用于在通道级别授予管理权限，前提是该通道的策略已写入以允许组织（或某些组织）的任何管理员执行某些通道功能（如实例化链码）的权限。以这样的方式，组织角色可以授予网络角色。

• Revoked Certificates: If the identity of an actor has been revoked, identifying information about the identity — not the identity itself — is held in this folder. For X.509-based identities, these identifiers are pairs of strings known as Subject Key Identifier (SKI) and Authority Access Identifier (AKI), and are checked whenever the X.509 certificate is being used to make sure the certificate has not been revoked.

• 已吊销的证书： 如果参与者的身份已被吊销，则有关该身份的标识信息（而不是标识本身）还保存在此文件夹中。对于X.509标识，这些标识是SKI和AKI对，每当使用X.509证书时都会进行检查，以确保证书没有被吊销。

  This list is conceptually the same as a CA’s Certificate Revocation List (CRL), but it also relates to revocation of membership from the organization. As a result, the administrator of an MSP, local or channel, can quickly revoke an actor or node from an organization by advertising the updated CRL of the CA the revoked certificate as issued by. This “list of lists” is optional. It will only become populated as certificates are revoked.
  此列表在概念上与CA的证书吊销列表（CRL）相同，但它也与组织成员资格的吊销有关。因此，本地或通道的MSP管理员可以通过广播CA更新的CRL，从而快速从组织中去除参与者或节点。此“列表们的列表”是可选的，仅在证书被吊销时填充。

• Node Identity: This folder contains the identity of the node, i.e., cryptographic material that — in combination to the content of KeyStore — would allow the node to authenticate itself in the messages that is sends to other participants of its channels and network. For X.509 based identities, this folder contains an X.509 certificate. This is the certificate a peer places in a transaction proposal response, for example, to indicate that the peer has endorsed it — which can subsequently be checked against the resulting transaction’s endorsement policy at validation time.

• 节点标识： 此文件夹包含节点的标识，即密码材料，与“KeyStore”的内容结合，允许节点在发送给其通道和网络的其他参与者的消息中进行身份验证。对于基于X.509的标识，此文件夹包含一个X.509证书。这是对等节点在事务提案响应中放置的证书，例如，用于指示对等节点已对其进行了背书，可以进一步在验证时对照生成事务的提案策略进行检查。
  This folder is mandatory for local MSPs, and there must be exactly one X.509 certificate for the node. It is not used for channel MSPs.
  此文件夹对于本地MSP是不可或缺的，并且节点必须只有一个X.509证书。它不用于通道MSP。

• KeyStore for Private Key: This folder is defined for the local MSP of a peer or orderer node (or in an client’s local MSP), and contains the node’s signing key. This key matches cryptographically the node’s identity included in Node Identity folder and is used to sign data — for example to sign a transaction proposal response, as part of the endorsement phase.

• 用于私钥的KeyStore: 此文件夹是为对等节点或排序节点的本地MSP（或在客户端的本地MSP中）定义的，包含节点的签名密钥。该密钥以密码方式匹配节点标识文件夹中包含的节点标识，用于签署数据，例如作为提案阶段的一部分，用于签署事务提案响应。

  This folder is mandatory for local MSPs, and must contain exactly one private key. Obviously, access to this folder must be limited only to the identities of users who have administrative responsibility on the peer.
  此文件夹对于本地MSP是必需的，并且必须正好包含一个私钥。显然，对该文件夹的访问必须仅限于对对等节点负有管理职责的用户。

  Configuration of a channel MSPs does not include this folder, as channel MSPs solely aim to offer identity validation functionalities and not signing abilities.
  channel MSPs的配置不包括此文件夹，因为channel MSPs的唯一目的是提供身份验证功能，而不是签名功能。

• TLS Root CA: This folder contains a list of self-signed X.509 certificates of the
  Root CAs trusted by this organization for TLS communications. An example of a TLS communication would be when a peer needs to connect to an orderer so that it can receive ledger updates.

• TLS根CA: 此文件夹包含来自此组织信任的根CA的自签名的X.509证书列表用于TLS通信。TLS通信的一个例子是，当对等节点需要连接到排序节点时发生，以便它可以接收分类帐更新。

  MSP TLS information relates to the nodes inside the network — the peers and the orderers, in other words, rather than the applications and administrations that consume the network.
  MSP TLS信息与网络内的节点（即对等节点和排序节点）相关，而不是与使用网络的应用程序和管理行为相关。

  There must be at least one TLS Root CA X.509 certificate in this folder.
  此文件夹中必须至少有一个TLS根CA X.509证书。

• TLS Intermediate CA: This folder contains a list intermediate CA certificates CAs trusted by the organization represented by this MSP for TLS communications. This folder is specifically useful when commercial CAs are used for TLS certificates of an organization. Similar to membership intermediate CAs, specifying intermediate TLS CAs is optional.

• TLS中间CA: 此文件夹包含来自此组织信任的中间CA的自签名的X.509证书列表用于TLS通信。当组织的TLS证书使用商业CA时，此文件夹特别有用。与成员身份中间CA类似，指定中间TLS CAs是可选的。

  For more information about TLS, click here.
  有关TLS的详细信息，请单击[此处]（https://hyperledger fabric.readthedocs.io/en/release-1.4/enable_tls.html）。

If you’ve read this doc as well as our doc on Identity, you should have a pretty good grasp of how identities and membership work in Hyperledger Fabric. You’ve seen how a PKI and MSPs are used to identify the actors collaborating in a blockchain network. You’ve learned how certificates, public/private keys, and roots of trust work, in addition to how MSPs are physically and logically structured.
如果您已经阅读过本文档以及我们关于[标识]的文档（https://hyperledger fabric.readthedocs.io/en/release-1.4/identity/identity.html），那么您应该很好地了解标识和成员身份在hyperledger fabric中的工作方式。您已经看到了如何使用pki和msp识别区块链网络中协作的参与者。除了MSP的物理和逻辑结构之外，您还了解了证书、公钥/私钥和信任根是如何工作的。