Последующие транзакции не обновляют бухгалтерскую книгу в Hyperledger Fabric, приводят к значительному состоянию

Question

Я работаю над небольшим проектом, чтобы познакомиться с Hyperledger Fabric .

В настоящее время у меня есть небольшая сеть, состоящая из одноранговых узлов, узлов-заказчиков и узлов ca (плюс cli, chaincode и explorer), определенных в docker-compose.yml

Я установил образец цепного кода, chaincode_example02 , чтобы быть более точным Начальное состояние регистра A: 100, B: 200, определяется как

peer chaincode instantiate -n mycc -v 0 -c '{"Args":["init","a","100","b","200"]}' -C myc

Когда я выполняю перевод, все работает как положено

peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}' -C myc

То есть 10 единиц переводятся из А в В

НО когда я запускаю, скажем, 3 транзакции,

for i in {1..3}
do
    peer chaincode invoke -n mycc -c '{"Args":["invoke","a","b","10"]}' -C myc
done

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

У меня вопрос: нужно ли прибегать к высокопроизводительному решению для получения детерминированных транзакций? Или есть другой способ добиться этого (например, с помощью событий)?

Answer 1

Наличие этих трех транзакций в одном и том же блоке будет означать, что успешна только одна, поскольку все три из них записывают в один и тот же ключ. Транзакция, которая должна быть выполнена, является первой, а две оставшиеся будут считаться одновременными и, следовательно, признанными недействительными.

Результатом моделирования / вызова цепного кода является набор «Чтение-запись», в котором он содержит ключи, значения и версию модификации. Транзакции, пытающиеся изменить ключ с такой же или устаревшей версией, не проходят проверку MVCC (Multi Value Concurrency Control) во время фиксации блока.