Стандарт ERC223 и его отличия от ERC20

Большинство токенов эфира выпускаются по стандарту ERC20 (подробнее можно почитать тут). Токены на основе этого стандарта работают вполне успешно.

Но все же были выявлены некоторые недостатки. Давайте посмотрим на эти недостатки и как их решили в ERC223.

Дополнение: На сегодняшний день ERC20 уже официально является стандартом и в него уже включены пункты 1, 2 и 3.

  1. Кошелькам нужно отображать имя токена. Возможности получить имя стандарт ERC20 не предусматривает. В ERC223 для этого ввели метод name.
  2. Также в кошельках необходимо отображать короткое имя токена. В ERC20 такой возможности нет. Токен ERC223 — уже содержит метод symbol.
  3. Необходимо знать количество знаков после запятой, чего нет в ERC20. В ERC223 — для этого есть метод decimals.
  4. Проблема потеряных токенов. Иногда люди по ошибке могут отправить токены на адрес, который является контрактом. В этом случае контракт станет владельцем токенов. И, если контракт не предусмотрел явную возможность работы с transfer, то токены останутся на адресе контракта навсегда. Стандарт ERC223 вводит интерфейс для контрактов, которые хотят работать с токенами. В этом интерфейсе есть функция tokenFallback, она должна вызываться при попытке отправить на контракт токены.
  5. При выполнении транзакции с помощью transfer возникает потребность добавлять дополнительную информацию. В ERC223 добавлен дополнительный метод transfer который содержит поле data — специально для передачи дополнительной информации. При этом старый метод transfer оставили для обратной совместимости.

До момента официального опубликования ERC20 в него не были включены функции symbol, name, decimals. Но многие контракты уже реализовывали эти функции. тем самым частично реализовав стандарт ERC223.

Рекомендованные интерфейсы и реализации ERC223 на Solidity можно посмотреть тут.

Стандарт ERC223 определяет из два интерфейса. Интерфейс токена.

И интерфейс контракта, который может получать токены.

А вот рекомендованная реализация ERC223.

В ERC223 функцию transfer с двумя параметрами оставили для обратной совместимости с ERC20. Ее реализация отличается от transfer с тремя параметрами только тем, что третий параметр заменяется на пустое значение.

Функция transfer теперь получает размер кода по адресу получателя. Если размер кода больше нуля, то получатель не просто адрес, а контракт. И в этом случае пытаемся вызвать функцию transferFallback.

  1. А что передаётся или можно передавать в этом третьем параметре — bytes data?
    Спасибо!

    • В ERC223 об этом прямо не сказано. Но судя по всему это дополнительные данные к транзакции. Т.е. поле используется на ваше усмотрение. Например, можно использовать как описание за что был платеж. Может быть равно нулю.

  2. Добрый день. Интересует вопрос о пробросе исключений с помощью require: можно ли выводить кастомное сообщение в исключении? Чтобы покупатель токенов знал в чем его ошибка?

    • Сам бы с удовольствием пользовался. Но такой возможности, к сожалению, нет.

  3. Спасибо за ответ. Очень жаль, конечно 🙁 Этого и правда сильно не хватает. Ну ладно, хоть пускай пока так.

  4. Не совсем понял, почему при использовании transfer мы сначала изменяем значения баланса, а лишь затем проверяем куда были отправлены токены и при необходимости делаем возврат. Почему сперва не проверить адресата и лишь затем отправлять токены?
    Заранее спасибо.

    • Потому что если мы сначала вызовем tokenFallback а потом отправим, то при работе tokenFallback не сможет оперировать с отправленными токенами. А где вы возврат увидели?

  5. А что если вообще без tokenFallback. Если мы видим, что пользователь хочет отправить токены на адрес контракта, то просто не проводим операцию.

    Мне показалось, что tokenFallback — это и есть возврат с адреса контракта или я не так понял?

    • tokenFallback это функция другого контракта, которая вызывается, чтобы оповестить другой контракт о поступлении средств (контракты работают только если у них кто-то вызывает функцию). Иначе другой контракт никак не отреагирует на прием средств. Соответственно если по адресу приема нет контракта, то мы все равно должны отправить средства. А в Вашем коде отправка только если на адресе нет контракта. Что не корректно. Стандарт именно для этого и сделан, чтобы другие контракты как-то реагировали на прием.
      Хотя в целом Ваша мысль ясна — не отправлять на не поддерживающие стандарт контракты. Но мы тогда ограничим контракт и потеряем обратную совместимость. Что очень плохою

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *