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

# Zustandsmodell

> Was den Chain-Zustand ausmacht, wie er adressiert und versioniert wird und welche der drei Zustandsdarstellungen maßgeblich ist.

In einer Trading-Engine heißen drei verschiedene Dinge „Zustand“, und wer sie verwechselt, landet bei Systemen, deren Antworten davon abhängen, wen man fragt. Diese Seite trennt sie und sagt, welche maßgeblich ist.

<h2 id="three-representations">
  Drei Darstellungen
</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">Engine-Zustand</span><span className="dg-s">Märkte · Konten · Positionen · Bücher · Clearingstelle</span><span className="dg-n">über Blöcke hinweg · eine Rekonstruktion</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">Working Set des Blocks</span><span className="dg-s">Marks · berührte Konten · Ausführungen · Ausgaben</span><span className="dg-n">nur für einen Block · ein Journal</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">Chain-Zustand</span><span className="dg-s">versionierte Schlüssel-Wert-Paare, Merkle-authentifiziert</span><span className="dg-n">maßgeblich</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">Der Fehler, den das verhindert</span><span className="dg-s">Eine Engine, deren Sicht im Arbeitsspeicher vom Festgeschriebenen abgedriftet ist, liefert weiter Antworten – und jede davon ist auf eine Weise falsch, die erst bei der Abrechnung auffällt.</span></div>
    <div className="dg-lbl" style={{left:"50.0000%",top:"61.1111%",width:"45.8333%",whiteSpace:"normal"}}>der Engine-Zustand muss aus dem festgeschriebenen Datensatz ableitbar sein, nie umgekehrt</div>
  </div>
</div>

**Der Engine-Zustand** ist das, was der [Kernel](/de/protocol/architecture/kernel) zwischen Blöcken hält: Marktmetadaten, Konten, Positionen, Orderbücher, Instrumentenzustand, Zustand der Clearingstelle. Er ist die Arbeitsdarstellung – ausgelegt auf die Zugriffsmuster, die Matching und Clearing tatsächlich haben, nicht auf Speicherung.

**Das Working Set eines Blocks** existiert nur, während der Block ausgeführt wird: die zu Beginn fixierten Mark-Preise, welche Konten und Orders berührt wurden, die erzeugten Ausführungen, die entstehenden Ausgabedaten. Es ist ein Journal dessen, was während dieses Blocks passiert ist.

**Der Chain-Zustand** ist das festgeschriebene Ergebnis: versionierte Schlüssel-Wert-Einträge, durch eine Merkle-Struktur authentifiziert, dauerhaft und im Replay reproduzierbar. Ihn synchronisiert eine Node, gegen ihn läuft ein Beweis, und ihn liest ein [Indexer](/de/protocol/architecture/indexer).

**Maßgeblich ist der Chain-Zustand.** Das Working Set eines Blocks ist ein Journal, aus dem deterministische Ausgabedaten gebaut werden – keine Quelle der Wahrheit. Der Engine-Zustand ist eine auf Ausführung optimierte Rekonstruktion des Chain-Zustands; er muss aus dem festgeschriebenen Datensatz ableitbar sein, nie umgekehrt.

Diese Vertauschung ist ein konkreter, wiedererkennbarer Fehler: Eine Engine, deren Sicht im Arbeitsspeicher vom Festgeschriebenen abgedriftet ist, liefert weiter Antworten – und jede davon ist auf eine Weise falsch, die erst bei der Abrechnung auffällt.

<h2 id="keys">
  Schlüssel
</h2>

Der Chain-Zustand wird über Schlüssel adressiert. Der Handelszustand ist in benannte, ausdrücklich versionierte Namensräume gruppiert – zum Beispiel die Gebührenkonfiguration, den Perpetual-Index, die Hebelstufentabelle, die Liste der administrativen Rollen.

Das Versionssuffix ist keine Zierde. Ändert sich die Form einer Konfiguration, wandert sie auf eine neue Version ihres Schlüssels, und der bisherige Schlüssel bleibt erhalten, damit Zustand aus dem alten Schema während der Migration weiter lesbar ist. Ein Leser, der eine Version fest einprogrammiert und nie erneut prüft, liest nach einer Migration stillschweigend veraltete Konfiguration; ein Leser, der den aktuellen Schlüssel auflöst, nicht.

<Note>
  Deshalb sollte Konfiguration von der Chain gelesen und nicht im Client-Code festgezurrt werden. Der [Dienst für Gebührenstufen](/de/protocol/architecture/programs) liest die aktuelle Gebührenkonfiguration in jedem Zyklus genau aus diesem Grund – eine in einen Client eingebackene Stufentabelle ist eine Tabelle, die irgendwann von der abweicht, die das Netzwerk anwendet.
</Note>

<h2 id="versions">
  Versionen
</h2>

Jeder festgeschriebene Block erhöht eine Version. Zustandswerte werden zu der Version gespeichert, bei der sie geschrieben wurden – der Speicher enthält also nicht bloß „den aktuellen Zustand“, sondern „den Zustand bei jeder beliebigen Version“.

Diese Eigenschaft macht mehrere Dinge gleichzeitig möglich:

* **Beweise** lassen sich gegen eine bestimmte Version führen, nicht nur gegen die Gegenwart.
* **Replay** kann bei jeder Version beginnen, nicht nur bei Genesis.
* **Lesezugriffe** können historisch sein – ein Indexer, der die Historie einer Position rekonstruiert, fragt alte Versionen ab, statt ein Log zu durchsuchen.
* **Pruning** wird zur Richtlinienentscheidung darüber, wie weit zurück aufbewahrt wird, statt zu einer strukturellen Grenze.

<h2 id="what-ends-up-committed">
  Was am Ende festgeschrieben wird
</h2>

Die Kernel-Ausführung erzeugt pro Block zweierlei. Zu jeder Transaktion gehören ihre eigenen Schreibvorgänge und Ereignisse, fest an sie gebunden. Wirkungen, die zu keiner einzelnen Nutzertransaktion gehören – Funding-Flüsse, Bewegungen des Versicherungsfonds, Zähler auf Blockebene –, laufen über einen eigenen Systemkanal.

Zwischen beiden geht nichts verloren. Es gibt keine Ausführungswirkung im Kernel, die zugleich in der Ausgabe einer Transaktion und im Systemkanal fehlt. Diese Vollständigkeit erlaubt es, den festgeschriebenen Datensatz als die ganze Geschichte zu behandeln statt als deren Zusammenfassung, und sie ist der Grund, warum sich ein Ereignis auf die Transaktion zurückführen lässt, die es verursacht hat – selbst wenn das Matching als Stapel lief.

<h2 id="where-to-go-next">
  Wie es weitergeht
</h2>

<CardGroup cols={2}>
  <Card title="Speicherung und Beweise" href="/de/protocol/architecture/state/storage">
    Wie festgeschriebener Zustand physisch gespeichert und authentifiziert wird und wie Pruning greift.
  </Card>

  <Card title="Zustandssynchronisation" href="/de/protocol/architecture/state/sync">
    Wie eine Node, die die Chain nie gesehen hat, zu ihr aufschließt.
  </Card>

  <Card title="IntentionKernel" href="/de/protocol/architecture/kernel">
    Wo der Engine-Zustand und das Working Set eines Blocks liegen.
  </Card>

  <Card title="Indexer" href="/de/protocol/architecture/indexer">
    Festgeschriebenen Zustand in etwas Abfragbares verwandeln.
  </Card>
</CardGroup>