Параметр decimals в ERC-20 задаёт масштаб, с помощью которого целое количество исходных единиц токена превращается в число для отображения человеку. Основная формула проста: исходное количество нужно разделить на десять в степени decimals. Однако правильный расчёт начинается с проверки того, какое значение относится к конкретному токену и предоставляет ли он эти метаданные вообще.
Здесь важно различать требования стандарта и особенности отдельной реализации. EIP-20 относит decimals() к необязательным методам. В реализации OpenZeppelin есть значение по умолчанию, но оно не определяет параметры всех токенов ERC-20. Разберём эту разницу, расчёт на условном примере и границы выводов, которые можно сделать по полученному числу.
Что означает decimals и почему этот метод необязателен
В стандарте EIP-20 метод decimals() описывает число десятичных разрядов, используемое для представления количества токенов пользователю. При этом стандарт прямо указывает на необязательность метода: интерфейсы и другие контракты не должны предполагать, что такие метаданные обязательно присутствуют.
Поэтому вопрос «сколько знаков после запятой у токена?» требует ответа именно для рассматриваемого токена. Само обозначение ERC-20 не даёт готового значения для подстановки в формулу. Если источник данных не устанавливает нужный масштаб, результат деления с произвольно выбранным числом будет лишь вычислением на неподтверждённом предположении.
Удобно держать рядом две записи одного количества: целое число исходных единиц и его представление для человека. Значение decimals связывает эти записи. Оно объясняет, где при отображении появляется десятичный разделитель, но не превращает исходные единицы учёта в дробные.
Обозначение 10 ** decimals означает возведение десяти в степень decimals. В формуле отображения это делитель. Не стоит воспринимать слово decimals как указание выполнять внутренние расчёты контракта с дробями: оно относится к масштабу представления количества.
Исходные единицы и число в интерфейсе
Руководство OpenZeppelin по ERC-20 объясняет такой учёт через целые числа. В описанной модели арифметика внутри контракта остаётся целочисленной, а интерфейсы, включая кошельки, должны учитывать decimals при отображении количества токенов. Руководство иллюстрирует этот принцип на вымышленном токене GLD.
Для чтения количества используйте соотношение: отображаемое количество = исходное количество / (10 ** decimals). В этой записи нужны оба входных значения. Исходное число без масштаба ещё не объясняет пользовательское представление, а масштаб без исходного числа не даёт количества.
Ответственность интерфейса за преобразование не доказывает, что конкретный интерфейс применил правильное значение. Это разные утверждения: одно описывает правило отображения, другое потребовало бы проверки конкретного случая. Поэтому при разборе числа полезно сохранять исходное значение и основание, по которому выбран масштаб.
Если вы готовите пояснение, запись или расчёт для другого человека, явно подписывайте обе формы. Например, слова «исходные единицы» показывают, что перед читателем целое число до масштабирования. Слова «отображаемые токены» указывают, что деление уже выполнено. Такая запись позволяет проверить ход расчёта без догадок о том, что обозначает каждое число.
Условный пример: от 1234500 единиц к 123,45 токена
Предположим, у вымышленного токена 4 десятичных разряда, а условный баланс составляет 1234500 исходных единиц. Токен, баланс и значение метаданных здесь придуманы исключительно для объяснения. Пример не описывает реальный счёт или результат операции.
- Записываем заданное значение:
decimals = 4. - Вычисляем масштаб:
10 ** 4 = 10000. - Делим исходное количество:
1234500 / 10000 = 123,45. - Подписываем результат: 123,45 отображаемого токена соответствуют 1234500 исходных единиц.
Это математический вывод из формулы и условных исходных данных. Мы не установили чей-либо баланс, а выразили одно придуманное количество в двух формах. Исходное число остаётся равным 1234500; запись 123,45 показывает его после применения заданного масштаба.
Как проверить преобразование в обратную сторону
Из той же формулы алгебраически следует обратное соотношение: исходное количество = отображаемое количество * (10 ** decimals). Для нашего условного примера умножение 123,45 * 10000 возвращает 1234500. Обратный расчёт помогает проверить, согласованы ли две записи между собой.
Есть существенное ограничение: точное обратное преобразование должно давать целое число исходных единиц. Этот вывод опирается на два положения из руководства: масштабирование количества и целочисленный учёт. Если результат не является целым числом, выбранное отображаемое количество нельзя точно выразить в исходных единицах при заданном масштабе.
Обратный расчёт остаётся проверкой представления числа. Он не является указанием отправить токены и не подтверждает, что какая-либо операция успешно выполнится. Для понимания примера достаточно сопоставить значения на бумаге или в учебной записи.
Почему значение 18 в OpenZeppelin не универсально
Справочник ERC20 в OpenZeppelin Contracts 5.x устанавливает значение decimals по умолчанию равным 18. Там же указано, что производный контракт может переопределить функцию, чтобы она возвращала другое значение. Эти сведения описывают конкретную реализацию и способ её настройки при разработке.
Переопределение функции не означает, что пользователь может произвольно изменить decimals уже развёрнутого токена. Документация объясняет устройство реализации; она не устанавливает наличие пользовательской настройки у любого конкретного контракта. Поэтому знакомое число 18 нельзя автоматически переносить на токен только по его обозначению ERC-20.
Логический вывод здесь строится на трёх предпосылках: EIP-20 делает метод необязательным, OpenZeppelin задаёт собственное значение по умолчанию, а производный контракт может его переопределить. Следовательно, обозначение ERC-20 само по себе не подтверждает ни наличие decimals(), ни значение 18. Этот вывод показывает предел общей информации, но не определяет метаданные отдельного токена.
При проверке объяснения отделяйте ссылку на стандарт от сведений о выбранной реализации. Стандарт отвечает на вопрос об обязательности метода. Документация OpenZeppelin отвечает на вопрос о поведении описанного ERC20. Для интерпретации конкретного количества дополнительно необходимо установить, какое значение относится к рассматриваемому токену.
Что преобразование для отображения не меняет
В документированной реализации OpenZeppelin сведения decimals используются для отображения и не влияют на арифметику контракта, включая balanceOf и transfer. Деление исходного баланса на масштаб само по себе не обновляет этот баланс. Выполнение такого расчёта также не исполняет перевод.
В условном примере меняется форма записи количества для читателя. Исходные 1234500 единиц не уменьшаются до 123 единиц из-за появления десятичного разделителя. Число 123,45 — результат представления тех же условных данных с масштабом 10000.
Эти границы нужно сохранять при использовании примера. Он объясняет соотношение единиц и отображения в описанной модели, но не оценивает особенности произвольного контракта. Статья также не определяет цену токена, не удостоверяет подлинность контракта и не подтверждает результат транзакции. Наличие ссылки на технический источник само по себе таких выводов не даёт.
Практический список проверки количества
- Зафиксируйте исходное число. Подпишите его как количество исходных единиц до преобразования.
- Установите основание для decimals. Уточните, предоставлены ли метаданные для рассматриваемого токена и какое значение используется.
- Отделите стандарт от реализации. Не заменяйте отсутствующие сведения значением 18 только потому, что оно принято по умолчанию в OpenZeppelin.
- Покажите вычисление. Разделите исходное число на
10 ** decimalsи подпишите результат как отображаемое количество. - Проверьте обратную связь. При обратном преобразовании используйте тот же масштаб и убедитесь, что получается целое количество исходных единиц.
- Укажите предел результата. Расчёт представления не подтверждает изменение баланса, исполнение перевода или подлинность контракта.
Если значение decimals для конкретного токена остаётся неустановленным, его масштабированное представление также остаётся неопределённым. При редакционной проверке такой случай требует дополнительного рассмотрения с отметкой editorial_review. Общее значение из документации не заменяет недостающих сведений.
Учебный материал подготовлен с помощью ИИ. Условные расчёты объясняют единицы учёта и не являются финансовой рекомендацией или предложением совершить транзакцию.
Материал по смежной теме: Комиссия gas в Ethereum: почему она отличается от суммы перевода.