Отслеживание статуса транзакции с помощью приватной цепочки ethereum

Я внедряю систему управления заказами, используя частную цепочку блоков ethereum. Каждый заказ представляет собой смарт-контракт. Каждый заказ будет выполняться несколькими актерами. Статус заказа также будет обновляться этими субъектами. Как узнать текущий статус заказа? Потребуется подробная информация, например, когда заказ был обработан в последний раз и кем, а также его статус. Мне также понадобится возможность находить заказы по статусу (например, «Выполнено», «Не выполнено» и т. д.). Найти заказы, которые были обработаны в пределах диапазона дат и т. д. Можно ли получить такие данные из самого блокчейна?

Если нет, то каким должен быть подход к внедрению такой системы?

Ответы (1)

Для сохранения статуса вы можете использовать события в своих функциях смарт-контракта и регистрировать любой статус, который вы хотите. Кроме того, вы можете получить доступ к журналам событий в квитанции о транзакции или просмотреть все события, зарегистрированные в контракте, чтобы получить доступ к зарегистрированным данным. Помимо сохранения кода состояния в событиях, вы можете регистрировать что-либо еще в соответствии с вашими требованиями.

Мы реализовали функциональность кода состояния в одном из наших проектов, вы можете посмотреть, и это может помочь вам лучше понять это решение -

Смарт-контракт с событиями состояния — https://github.com/Imaginea/lms/blob/master/contracts/LMS.sol

Тестовые примеры для доступа к этим журналам событий — https://github.com/Imaginea/lms/blob/master/test/testLMS.js.

Список статусов, который мы используем в нашем коде — https://github.com/Imaginea/lms/blob/master/app/components/notifications/status.js#L2.

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

Надеюсь это поможет.

Спасибо за ответ. Создание событий было тем, чем я думал заниматься. Но если я создаю события, а затем регистрирую/сохраняю эти данные, не будет ли это похоже на создание нераспределенной системы? Это правильный подход?
События — это не что иное, как транзакции, поэтому, насколько я понимаю, они будут храниться в блокчейне (который в конечном итоге распределяется). Возврат статуса очень удобен, и получить его тоже легко.