State: Was eine Blockchain überhaupt wissen muss

State ist die Gegenwart, History ist der Weg dorthin

Eine Blockchain enthält eine chronologische Historie von Transaktionen und Blöcken. Für viele Entscheidungen reicht die Historie allein aber nicht. Ein Knoten muss aus ihr ableiten können, welcher Zustand jetzt gültig ist. Dieser aktuelle Zustand wird häufig als State bezeichnet.

Ein einfaches Beispiel

Angenommen, ein digitales System kennt drei Personen. In der Vergangenheit wurden viele Zahlungen durchgeführt. Für eine neue Zahlung muss das Netzwerk nicht nur wissen, dass früher Transaktionen stattgefunden haben. Es muss wissen, welcher Wert aktuell noch ausgegeben werden darf und unter welchen Bedingungen.

Je nach Architektur kann dieser Zustand als Kontostand, als Menge unverbrauchter Outputs oder als Kombination aus Daten und Ausgaberegeln dargestellt werden.

State Transition

Eine Transaktion ist eine vorgeschlagene Zustandsänderung. Vereinfacht lässt sich das als Funktion darstellen:

alter Zustand + gültige Transaktion → neuer Zustand

Ist die Transaktion ungültig, darf der vorgeschlagene Übergang nicht zum neuen kanonischen Zustand werden. Das Netzwerk benötigt deshalb Regeln, nach denen jeder validierende Teilnehmer denselben Übergang nachvollziehen kann.

Validität und Konsens sind nicht dasselbe

Validität fragt, ob eine Transaktion die technischen und kryptographischen Regeln erfüllt. Konsens fragt, auf welche gültige Reihenfolge oder welchen gültigen Kettenstand sich das verteilte Netzwerk einigt. Beide Bereiche hängen zusammen, lösen aber unterschiedliche Probleme.

Wallet ist nicht gleich State

Eine Wallet ist in erster Linie ein Werkzeug zum Verwalten von Schlüsseln und zum Erzeugen oder Anzeigen von Transaktionen. Die Blockchain muss nicht glauben, was eine Wallet als Guthaben anzeigt. Knoten prüfen den gültigen Ledger-Zustand selbst. Ein angezeigter Saldo ist deshalb eine Sicht auf den Zustand, nicht die Quelle der Wahrheit.

Warum das für alle Modelle wichtig ist

Account, UTXO und eUTXO unterscheiden sich vor allem darin, wie sie gültigen Zustand repräsentieren und wie eine Transaktion ihn verändert. Wer diesen Ausgangspunkt versteht, kann spätere Unterschiede bei Smart Contracts, Gebühren, Parallelität und Sicherheit wesentlich sauberer einordnen.

Die entscheidende Frage lautet nicht nur: Welche Transaktionen gab es? Sondern: Welcher Zustand ist nach Anwendung aller gültigen Regeln jetzt gültig?

Praxisaufgabe: Zustand statt Verlauf denken

1. Denke dir ein System mit drei Personen und beliebig vielen früheren Zahlungen aus.
2. Schreibe auf, welche Informationen eine neue Zahlung tatsächlich benötigt.
3. Trenne diese Informationen in „Historie“ und „aktueller Zustand“.
4. Formuliere eine einfache State-Transition in der Form „vorher + Aktion → nachher“.
5. Notiere zusätzlich eine Bedingung, unter der der Übergang ungültig wäre.

Mini-Schritt: Erkläre in einem Satz den Unterschied zwischen State und Blockchain-Historie.