Перейти к содержанию

ERC-20

ERC-20 — стандартный интерфейс взаимозаменяемых токенов в Ethereum. Узнайте, как работают балансы, переводы, лимиты и одобрения и чего стандарт не гарантирует.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

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

Основной интерфейс включает:

  • totalSupply и balanceOf для чтения объема предложения и балансов счетов;
  • transfer для отправки токенов вызывающей стороны;
  • approve и allowance для установки и чтения лимита уполномоченного адреса;
  • transferFrom для расходования средств с баланса владельца в пределах этого лимита; и
  • события Transfer и Approval для регистрации переводов и одобрений.

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

Как это работает

Баланс ERC-20 — это связанная с адресом запись в состоянии контракта токена. Кошелек отображает это состояние, а не хранит отдельный файл токена. Когда transfer(to, amount) выполняется успешно, контракт уменьшает баланс вызывающей стороны, увеличивает баланс получателя и создает событие Transfer. Обычно пользователь оплачивает сетевой газ в ETH. Если выполнение откатывается, изменения состояния токена отменяются, но уже израсходованный газ возвращается не полностью.

Делегированные расходы осуществляются через лимит. Вызов approve(spender, amount) устанавливает сумму, которую указанный уполномоченный адрес может потратить с баланса вызывающей стороны. Затем он может вызвать transferFrom(owner, to, amount), а allowance(owner, spender) показывает оставшийся лимит. Одобрение относится к одной паре владельца и уполномоченного адреса, одному контракту токена и одной сети; оно не дает разрешения на все активы в кошельке.

Повторный вызов approve перезаписывает прежний лимит. Спецификация EIP-20 предупреждает, что пользовательским интерфейсам следует сначала установить существующий лимит на 0, а уже затем задать другое ненулевое значение: иначе из-за порядка транзакций уполномоченный адрес может успеть использовать и старый, и новый лимит. Установка лимита на 0 способна остановить будущие вызовы transferFrom для данной комбинации владельца, уполномоченного адреса и токена, но не вернет уже переведенные токены.

name, symbol и decimals — необязательные методы метаданных в EIP-20. decimals влияет на отображение единиц, а не на целочисленный учет в контракте. Стандарт также не определяет, как выпускаются или сжигаются токены, можно ли приостанавливать переводы или взимать с них комиссию, блокировать адреса либо обновлять логику прокси-контракта. Эти свойства нужно проверять в развернутом коде, текущей реализации и административных полномочиях.

Пример

Предположим, в кошельке есть 1,000 единиц токена ERC-20, а пользователь хочет обменять 100 из них через маршрутизатор децентрализованной биржи. Сначала он отправляет approve(router, 100). Если вызов успешен, маршрутизатор может выполнить transferFrom(user, pool, 100); после расходования всей суммы обычный оставшийся лимит равен 0. Транзакция одобрения и транзакция обмена — отдельные действия в блокчейне, поэтому каждое может потребовать газа и независимо завершиться неудачей.

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

Риски

  • Неверный контракт или сеть: названия, символы и значки можно скопировать; проверяйте адрес контракта в нужной сети.
  • Чрезмерный лимит: злоумышленник или скомпрометированный уполномоченный адрес может израсходовать неиспользованный лимит вплоть до одобренной суммы.
  • Нестандартное поведение: некоторые широко используемые токены возвращают значения не в точном соответствии с ожиданиями, а другие взимают комиссию за перевод, пересчитывают балансы, блокируют адреса или приостанавливают переводы.
  • Административный контроль: выпуск, заморозка, обновления и другие привилегированные действия могут изменить риск токена уже после его приобретения.
  • Необратимый перевод: при отправке токенов на неверный адрес или контракту, который не умеет их обрабатывать, восстановление может оказаться невозможным.

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

Распространенные заблуждения

Миф 1: Маркировка ERC-20 доказывает, что токен настоящий

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

Миф 2: Одобрение немедленно переводит разрешенные токены

Обычно approve изменяет лимит, но само по себе не перемещает токены на уполномоченный адрес. Их переводит последующий вызов transferFrom. Тем не менее действующий лимит — это реальное разрешение, которое может использоваться, пока его не израсходуют, не заменят или не установят на 0.

Миф 3: Все токены ERC-20 ведут себя одинаково

Стандарт задает минимальный общий интерфейс. Он не требует определенной политики предложения и не запрещает комиссии, приостановку, черные списки, пересчет балансов или обновляемость. Интеграции должны учитывать фактическую реализацию, а не полагаться только на маркировку ERC-20.

Похожие темы

Источники

Навигация

Поиск по вики...