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的實體和邏輯結構之外，您還了解了證書、公鑰/私鑰和信任根是如何工作的。