本地MSP只保存有Global MSP上的子集，内容保存在本地文件系统上，而全局MSP可在逻辑上认为是配置在系统上的，它实际也在每个参与者上保存一份拷贝，但会维持一致性。
MSP也分级，如图16中所示，底层的network MSP负责网络层的准入，其MSP由ORG1拥有，而上面的某个channel的MSP则由ORG1和ORG2共同管理。
图16-MSP是分级的
一个MSP下含有以下结构，如图17所示。
图17-MSP结构
可见，MSP结构包括：
RCA根证书
ICA中间证书
OU组织单位
管理员证书
RCL吊销证书列表
结点上的具体证书
存储私钥的keystore
TLS的根证书与中间证书
?
peer结点上保存有账本ledger以及智能合约，如下图所示：
channel是一个逻辑概念，可以通过MSP隔离全网不同组织的参与者，如下图所示：
当有多方参与者时，例如4个org组织、8个peer结点时，其中channel连接了P1、P3、P5、P7、P8这五个节点，其他3个节点加入了其他channel，其部署图如下所示：
加入MSP来管理身份时，如P1和P2由ORG1.MSP管理，而P3和P4的证书则由ORG2.MSP管理，他们共同使用一个channel，则如下图所示：
去中心化的设计，必然需要通过投票（多数大于少数）来维持数据一致性，而任何投票都必须经历以下三个过程：
有一方先提出议案proposal，该议案有对应的一批投票者需要对该结果背书，这些投票者依据各自的习惯投票，并将结果反馈；
统计投票结果，若获得多数同意，才能进行下一步；
将获得多数同意的议案记录下来，且公之于众。
而这三步fabric当然也少不了，当然它的称法就有所不同，其对应的三步如下：
由client上的CLI或者SDK进行proposal议案的提出。client会依据智能合约chaincode根据背书策略endorse policy决定把proposal发往哪些背书的peer节点，而peer节点进行投票，client汇总各背书节点的结果；
client将获得多数同意的议案连同各peer的背书（包括其投票结果以及背书签名）交给orderring service，而orderer会汇总各client递交过来的trasaction交易，排序、打包。
orderer将交易打包成区块block，然后通知所有commit peer，各peer各自验证结果，最后将区块block记录到自己的ledger账本中。
我们看一个具体的例子，若channel上有三个peer背书者，client提交流程如下图所示：
详细解释下上图的流程：
首先，client发起一个transaction交易，含有<clientID, chaincodeID, txPayLoad, timestamp, clientSig>等信息，指明了3W要素：消息是谁who在什么时间when发送了什么what。该消息根据chaincode中的背书策略，发向EP1、EP2、EP3这三个peer节点。
这三个peer节点模拟执行智能合约，并将结果及其各自的CA证书签名发还client。client收集到足够数量的结果后再进行下一步。
client将含背书结果的tx交易发向ordering service。
ordering service将打包好的block交给committing peer CP1以及EP1、EP2、EP3这三个背书者，背书者此时会校验结果并写入世界状态以及账本中。同时，client由于订阅了消息，也会收到通知。
如果我们从编程的角度来看，则流程会更清楚：