Ошибка средства проверки политики одобрения фабрики Hyperledger

На основании ролей равноправия и порядка вы можете иметь ошибку в проверке политики.

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

Политика одобрения указана в узле 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}
]
}
}

Вызвать транзакцию с узлом sdk e2e func invokeChaincode в 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

Проблема в заказе или добавлении пиров. Мы ожидаем, что порядок добавления коллег не должен влиять на результаты одобрения.

Источник

1 ответ

Проверка политики одобрения

Поведение средства проверки политики, когда политика одобрения требует, чтобы оба участника - "администратор" и "участник" - одной и той же организации, некоторые действительные одобрения могут не пройти проверку политики.

Чтобы проиллюстрировать это, давайте использовать следующий пример:

  • У вас есть два одобрения: endorser1 как участник в org1 (E1) и endorser2 как администратор в org1 (E2)

  • У вас есть политика одобрения: "И (org1.member, org1.admin)" или когда она указана в формате JSON, используемом с node.js SDK:

    {"identity": [ { "role": { "name": "member", "mspId": "org1" }, { "role": { "name": "admin", "mspId": "org1" }], "2-из": [{"подписано": 0 }, { "подписано": 1 ] }

Текущее поведение средства проверки политики зависит от порядка двух принципалов MSP в политике подтверждения. Вот описание текущей реализации:

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."

Работа вокруг

Всегда указывайте идентификатор администратора в политике перед идентификатором члена той же организации, который всегда будет работать независимо от порядка индоссантов.

Дальнейшие технические детали можно найти в FAB-4248

Источник
Другие вопросы по тегам