> ## 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.

# ステートモデル

> チェーン状態とは何を指すのか、どうキー付けされバージョン付けされるのか、3つの状態表現のうちどれが権威を持つのかです。

取引エンジンでは、3つの異なるものが「状態」と呼ばれます。それらを混同すると、誰に聞くかで答えが変わるシステムができあがります。このページでは3つを切り分け、どれが権威を持つのかを示します。

<h2 id="three-representations">
  3つの表現
</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">1ブロックだけ存在 · ジャーナル</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">バージョン付きキーバリュー、Merkleで認証</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>

**エンジン状態**とは、[カーネル](/ja/protocol/architecture/kernel)がブロックとブロックの間で保持しているものです。マーケットのメタデータ、アカウント、ポジション、板、銘柄の状態、クリアリングハウスの状態です。これは作業用の表現であり、ストレージ向けではなく、マッチングとクリアリングが実際に行うアクセスパターンに合わせて配置されています。

**ブロックワーキングセット**は、ブロックの実行中にだけ存在します。開始時に固定されたマーク価格、どのアカウントと注文に触れたか、生成された約定、組み立て途中の出力です。このブロックの中で何が起きたかを記録したジャーナルです。

**チェーン状態**はコミットされた結果です。バージョン付きのキーバリューエントリで、Merkle構造によって認証され、永続的でリプレイ可能です。ノードが同期する対象であり、証明が向けられる対象であり、[インデクサー](/ja/protocol/architecture/indexer)が読む対象です。

**権威を持つのはチェーン状態です**。ブロックワーキングセットは決定的な出力を組み立てるためのジャーナルであって、真実の拠り所ではありません。エンジン状態は、実行向けに最適化されたチェーン状態の再構成です。コミット済みの記録から導出できなければならず、その逆であってはなりません。

ここを逆にすると、特有の、見分けのつく形で壊れます。メモリ上のビューがコミット済みの内容からずれたエンジンは、そのまま答えを返し続けます。その答えはすべて誤っており、しかもずれが表に出るのは決済の段階になってからです。

<h2 id="keys">
  キー
</h2>

チェーン状態はキーでアドレス指定されます。取引に関する状態は、名前が付き、バージョンが明示された名前空間にまとめられます。たとえば手数料設定、無期限先物のインデックス、レバレッジティア表、管理ロールの一覧です。

バージョンの接尾辞は飾りではありません。設定の形が変わると、そのキーは新しいバージョンへ移り、旧スキーマで書かれた状態を移行中も読めるように以前のキーが残されます。特定のバージョンをハードコードして再確認しない読み手は、移行後も古い設定を黙って読み続けます。現在のキーを解決する読み手はそうなりません。

<Note>
  設定をクライアントのコードに固定するのではなく、チェーンから読むべき理由がこれです。[手数料ティアのサービス](/ja/protocol/architecture/programs)がサイクルごとにライブの手数料設定を読み直しているのも、まさにこの理由によります。クライアントに焼き込まれたティア表は、いずれネットワークが適用している表と食い違います。
</Note>

<h2 id="versions">
  バージョン
</h2>

コミットされたブロックごとに、バージョンが1つ進みます。状態の値は書き込まれた時点のバージョンに紐づけて保存されるため、ストアが持つのは「現在の状態」だけではなく「任意のバージョン時点の状態」です。

この性質が、いくつものことを同時に可能にしています。

* **証明**を、現在に対してだけでなく特定のバージョンに対して生成できます。
* **リプレイ**を、ジェネシスからだけでなく任意のバージョンから開始できます。
* **読み取り**は過去に向けられます。ポジションの履歴を再構成するインデクサーは、ログを走査しているのではなく古いバージョンを問い合わせています。
* **プルーニング**は、構造上の制約ではなく、どこまで遡って保持するかというポリシーの判断になります。

<h2 id="what-ends-up-committed">
  最終的にコミットされるもの
</h2>

カーネルの実行は、ブロックごとに2種類のものを生み出します。各トランザクションは、それ自身に紐づいた書き込みとイベントを持ちます。単一のユーザートランザクションに属さない効果（資金調達フロー、保険基金の移動、ブロック単位のカウンタ）は、専用のシステムチャネルへ送られます。

この2つの間で失われるものはありません。カーネル内部の実行効果で、トランザクションの出力にもシステムチャネルにも現れないものは存在しません。この完全性があるからこそ、コミット済みの記録は要約ではなく全体像として扱えます。マッチングがバッチで走った場合でもイベントを原因のトランザクションまで辿れるのは、このためです。

<h2 id="where-to-go-next">
  次に読む
</h2>

<CardGroup cols={2}>
  <Card title="ストレージと証明" href="/ja/protocol/architecture/state/storage">
    コミット済みの状態が物理的にどう保存され、認証され、プルーニングされるのかです。
  </Card>

  <Card title="ステートシンク" href="/ja/protocol/architecture/state/sync">
    チェーンを一度も見たことのないノードが、どうやって追いつくのかです。
  </Card>

  <Card title="IntentionKernel" href="/ja/protocol/architecture/kernel">
    エンジン状態とブロックワーキングセットが存在する場所です。
  </Card>

  <Card title="インデクサー" href="/ja/protocol/architecture/indexer">
    コミット済みの状態を、照会可能なものに変えます。
  </Card>
</CardGroup>