首页 > 解决方案 > 链码提交期间的 Hyperledger Fabric 2.0 背书失败

问题描述

我正在使用 Fabric 2.0,并且正在尝试将链码提交到通道。但我明白了Error: transaction invalidated with status (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 政策没有被评估,我不明白为什么。

标签: hyperledger-fabrichyperledger-chaincode

解决方案


在邮件列表中,我收到了这个答案:背书由处理交易的对等方完成,而不是提交交易的客户端。因此,在 Endorsement 和 LifecycleEndorsement 策略中,您必须指定一组组织同行,而不是组织管理员。

所以我将规则更改为“OR('MyOrgMSP.peer')”,现在它可以工作了。


推荐阅读