即使在 Hyperledger Fabric v1.4 中背书策略失败后也会提交块
Block Committed Even After Endorsement Policy Failure In Hyperledger Fabric v1.4
我已将背书政策设置为“AND ('Org1MSP.peer','OrgMainMSP.peer')”,这意味着我需要两个组织的证书才能执行交易成功。
交易执行如下:
peer chaincode invoke -o orderer0.org.com:7050 --tls --cafile
/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/org.com/orderers/orderer0.org.com/msp/tlscacerts/tlsca.org.com-cert.pem
-n accessControl --peerAddresses peer0.org-main.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org-main.com/peers/peer0.org-main.com/tls/ca.crt
--peerAddresses peer0.org1.com:10051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.com/peers/peer0.org1.com/tls/ca.crt
-c '{"Args":[]}'
一切正常。成功提交了一个新块,也可以在 couchdb 上看到。但是当我发送交易删除其中一个证书时,如下所示:
"peer chaincode invoke -o orderer0.org.com:7050 --tls --cafile
/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/org.com/orderers/orderer0.org.com/msp/tlscacerts/tlsca.org.com-cert.pem
-n accessControl --peerAddresses peer0.org-main.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org-main.com/peers/peer0.org-main.com/tls/ca.crt
-c '{"Args":[]}' "
新块已通过事务提交,但被提交者标记为无效,并在日志中显示以下错误消息
peer0.org-main.com | 2020-03-20 07:59:30.868 UTC [vscc] Validate ->
ERRO 094 VSCC error: stateBasedValidator.Validate failed, err
validation of endorsement policy for chaincode accessControl in tx 7:0
failed: signature set did not satisfy policy
peer0.org-main.com | 2020-03-20 07:59:30.868 UTC [valimpl]
preprocessProtoBlock -> WARN 097 Channel [myc]: Block [7] Transaction
index [0] TxId
[01246b27c11f94124aee3c4ac84a011be51a26aaa50fc28f1d6f5f5a8860c079]
marked as invalid by committer. Reason code
[ENDORSEMENT_POLICY_FAILURE]
peer0.org-main.com | 2020-03-20 07:59:31.156 UTC [kvledger]
CommitWithPvtData -> INFO 098 [myc] Committed block [7] with 1
transaction(s) in 287ms (state_validation=0ms
block_and_pvtdata_commit=220ms state_commit=17ms)
commitHash=[9d52225ddbc8f6f98edd37388cbcf369fea22666b9ec1cff1a91debdebc2d2a1]
当我再次提交通过两个证书的交易时,它抛出一个错误
Error: could not assemble transaction: ProposalResponsePayloads do not
match - proposal response: version:1 response status:200 payload:...
>
这里的问题是,如果我错误地调用了仅传递一个组织证书的调用函数(背书策略失败),那么我将无法进行进一步的交易。
- 根据背书政策签署的交易。
没关系。块提交和状态更新。
- 交易签名与背书政策不符。
没关系。您的客户最好不要尝试提交该交易,但如果这样做,则会提交一个包含无效交易的新区块,并且不会更新状态。
ProposalResponsePayloads do not match
.
现在问题不同了。我认为这与之前的交易没有关系。签名是预期的签名,但您正在编写一个包含 2 个不匹配的交易提案的交易。他们的响应或写集是不一样的。确保您没有在链代码中使用外部调用、随机数、时间戳(交易或区块的时间戳除外)或可能在两个背书中都不匹配的类似值。当然,交易是无效的,但是一个新的区块被提交了。
我已将背书政策设置为“AND ('Org1MSP.peer','OrgMainMSP.peer')”,这意味着我需要两个组织的证书才能执行交易成功。
交易执行如下:
peer chaincode invoke -o orderer0.org.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/org.com/orderers/orderer0.org.com/msp/tlscacerts/tlsca.org.com-cert.pem -n accessControl --peerAddresses peer0.org-main.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org-main.com/peers/peer0.org-main.com/tls/ca.crt --peerAddresses peer0.org1.com:10051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.com/peers/peer0.org1.com/tls/ca.crt -c '{"Args":[]}'
一切正常。成功提交了一个新块,也可以在 couchdb 上看到。但是当我发送交易删除其中一个证书时,如下所示:
"peer chaincode invoke -o orderer0.org.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/org.com/orderers/orderer0.org.com/msp/tlscacerts/tlsca.org.com-cert.pem -n accessControl --peerAddresses peer0.org-main.com:7051 --tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org-main.com/peers/peer0.org-main.com/tls/ca.crt -c '{"Args":[]}' "
新块已通过事务提交,但被提交者标记为无效,并在日志中显示以下错误消息
peer0.org-main.com | 2020-03-20 07:59:30.868 UTC [vscc] Validate -> ERRO 094 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode accessControl in tx 7:0 failed: signature set did not satisfy policy
peer0.org-main.com | 2020-03-20 07:59:30.868 UTC [valimpl] preprocessProtoBlock -> WARN 097 Channel [myc]: Block [7] Transaction index [0] TxId [01246b27c11f94124aee3c4ac84a011be51a26aaa50fc28f1d6f5f5a8860c079] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
peer0.org-main.com | 2020-03-20 07:59:31.156 UTC [kvledger] CommitWithPvtData -> INFO 098 [myc] Committed block [7] with 1 transaction(s) in 287ms (state_validation=0ms block_and_pvtdata_commit=220ms state_commit=17ms) commitHash=[9d52225ddbc8f6f98edd37388cbcf369fea22666b9ec1cff1a91debdebc2d2a1]
当我再次提交通过两个证书的交易时,它抛出一个错误
Error: could not assemble transaction: ProposalResponsePayloads do not match - proposal response: version:1 response status:200 payload:... >
这里的问题是,如果我错误地调用了仅传递一个组织证书的调用函数(背书策略失败),那么我将无法进行进一步的交易。
- 根据背书政策签署的交易。
没关系。块提交和状态更新。
- 交易签名与背书政策不符。
没关系。您的客户最好不要尝试提交该交易,但如果这样做,则会提交一个包含无效交易的新区块,并且不会更新状态。
ProposalResponsePayloads do not match
.
现在问题不同了。我认为这与之前的交易没有关系。签名是预期的签名,但您正在编写一个包含 2 个不匹配的交易提案的交易。他们的响应或写集是不一样的。确保您没有在链代码中使用外部调用、随机数、时间戳(交易或区块的时间戳除外)或可能在两个背书中都不匹配的类似值。当然,交易是无效的,但是一个新的区块被提交了。