У вашего вопроса два аспекта: один - это аспект одобрения живого человека, а второй - целостность состояния бухгалтерской книги (консенсус).
Объясню в обратном порядке.
Консенсусная часть
Итак, Hyperledger Fabric - это корпоративное решение, которое нацелено на ведение последовательной бухгалтерской книги, с которой должна согласиться вся организация консорциума. Это достигается путем объединения регистров нескольких организаций в один регистр, и транзакции, записанные в этом одном регистре, будут включать транзакции от каждой стороны.
Эти транзакции не являются случайными транзакциями, а скорее являются реализацией смарт-контракта, который в терминологии Fabric называется чейнкодом. Всякий раз, когда чейнкод развертывается на канале Fabric (частная подсеть, связанная с ее собственным регистром), он инициализирует состояние мира, то есть активы по умолчанию и их значения.
Затем каждая организация согласовывает политику подтверждения, например, 1 партнер из каждой организации должен подтвердить транзакцию (в этом состоянии называется предложением транзакции), подтверждение - это просто набор для чтения-записи транзакции, имеющей набор для чтения (значения активов до транзакции моделирование), записать множество (значения активов после моделирования транзакции). Если одобрение со стороны всех одноранговых узлов (всех тех одноранговых узлов, которые удовлетворяют политике одобрения) одинаково, это означает, что мировое состояние активов согласовано для всех одноранговых узлов (по крайней мере, тех, которые удовлетворяют политике одобрения), и, следовательно, достигается целостность данных реестра.
Консенсус также включает группирование транзакций в блоки и упорядочивание транзакций внутри блока путем заказа услуги, которая снова проверяет подписи индоссантов, и проверка состояния мира выполняется в последний раз, когда блок достигает одноранговых узлов для фиксации.
Утверждение
Когда у вас есть процесс утверждения, требующий взаимодействия с участниками, вам нужно будет позаботиться об этом в своем цепном коде. Композитор - лучшее место для начала.
Из примеров Composer посмотрите на пример CarAuction, и вы поймете, что для каждого перехода между состояниями вам потребуется регистрация, например, участник-продавец владеет активом Автомобиль, но когда Автомобиль выставлен на аукцион для продажи, он должен быть добавлен в реестр листинга с помощью транзакции где это будет видно всем участникам торгов, это изменение состояния актива «Автомобиль» достигается с помощью транзакции AuctionMyCardOrSomething, инициированной авторизованной стороной здесь, продавцом. Затем, когда аукционист (другой участник с другой ролью) выполняет другую транзакцию, называемую закрытыми торгами, право собственности на автомобиль может быть передано участнику, предложившему самую высокую цену, если все условия выполнены. Узел размещения ставки также является транзакцией.
Обратите внимание на Auctioneer и переходы состояний в этом примере, и та же модель может быть применена к вашему случаю. Каждый раз, когда требуется переход между состояниями, вы должны выполнять транзакцию и обновлять регистр.
Надеюсь это поможет.
person
KKK
schedule
18.04.2018
