Follow Us
Facebooktwitteryoutube
YouTube
Promo
banner
Promo
banner

Руководство по событиям и журналам в смарт-контрактах Ethereum

блог 1НовостиДля разработчиковПредприятиеБлокчейн РазъяснениеМероприятия и конференцииПрессаИнформационные бюллетени

Подписывайтесь на нашу новостную рассылку.

Адрес электронной почты

Мы уважаем вашу конфиденциальность

ГлавнаяБлогРазработка блокчейна

Руководство по событиям и журналам в смарт-контрактах Ethereum

Техническое введение в сценарии использования событий и журналов в блокчейне Ethereum с образцом кода от Джозеф Чоу 6 июня 2016 г.Опубликовано 6 июня 2016 г.

ConsenSys Signal: руководство по событиям и журналам в Ethereum Smart Contracts Hero

События и журналы важны в Ethereum, потому что они облегчают взаимодействие между смарт-контрактами и их пользовательскими интерфейсами. В традиционной веб-разработке ответ сервера предоставляется в виде обратного вызова веб-интерфейсу. В Ethereum, когда транзакция добывается, смарт-контракты могут генерировать события и записывать журналы в блокчейн, которые затем может обрабатывать интерфейс. Есть разные способы обработки событий и журналов. Это техническое введение объяснит некоторые источники путаницы в отношении событий и некоторый пример кода для работы с ними..

События могут сбивать с толку, потому что их можно использовать по-разному. Событие для одного может не выглядеть событием для другого. Есть 3 основных варианта использования событий и журналов:

  1. Возвращаемые значения смарт-контракта для пользовательского интерфейса
  2. Асинхронные триггеры с данными
  3. Более дешевая форма хранения

Терминология между событиями и журналами – еще один источник путаницы, и это будет объяснено в третьем варианте использования..

1) Возвращаемые значения смарт-контрактов для пользовательского интерфейса

Самое простое использование события – передать возвращаемые значения из контрактов во внешний интерфейс приложения. Чтобы проиллюстрировать, вот проблема:

