有关https://hyperledger-fabric.readthedocs.io/en/release-1.2/endorsement-policies.html上的认可政策语法文档 声明将主体定义为MSP.ROLE，其中MSP是MSP ID，ROLE是成员，管理员，客户端或对等方
在所示的示例中，大多数使用成员。声明“ MSP.member”将表示“任何成员”，但是什么是成员？当前，由于我们使用的大多数背书策略都遵循该语法，因此我们假设这意味着任何同peer？但是，还有“ MSP.peer”的示例。
由于这是一项签注策略，在此策略中，它会检查是否已批准交易，何时使用“ admin”和“ client”？ （因为管理员或客户似乎不太可能认可交易）。
关于何时使用成员，管理员，客户和对等方的背书策略是否有明确的指南？
答案 0 :(得分：1)
Fabric网络的成员是区块链网络上的用户。通常，成员表示组织。
以下官方文档中的示例表示，要使交易获得认可并发送给订购者，每个组织的用户都必须签名/认可。
AND('Org1.member', 'Org2.member', 'Org3.member') requests 1 signature from each of the three principals
管理员是成员上一级。管理员可以在网络中添加和删除成员，以及修改成员设置。
对等可以是背书的对等人或不背书但提交事务的常规对等人。
客户通常是在区块链网络上调用智能合约的组织。
答案 1 :(得分：0)
admin：具有代表该组织添加/删除对等方，部署链码，创建和加入渠道等的用户角色。
客户：如果身份提交交易，查询对等等（例如您的应用程序），则应将其归类为客户
peer：对等身份：如果其认可或提交交易，则应将其分类为对等身份。 （例如背书人，对等方提交）
答案 2 :(得分：0)
在您的组织中，您将拥有角色，并且每个角色都将具有其特权。对于策略认可，角色只有四种类型：成员，客户端，对等和管理员，并且认可策略可以是：
OR（'Org1.admin'，AND（'Org1.member'，'Org1.member'））
这意味着，先前在Org1中实例化的链码交易可以由一名Org1的管理员或两名成员认可。在Fabric环境中，您可以设置哪些对等方可以验证和认可交易，并且使用Fabric CA提供的MSP，可以设置对等方允许使用哪个角色。您可以了解有关here的更多信息。
在Fabric CA中，您可以在组织中注册和注册新身份。每个身份都有一个角色和一个属性，例如，您作为Amazon Programing Department的管理员，您可以注册，赋予一个角色和一个属性以在编程部门中注册新用户。这与对等方的工作原理相同，您可以注册新的对等方身份并为其赋予一个角色（成员，管理员，客户端和对等方）here
学分：亚历山大·雅明