Hyperledger Fabric nodejs sdk 性能问题

Question

我在使用 Hyperledger fabric node.js sdk 时遇到性能问题。

当我向 sdk 发出调用请求并使用以下代码使用链码给出的响应时

var proposalResponse = results[0];
            var proposal = results[1];
            let isProposalGood = false;

            if(proposalResponse
                && proposalResponse[0].response
                && proposalResponse[0].response.status === 200){
                    isProposalGood = true;
                    var res = JSON.parse(proposalResponse[0].response.payload.toString());
                            res.event_status = 'VALID'
                            resolve(res);
                }else{
                    reject(createErrorResponse(proposalResponse[0].message,500))
                    return
                }

api 会在 50 毫秒内做出响应，如下图所示：

但是，当我使用以下代码等待订购者确认交易时：

if (code === 'VALID'){
                            //get payload from proposal response
                            var res = JSON.parse(proposalResponse[0].response.payload.toString());
                            res.event_status = 'VALID'
                            resolve(res);
                        }else{
                            var return_status = createErrorResponse("Transaction was not valid", 500);
                            return_status.tx_id = transaction_id_string
                            reject(return_status)
                            return
                        }

响应时间接近2500ms，如下邮递员截图：

如有错误请指正

我知道这需要时间，因为 orderer 确认交易并提交到 ledger。但是你不认为只有 orderer 同意交易并提交给 ledger 我们才应该继续。如果是，则需要 2.5 秒才能响应（网络在 docker 上运行在本地计算机和 sdk 在同一台计算机上）这是一个性能问题。

如果数据被写入链代码，然后排序者拒绝将交易写入账本，会发生什么情况？

如有任何帮助，我们将不胜感激

Answer 1

the orderer confirms the transaction and commits into the ledger.

排序服务（顾名思义）的任务只是将收到的背书交易按照通道的时间顺序进行排序，然后将它们传递给通道中的所有节点。排序者实际上并不将交易提交到账本中。

提交者同行 这样做。提交是一个耗时的过程，因为所有对等方都验证块内的所有交易，以确保背书政策得到履行，并确保自交易生成读取集以来，读取集变量的分类帐状态没有发生变化执行。区块中的交易被标记为有效或无效。然后每个节点将块附加到通道的链，并且对于每个有效事务，写入集都提交到当前状态数据库。 发出一个事件，以通知客户端应用程序交易（调用）已被不可变地附加到链中，以及交易是有效还是无效的通知。

所以在了解 Transaction Flow 中的所有这些细节后，应该注意客户端应用程序不应该等待订购者收到的响应。相反，它应该只请求排序者交付背书的交易，并且应用程序应该订阅节点发出的事件，以便它应该知道或被通知交易实际上是在通道链中不可变地提交的。

您可以在 Fabric Node SDK docs 中获得有关事件订阅的更多帮助。

What happen if data is written into the chaincode and after that orderers deny to write the transaction into the ledger?

这根本不可能，因为只有当交易通过背书节点（由背书策略指定）的适当背书进行验证时，数据才会附加到链中，然后最终交付给提交节点以将新值附加到链中链并更新世界状态。数据只有在通过所有验证后才会写入链中，因此排序者永远不能拒绝对数据所做的更改。

Answer 2

我找到了延迟的另一个原因。

configtx.yaml 中的 batchtimeout 变量设置为 2 秒。所以它会进行处理，然后等待 2 秒，然后切割一个块。所以写操作大约需要2.5秒。

Hyperledger Fabric nodejs sdk 性能问题

Hyperledger Fabric nodejs sdk performance issue

node.js

hyperledger-fabric