Skip to main content
Словом «состояние» в торговом движке называют три разные вещи, и именно из-за их смешения системы начинают выдавать ответы, которые зависят от того, кого спросить. Эта страница их разделяет и говорит, какое из трёх — источник истины.

Три представления

Состояние движкарынки · счета · позиции · стаканы · клиринговая палатаживёт между блоками · реконструкция
Рабочий набор блокацены · затронутые счета · исполнения · выходные данныеживёт один блок · журнал
Состояние блокчейнаверсионированные записи, аутентификация Мерклаисточник истины
Какой отказ это предотвращаетДвижок, чьё представление в памяти разошлось с зафиксированным, продолжает выдавать ответы, и каждый из них неверен так, что это всплывёт только при расчёте.
состояние движка должно выводиться из зафиксированной записи, и никогда наоборот
Состояние движка — это то, что ядро держит между блоками: метаданные рынков, счета, позиции, стаканы заявок, состояние инструментов, состояние клиринговой палаты. Это рабочее представление, разложенное под те шаблоны доступа, которые реально нужны сопоставлению и клирингу, а не под хранение. Рабочий набор блока существует только пока блок исполняется: маркировочные цены, зафиксированные в начале; какие счета и ордера были затронуты; какие исполнения получились; выходные данные, которые собираются по ходу. Это журнал того, что произошло за этот блок. Состояние блокчейна — зафиксированный результат: версионированные записи «ключ — значение», аутентифицированные структурой Меркла, долговечные и воспроизводимые. Именно его синхронизирует узел, именно к нему привязано доказательство и именно его читает индексатор. Источник истины — состояние блокчейна. Рабочий набор блока — это журнал, по которому собираются детерминированные выходные данные, а не источник истины. Состояние движка — реконструкция состояния блокчейна, оптимизированная под исполнение; оно должно выводиться из зафиксированной записи, и никогда наоборот. Перепутать здесь направление — вполне конкретный и узнаваемый отказ: движок, чьё представление в памяти разошлось с зафиксированным, продолжит выдавать ответы, и каждый из них будет неверным так, что это всплывёт только при расчёте.

Ключи

Состояние блокчейна адресуется по ключу. Торговое состояние сгруппировано в именованные пространства имён с явной версией — например, конфигурация комиссий, индекс бессрочных контрактов, таблица ступеней плеча, список административных ролей. Суффикс версии — не украшение. Когда меняется форма конфигурации, она переезжает на новую версию своего ключа, а прежний ключ сохраняется, чтобы состояние, записанное по старой схеме, можно было читать во время миграции. Читатель, который зашил одну версию в код и никогда её не перепроверяет, после миграции будет молча читать устаревшую конфигурацию; читатель, который каждый раз перечитывает актуальный ключ, — не будет.
Поэтому конфигурацию следует читать с блокчейна, а не закреплять в коде клиента. Сервис комиссионных уровней читает актуальную конфигурацию комиссий на каждом цикле ровно по этой причине: таблица уровней, зашитая в клиент, — это таблица, которая рано или поздно разойдётся с той, что применяет сеть.

Версии

Каждый зафиксированный блок продвигает версию. Значения состояния хранятся привязанными к версии, на которой они были записаны, а значит, хранилище — это не просто «текущее состояние», а «состояние на любой версии». Отсюда сразу несколько возможностей:
  • Доказательства можно строить для конкретной версии, а не только для текущего момента.
  • Воспроизведение можно начинать с любой версии, а не только с генезиса.
  • Чтения могут быть историческими: индексатор, восстанавливающий историю позиции, запрашивает старые версии, а не сканирует лог.
  • Обрезка истории становится вопросом политики — насколько глубоко хранить, — а не структурным ограничением.

Что в итоге фиксируется

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

Что дальше

Хранение и доказательства

Как зафиксированное состояние физически хранится, аутентифицируется и обрезается.

Синхронизация состояния

Как узел, никогда не видевший блокчейна, догоняет его.

IntentionKernel

Где живут состояние движка и рабочий набор блока.

Индексатор

Как зафиксированное состояние превращается в то, что можно запрашивать.