CODEWITHSUNDEEP
sdkhyperledger
Mark P
Mark P

Reputation: 221

Hyperledger Fabric Endorsement Policy checker failure

Based on peer roles and the order you might have a failure in the policy checker.

Peer roles:
org1peer1:member
org1peer2:member
org2peer1:admin
org2peer2:member`

Endorsement policy specified in node sdk e2eUtils.js

'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: ORGS['org1'].mspid }},
{ role: { name: 'member', mspId: ORGS['org2'].mspid }},
{ role: { name: 'admin', mspId: ORGS['org1'].mspid }},
{ role: { name: 'admin', mspId: ORGS['org2'].mspid }}
],
policy: {
'2-of': [
  { 'signed-by': 1},
  { 'signed-by': 3}
]
}
}

Invoke transaction with node sdk e2e func invokeChaincode in e2eUtils.js

send endorsement responses with order (Org2Member,Org2Admin) -> SUCCESS
send endorsement responses with order (Org2Admin, Org2Member) -> ENDORSEMENT_POLICY_FAILURE
only send proposal to Org2Admin, and make another copy of response from Org2Admin, to make it (Org2Admin, Org2Admin) -> SUCCESS

The problem is the order or adding peers matters. We would expect the order of adding peers should not affect endorsement results.

Upvotes: 0

Views: 1288

Answers (1)

Mark P
Mark P

Reputation: 221

Endorsement Policy Checker

The behavior of the policy checker, when endorsement policy requires both the "admin" and "member" principals of the same organization, certain valid endorsements may fail the policy check.

To illustrate this let's use the following example:

  • You have two endorsements: endorser1 as a member in org1 (E1) and endorser2 as an admin in org1 (E2)

  • You have the endorsement policy: "AND (org1.member, org1.admin)" or when specified in the JSON format used with the node.js SDK:

    { "identities": [ { "role": { "name": "member", "mspId": "org1" }, { "role": { "name": "admin", "mspId": "org1" }], "2-of": [ { "signed-by": 0 }, { "signed-by": 1 ] }

The current behavior of the policy checker depends on the order of the two MSP principals in the endorsement policy. Here's a description of the current implementation:

If the policy is similar to the code illustrated above, where the "member"
role is put ahead of the "admin" role of the same organization. AND the
policy requires both roles to be satisfied. Then the policy check will fail.

If the order of the endorsements inside the ProposalResponsePayload is
flipped. Meaning that E2 comes before E1, then the policy check will succeed.

However, if the "admin" role is put ahead of the "member" role, then the
policy check always succeeds regardless of the order of the endorsements."

Work around

Always specify admin identity in the policy before the member identity of the same org, which will always work regardless of the order of the endorsers.

Further technical detail can be located in FAB-4248

Upvotes: 1

Related Questions