MSPs会配置在区块链网络中的两个地方：通道配置(channel MSPs)和本地配置(local MSP)。客户端(users)和nodes节点(peers和orderers)会使用到本地MSPs。本地节点的MSPs定义了该节点的权限(例如：该节点的管理员)。本地MSPs可以使用户在一个事务中实现自我认证(签名)，证明该用户是一个通道的成员(例如：在链码事务中)，或者作为在系统中特殊角色的拥有者(例如：组织管理员，在配置事务中)。
每个节点和用户必须定义一个本地MSP，它定义了谁拥有管理或访问权限在它所在的层级(peer的管理员不一定是通道管理员，反之亦然)。
通道MSPS在通道层级定义了管理和访问权限。每个参加通道的组织需要有一个MSP。通道中的peer和orderers共享相同的通道MSPs信息，它们能正确的识别通道参与者。如果一个组织希望加入某个通道，那么该组织信任链上游的MSP需要被包含在通道配置中。否者基于该组织的事务将被通道中的节点拒绝。
本地MSPs和通道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.
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.
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.)
