Асинхронные Сообщения

Асинхронность — это не просто техническая деталь, а основное архитектурное ограничение (и преимущество) TON. В отличие от синхронного мира Ethereum, где вы можете вызвать контракт и тут же получить результат, в TON каждое межконтрактное взаимодействие — это отдельная транзакция. Это как разница между телефонным звонком (синхронно) и перепиской по email (асинхронно): оба работают, но требуют разных паттернов общения.

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

Жизненный цикл сообщения

Сообщение проходит следующие этапы:

1. Создание — контракт-отправитель формирует сообщение (адрес, значение, тело)
2. Маршрутизация — валидаторы определяют шард получателя и доставляют сообщение
3. Доставка — сообщение попадает во входящую очередь шарда получателя
4. Исполнение — TVM обрабатывает сообщение, изменяя состояние контракта-получателя
5. Ответ — контракт-получатель может создать одно или несколько ответных сообщений

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

Рассмотрим типичный сценарий: пользователь хочет обменять TON на USDT через DEX.

Обратите внимание: каждый шаг — отдельная транзакция. Между шагами может пройти несколько секунд (время создания нового блока).

Ключевые свойства асинхронных сообщений

Отсутствие гарантированного порядка

Если контракт A отправляет два сообщения — B и C — одновременно, нет гарантии, какое будет обработано первым. Это зависит от маршрутизации между шардами.

Контракт A отправляет:
  msg1 → Контракт B (шард 1)
  msg2 → Контракт C (шард 2)

Возможный порядок обработки:
  [OK] msg1, затем msg2
  [OK] msg2, затем msg1
  [OK] одновременно (разные шарды)

Гарантия доставки

TON гарантирует доставку каждого сообщения. Если сообщение создано, оно будет обработано получателем (или “отскочит” обратно, если получатель не может его принять).

Каузальный порядок

Хотя общий порядок не гарантирован, каузальный порядок соблюдается: если сообщение M2 было создано в результате обработки M1, то M2 будет обработано после M1.

Паттерны асинхронного программирования

Запрос-Ответ

Самый простой паттерн: контракт A отправляет запрос контракту B и обрабатывает ответ.

A: send query → B
B: process query, send response → A
A: handle response

Цепочка сообщений

Более сложный паттерн, где результат одного контракта передаётся следующему:

A → B → C → D → ... → A (финальный ответ)

Параллельные запросы

Контракт A может отправить несколько сообщений одновременно и собирать ответы по мере поступления:

A → B (запрос 1)
A → C (запрос 2)
B → A (ответ 1)
C → A (ответ 2)
A: все ответы получены, финализация

Стоимость сообщений

Каждое сообщение несёт затраты:

• Gas за обработку — TVM выполняет код получателя
• Forwarding fee — плата за маршрутизацию между шардами
• Value — TON, прикреплённый к сообщению (передаётся получателю)

Отправитель прикрепляет к сообщению TON, из которых оплачиваются gas и forwarding. Остаток получает контракт-получатель.

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

1. Предполагают, что сообщения между контрактами доставляются мгновенно, хотя доставка может занять от одного до нескольких блоков, особенно при межшардовом взаимодействии.
2. Не реализуют паттерн «запрос-ответ» при взаимодействии контрактов: отправляют сообщение, но не предусматривают обработку ответного сообщения.
3. Забывают, что порядок обработки сообщений не гарантирован для сообщений от разных отправителей — только от одного отправителя к одному получателю порядок сохраняется.
4. Не закладывают таймауты и fallback-логику на случай, если ответное сообщение не придёт (например, контракт-получатель удалён или заморожен).