fabric2.0官方文档翻译：使用Identity Mixer的MSP实现
https://hyperledger-fabric.readthedocs.io/en/release-2.0/idemix.html
使用Identity Mixer的MSP实现
什么是Idemix？
Idemix是一种加密协议套件，可提供强大的身份验证以及隐私保护功能，例如匿名性（交易时不透露交易者身份的能力）以及不可链接性（单个身份发送多个交易而不透露交易来自同一个身份的能力）。
Idemix流程涉及三个参与者：用户，发行者和 验证者。
- 发行者对一组用户属性的证明以数字证书的形式发行，以下称为“凭证”。
- 用户随后通过“ 零知识证明 ”生成证书拥有权的证明，并且可以选择性地仅公开用户选择显示的属性。该证明是零知识的，其他任何人只能够知道用户确实拥有发行者发行的一个有效凭证，而不能知道凭证的内容。
Idemix身份验证技术可以提供与标准X.509证书类似的信任模型和安全性身份证明，并且通过底层密码算法，可以有效地提供包括上述高级隐私功能。我们将在下面的技术部分中详细比较Idemix和X.509技术。
如何使用Idemix
若要了解如何将Idemix与Hyperledger Fabric结合使用，我们需要查看Idemix中哪些Fabric组件与用户，发行者和验证者相对应，如下图所示：
为了在fabric中使用Idemix,需要以下基本的三个步骤：
1：考虑发行人issuer
Fabric CA（1.3版或更高版本）可以自动用作Idemix发行者。当fabric-ca-server启动（或通过fabric-ca-server init命令初始化），在 fabric-ca-server根目录下会自动创建下面两个文件：IssuerPublicKey和IssuerRevocationPublicKey，这些文件在步骤2中是必需的。
对于开发环境，如果您不使用Fabric CA，则可以使用它们 idemixgen来创建这些文件。
2：考虑验证者
您需要使用第1步创建的IssuerPublicKey和 IssuerRevocationPublicKey创建一个Idemix MSP 。
例如，参考以下从Hyperledger Java SDK示例的configtx.yaml中摘录的：
将msptype设置为idemix，mspdir 目录（crypto-config/peerOrganizations/org3.example.com/msp）下包含IssuerPublicKey和IssuerRevocationPublicKey 文件。
请注意，在此示例中，Org1Idemix代表具有X509 证书MSP的组织Org1 （示例中未介绍）的Idemix MSP 。
3：考虑用户
要将Idemix与Java SDK（用户的API）一起使用，只需要一个附加的API调用即可： 为org.hyperledger.fabric_ca.sdk.HFCAClient类增加一个idemixEnroll方法。例如，假设 hfcaClient你HFCAClient对象，并x509Enrollment为您 org.hyperledger.fabric.sdk.Enrollment与您的X509证书相关联。
以下调用将返回一个与你的Idemix凭证相关联的org.hyperledger.fabric.sdk.Enrollment 对象。 （参数hfcaClient 是你的HFCAClient对象；x509Enrollment是一个与你的X509证书相关联的 org.hyperledger.fabric.sdk.Enrollment对象）
返回的Idemix凭证和传入的x509Enrollment是相对应的，并且两者都实现了org.hyperledger.fabric.sdk.Enrollment接口，具有相同的身份证明功能，只是后者增加了隐私性和不可链接性。
Idemix和Chaincode
了解了Idemix发行者（CA或idemixgen）、获取Idemix凭证的方式、验证者(Idemix MSP)设置，从验证者的角度来看，还有一个部分需要考虑：chaincode。使用Idemix凭证时，chaincode可以从中了解到有关交易者的哪些信息？
在CID（客户端标识）库 （用于golang只），已经扩展到在使用Idemix凭证时支持GetAttributeValue方法。但是，如下面“当前限制”部分所述，使用Idemix时，该方法也只能获取两个属性：ou和role。
如果Fabric CA是证书颁发者：
ou属性的值是身份的 从属关系affiliation（例如“ org1.department1”）；
该role属性的值将为“ member”或“ admin”。值“ admin”表示该身份是MSP管理员。默认情况下，Fabric CA创建的身份将返回“member”角色。为了创建“管理员”身份，请使用role属性和值注册该身份2。
有关在Java SDK中获取匿名证书时设置从属关系 affiliation的示例，请参见此示例https://github.com/hyperledger/fabric-sdk-java/blob/master/src/test/java/org/hyperledger/fabric/sdkintegration/End2endIdemixIT.java#L121。
（509证书中的OUs或者role属性怎么设置？509证书中的OUs或者role与匿名证书中的OUs或ROLE有什么关系？一个普通用户角色的509证书可以申请admin角色的匿名证书吗）
有关在go chaincode中使用CID库检索属性的示例，请参见 https://github.com/hyperledger/fabric-sdk-java/blob/master/src/test/fixture/sdkintegration/gocc/sampleIdemix/src/github.com/example_cc/example_cc.go#L88。
Idemix组织不能用于背书链码或批准链码定义（因为背书时要将交易提案发给背书节点，而我们不能获得idemix组织节点的地址？）。在您的频道上设置LifecycleEndorsement和Endorsement策略时，必须考虑到这一点。有关更多信息，请参见下面的限制部分。
——————————————————————————————————————————————————未校对分割线
当前限制
当前版本的Idemix确实有一些限制。
Idemix组织和认可政策
Idemix组织不能用于认可链码交易或批准链码定义。默认情况下， Channel/Application/LifecycleEndorsementand Channel/Application/Endorsement策略将要求该渠道上活跃的大多数组织的签名。这意味着包含大量Idemix组织的渠道可能无法达到实现默认策略所需的多数。例如，如果某个渠道有两个MSP组织和两个Idemix组织，则渠道政策将要求四个组织中的三个批准链码定义，以将该定义提交给该渠道。由于Idemix组织无法批准链码定义，因此该策略将只能验证四个签名中的两个。
如果您的频道包含足够数量的Idemix组织来影响认可策略，则可以使用签名策略来明确指定所需的MSP组织。
固定属性集
尚无法颁发或使用具有自定义属性的Idemix凭据。在将来的版本中将支持自定义属性。
当前支持以下四个属性：
组织单位属性（“ ou”）：
用法：与X.509相同
类型：字符串
显示：始终
角色属性（“角色”）：
用法：与X.509相同
类型：整数
显示：始终
注册ID属性
用法：唯一地标识一个用户-在属于同一用户的所有注册凭证中都相同（将在以后的版本中用于审核）
类型：大
揭示：从不在签名中，仅在为Fabric CA生成身份验证令牌时
吊销句柄属性
用法：唯一地标识一个凭证（将在以后的版本中用于撤销）
类型：整数
显露：从不
尚不支持吊销
尽管可以通过上面提到的撤消句柄属性看到很多撤消框架，但是尚未支持Idemix凭据的撤消。
peer不使用Idemix进行背书
当前，peer节点的Idemix MSP仅用于签名验证（比如匿名身份要在peer节点进行链码安装，peer节点使用idemix MSP对该身份进行验证？）。仅通过客户端SDK才能使用Idemix凭证进行签名。Idemix MSP将支持更多角色（包括“对等”角色）。
技术摘要
将Idemix凭据与X.509证书进行比较
证书/证书的概念和颁发过程在Idemix和X.509证书中非常相似：一组属性是用无法伪造的签名进行数字签名的，并且存在一个密钥，证书将其与密码进行绑定。
标准X.509证书和Identity Mixer证书之间的主要区别是用于认证属性的签名方案。身份混合器系统基础的签名允许有效地证明拥有签名和相应的属性，而无需透露签名和（选定的）属性值本身。我们使用零知识证明来确保不会泄露这种“知识”或“信息”，同时确保对某些属性的签名有效并且用户拥有相应的凭据秘密密钥。
这种证明如X.509证书一样可以使用原始签署证书的授权机构的公钥进行验证，且无法伪造，只有知道凭证秘密密钥的用户才能生成有关凭证及其属性的证明。
关于不可链接性，当提供X.509证书时，必须显示所有属性以验证证书签名。这意味着用于签署交易的所有证书用法都是可链接的。
为了避免这种可链接性，每次都需要使用新的X.509证书，这将导致复杂的密钥管理以及通信和存储开销。此外，在某些情况下，甚至颁发证书的CA都不能将所有交易链接到用户也很重要。
Idemix有助于避免相对于CA和验证者的可链接性，因为即使CA也无法将证明链接到原始凭证。发行者或验证者都无法分辨两个证据是否来自同一证书（或来自两个不同的证书）。
有关身份混合器技术的概念和功能的更多详细信息，请参见论文《基于隐私保护属性的身份验证的概念和语言》。
拓扑信息
鉴于上述限制，建议每个通道或每个网络仅包含一个基于Idemix的MSP。确实，例如，每个通道具有多个基于Idemix的MSP，将允许一方阅读该通道的分类帐，区分属于不同基于Idemix的MSP的各方签署的交易。这是因为，每个事务都会泄漏签名者的MSP-ID。换句话说，Idemix当前仅提供同一组织（MSP）中客户的匿名性。
将来，可以将Idemix扩展为支持基于Idemix的证书颁发机构的匿名层次结构，该证书颁发机构的证书可以通过使用唯一的公钥进行验证，从而实现跨组织（MSP）的匿名性。这将允许多个基于Idemix的MSP在同一通道中共存。
原则上，可以将通道配置为具有单个基于Idemix的MSP和多个基于X.509的MSP。当然，这些MSP之间的交互作用可能会泄漏信息。对泄漏信息的评估需要逐案进行。
基础加密协议
Idemix技术是基于盲签名方案构建的，该方案支持多条消息以及有效的零知识证明拥有签名。Idemix的所有密码构建块均在顶级会议和期刊上发布，并经过科学界的验证。
这种针对Fabric的特殊Idemix实现使用了基于配对的签名方案，该方案由Camenisch和Lysyanskaya简要提出， 并由Au等人详细描述。。在零知识证明中证明证明签名知识的能力 Camenisch等。被使用了。