> ## 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.
# Zustandssynchronisation
> Wie eine Node, die die Chain nie gesehen hat, zur aktuellen Version aufschließt und wie sie dort bleibt.
Eine Node, die dem Netzwerk beitritt, muss zwei Fragen beantworten: Wie komme ich dahin, wo die Chain jetzt steht, und wie bleibe ich dort? Die Zustandssynchronisation beantwortet beides, und der Zielkonflikt dazwischen ist ausdrücklich benannt statt versteckt.
Zwei Wege, um aufzuschließen
Das Bootstrapping – von null auf die aktuelle Version zu kommen – geht auf zwei grundsätzlich verschiedene Arten.
**Die Historie erneut durchlaufen.** Bei Genesis beginnen und sich nach vorn arbeiten, entweder indem jede Transaktion erneut ausgeführt wird oder indem die Ausgaben angewendet werden, die die Ausführung bereits erzeugt hat. Das Ergebnis ist eine Node mit der gesamten Historie: jede Version, jeder Beweis, jede Transaktion. Es ist außerdem langsam, und es wird mit jedem Tag langsamer, den die Chain läuft.
**Den aktuellen Zustand herunterladen.** Die Historie überspringen und die Zustandsschlüssel und -werte so abrufen, wie sie bei der neuesten Version stehen, geprüft gegen die festgeschriebene Wurzel. Die Node ist in einem Bruchteil der Zeit aktuell – und weiß nichts darüber, wie die Chain dorthin gekommen ist.
Eine neue Node
Bootstrapping-Modus
Historie durchlaufenab Genesis neu ausführen oder Ausgaben anwendenlangsam, und täglich langsamer
Zustand herunterladenSchlüssel und Werte bei der neuesten Version, geprüft gegen die festgeschriebene Wurzelaktuell in einem Bruchteil der Zeit
Aktuelle Versionlaufender Sync
Die beiden Wege sind nicht gleichwertigEine Node, die den Zustand heruntergeladen hat, kann keine historischen Abfragen bedienen und nicht sagen, wie eine Position dorthin kam. Wer einen Indexer oder ein Audit bedient, braucht genau die übersprungene Historie.
Innerhalb des Replay-Pfads gibt es eine weitere Wahl – Transaktionen neu ausführen, die gespeicherten Ausgaben anwenden oder die Node an jeder Stelle das Schnellere wählen lassen. Die Neuausführung ist die stärkere Prüfung, weil sie das Ergebnis reproduziert, statt einem aufgezeichneten zu vertrauen; das Anwenden der Ausgaben ist schneller. Den gemischten Modus gibt es, weil die richtige Antwort davon abhängt, wie weit die Node zurückliegt.
Das ist eine operative Entscheidung und keine Voreinstellung, die man ungeprüft übernimmt. Eine Node, die den aktuellen Zustand heruntergeladen hat, kann weder historische Abfragen bedienen noch beantworten, wie eine Position dorthin gekommen ist, wo sie steht – sie hat keine Historie zu lesen. Eine Node, die einen [Indexer](/de/protocol/architecture/indexer) oder einen Prüfprozess bedient, braucht genau die Historie, die sie übersprungen hat.
Aktuell bleiben
Ist die aktuelle Version erreicht, hält eine Node Schritt, indem sie festgeschriebene Blöcke konsumiert, sobald sie eintreffen – wieder entweder durch Ausführen der Transaktionen oder durch Anwenden der Ausgaben, mit derselben Abwägung zwischen Prüftiefe und Geschwindigkeit.
Der Unterschied zum Bootstrapping: Der Abstand ist klein und konstant statt groß und schrumpfend. Eine Node, die weit genug zurückfällt, geht wieder in den Bootstrapping-Pfad, statt einen beliebig großen Abstand schrittweise schließen zu wollen.
Wie die Daten fließen
Beim Sync bittet nicht einfach eine Node eine andere um einen Bereich von Blöcken. Der Ablauf ist in Schichten getrennt, damit kein einzelner Peer zur Abhängigkeit wird und kein einzelner Ausfall den Fortschritt anhält.
| Schicht | Aufgabe |
| --------------------- | ------------------------------------------------------------------------------------------------- |
| **Storage-Service** | Liefert Daten an andere Nodes: Transaktionen, Ausgaben, Zustandswerte und die zugehörigen Beweise |
| **Data-Client** | Wählt Peers, verfolgt, wer was hat, sendet Anfragen und behandelt die fehlgeschlagenen |
| **Streaming-Service** | Macht aus „bring mich von hier nach dort“ einen geordneten Strom geprüfter Chunks |
| **Driver** | Entscheidet, was die Node als Nächstes braucht, und wendet an, was eintrifft |
Die Konsequenz, die man verstanden haben sollte: Eine synchronisierende Node vertraut keinem Peer. Jeder Chunk kommt mit einem Beweis gegen eine Wurzel, die das Netzwerk festgeschrieben hat, und ein Peer, der Inkonsistentes liefert, wird abgelehnt statt geglaubt. Die Peer-Auswahl ist eine Performance-Entscheidung, keine Vertrauensentscheidung.
Verifikation
Nichts in der Zustandssynchronisation wird akzeptiert, weil es von einem bestimmten Absender kommt.
Zustandswerte werden gegen den festgeschriebenen State-Root geprüft. Transaktionen und Ausgaben werden gegen die Akkumulatoren geprüft. Eine Node, die das Bootstrapping abschließt, hat einen Zustand, dessen Wurzel zu dem passt, was ein Quorum von Validatoren signiert hat – und genau das macht den schnellen Weg sicher: Wer den aktuellen Zustand herunterlädt, überspringt die Historie, nicht aber die Verifikation.
Wie es weitergeht
Die Strukturen, die Sync überprüfbar machen.
Node-Rollen und wie man sich für den Betrieb einer Node meldet.
Mit welcher Node-Stufe ein synchronisierender Peer spricht.
Was die Historie beantwortet, was der aktuelle Zustand nicht kann.