Проблема производительности 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
                        }

Для ответа требуется около 2500 мс, как вы можете видеть на скриншоте почтальона ниже:

Поправь меня, если я ошибаюсь

Я знаю, что это занимает время, потому что orderer подтверждает транзакцию и фиксирует в ledger. Но разве вы не думаете, что мы должны действовать, только если orderer согласен на транзакцию и подтвердит ledger. Если да, то для ответа потребуется 2,5 секунды (сеть работает на докере на локальном компьютере и sdk на том же компьютере), что является проблемой производительности.

Что произойдет, если данные будут записаны в код цепи и после этого заказчики откажутся записать транзакцию в книгу?

Буду признателен за любую помощь

Answer 1

Я нашел другую причину этой задержки.

Переменная batchtimeout в configtx.yaml установлена ​​на 2 секунды. Таким образом, он выполнит свою обработку, затем подождет 2 секунды, а затем отрежет блок. Таким образом, для операции записи требуется примерно 2,5 секунды.

Answer 2

заказчик подтверждает транзакцию и фиксирует ее в регистре.

Задача службы Ordering (как следует из названия) состоит только в том, чтобы упорядочить полученные подтвержденные транзакции в хронологическом порядке по каналам и затем доставить их всем партнерам в канале. На самом деле заказчики не фиксируют транзакции в бухгалтерской книге.

Узел равноправный do. И фиксация занимает много времени, так как все одноранговые узлы проверяют все транзакции в блоке, чтобы убедиться, что политика одобрения выполнена, и убедиться, что не было никаких изменений в состоянии бухгалтерской книги для переменных набора чтения, так как набор чтения был сгенерирован транзакцией. выполнение. Транзакции в блоке помечаются как действительные или недействительные. Затем каждый узел добавляет блок в цепочку канала, и для каждой действительной транзакции наборы записи фиксируются в базе данных текущего состояния. Событие отправляется , чтобы уведомить клиентское приложение о том, что транзакция (вызов) была неизменно добавлена ​​в цепочку, а также уведомление о том, была ли транзакция подтверждена или признана недействительной.

Поэтому, зная все эти детали в Потоке транзакций , следует отметить, что клиентское приложение не должно ждать ответа, полученного заказчиком. Вместо этого он должен просто запросить у заказчика доставить одобренные транзакции, и приложение должно быть подписано на события, генерируемые одноранговыми узлами, чтобы оно могло знать или получать уведомление о том, что транзакции фактически являются неизменными в цепочке канала.

Дополнительную информацию о подписке на события можно получить в документах Fabric Node SDK .

Что произойдет, если данные будут записаны в код цепи и после этого заказчики отказывают в записи транзакции в книгу?

Это просто невозможно, поскольку данные добавляются в цепочку только тогда, когда транзакция проверяется посредством надлежащих подтверждений от одноранговых узлов-индоссантов (указанных в политике одобрения), а затем, наконец, доставляется одноранговым узлам-коммиттерам для добавления новых значений в цепочку. и обновить мировое состояние. Данные записываются в цепочку только после того, как они проходят все проверки, и, следовательно, заказчик никогда не может отрицать изменения, внесенные в данные.