Hyperledger Fabri c 2.0 Ошибка подтверждения при фиксации кода

Question

Я использую Fabri c 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 не оценивается, и я не могу понять, почему.

Answer 1

В списке рассылки я получил этот ответ: одобрение выполняется партнером, который обрабатывает транзакцию, а не клиентом, который отправил транзакцию. Поэтому в политиках Endorsement и LifecycleEndorsement необходимо указать набор участников org, а не администраторов org.

Поэтому я изменил правило на «OR ('MyOrgMSP.peer')», и теперь оно работает.