Что такое ERC-20: интерфейс токенов Ethereum

ERC-20 — это общий интерфейс для токенов в смарт-контрактах Ethereum. Он описывает, как приложения могут запрашивать сведения о токене, например баланс определённого адреса, и взаимодействовать с переводами. Один и тот же стандарт могут реализовать разные контракты. Поэтому ERC-20 обозначает набор согласованных правил взаимодействия, а не один конкретный токен.

Чтобы разобраться, что такое ERC20, полезно разделить два понятия: общий способ обращения к контракту и данные, которые возвращает выбранный контракт. Одинаковые названия методов не означают одинаковые балансы или общий объём выпуска. Понимание этой разницы помогает читать сведения о токенах, не принимая знакомый интерфейс за рекомендацию продукта или экономическую гарантию.

Что стандартизирует интерфейс ERC-20

Программный интерфейс, или API, определяет способы взаимодействия программ. ERC-20 задаёт общие названия методов и их назначение. Например, приложение может запросить баланс адреса через balanceOf, используя предусмотренный стандартом способ обращения, вместо того чтобы для каждого токена искать отдельный метод с другим названием.

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

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

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

Общий объём токенов и баланс адреса — разные величины

totalSupply() возвращает общий объём токенов для контракта, к которому направлен запрос. balanceOf(owner) возвращает баланс токенов, связанный с указанным адресом. Первый метод отвечает на вопрос об общем количестве, второй — о количестве, учитываемом для одного адреса в этом контракте.

При чтении числа сохраняйте рядом и название контракта, и смысл запроса. Запись «25 токенов» без пояснений оставляет несколько вопросов: о каком токене идёт речь, показан ли общий объём или баланс адреса, в каких единицах представлено количество. Одного числа для такого различения недостаточно.

В спецификации результат totalSupply определён как общий объём токенов. Из этого определения самого по себе не следует ни рыночная оценка, ни отдельный показатель количества токенов в обращении. Аналогично баланс адреса — это количество в выбранном контракте; само значение не устанавливает, сколько оно стоит.

Поэтому при подготовке учебной записи удобно подписывать результаты отдельно: «контракт A, общий объём» и «контракт A, баланс адреса владельца». Такая запись позволяет проверить, на какой именно вопрос отвечает каждое число, прежде чем сравнивать результаты.

Условный пример: одинаковые методы, разные балансы

Рассмотрим два полностью вымышленных контракта токенов, A и B, и один вымышленный адрес владельца. По условиям примера оба контракта предоставляют методы с названиями из API ERC-20. Зададим следующие придуманные количества в исходных единицах учёта:

Контракт A: totalSupply() возвращает 1000, а balanceOf(holder) — 10.
Контракт B: totalSupply() возвращает 5000, а balanceOf(holder) — 25.

Адрес владельца в обоих запросах один и тот же. Название метода чтения баланса также совпадает. Тем не менее по заданным условиям баланс этого адреса равен 10 в контракте A и 25 в контракте B. Общие объёмы тоже относятся к разным контрактам и составляют отдельные величины.

Логический вывод из общего API и определения адресного баланса таков: одинаковый способ задать вопрос не требует одинакового ответа от разных контрактов. Он также не объединяет полученные значения в единый баланс. В учебной записи нужно сохранить две отдельные строки с указанием соответствующего контракта.

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

Что описывают transfer и событие Transfer

Предусмотренное стандартом назначение transfer — перевести указанное количество токенов на указанный адрес назначения. При переводе ERC-20 требует формировать событие Transfer. В объявлении этого события предусмотрены поля адреса отправителя, адреса получателя и количества.

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

Нулевые переводы прямо включены в требования: они должны обрабатываться как обычные переводы и сопровождаться событием. Отсюда следует конкретный логический вывод: наличие Transfer само по себе не означает положительное количество. Чтобы понять запись, нужно прочитать поле значения, а не ограничиваться названием события.

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

Name, symbol и decimals — необязательные метаданные

Стандарт описывает три метода, которые помогают представлять сведения о токене. Если они предоставлены, name() возвращает название, symbol() — символ токена, а decimals() — число десятичных разрядов, используемое для представления количества пользователю.

Все три метода необязательны. Спецификация прямо указывает, что интерфейсы и другие контракты не должны рассчитывать на наличие этих значений. Поэтому корректное объяснение допускает отсутствие названия, символа или сведений о десятичных разрядах. Нельзя молча подставить предполагаемые метаданные и выдать их за ответ выбранного контракта.

Из определений методов следует ещё одно различие: метаданные и баланс адреса — разные сведения. Название и символ описывают токен; decimals относится к представлению количества. Ни один из этих ответов сам по себе не является адресным балансом, который возвращает balanceOf.

Если нужен именно расчёт отображаемого количества, он разобран в материале «Decimals в ERC-20: исходные единицы и отображение». Для понимания общего интерфейса достаточно сохранить различие между количеством, его представлением и описательными сведениями о токене.

Практический список проверки объяснения ERC-20

Укажите контракт. Каждое количество должно оставаться связанным с тем контрактом токена, о котором идёт речь.
Определите вопрос. Различайте общий объём totalSupply и баланс конкретного адреса balanceOf.
Отделите метаданные. Название, символ и число десятичных разрядов не заменяют ответ о балансе владельца.
Учитывайте необязательность. Не предполагайте, что три метода метаданных обязательно доступны.
Прочитайте поля перевода. Рассматривайте адрес отправителя, адрес получателя и количество вместе, включая возможное нулевое значение.
Сохраните пределы выводов. Общий API поддерживает совместимость, но его наличие само по себе не устанавливает универсальную совместимость, стоимость, добросовестность реализации или завершение оплаты.

Этот список предназначен для чтения документации и учебных примеров. Для его применения достаточно разобрать определения и подписать данные; отправлять токены или подписывать запрос кошелька не требуется.

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