Skip to main content
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.

​
Drei Darstellungen

Engine-ZustandMärkte · Konten · Positionen · Bücher · Clearingstelleüber Blöcke hinweg · eine Rekonstruktion
Working Set des BlocksMarks · berührte Konten · Ausführungen · Ausgabennur für einen Block · ein Journal
Chain-Zustandversionierte Schlüssel-Wert-Paare, Merkle-authentifiziertmaßgeblich
Der Fehler, den das verhindertEine 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.
der Engine-Zustand muss aus dem festgeschriebenen Datensatz ableitbar sein, nie umgekehrt
Der Engine-Zustand ist das, was der 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. 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.

​
Schlüssel

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.
Deshalb sollte Konfiguration von der Chain gelesen und nicht im Client-Code festgezurrt werden. Der Dienst für Gebührenstufen 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.

​
Versionen

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.

​
Was am Ende festgeschrieben wird

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.

​
Wie es weitergeht

Speicherung und Beweise

Wie festgeschriebener Zustand physisch gespeichert und authentifiziert wird und wie Pruning greift.

Zustandssynchronisation

Wie eine Node, die die Chain nie gesehen hat, zu ihr aufschließt.

IntentionKernel

Wo der Engine-Zustand und das Working Set eines Blocks liegen.

Indexer

Festgeschriebenen Zustand in etwas Abfragbares verwandeln.