Блог

В Ethereum события четко определены, каждое из них представляет собой структуру данных, используемую для сигнализации о каком-либо действии. В Near env::log находятся сообщения. Пример:

• В Ethereum мы используем журналы для большинства изменений состояния токенов
• NEP-21 ничего не говорит о журналах.

Есть ли какой-либо смысл использовать журналы в near, кроме «отладки» / возврата информации о пользователе? Должны ли журналы быть стандартизированы? Может быть, лучше провести это обсуждение в каком-нибудь другом месте …?

Далее следует: аргументы транзакции сериализованы и четко видны. Есть ли смысл регистрировать аргументы транзакции? Например: в функциях передачи токенов Ethereum все аргументы дополнительно записываются в событие. Для этого есть несколько причин:

1. С помощью событий мы должны иметь возможность воссоздать состояние контракта;
2. это более удобно для чтения при просмотре блокчейна. Но в случае переноса я не думаю, что есть какая-то дополнительная ценность, потому что мы не регистрируем ничего, кроме аргументов функции.

Мы еще не добавили аналог событий Ethereum в NEAR. Контракты, которые хотят сигнализировать о каком-либо событии, должны возвращать его как часть результата метода, как здесь . Поэтому наш env::log в настоящее время предназначен только для информационных целей и может использоваться для отладки и тому подобного.

В общем, наши контракты могут выбирать, как сериализовать аргументы, поэтому контракту может быть полезно регистрировать свои собственные аргументы, поскольку он может использовать для них сложный механизм сериализации.

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