Модель Акторов в TON

Модель акторов — это фундаментальная парадигма, определяющая всю архитектуру приложений на TON. Представьте каждый смарт-контракт как независимого сотрудника в компании: он имеет свой «стол» (состояние), обрабатывает «письма» (сообщения) и может отправлять «письма» другим сотрудникам. Без глубокого понимания модели акторов невозможно писать корректные контракты — каждый баг в продакшене, связанный с race conditions или потерей средств, восходит к непониманию этой модели.

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

Что такое актор?

Актор — это изолированная вычислительная единица, которая обладает:

• Собственным состоянием (storage) — данные контракта, хранящиеся в дереве ячеек
• Собственным кодом — логика обработки сообщений (TVM bytecode)
• Собственным балансом — TON, необходимые для оплаты хранения и газа
• Адресом — уникальный идентификатор в сети

Акторы не имеют доступа к состоянию друг друга. Единственный способ взаимодействия — отправка сообщений.

Изоляция состояния

В модели акторов TON нет общего глобального состояния. Каждый контракт видит только свои данные:

Контракт A не может прочитать state_B. Если ему нужны данные из B, он отправляет сообщение-запрос и ждёт ответа.

Преимущества модели акторов

1. Нет атак reentrancy

В Ethereum reentrancy — одна из самых опасных уязвимостей (вспомните взлом The DAO). В TON reentrancy невозможна: каждое сообщение обрабатывается в отдельной транзакции, контракт не может быть вызван повторно до завершения текущей обработки.

2. Естественный шардинг

Поскольку акторы изолированы, блокчейн может распределять их по шардам без конфликтов. Каждый шард обрабатывает свой набор акторов независимо.

3. Параллельное исполнение

Транзакции, затрагивающие разных акторов, выполняются параллельно. Это обеспечивает горизонтальную масштабируемость.

Сложности модели акторов

Обработка ошибок

Если контракт B не смог обработать сообщение от A, нет автоматического отката состояния A. Вместо этого TON использует механизм bounce — неуспешное сообщение “отскакивает” обратно.

Отсутствие атомарности

В Ethereum вызов A → B → C атомарен: если C откатывается, откатываются и B, и A. В TON каждый шаг — отдельная транзакция. Разработчик должен явно обрабатывать все промежуточные состояния.

Eventual consistency

Состояние системы из нескольких контрактов в TON — eventually consistent. Между отправкой и получением сообщения проходит время, и состояние отправителя и получателя не синхронизированы.

Жизненный цикл актора

1. Создание — деплой кода и начального состояния
2. Получение сообщения — TVM загружает код и состояние контракта
3. Обработка — выполнение кода, изменение состояния
4. Отправка сообщений — результат обработки (0 или более исходящих сообщений)
5. Сохранение — обновлённое состояние записывается в блокчейн
6. Заморозка — если баланс падает ниже минимума, контракт “замораживается”

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

1. Пытаются прочитать состояние другого контракта напрямую, хотя в модели акторов это невозможно; нужно отправить сообщение-запрос и обработать ответ.
2. Забывают, что контракт обрабатывает сообщения строго последовательно, но несколько контрактов работают параллельно, что создаёт иллюзию одновременности.
3. Не учитывают, что между отправкой сообщения и получением ответа состояние контракта-получателя может измениться из-за других входящих сообщений.
4. Проектируют систему как единый монолитный контракт вместо набора взаимодействующих акторов, что является антипаттерном в TON и ограничивает масштабируемость.