Hyperledger Fabric — реализация типов транзакций и настройка политик подтверждения для каждого типа транзакций
В Hyperledger Fabric один актив имеет несколько транзакций. Эти транзакции обновляют состояние актива и также поддерживают трассировку.
В настоящее время, если я хочу иметь разные типы транзакций для одного актива, я написал разные функции в коде цепочки, которые соответствуют типам транзакций.
Например: если моими активами являются автомобили, то у каждого актива могут быть транзакции типа продажа, покупка, обслуживание, ремонт и т. д. Для каждой из этих покупок, ремонта, обслуживания и т. д. я написал функцию в коде цепочки, которая получает вызывается на основе типа транзакции, которая отправляется в качестве входных данных (тип транзакции отправляется в качестве аргумента в команде вызова однорангового кода цепочки).
Как вы думаете, это хороший подход? Чему вы следуете? Что рекомендуется для достижения различных типов транзакций? Кроме того, как я могу применить разные политики подтверждения для разных типов транзакций?
Примечание. Мне известны политики подтверждения на основе активов (или на основе ключей) (Fabric v1.4), которые можно записать в чейнкоде. Но это не позволяет мне настраивать политики подтверждения на основе типов транзакций.
Ответы 1
Шаблон, который вы используете, довольно типичен ... в конце концов, чейн-код - это всего лишь конечный автомат. Довольно часто разные чейнкоды представляют разные типы активов или классы активов. Обычно у вас будет несколько функций, которые управляют жизненным циклом актива (что, похоже, вы делаете). Типичный шаблон заключается в том, что первый аргумент при вызове чейнкода представляет функцию, которую вы хотите вызвать, но зависит от вас, хотите ли вы изменить этот шаблон.
С точки зрения наличия разных политик подтверждения для разных действий, предпринимаемых в одном и том же состоянии, это не поддерживается, поскольку обычно в этом нет необходимости. Вам нужно позаботиться о том, чтобы не перепутать политику одобрения (соглашение о выводе вызова) с протоколом соглашения (например, я согласен продать вам свою машину). Этот тип логики обычно обрабатывается в функции (ах) цепного кода (например, вы должны проверить, что создатель вызова на самом деле является владельцем автомобиля).
Надеюсь это поможет.
P.S. Если вы хотите иметь разные политики подтверждения для разных типов транзакций, вы, вероятно, могли бы использовать подтверждение на основе состояния ... политики в любом случае устанавливаются через код цепочки ... поэтому вы можете попытаться установить политику подтверждения для каждого состояния на основе Тип операции.
У меня есть 2 вопроса: 1) Я могу установить политику одобрения для ключа через одобрение на основе штата. Но в конечном итоге это станет политикой подтверждения для этого ключа для всех транзакций, связанных с этим ключом. Я не смогу добиться разных политик подтверждения для каждого типа транзакции для одного ключа. 2) Если я начну устанавливать политики подтверждения по-разному для каждого ключа, скажем, у меня есть 10000 ключей, мне придется установить политику подтверждения для каждого из них. Более простым способом было бы установить политику подтверждения на основе типа транзакции, если это возможно.
Также это невозможно. Как насчет вопроса 1, который я задал выше? Дайте мне знать, если я что-то упустил в понимании того, что вы сказали.
Для вопроса 1 это может сработать, если существует определенный жизненный цикл для типов транзакций... например, если обычно вызывается DoA(), затем DoB(), затем DoC(), вывод каждого шага может установить политику подтверждения, которая будет быть подходящим для следующего шага. Кроме того, вы застряли в политике одобрения канала/чейнкода.
Я понимаю разницу между политикой подтверждения и протоколом соглашения. В практическом сценарии допустим, что у меня есть 3 организации — организация A, B и C как часть канала. Для нескольких конкретных транзакций я хочу получить одобрение от организаций A и B, потому что эти транзакции представляют большой интерес для A и B. Но для некоторых других транзакций мне может потребоваться одобрение от организаций A и C, потому что эти транзакции представляют большой интерес для A и C. Имеет ли смысл этот сценарий? Если да, то что было бы хорошим подходом к политике одобрения конкретных типов транзакций? Спасибо за ваше время.