Перейти к основному содержимому

Адреса смарт-контрактов

В блокчейне TON каждый актор, включая кошельки и смарт-контракты, представлен адресом. Эти адреса используются при получении и отправке сообщений и транзакций. Существует два основных формата адресов: исходный (raw) и пользовательский (user-friendly).

Компоненты адреса

Каждый адрес в TON состоит из двух основных компонентов:

  • Workchain ID: 32-битное целое число со знаком, которое обозначает, к какому воркчейну относится контракт (например, -1 для мастерчейна и 0 для бейсчейна).
  • Account ID: Уникальный идентификатор контракта, обычно длиной 256 бит для мастерчейна и бейсчейна.

Состояния адресов

Каждый адрес в TON может находиться в одном из следующих состояний:

  • Nonexist: Адрес не имеет данных (начальное состояние для всех адресов)
  • Uninit: У адреса есть баланс, но нет кода смарт-контракта.
  • Active: Адрес активен, у него есть и код, и баланс.
  • Frozen: Адрес заблокирован из-за того, что расходы на хранение превысили его баланс.

Форматы адресов

Адрес каждого контракта в TON позволяет идентифицировать контракт в блокчейне, в нём обозначены воркчейн и хэш от исходного состояния контракта. Используются два стандартных формата: исходный (raw), где воркчейн и закодированный в HEX хэш разделены двоеточием) и пользовательский (user-friendly), где используется base64-кодировка и определённые флаги.

User-friendly: EQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPrHF
Raw: 0:ca6e321c7cce9ecedf0a8ca2492ec8592494aa5fb5ce0387dff96ef6af982a3e

Пользовательский адрес

Адрес в пользовательском (user-friendly) формате рассчитан на то, чтобы его было удобнее воспринимать, и включает в себя:

  1. Флаги: Показывают значение параметра bounceable у контракта.
  2. Контрольную сумму: 2-байтовый механизм проверки ошибок CRC16, который помогает обнаруживать неточности перед отправкой.
  3. Кодирование: оно преобразует исходный адрес в более читаемую компактную форму с использованием base64 или base64url.

Пример: EQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPrHF (base64)

Пользовательские адреса делают транзакции безопаснее, предотвращая ошибки и позволяя возвращать средства в случае неудачных транзакций.

Флаги в пользовательских адресах

В них определены два флага: bounceable/non-bounceable и тестнет/любая сеть. Первая буква адреса отображает его тип, потому что она отвечает за первые 6 бит в бинарной форме адреса, а флаги располагаются в этих 6 битах, в соответствии с TEP-2:

Начало адресаБинарная формаBounceableТолько тестнет
E...000100.01данет
U...010100.01нетнет
k...100100.01дада
0...110100.01нетда
подсказка

Флаг «только для тестнета» не имеет отображения в блокчейне. Флаг «non-bounceable» имеет значение только когда адрес используется как адрес назначения платежа: в этом случае он отключает «отскок» для отправленного сообщения; адрес в блокчейне, опять же, не содержит этого флага.

default bounceable: EQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPrHF
urlSafe: EQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff+W72r5gqPrHF
non-bounceable: UQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPuwA
Testnet: kQDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPgpP
non-bounceable, Testnet: 0QDKbjIcfM6ezt8KjKJJLshZJJSqX7XOA4ff-W72r5gqPleK

Исходный адрес

Исходный адрес содержит только основные элементы:

  • Workchain ID (например, -1 для мастерчейна)
  • Account ID: 256-битный уникальный идентификатор

Пример:
-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260

Однако у адресов в исходном формате есть два основных недостатка:

  1. У них нет встроенной проверки на ошибки, поэтому при ошибочном копировании можно потерять средства.
  2. Они не поддерживают дополнительные функции вроде флага для параметра bounceable.

Преобразование между форматами адресов

Для преобразования между разными вариантами адреса вы можете использовать ton.org/address.

Более подробную информацию о том, как обрабатывать эти адреса, вы можете найти в Документации по адресам.

См. также

Was this article useful?