контракт ExampleContract {// некоторые переменные состояния … function foo (int256 _value) returns (int256) {// управление состоянием … return _value; }} Язык кода: JavaScript (javascript)

Предполагая, что exampleContract является экземпляром ExampleContract, внешнего интерфейса, использующего web3.js, можно получить возвращаемое значение, моделируя выполнение контракта:

var returnValue = exampleContract.foo.call (2); console.log (returnValue) // 2Code язык: JavaScript (javascript)

Однако, когда web3.js отправляет вызов контракта как транзакцию, он не может получить возвращаемое значение [1]:


var returnValue = exampleContract.foo.sendTransaction (2, {from: web3.eth.coinbase}); console.log (returnValue) // язык хеш-кода транзакции: JavaScript (javascript)

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

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

контракт ExampleContract {событие ReturnValue (адрес проиндексирован _from, int256 _value); функция foo (int256 _value) возвращает (int256) {ReturnValue (msg.sender, _value); return _value; }} Затем интерфейсный интерфейс может получить возвращаемое значение: var exampleEvent = exampleContract.ReturnValue ({_ from: web3.eth.coinbase}); exampleEvent.watch (function (err, result) {if (err) {console.log (err) return;} console.log (result.args._value) // проверяем, что result.args._from – это web3.eth.coinbase затем // отображаем result.args._value в пользовательском интерфейсе и вызываем // exampleEvent.stopWatching ()}) exampleContract.foo.sendTransaction (2, {from: web3.eth.coinbase}) Язык кода: JavaScript (javascript)

Когда будет добыта транзакция, вызывающая foo, будет запущен обратный вызов внутри часов. Это эффективно позволяет веб-интерфейсу получать возвращаемые значения из foo..

2) Асинхронные триггеры с данными

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

3) Более дешевая форма хранения

Третий вариант использования сильно отличается от того, что было рассмотрено, и заключается в использовании событий в качестве значительно более дешевой формы хранения. В виртуальной машине Ethereum (EVM) и Желтая бумага Ethereum, события называются журналами (есть коды операций LOG). Говоря о хранилище, технически точнее было бы сказать, что данные могут храниться в журналах, а не в событиях. Однако, когда мы поднимаемся на уровень выше протокола, точнее будет сказать, что контракты генерируют или запускают события, на которые интерфейс может реагировать. Каждый раз, когда генерируется событие, соответствующие журналы записываются в блокчейн. Терминология между событиями и журналами – еще один источник путаницы, потому что контекст диктует, какой термин более точен..

Бревна были спроектированы как форма хранения, которая стоит значительно меньше газа, чем контрактное хранение. Журналы в основном [2] стоят 8 единиц газа за байт, тогда как хранение по контракту стоит 20 000 единиц газа за 32 байта. Хотя бревна обеспечивают колоссальную экономию газа, журналы недоступны по контрактам [3].

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

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

контракт CryptoExchange {событие депозита (uint256 проиндексирован _market, адрес проиндексирован _sender, uint256 _amount, uint256 _time); функция deposit (uint256 _amount, uint256 _market) возвращает (int256) {// выполнить депозит, обновить баланс пользователя и т. д. Депозит (_market, msg.sender, _amount, now); } Язык кода: JavaScript (javascript)

Предположим, мы хотим обновлять пользовательский интерфейс, когда пользователь вносит депозиты. Вот пример использования события (Депозит) в качестве асинхронного триггера с данными (_market, msg.sender, _amount, now). Предположим, что cryptoExContract является экземпляром CryptoExchange:

var depositEvent = cryptoExContract.Deposit ({_ sender: userAddress}); depositEvent.watch (function (err, result) {if (err) {console.log (err) return;} // добавляем детали result.args в UI}) Язык кода: JavaScript (javascript)

Повышение эффективности получения всех событий для пользователя является причиной, по которой параметр _sender для события индексируется: событие Deposit (uint256 indexed _market, address indexed _sender, uint256 _amount, uint256 _time).

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

var depositEventAll = cryptoExContract.Deposit ({_ sender: userAddress}, {fromBlock: 0, toBlock: ‘latest’}); depositEventAll.watch (function (err, result) {if (err) {console.log (err) return;} // добавляем детали result.args в UI}) Язык кода: JavaScript (javascript)

Когда пользовательский интерфейс визуализируется, необходимо вызвать depositEventAll.stopWatching ().

В сторону – индексированные параметры

Можно проиндексировать до 3 параметров. Например, в предлагаемом стандарте токенов есть: передача события (адрес проиндексирован _from, адрес проиндексирован _to, uint256 _value). Это означает, что интерфейс может эффективно просто наблюдать за передачей токенов, которые:

  • отправлено адресом tokenContract.Transfer ({_ from: senderAddress})
  • или получен адресом tokenContract.Transfer ({_ to: ReceiverAddress})
  • или отправлено с адреса на конкретный адрес tokenContract.Transfer ({_ from: senderAddress, _to: ReceiverAddress})

Вывод

Для мероприятий были представлены три варианта использования. Во-первых, использование события для простого получения возвращаемого значения из функции контракта, вызванной с помощью sendTransaction (). Во-вторых, использование события в качестве асинхронного триггера с данными, которые могут уведомлять наблюдателя, такого как пользовательский интерфейс. В-третьих, использование события для записи журналов в цепочку блоков в качестве более дешевой формы хранения. Это введение показало некоторые из API для работы с событиями. Есть другие подходы для работы с событиями, журналами и квитанциями, и эти темы могут быть рассмотрены в следующих статьях.

Спасибо Аарону Дэвису, Винсенту Гариепи и Джозефу Любину за отзывы об этой статье..

Рекомендации

[1] web3.js может наблюдать за включением транзакции в цепочку блоков, а затем воспроизводить транзакцию в экземпляре EVM, чтобы получить возвращаемое значение, но это значительный объем логики, который нужно добавить в web3.js

[2] Расходы на газ составляют 375 для операции журнала и 375 для каждой темы, но когда хранится много байтов, эти затраты составляют незначительную часть от общей стоимости хранения..

[3] Доказательства Меркла для журналов возможны, поэтому, если внешняя организация предоставляет контракт с таким доказательством, контракт может подтвердить, что журнал действительно существует внутри цепочки блоков..

Хотите, чтобы руководства для разработчиков попадали прямо в ваш почтовый ящик?

Подпишитесь на информационный бюллетень для разработчиков ConsenSys

Подпишитесь на нашу рассылку, чтобы получать последние новости Ethereum, корпоративные решения, ресурсы для разработчиков и многое другое.Как создать успешный блокчейн-продуктВебинар

Как создать успешный блокчейн-продукт

Как настроить и запустить узел EthereumВебинар

Как настроить и запустить узел Ethereum

Как создать собственный API EthereumВебинар

Как создать собственный API Ethereum

Как создать социальный токенВебинар

Как создать социальный токен

Использование инструментов безопасности при разработке смарт-контрактовВебинар

Использование инструментов безопасности при разработке смарт-контрактов

Будущее финансовых цифровых активов и DeFiВебинар

Будущее финансов: цифровые активы и DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Adblock
detector