Crypto · Lektion 2 von 8
Account Model: Zustand als Konten und Speicher
⏱ ca. 16 Minuten
Das Account Model verändert bestehende Zustandsobjekte
Im Account Model wird der Ledger-Zustand über Konten und deren Eigenschaften beschrieben. Ein einfaches Konto kann beispielsweise einen Saldo und eine laufende Nummer für Transaktionen besitzen. Ein Smart-Contract-Konto kann zusätzlich Code und persistenten Speicher besitzen.
Ethereum ist ein bekanntes Beispiel für eine account-basierte Smart-Contract-Architektur. Eine Transaktion kann dort den globalen Zustand verändern, indem sie etwa einen Kontostand reduziert, einen anderen erhöht oder Daten im Speicher eines Smart Contracts aktualisiert.
Die Bankkonto-Analogie
Die Analogie eines Bankkontos ist nützlich, solange man sie nicht übertreibt. Wenn Anna 10 Einheiten besitzt und 3 an Ben sendet, wird Annas Zustand auf 7 und Bens Zustand entsprechend erhöht. Technisch ist ein öffentliches Blockchain-Netzwerk natürlich keine zentrale Bankdatenbank. Viele Knoten halten und prüfen den Zustand nach denselben Regeln.
Persistenter Contract Storage
Smart Contracts benötigen oft Daten, die zwischen zwei Transaktionen erhalten bleiben: Eigentümer, Guthaben innerhalb einer Anwendung, Abstimmungsstände oder Parameter eines Protokolls. In einer account-basierten virtuellen Maschine kann ein Contract solche Werte in seinem persistenten Speicher halten und später verändern.
Reihenfolge erzeugt Abhängigkeiten
Wenn mehrere Transaktionen denselben Zustand lesen oder verändern, kann ihre Reihenfolge wichtig sein. Beispiel: Ein Vertrag enthält einen Zähler mit dem Wert 10. Zwei Transaktionen wollen ihn jeweils erhöhen. Damit das Endergebnis korrekt bestimmt wird, muss klar sein, in welcher Reihenfolge und auf welchem vorherigen Zustand die Operationen ausgeführt werden.
Das bedeutet nicht, dass account-basierte Systeme grundsätzlich keine Parallelisierung erlauben. Unabhängige Zugriffe können technisch parallelisiert oder vorab analysiert werden. Die Architektur muss jedoch Abhängigkeiten zwischen Lese- und Schreibzugriffen berücksichtigen.
Stärken des Modells
- für Entwickler oft intuitiv, weil veränderbare Variablen bekannten Programmiersprachen ähneln
- gemeinsamer Contract-Zustand lässt sich direkt modellieren
- komplexe Aufrufketten zwischen Verträgen sind möglich
Trade-offs
- Transaktionen können von gemeinsamem veränderbarem Zustand abhängen
- Reihenfolge und Zwischenzustände können für das Ergebnis wichtig sein
- komplexe externe Aufrufe können zusätzliche Sicherheitsrisiken erzeugen
- wachsender persistenter Zustand muss von der Infrastruktur verwaltet werden
Das Account Model ist nicht „eine große zentrale Tabelle“. Es ist ein replizierter, nach Protokollregeln veränderter Zustand, dessen Objekte als Accounts und Speicherbereiche organisiert werden.
📝 Aufgaben
Praxisaufgabe: Einen Account-State modellieren
- Lege die Konten Anna = 12, Ben = 5 und Contract X mit counter = 3 an.
- Führe gedanklich eine Überweisung von 4 Einheiten von Anna an Ben aus.
- Erhöhe danach counter um 1.
- Notiere den Zustand vor und nach jeder Aktion.
- Vertausche die Reihenfolge zweier Aktionen, die denselben Contract-Wert verändern, und prüfe, ob die Reihenfolge relevant ist.
Mini-Schritt: Markiere in deinem Beispiel jede Stelle, an der bestehender Zustand überschrieben oder aktualisiert wird.
❓ Quiz · 4 Fragen
Mehrere Antworten können richtig sein. Für den Kursabschluss brauchst du insgesamt mindestens 80 %.
Melde dich an, um das Quiz zu machen und Belohnungen zu sammeln.