Хотя я, возможно, и не предоставляю наилучшего решения, я надеюсь поделиться некоторыми идеями и возможными обходными путями к этому вопросу.
Сначала давайте кратко объясним, почему вы получаете эту ошибку. Базовая база данных Hyperledger Fabric использует MVCC-подобную (Multi-Version Concurrency Control) модель. Примером этого могут быть два клиента, пытающиеся обновить актив версии 0 до определенного значения. Один из них будет успешным (обновит значение и увеличит номер версии в stateDB до 1), а другой выйдет из-за этой ошибки (MVCC_READ_CONFLICT) из-за несоответствия версий.
Одним из возможных решений, обсуждаемых здесь (https://medium.com/wearetheledger/hyperledger-fabric-concurrency-really-eccd901e4040), было бы создание собственной очереди FIFO между бизнес-логикой и Fabric SDK. В этом случае также может быть добавлена логика повторения.
Другим способом было бы использование дельта-концепции. Предположим, что есть актив A со значением 10 (возможно, он представляет баланс счета). Этот актив часто обновляется (скажем, обновляется в этом наборе значений 12 -> 19 -> 16) несколькими одновременными транзакциями, и вышеупомянутая ошибка легко может быть вызвана. Вместо этого мы сохраняем значение как дельты (+2 -> +7 -> -3), и итоговое агрегированное значение будет таким же в бухгалтерской книге. Но имейте в виду, что этот трюк НЕ МОЖЕТ подойти для каждого случая, и в этом примере вам также может понадобиться внимательно следить за промежуточным итогом, чтобы избежать выдачи денег, если вы оказались пустыми на своем счете. Так что это сильно зависит от типа данных и варианта использования.
Для получения дополнительной информации вы можете взглянуть на это: https://github.com/hyperledger/fabric-samples/tree/release-1.1/high-throughput