Question

我的链码已通过以下命令实例化：

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

因此，尽管我能够停止自动接受交易，但现在发现自己无法验证任何交易。

我更改链码认可政策的过程是否正确？
我的背书政策会做我打算做的事吗？
为什么我不再能够验证交易？

编辑：我将日志记录规范更改为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')

Answer 1

您的认可政策不令人满意。在升级命令中：

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

您会看到您的政策是：

-P "OutOf(2, 'Org1MSP.member')"

此认可政策要求“必须在1个身份中签名2个”。这永远无法满足，因为您永远不能拥有比原理更多的签名。本质上是在说“从一件东西中挑出两件”，这是一个矛盾。如果您确实需要来自同一组织的两个同行，那么您将需要编写：

-P "OutOf(2, 'Org1MSP.member', 'Org1MSP.member')"

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

-P "AND('Org1MSP.member', 'Org1MSP.member')"

我要指出，要求来自同一组织的多个对等方认可是不寻常的，如果您采用这种方法，则在证书管理中需要格外小心。特别是，如果您使用的是fabric-ca，则必须确保对等方身份只能注册一次，否则可以重新注册并现在具有两个有效身份，并且可以假装为两个不同的对等方。同样，如果必须重新颁发身份，请注意确保吊销旧证书。

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

-P "AND('Org1MSP.member', 'Org2MSP.member')"

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

更改背书政策以要求有多个成员，但不确定如何让所有同龄人背书

1 个答案: