Выполнение внешнего вызова API из смарт-контракта фабрики Hyperledger технически возможно, это рискованная идея по нескольким причинам:
1) цепной код должен быть детерминированным, а проблема с «обогащением» транзакции с использованиемвнешний API заключается в том, что он должен возвращать один и тот же результат, выполняемый в любом месте в бизнес-сети, которая вполне может работать в глобальном масштабе, поэтому вы должны верить, что ответы будут одинаковыми в пределах временных окон, которые немного шире, чемнесколько мс 2) запуск только одного индоссанта в разработке и production помогает вам обойти эту проблему, но немного ослабляет консенсус и делает практически невозможным доказать детерминизм для любой конкретной транзакции 3) разработка такой ослабленной системыэто не очень хорошая идея, так как неизбежно кто-то поймет, что политика одобрения должна быть более сильной, и вы вернетесь к проблемам, указанным в пункте 1
. Одним из способов решения этой проблемы является использование распределенного внешнего API с версионными данными.(а также вам может потребоваться написать оракула для предоставления этой возможности поверх API, который не поддерживает управление версиями своих данных), чтобы все индоссанты сохраняли текущую версию внешних данных в хранилище ресурсов также в мировом состоянии.Это гарантирует, что считанные данные идентичны и учитывают задержки в распространении в сети оракула.Присутствие версии данных API в окончательных данных активов в мировом состоянии (точнее, в наборе для чтения / записи для транзакции) гарантирует, что разные версии данных в разных регионах оракула (например, задержки распространения) потерпят неудачу в любойполитика одобрения.Конечно, клиент, разработанный в такой среде, может повторно отправить транзакцию для одобрения, чтобы получить консенсус.