chaincode提交期间Hyperledger Fabric 2.0背书失败

Question

我正在使用Fabric 2.0，并试图将链码提交给一个通道。但我得到错误：事务无效，状态为(ENDORSEMENT_POLICY_FAILURE)。订货者的日志如下：

2020-04-24 12:50:08.213 UTC [policies] SignatureSetToValidIdentities -> DEBU 5a6 signature for identity 0 validated
2020-04-24 12:50:08.213 UTC [cauthdsl] func1 -> DEBU 5a7 0xc000ca2ad0 gate 1587732608213658142 evaluation starts
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5a8 0xc000ca2ad0 signed by 0 principal evaluation starts (used [false])
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5a9 0xc000ca2ad0 processing identity 0 - &{MyOrgMSP da7c5ecfa6c3070127f5e36c5f39500c4f826af8f0b879f86e849b82058cc378}
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5aa 0xc000ca2ad0 principal evaluation succeeds for identity 0
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5ab 0xc000ca2ad0 signed by 1 principal evaluation starts (used [true])
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5ac 0xc000ca2ad0 skipping identity 0 because it has already been used
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5ad 0xc000ca2ad0 principal evaluation fails
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5ae 0xc000ca2ad0 signed by 2 principal evaluation starts (used [true])
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5af 0xc000ca2ad0 skipping identity 0 because it has already been used
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5b0 0xc000ca2ad0 principal evaluation fails
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5b1 0xc000ca2ad0 signed by 3 principal evaluation starts (used [true])
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5b2 0xc000ca2ad0 skipping identity 0 because it has already been used
2020-04-24 12:50:08.213 UTC [cauthdsl] func2 -> DEBU 5b3 0xc000ca2ad0 principal evaluation fails
2020-04-24 12:50:08.213 UTC [cauthdsl] func1 -> DEBU 5b4 0xc000ca2ad0 gate 1587732608213658142 evaluation succeeds
2020-04-24 12:50:08.213 UTC [policies] EvaluateSignedData -> DEBU 5b5 Signature set satisfies policy /Channel/Application/MyOrgMSP/Writers
2020-04-24 12:50:08.213 UTC [policies] EvaluateSignedData -> DEBU 5b6 == Done Evaluating *cauthdsl.policy Policy /Channel/Application/MyOrgMSP/Writers
2020-04-24 12:50:08.213 UTC [policies] EvaluateSignedData -> DEBU 5b7 Signature set satisfies policy /Channel/Application/Writers
2020-04-24 12:50:08.213 UTC [policies] EvaluateSignedData -> DEBU 5b8 == Done Evaluating *policies.ImplicitMetaPolicy Policy /Channel/Application/Writers
2020-04-24 12:50:08.213 UTC [policies] EvaluateSignedData -> DEBU 5b9 Signature set satisfies policy /Channel/Writers
2020-04-24 12:50:08.213 UTC [policies] EvaluateSignedData -> DEBU 5ba == Done Evaluating *policies.ImplicitMetaPolicy Policy /Channel/Writers

标识似乎是有效的，在我的configtx.yaml中，我像这样配置了LifecyCleEndorsment:

LifecycleEndorsement:
         Type: Signature
         Rule: "OR('MyOrgMSP.admin')"

因此，我希望只使用MyOrg的管理员标识就能成功提交链码（我只在这个组织中批准了链码定义）。你知道吗？我认为LifecycleEndorsment策略没有被评估，我不明白为什么。

Answer 1

在邮件列表中，我重复了这个答案：认可是由处理事务的对等方完成的，而不是提交事务的客户端。因此，在背书和LifecyCle背书策略中，您必须指定一组组织对等方，而不是组织管理员。

因此，我将规则更改为“或('myorgmsp.peer')”，现在它可以工作了。