Чтение реестра из etherscan API и отправка событий

Рассмотрим следующую функцию из Solidity Contract:

function createProduct(uint _price, string memory _desc) public payable{ 
   emit UserLedgerUpdated(_desc, -1*int(msg.value));
}

Я хочу, чтобы мое Dapp показывало простую бухгалтерскую книгу, подобную следующей:

Created Shoes priced at 100 Wei for a Total Cost of 2345 Wei

У меня есть два варианта:

  1. Поймай UserLedgerUpdatedсобытие в Dapp

  2. Используйте API etherscan для получения сведений о txn.

Мои вопросы:

а) Если я выберу вариант 2 (т.е. чтение сведений о txn), то я смогу избежать генерации событий. Поскольку события регистрируются и занимают место, они будут стоить газа и, следовательно, будут дороже, чем бесплатное чтение сведений о txn. Правильно ли я понимаю?

б) При чтении API ethscan я получаю входные данные для функции в шестнадцатеричном формате. Я могу использовать web3.toAsciiего для преобразования в строку, но обратите внимание, что первый аргумент функции на самом деле является числом. Следовательно, когда я конвертирую входные данные в Sample Transaction , я получаю {@Shoesвместо 123Shoes. Есть ли способ правильно преобразовать шестнадцатеричные данные, которые мы получаем из API ethrscan?

Ответы (1)

  1. Да, вы определенно экономите газ, не генерируя события. Однако цена заключается в том, что вы полагаетесь на Etherscan для функционирования вашего децентрализованного приложения. Если Etherscan не работает, ваше децентрализованное приложение не работает. Вы также потеряете всех пользователей, использующих мультиподпись, поскольку их вызовы этого контракта никогда не будут отображаться в транзакциях Etherscan (хотя Etherscan также обслуживает внутренние транзакции, поэтому вы можете обойти это). Он также определенно теряет аспект своей «современности», поскольку теперь он полагается на централизованный сервис для чтения данных. Если вы придерживаетесь событий, то пользователям просто нужен доступ к синхронизированному узлу. Это может быть от Infura, другого поставщика узлов или локального узла.
  2. Это связано с тем, что 123 (7b) является priceпеременной, которая является числом, а не строкой, а 0x7B оказывается { в ascii. Что вы можете сделать, так это передать abi функции и данные tx в функцию web3.eth.abi.decodeParametersпосле удаления сигнатуры функции (первые 4 байта после 0x). Это вернет декодированные данные.
Я заимствую термин «дерзость» на всю оставшуюся жизнь :)
Итак, какое решение будет стабильным при использовании API сканирования эфира, подграфа или инфуры? У меня есть смарт-контракт для генерации событий.