node.js - 为什么在 hyperledger/fabric-sdk-node 项目 test/integration/invoke.js 中的 invokeChaincode 方法需要所有 Node 在提案时得到相同的结果？

Question

在hyperledger/fabric-sdk-node项目中，test/integration/invoke.js测试文件，invokeChaincode方法。 我发现当 channel 向所有peer发送交易提案时，它会检查所有peer的响应，只有当它们都相同且状态码为200时，才会通过发送交易。

...
}).then((nothing) => {
    tx_id = client.newTransactionID(the_user);

    // send proposal to endorser
    var request = {
        chaincodeId : e2e.chaincodeId,
        fcn: 'move',
        args: ['a', 'b','100'],
        txId: tx_id,
    };
    return channel.sendTransactionProposal(request);

}, (err) => {
    t.fail('Failed to enroll user \'admin\'. ' + err);
    throw new Error('Failed to enroll user \'admin\'. ' + err);

}).then((results) => {
    var proposalResponses = results[0];

    var proposal = results[1];
    var header   = results[2];
    var all_good = true;

    for(var i in proposalResponses) {
        let one_good = false;
        let proposal_response = proposalResponses[i];
        if( proposal_response.response && proposal_response.response.status === 200) {
            t.pass('transaction proposal has response status of good');
            one_good = channel.verifyProposalResponse(proposal_response);
            if(one_good) {
                t.pass(' transaction proposal signature and endorser are valid');
            }
        } else {
            t.fail('transaction proposal was bad');
        }
        all_good = all_good & one_good;
    }
    if (all_good) {
        // check all the read/write sets to see if the same, verify that each peer
        // got the same results on the proposal
        all_good = channel.compareProposalResponseResults(proposalResponses);
        t.pass('compareProposalResponseResults exection did not throw an error');
        if(all_good){
            t.pass(' All proposals have a matching read/writes sets');
        }
        else {
            t.fail(' All proposals do not have matching read/write sets');
        }
    }
    if (all_good) {
        // check to see if all the results match
...

据我了解，我认为检查提案是排序者服务的责任，而不是同行的责任。并且并不总是需要所有 Node 的提案都是200状态码，这取决于背书 Node 的策略来决定它是否有效。 例如，如果一个对等点发生故障(该对等点不是背书对等点)，则提案将始终有一个由该对等点发送的错误。那么调用永远不会成功。 我认为这不是正确的做法，这真的很奇怪。是不是有什么问题？

Answer 1

这个想法是，为了实现(使其在提交时通过验证)需要来自多个组织的签名的背书策略，您需要多个对等点(来自不同的组织)来签署相同的有效负载。这就是进行比较的原因。

也就是说，这取决于背书政策，这是正确的。