> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Модель состояния

> Что считается состоянием блокчейна, как оно адресуется и версионируется и какое из трёх представлений состояния авторитетно.

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

<h2 id="three-representations">
  Три представления
</h2>

<div className="dg" data-dg="state-model">
  <div className="dg-c" style={{aspectRatio:"720 / 288"}}>
    <svg className="dg-w" viewBox="0 0 720 288" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 215.00 90.00 L 243.60 90.00" />

      <path className="dg-head dg--blue" d="M 250.00 90.00 L 243.60 94.40 L 243.60 85.60 Z" />

      <path className="dg-wire dg--green" d="M 470.00 90.00 L 498.60 90.00" />

      <path className="dg-head dg--green" d="M 505.00 90.00 L 498.60 94.40 L 498.60 85.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 615.00 145.00 L 615.00 176.00 L 105.00 176.00 L 105.00 151.40" />

      <path className="dg-head dg--green" d="M 105.00 145.00 L 109.40 151.40 L 100.60 151.40 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"13.8889%",width:"29.1667%",height:"34.7222%"}}><span className="dg-t">Состояние движка</span><span className="dg-s">рынки · счета · позиции · стаканы · клиринговая палата</span><span className="dg-n">живёт между блоками · реконструкция</span></div>
    <div className="dg-b dg--yellow dg-dashed" style={{left:"35.4167%",top:"13.8889%",width:"29.1667%",height:"34.7222%"}}><span className="dg-t">Рабочий набор блока</span><span className="dg-s">цены · затронутые счета · исполнения · выходные данные</span><span className="dg-n">живёт один блок · журнал</span></div>
    <div className="dg-b dg--green" style={{left:"70.8333%",top:"13.8889%",width:"29.1667%",height:"34.7222%"}}><span className="dg-t">Состояние блокчейна</span><span className="dg-s">версионированные записи, аутентификация Меркла</span><span className="dg-n">источник истины</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"0.0000%",top:"72.9167%",width:"100.0000%",height:"23.6111%"}}><span className="dg-t">Какой отказ это предотвращает</span><span className="dg-s">Движок, чьё представление в памяти разошлось с зафиксированным, продолжает выдавать ответы, и каждый из них неверен так, что это всплывёт только при расчёте.</span></div>
    <div className="dg-lbl" style={{left:"50.0000%",top:"61.1111%",width:"45.8333%",whiteSpace:"normal"}}>состояние движка должно выводиться из зафиксированной записи, и никогда наоборот</div>
  </div>
</div>

**Состояние движка** — это то, что [ядро](/ru/protocol/architecture/kernel) держит между блоками: метаданные рынков, счета, позиции, стаканы заявок, состояние инструментов, состояние клиринговой палаты. Это рабочее представление, разложенное под те шаблоны доступа, которые реально нужны сопоставлению и клирингу, а не под хранение.

**Рабочий набор блока** существует только пока блок исполняется: маркировочные цены, зафиксированные в начале; какие счета и ордера были затронуты; какие исполнения получились; выходные данные, которые собираются по ходу. Это журнал того, что произошло за этот блок.

**Состояние блокчейна** — зафиксированный результат: версионированные записи «ключ — значение», аутентифицированные структурой Меркла, долговечные и воспроизводимые. Именно его синхронизирует узел, именно к нему привязано доказательство и именно его читает [индексатор](/ru/protocol/architecture/indexer).

**Источник истины — состояние блокчейна.** Рабочий набор блока — это журнал, по которому собираются детерминированные выходные данные, а не источник истины. Состояние движка — реконструкция состояния блокчейна, оптимизированная под исполнение; оно должно выводиться из зафиксированной записи, и никогда наоборот.

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

<h2 id="keys">
  Ключи
</h2>

Состояние блокчейна адресуется по ключу. Торговое состояние сгруппировано в именованные пространства имён с явной версией — например, конфигурация комиссий, индекс бессрочных контрактов, таблица ступеней плеча, список административных ролей.

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

<Note>
  Поэтому конфигурацию следует читать с блокчейна, а не закреплять в коде клиента. [Сервис комиссионных уровней](/ru/protocol/architecture/programs) читает актуальную конфигурацию комиссий на каждом цикле ровно по этой причине: таблица уровней, зашитая в клиент, — это таблица, которая рано или поздно разойдётся с той, что применяет сеть.
</Note>

<h2 id="versions">
  Версии
</h2>

Каждый зафиксированный блок продвигает версию. Значения состояния хранятся привязанными к версии, на которой они были записаны, а значит, хранилище — это не просто «текущее состояние», а «состояние на любой версии».

Отсюда сразу несколько возможностей:

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

<h2 id="what-ends-up-committed">
  Что в итоге фиксируется
</h2>

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

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

<h2 id="where-to-go-next">
  Что дальше
</h2>

<CardGroup cols={2}>
  <Card title="Хранение и доказательства" href="/ru/protocol/architecture/state/storage">
    Как зафиксированное состояние физически хранится, аутентифицируется и обрезается.
  </Card>

  <Card title="Синхронизация состояния" href="/ru/protocol/architecture/state/sync">
    Как узел, никогда не видевший блокчейна, догоняет его.
  </Card>

  <Card title="IntentionKernel" href="/ru/protocol/architecture/kernel">
    Где живут состояние движка и рабочий набор блока.
  </Card>

  <Card title="Индексатор" href="/ru/protocol/architecture/indexer">
    Как зафиксированное состояние превращается в то, что можно запрашивать.
  </Card>
</CardGroup>