更改背书策略以要求多个成员，但不确定如何让所有同行都背书

问题描述

我的链码是使用以下命令实例化的：

peer chaincode instantiate -o orderer1.example.com:7050 --tls true --cafile <cafile> -C mychannel
-n mycc -l java -v 1.0 -c '{"Args":[]}' -P "OR ('Org1MSP.member')"

我要更改背书策略，使组织中的所有同级都需要背书；目前我有两个同级，但数量设置为增加。

我现在要做的是以下步骤：

第一步：使用不同的版本名称安装相同的链码。

peer chaincode install -n mycc -v <version> -l java -p /opt/gopath/src/github.com/chaincode

第二步：使用以下命令升级链码：

peer chaincode upgrade -o orderer1.example.com:7050 --tls true --cafile <cafile> -C mychannel
-n mycc -l java -v <version> -c '{"Args":[]}' -P "OutOf(2, 'Org1MSP.member')"
-peerAddresses peer1.org1.example.com:7051 -peerAddresses peer2.org1.example.com:7051

然而，我无法达到我想要的结果。根据目前的背书政策，当我使用我的客户提交交易时，它会在一段时间后提交。在我更改策略之后，我的事务不再被自动接受，日志反映了这一点，并显示以下错误消息：

VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode
mycc in tx 132:0 failed: signature set did not satisfy policy

因此，虽然我可以停止自动接受交易，但现在我发现自己无法验证任何交易。

1. 我更改链码背书策略所遵循的过程是否正确？

2. 我的背书策略是否做了我想做的事情？

3. 为什么我无法再验证交易？

---

编辑：我将我的日志记录规范更改为Jason Yellick建议的规范。我想我找到了一些调试程序，它可能会提供洞察力：

<time> [cauthdsl] func1 -> DEBU 4bd 0xc0004e4050 gate 1594275943563937246 evaluation starts
<time> [cauthdsl] func2 -> DEBU 4be 0xc0004e4050 signed by 0 principal evaluation starts (used [false])
<time> [cauthdsl] func2 -> DEBU 4bf 0xc0004e4050 processing identity 0 with bytes of 1159660
<time> [cauthdsl] func2 -> DEBU 4c0 0xc0004e4050 principal matched by identity 0
<time> [cauthdsl] func2 -> DEBU 4c1 0xc0004e4050 principal evaluation succeeds for identity 0
<time> [cauthdsl] func2 -> DEBU 4c2 0xc0004e4050 signed by 1 principal evaluation starts (used [true])
<time> [cauthdsl] func2 -> DEBU 4c3 0xc0004e4050 skipping identity 0 because it has already been used
<time> [cauthdsl] func2 -> DEBU 4c4 0xc0004e4050 principal evaluation fails
<time> [cauthdsl] func1 -> DEBU 4c5 0xc0004e4050 gate 1594275943563937246 evaluation fails
<time> [vscc] Validate -> ERRO 4c6 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [vscc] Validate -> DEBU 4c7 block 140, namespace: myteacc, tx 0 validation results is: validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [committer.txvalidator] ValidateWithPlugin -> DEBU 4c8 Transaction 1d8f66a10658c3d808ad4ce0feef9fd5c13816187a39fcedc8a32ce91016df0d appears to be invalid: validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [committer.txvalidator] validateTx -> ERRO 4c9 VSCCValidateTx for transaction txId = 1d8f66a10658c3d808ad4ce0feef9fd5c13816187a39fcedc8a32ce91016df0d returned error: validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [committer.txvalidator] validateTx -> DEBU 4ca [isprintchannel] validateTx completes for block 0xc0026306c0 env 0xc00245e190 txn 0

这是策略设置为AND('Org1MSP.member','Org1MSP.member')

的情况

推荐答案

您的背书政策无法满足。在您的升级命令中：

您可以看到您的策略是：

此背书政策要求%1个身份中的%2个必须签署"；。这是永远不能满足的，因为你的签名永远不会比原则多。它实质上是说，从一件事中挑出两件，这是矛盾的。如果您确实需要来自同一组织的两个对等机，则需要编写：

或者，您可以简单地使用AND语法：

我要指出的是，要求来自同一组织的多个对等体进行背书的情况并不常见，如果您采用这种方式，则需要小心进行证书管理。特别地，如果您使用Fabric-CA，则必须确保对等身份只能注册一次，否则它可以重新注册，并且现在具有两个有效的身份，并且能够假装为两个不同的对等身份。同样，如果必须重新颁发标识，请小心确保吊销旧证书。

您可以考虑改为定义第二个逻辑组织，并使用两个不同的逻辑组织编写策略，例如：

这是操作Fabric的一种更为传统的方式。

这篇关于更改背书策略以要求多个成员，但不确定如何让所有同行都背书的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！