Zum Inhalt springen
Financial Context Wiki

Zustandswurzel

Die Zustandswurzel ist Ethereums kompakte Bindung an den Weltzustand nach einem Block. Der Artikel erklärt Berechnung, Aussagekraft von Konto- und Speichernachweisen sowie Grenzen.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Eine Zustandswurzel ist eine 32 Byte lange kryptografische Bindung im Header eines Ethereum-Blocks an den Weltzustand nach Verarbeitung dieses Blocks. Der Weltzustand ordnet Adressen Konten zu. Jedes Konto bindet Nonce, Saldo, Speicherwurzel und Code-Hash; die Speicherwurzel jedes Vertrags bindet wiederum die Speicherplätze dieses Kontos.

Die Wurzel ist ein Digest, kein herunterladbarer Schnappschuss. Knoten können damit unabhängig berechnete Ergebnisse vergleichen, und Prüfer können einen Konto- oder Speichernachweis gegen einen vertrauenswürdigen Block prüfen. Die Wurzel allein kann den Zustand nicht rekonstruieren, Datenverfügbarkeit oder Finalität belegen und auch nicht zeigen, dass ein Vertrag wirtschaftlich sicher ist.

„Zustandswurzel“ ist protokollspezifisch. Ethereum bindet seinen Ausführungszustand derzeit mit einem modifizierten Merkle-Patricia-Trie. Andere Netze können andere Zustandsmodelle, Kodierungen, Hashfunktionen oder authentifizierte Datenstrukturen verwenden; derselbe Begriff macht ihre Wurzeln und Nachweise nicht austauschbar.

Funktionsweise

Ein Ausführungsclient beginnt mit dem Zustand des Elternblocks, validiert und verarbeitet den neuen Block nach den aktiven Protokollregeln und übernimmt die daraus entstehenden Konto- und Speicheränderungen. Schematisch:

S_n = Υ(S_(n-1), B_n)

Dabei ist S_(n-1) der Elternzustand, B_n die gesamte protokolldefinierte Verarbeitung des neuen Blocks und S_n der Ergebniszustand. Der Client kodiert diesen Zustand deterministisch im Zustandstrie und berechnet dessen Wurzel-Hash. Ein gültiger Blockheader muss dasselbe Ergebnis enthalten; bei einer Abweichung ist der Block für diesen Client ungültig.

Im Ethereum-Zustandstrie wird der Pfad eines Kontos aus seiner Adresse abgeleitet. Das kodierte Konto enthält Nonce, Saldo, Speicherwurzel und Code-Hash. Vertragscode wird über seinen Hash referenziert, und jeder Vertrag besitzt einen eigenen Speichertrie. Durch diese Verschachtelung kann ein geänderter Speicherplatz die Speicherwurzel des Vertrags, dann das kodierte Konto und schließlich die globale Zustandswurzel ändern.

Die Zustandswurzel unterscheidet sich von Transaktions- und Belegwurzel im selben Header. Die Transaktionswurzel bindet geordnete Transaktionsdaten, die Belegwurzel Ausführungsbelege. Keine kann die andere ersetzen.

EIP-1186 definiert eth_getProof, das für einen bestimmten Block einen Kontonachweis und angeforderte Speichernachweise liefern kann. Ein Prüfer benötigt weiterhin einen authentifizierten Block-Hash oder eine Zustandswurzel, die korrekten Trie- und Kodierungsregeln sowie eine passende Bestätigungs- oder Finalitätsrichtlinie.

Beispiel

Angenommen, eine Transaktion überträgt ETH von Alice an Bob. Die korrekte Ausführung kann Nonce und Saldo von Alice, Bobs Saldo und den Saldo des Gebührenempfängers ändern. Ruft sie einen Vertrag auf, können sich auch Speicherplätze und die Speicherwurzel des Vertrags ändern. Diese Aktualisierungen führen zu einer neuen globalen Zustandswurzel, obwohl die meisten Konten unberührt bleiben.

Zwei ehrliche Clients, die vom selben Elternzustand ausgehen und denselben gültigen Block nach denselben Regeln verarbeiten, sollten dieselbe Wurzel berechnen. Schreibt ein Client einen falschen Betrag gut oder nutzt eine falsche Trie-Kodierung, weicht seine Wurzel vom Header ab. Er muss den Block verwerfen, statt seinen lokalen Zustand stillschweigend anzunehmen.

Um Bobs Saldo ohne den gesamten Weltzustand zu prüfen, kann ein Prüfer Blockheader und Kontonachweis beziehen. Die Neuberechnung des Nachweispfads zeigt, ob das kodierte Konto zur Zustandswurzel des Headers passt. Sie beweist nicht, dass der gewählte Header kanonisch oder final ist; dies ergibt sich aus den Ketten- und Finalitätsprüfungen.

Risiken

  • Nicht vertrauenswürdige Wurzel: Ein gültiger Nachweis gegen eine vom Angreifer gewählte oder veraltete Wurzel belegt den falschen Bezugspunkt. Binden Sie die Wurzel an geprüften Block-Hash, Chain-ID und Blocknummer.
  • Reorganisationen und Finalität: Ein Nachweis kann für einen Block korrekt sein, der später die kanonische Kette verlässt. Bestätigungstiefe oder Finalität müssen zur Verlusttoleranz der Anwendung passen.
  • Kodierungsfehler: Adress-Hashing, RLP-Kodierung, Nibble-Pfade, eingebettete Knoten und Speicherschlüssel müssen exakt den Protokollregeln folgen. Eine allgemeine Bibliothek für binäre Merkle-Nachweise reicht nicht aus.
  • Fehlende Daten: Eine Wurzel bindet den Zustand, macht aber Trie-Knoten, historische Zustände oder Nachweisdienste nicht verfügbar. Bereinigte Knoten können alte Nachweise oft nicht liefern.
  • Überzogene Zusicherung: Übereinstimmende Wurzeln erkennen inkonsistente Ausführung; sie prüfen keine Vertragslogik, authentifizieren keine Orakeldaten, sichern keinen RPC-Endpunkt, garantieren keinen Vermögenswert und verhindern keine Autorisierung mit kompromittierten Schlüsseln.

Häufige Missverständnisse

  • Die Zustandswurzel speichert alle Kontosalden. Sie ist eine Bindung fester Länge an einen kodierten Trie; die zugrunde liegenden Trie-Daten müssen separat beschafft werden.
  • Gleiche Zustandswurzeln beweisen identische Datenbanken. Sie binden denselben logischen Weltzustand nach den Protokollregeln, doch Clients können ihn unterschiedlich speichern, indizieren, bereinigen oder zwischenspeichern.
  • Eine abweichende Zustandswurzel zeigt die fehlerhafte Transaktion. Sie zeigt nur Uneinigkeit im endgültig gebundenen Zustand, nicht den Beginn der Abweichung; zur Diagnose muss die Ausführung verfolgt werden.
  • Ein gültiger Kontonachweis beweist Finalität und Sicherheit. Er beweist nur Konsistenz mit einer Wurzel. Kettenwahl, Finalität, Datenaktualität, Vertragsverhalten und wirtschaftliches Risiko bleiben getrennte Fragen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...