1

I'm using Fabric 2.0 and I'm trying to commit a chaincode to a channel. But I get Error: transaction invalidated with status (ENDORSEMENT_POLICY_FAILURE). The orderer's logs are these: 

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

It seems that the identity is valid, in my configtx.yaml I have configured the LifecycleEndorsment like this: 

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

So I'm expecting to successfully commit the chaincode using only the admin identity of MyOrg (I've approved the chaincode definition only with this organization). Any idea? I think that the LifecycleEndorsment policy is not being evaluated and I can't understand why.

ultracode
  • 107
  • 1
  • 8
  • What are the other policies in `configtx.yaml` file? – Chintan Rajvir Apr 25 '20 at 06:31
  • The other policies have the default settings, so in the Application/Policies I have: ```Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" Endorsement: Type: ImplicitMeta Rule: "MAJORITY Endorsement" LifecycleEndorsement: Type: Signature Rule: "OR('MyOrgMSP.admin')"``` – ultracode Apr 27 '20 at 06:36

1 Answers1

0

In the mailing list I've recived this answer: Endorsement is done by the peer that processes the transaction, not the client that submitted the transaction. Therefore in the Endorsement and LifecycleEndorsement policies, you must specify a set of org peers, not org admins.

So I changed the rule to "OR('MyOrgMSP.peer')" and now it works.

ultracode
  • 107
  • 1
  • 8