Асинхронная модель

Tycho использует акторную модель вычислений: каждый аккаунт (смарт-контракт) является изолированным «актором» со своим состоянием и обрабатывает входящие сообщения. Взаимодействие между контрактами строится как обмен сообщениями, а «транзакция» — это результат исполнения одного сообщения на одном аккаунте.

В классическом определении акторной модели актор — базовый строительный блок конкурентных вычислений. Получив сообщение, актор может:

• принять локальное решение и изменить своё состояние
• отправить сообщения другим акторам
• создать новых акторов (в блокчейне — развернуть новые контракты)

В терминах блокчейна это удобно интерпретировать так: контракт обрабатывает входящее сообщение, обновляет своё состояние и выпускает новые сообщения (в другие контракты или в себя), формируя дальнейший workflow (цепочку сообщений).

Ключевые идеи

• Нет «вызовов контрактов в одном стеке» как в EVM: контракт не вызывает другой контракт синхронно, он отправляет ему сообщение
• Одно external-сообщение (вход извне) может породить цепочку internal-сообщений (межконтрактных), которые будут выполнены в последующих транзакциях
• Сообщения одного аккаунта исполняются последовательно, но сообщения разных аккаунтов могут исполняться параллельно, что повышает пропускную способность

Акторы: аккаунт = контракт = единица изоляции

В акторной модели:

• у каждого актора есть собственное состояние, которое изменяется только при обработке входящего сообщения
• акторы не имеют общей памяти и «не делят состояние напрямую» — только через сообщения
• обработка сообщения на акторе атомарна относительно этого актора (внутри одного аккаунта нет параллельного исполнения нескольких сообщений)

Практический смысл: чтобы изменить состояние другого контракта, нужно отправить ему internal-сообщение и дождаться, пока он обработает его в своей транзакции.

Очередь входящих сообщений

В классической акторной модели у актора есть «почтовый ящик» (mailbox) — очередь входящих сообщений, а обработка идёт последовательно, по одному сообщению за раз. Это даёт два практических эффекта:

• нет необходимости в блокировках для защиты инвариантов состояния
• параллелизм достигается за счёт одновременной работы разных акторов

В Tycho порядок исполнения сообщений для аккаунта дополнительно фиксируется правилами logical time (LT) и детерминированными правилами выборки сообщений, но модель «одно сообщение → одна транзакция → обновление состояния» остаётся базовой.

Как делать большие workflow (длинные процессы)

Каждая транзакция ограничена ресурсами исполнения (например, лимитами по газу и параметрами блока). Поэтому «бесконечный цикл» или обработка большого объёма данных обычно проектируются как пошаговый процесс:

1. контракт обрабатывает входящее сообщение и делает часть работы
2. сохраняет промежуточное состояние
3. отправляет internal-сообщение (часто самому себе) для продолжения

Такой подход снимает ограничение «всё должно поместиться в одну транзакцию» и позволяет выполнять произвольный объём работы, распределяя её по цепочке сообщений.

Параллельность без гонок

Акторная модель хорошо распараллеливается, потому что изоляция по аккаунтам естественным образом задаёт границы независимости:

• для одного аккаунта сообщения исполняются строго последовательно (чтобы состояние было однозначным)
• для разных аккаунтов исполнение можно распараллеливать, если соблюсти детерминированные правила выбора и порядка сообщений

Это отличается от EVM-подхода, где кросс-контрактные взаимодействия происходят синхронно в рамках одного транзакционного стека (call stack), что приводит к классу проблем вроде «вклинивания» (reentrancy) и усложняет безопасное проектирование. В асинхронной модели вместо «вызова и немедленного результата» используются сообщения и явные состояния/колбэки.

Гарантии порядка: Logical Time (LT) и детерминизм исполнения

Чтобы разные ноды получили одинаковый результат при создании блока, Tycho вводит правила, устраняющие неоднозначность порядка исполнения сообщений. Для детерминизма требуется, чтобы сообщения «внутри контракта» исполнялись в строгом порядке logical time. Это обеспечивается:

1) Правилами LT для исходящих сообщений

• Для последовательных сообщений, отправленных контрактом A, соблюдается монотонность: LT(M1) > LT(M0)
• На уровне блоков соблюдается порядок: сообщения в блоке B+1 имеют больший LT, чем сообщения в блоке B+0

2) Правилами выбора и сортировки сообщений на исполнение

• Буфер очереди для каждого аккаунта-получателя сортируется по возрастанию logical time hash (ключ детерминированной выборки)
• Группы на исполнение формируются со строгим соблюдением порядка logical time hash
• Дополнительно применяется исполнение «волнами»: сообщения группируются в наборы (условно S1, S2, …) и обрабатываются по порядку наборов. Сообщения, которые появились как результат исполнения набора S1, попадают в следующий набор S2 и не могут «обогнать» сообщения из S1. Это помогает сохранять причинно-следственный порядок и эффективно распараллеливать вычисления в пределах доступных ресурсов

Порядок для взаимозависимых переходов состояния (Triangle constraint)

Отдельная задача — взаимозависимые состояния, когда сообщения порождают новые сообщения в связанные контракты:

• контракт A одновременно отправляет M1 в B и M2 в C
• при обработке M1 контракт B создаёт ещё одно сообщение M3 в C
• тогда C обязан обработать M2 раньше, чем M3 (даже если сообщения попадают в один блок или в разные блоки)

Это ограничение нужно, чтобы причинно-следственные зависимости между сообщениями сохранялись даже при распараллеливании исполнения.