Actor Model: фундамент архитектуры TON

Что такое Actor Model

Actor Model — модель вычислений, где actor — это базовая единица, которая:

1. Имеет собственное состояние (недоступное извне)
2. Получает и обрабатывает сообщения (по одному за раз)
3. В ответ на сообщение может: изменить своё состояние, отправить сообщения другим акторам, создать новых акторов

Actor Model в индустрии

Actor Model — не изобретение TON. Это проверенная модель из 1973 года:

TON как Actor System

В TON каждый аккаунт — actor:

Аккаунт в TON:
├── Address (256-bit unique ID)
├── Code (TVM bytecode — логика обработки сообщений)  
├── Data (persistent state — cells)
├── Balance (TON coins для gas и storage)
└── Message Queue (входящие сообщения)

Правила Actor Model в TON

1. Изоляция: Контракт A не может прочитать state контракта B. Только отправить сообщение и ждать ответ.
2. Последовательность: Внутри одного контракта сообщения обрабатываются строго по одному. Нет race conditions внутри контракта.
3. Асинхронность: Отправка сообщения — fire-and-forget. Ответ придёт в следующей транзакции.

Типы сообщений в TON

External Messages

Входящие сообщения из внешнего мира (off-chain → on-chain):

External Message:
Источник:    Кошелёк пользователя (off-chain)
Назначение:  Smart contract (on-chain)
Оплата gas:  Контракт-получатель платит из своего баланса
Bounce:      Невозможен (нет адреса возврата)

Internal Messages

Сообщения между контрактами (on-chain → on-chain):

Internal Message:
Источник:    Smart contract A
Назначение:  Smart contract B
Оплата gas:  Из value, приложенного к сообщению
Bounce:      Да (если bounce: true)

Log Messages

Исходящие сообщения наружу (on-chain → off-chain):

Log Message:
Источник:    Smart contract
Назначение:  Внешние системы (indexers, dApps)
Оплата gas:  Контракт-отправитель
Использование: Events для off-chain подписчиков

Транзакция в TON: anatomy

Транзакция в TON — это обработка одного сообщения одним контрактом:

Transaction:
1. Получить входящее сообщение (internal или external)
2. Credit Phase: зачислить value из сообщения на баланс
3. Compute Phase: выполнить код контракта (TVM)
4. Action Phase: отправить исходящие сообщения
5. Storage Phase: оплатить storage fee

Сравнение: TON vs Ethereum execution

Implications для System Design

1. Проектируйте State Machines

Каждый контракт — это state machine, который переходит между состояниями при получении сообщений:

DEX Pool State Machine:

State: IDLE
  → recv(swap_request) → State: PROCESSING_SWAP
  
State: PROCESSING_SWAP
  → recv(token_received) → execute swap → State: IDLE
  → recv(timeout) → refund → State: IDLE
  → recv(bounce) → error handling → State: IDLE

2. Планируйте message chains

Сложные операции = цепочки сообщений. Планируйте весь flow заранее:

• Сколько сообщений?
• Сколько gas на каждый hop?
• Что делать при ошибке на каждом шаге?

3. Не полагайтесь на порядок

Если контракт отправил два сообщения разным получателям — нет гарантии, что они обработаются в определённом порядке. Проектируйте для out-of-order delivery.

Системный взгляд на actor-model полезно дополнить пониманием низкоуровневого execution: как именно TVM исполняет контракт, как устроен стек, continuation-based control flow и взаимодействие со стеком ячеек.