Архитектура Jetton 2.0

Jetton — это стандарт взаимозаменяемых токенов на TON, аналог ERC-20 в Ethereum, но с принципиально другой архитектурой. В отличие от ERC-20, где все балансы хранятся в одном контракте, в Jetton каждый держатель имеет свой отдельный контракт (Jetton Wallet). Это обеспечивает бесконечную масштабируемость, но требует понимания двухуровневой архитектуры для корректной интеграции.

В модулях M03 и M04 мы научились писать смарт-контракты на Tact и разобрали модель акторов. Теперь применим эти знания к токенам — одному из главных применений блокчейна. TON использует уникальную шардированную архитектуру токенов, принципиально отличающуюся от Ethereum.

ERC-20 vs Jetton: два разных подхода

В Ethereum токен стандарта ERC-20 — это один контракт с маппингом balances[address] => amount. Все балансы хранятся в одном месте:

В TON такой подход невозможен по архитектуре. Поскольку контракты распределены по шардчейнам и не имеют синхронного доступа к чужому состоянию, хранить все балансы в одном контракте — значит создать узкое место (bottleneck), нарушающее принцип параллелизма.

Шардированная модель Jetton 2.0

Стандарт TEP-74 определяет архитектуру Jetton 2.0, состоящую из двух типов контрактов:

Jetton Master (мастер-контракт)

Один на весь токен. Хранит:

• Metadata (TEP-64): имя токена, символ, описание, иконка
• total_supply: общее количество выпущенных токенов
• owner: адрес владельца (может минтить новые токены)
• mintable: разрешено ли создание новых токенов

Jetton Master не хранит балансы пользователей. Его задача — управлять метаданными и создавать новые Jetton Wallet при минтинге.

Jetton Wallet (контракт баланса)

Один на каждого пользователя, владеющего токеном. Хранит:

• balance: количество токенов пользователя
• owner: адрес TON-кошелька владельца
• jetton_master: адрес мастер-контракта

Jetton Wallet развёрнут в шардчейне своего владельца. Это ключевое свойство Jetton 2.0 — контракт баланса находится рядом с кошельком пользователя, обеспечивая максимальную скорость обработки.

Почему шардирование?

Шардированная архитектура Jetton 2.0 решает три ключевые проблемы:

1. Параллелизм

Каждый Jetton Wallet обрабатывается в шардчейне своего владельца. Когда Alice и Bob одновременно переводят токены разным получателям, их транзакции обрабатываются параллельно в разных шардах. Нет общего контракта, который стал бы узким местом.

2. Масштабируемость

Токен с миллионом держателей = миллион отдельных контрактов, распределённых по шардчейнам. Нагрузка распределяется равномерно по всей сети, а не концентрируется на одном контракте.

3. Локальность данных

Jetton Wallet пользователя находится в том же шардчейне, что и его TON Wallet. Это минимизирует межшардовые сообщения при инициации транзакций.

Детерминистическое обнаружение адресов

Как Jetton Master “знает” адрес Jetton Wallet конкретного пользователя? Адрес вычисляется детерминистически из init-данных:

jetton_wallet_address = hash(
  code: jetton_wallet_code,
  data: init(owner_address, jetton_master_address)
)

Это означает, что:

• Любой может вычислить адрес Jetton Wallet, зная адрес владельца и мастер-контракта
• Jetton Wallet не нужно регистрировать — его адрес предсказуем
• При первом переводе Jetton Wallet может быть развёрнут автоматически

Именно так кошельки и DEX определяют, где находится баланс пользователя: они вычисляют адрес Jetton Wallet и запрашивают его состояние.

Metadata по стандарту TEP-64

Jetton Master хранит метаданные токена в формате TEP-64. Существуют два подхода:

On-chain metadata — все данные в Cell контракта:

content_layout: 0x00
metadata:
  name: "My Token"
  symbol: "MTK"
  decimals: "9"
  description: "A sample Jetton 2.0 token"
  image: "https://example.com/token.png"

Off-chain metadata — ссылка на JSON-файл:

content_layout: 0x01
uri: "https://example.com/token-metadata.json"

Интерактивная визуализация

В следующем уроке мы детально разберём поток перевода Jetton и используем интерактивную диаграмму JettonFlowDiagram, которая показывает:

1. Архитектуру — связь Master и Wallet контрактов
2. Перевод — 4-шаговый поток сообщений между контрактами
3. Минтинг — создание новых токенов через Master

Итоги

Частые ошибки

1. Пытаются прочитать баланс пользователя из Jetton Master, хотя балансы хранятся в индивидуальных Jetton Wallet контрактах, а не централизованно.
2. Путают Jetton Master (minter) и Jetton Wallet (balance holder): это два разных типа контрактов с разными интерфейсами.
3. Не верифицируют, что Jetton Wallet действительно принадлежит заявленному Jetton Master, что позволяет фишинговым токенам подделывать метаданные.
4. Забывают, что total_supply в Jetton Master обновляется асинхронно: в момент чтения он может не отражать все pending-операции mint/burn.