Hyperledger Fabric 1.3 官方文档翻译（三）关键概念 (Key Concepts) - 3.6 成员 (Membership)

川长思鸟来 2022-05-09 05:44 242阅读 0赞

### 文章目录 ###

*  成员（Membership）
 *   *  将MSP映射到组织（Mapping MSPs to Organizations）
     *   *  组织单元和MSP（Organizational Units and MSPs）
     *  本地和通道MSP（Local and Channel MSPs）
     *  MSP级别（MSP Levels）
     *  MSP结构（MSP Structure）

# 成员（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.  
如果你已阅读[身份][identity]上的文档，您已经了解了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被信任来定义信任域的成员，例如组织**，通过列出他们的成员的身份，或通过识别哪些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][identity] documentation — but we will talk about how that process also extends to an MSP.  
此外，MSP可以允许识别已被撤销的身份列表 - 如[身份][identity]文档 - 但我们将讨论该过程如何扩展到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一般会做些什么。

## 将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证书中定义的组织概念不同，我们将在稍后讨论。

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`，反映了在`NATIONAL`销售通道与`GOVERNMENT`监管通道道相比，在`ORG2`内的不同成员信任根。

![MSP1][]

*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用于表示具有国家、国际和政府关系的不同组织群组。*

### 组织单元和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` OU的标识才能访问一个通道，而`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的轻微滥用，但它们有时可以被联盟中的不同组织用来区分彼此。 在这种情况下，不同的组织将相同的根CA和中间CA用于其信任链，但是指定“OU”字段以标识每个组织成员。 我们还将看到如何配置MSP以便以后实现此目的。

## 本地和通道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出现在区块链网络中的两个位置：通道配置（\*\*通道MSP \*\*），以及在参与者本地的前提下（\*\*本地MSP \*\*）。 \*\*为客户端（用户）和节点（对等节点和排序节点）定义本地MSP \*\*。节点本地MSP定义该节点的权限（例如节点管理员是谁）。用户的本地MSP允许用户侧作为频道的成员（例如在链代码交易中）在其交易中认证自身，或者在系统中作为特定角色的所有者（例如配置交易的组织管理员）。

**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.  
相反，**通道MSP在通道级别定义了管理和参与权利**。参与通道的每个组织都必须为其定义MSP。通道上的对等节点和排序节点都将共享相同的通道MSP视图，因此能够正确地验证通道参与者。这意味着，如果组织希望加入该通道，则需要将包含该组织成员信任链的MSP纳入通道配置中。否则，将拒绝源自该组织的交易。

The key difference here between local and channel MSPs is not how they function — both turn identities into roles — but their **scope**.  
本地和通道MSP之间的关键区别不在于它们如何运作 - 既将身份转变为角色 - 而是**范围**。

![MSP2][]

*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.*  
*本地和通道MSP。 每个对等节点的信任域（例如，组织）由对等节点的本地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很有帮助，如[上图][diagram above]所示。

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.  
**本地MSP仅**在它们适用的**节点或用户的文件系统上定义**。因此，在物理上和逻辑上，每个节点或用户只有一个本地MSP。但是，由于通道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.  
通道和本地MSP之间的分离反映了组织管理其本地资源（例如对等节点或排序节点），及其运行在通道或网络\*\* 级别**的资源（如帐本、智能合约和联盟）的需求。 将** MSP视为处于不同级别**是有帮助的，更高级别的MSP处于与网络管理相关，而**较低级别的 MSP处理私有资源管理的身份\*\*。 MSP在每个管理级别都是必需的 - 必须为网络、通道、对等节点、排序节点和用户定义MSP。

![MSP3][]

*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级别。对等节点和排序节点的MSP是本地的，而通道的MSP（包括网络配置通道）被该通道的所有参与者之间共享。在此图中，网络配置通道由ORG1管理，但另一个应用通道可由ORG1和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**：通道必须单独维护其成员的MSP。通道在特定的一组组织之间提供私有通信，这些组织又对其进行管理控制。在该通道的MSP环境中解释的通道策略，定义谁有能力参与通道上的某些动作，例如，添加组织或实例化链代码。请注意，管理通道的权限与管理网络配置通道（或任何其他通道）的权限之间没有必然的关系。管理权限存在于管理范围内（除非规则已经另行规定 - 请参阅下面对`ROLE`属性的讨论）。
 *  **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完全相同的功能，其限制是它仅适用于定义它的对等节点。使用对等节点的本地MSP评估其授权的操作的示例是在对等节点上安装链代码。
 *  **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结构（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的规范。 但是，有更多的元素与这两个元素结合使用以协助成员功能。

![MSP4][]

*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.  
    **根CA**：此文件夹包含由此MSP代表的组织信任的根CA的自签名X.509证书列表。 此MSP文件夹中必须至少有一个Root 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。
 *  **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.  
    **中间CA**：此文件夹包含此组织信任的中间CA的X.509证书列表。 每个证书必须由MSP中的一个根CA或中间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可用于表示组织细分。[这里][Here] 你可以找到有关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.  
    **组织单元（OU）**：这些列在`$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证书具有`ROLE`属性（例如，指定一个参与者是一个`admin`），这指的是一个参与者在其组织内而不是在区块链网络中的角色。这于`OU`属性的目的类似，如果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.  
    如果已编写该通道的策略以允许组织（或某些组织）的任何管理员执行某些通道功能（例如实例化链代码），则`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.  
**通道MSP**的配置不包括此文件夹，因为通道MSP仅旨在提供身份验证功能而不是签名能力。

*  **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**：此文件夹包含由此MSP 代表的组织信任的**用于TLS通信**的CA证书的中间CA列表。 当商业CA用于组织的TLS证书时，此文件夹特别有用。 与成员中间CA类似，指定中间TLS的CA是可选的。
    
    For more information about TLS, click [here][].  
    有关TLS的更多信息，请单击[此处][here]。

If you’ve read this doc as well as our doc on [Identity][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.  
如果你已经阅读过这个文档以及我们关于[身份][identity]的文档，你应该很好地掌握Hyperledger Fabric中的身份和成员如何工作。你已经了解了如何使用PKI和MSP来识别在区块链网络中协作的参与者。 除了MSP如何物理和逻辑的结构化之外，你还了解了证书、公钥/私钥和信任根的工作原理。

[identity]: https://hyperledger-fabric.readthedocs.io/en/release-1.3/identity/identity.html
[MSP1]: /images/20220509/413c218bf1a64048982627a9e952e74b.png
[MSP2]: /images/20220509/883e7d6b01b84c56a43e51c8fc891302.png
[diagram above]: https://hyperledger-fabric.readthedocs.io/en/release-1.3/membership/membership.html#msp2img
[MSP3]: /images/20220509/efd2a8fc8bd64b938d6dec0ca0cab8d3.png
[MSP4]: /images/20220509/1756ec24ce3c4f578365a2e79f6250f6.png
[Here]: https://hyperledger-fabric.readthedocs.io/en/release-1.3/msp.html
[here]: https://hyperledger-fabric.readthedocs.io/en/release-1.3/enable_tls.html