Kontobasiertes Zustandsmodell

Ethereums kontobasiertes Modell anhand von Kontofeldern, State- und Storage-Roots, geordneter Ausfuhrung, Gas und Reverts, Token-Speicher, EIP-7702-Delegation, Access Lists, Traces und Finalitat verstehen.

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

Direkte Antwort

Ein kontobasiertes Modell bildet den Ausfuhrungszustand als nach Adressen geordnete Daten ab. In Ethereums Ausfuhrungsschicht enthalt ein Kontoblatt [nonce, balance, storageRoot, codeHash]. Die native balance lautet auf Wei; Vertragsdaten liegen hinter dem storageRoot dieses Kontos; der stateRoot nach der Blockausfuhrung verpflichtet auf den resultierenden Weltzustand. Wallet, RPC-Anbieter oder Explorer lesen und interpretieren diesen Zustand, speichern aber nicht stellvertretend den kanonischen Saldo.

ERC-20-Salden, Allowances, Kreditverbindlichkeiten und Sicherheiten sind normalerweise Werte im Vertragsspeicher, keine Zusatzfelder im Protokollkonto des Inhabers. Eine vom Explorer angezeigte “interne Transaktion” ist meist ein per Trace rekonstruierter EVM Message Call, keine separat signierte Ethereum-Transaktion mit eigenem Hash und Sender-Nonce.

Die traditionelle Unterscheidung von Externally Owned Account (EOA) und Contract Account bleibt nutzlich, doch auf einer Kette mit EIP-7702 gilt “eine EOA hat immer leeren Code” nicht mehr absolut. Eine EOA kann den Delegationsindikator 0xef0100 || address tragen und Code des Delegierten ausfuhren, wahrend ihre Transaktionsautoritat erhalten bleibt. Klassifizierung muss Kettenregeln und realen Code nutzen, nicht ein altes UI-Label.

Zustandsubergang in sieben Schritten prufen

Beobachtung fixieren: Netzwerk, chainId, Fork-Regeln, Blocknummer und -hash, Timestamp sowie Tag wie pending, latest, safe oder finalized. Zustand nahe der Spitze kann sich nach einem Reorg andern; Daten verschiedener Blocke nie unmarkiert mischen.
Protokollfelder lesen: nonce, native balance, storageRoot und codeHash. Ist der Code ein EIP-7702-Indikator, den Delegierten nach den Fork-Regeln auflosen. Bei Proxies und delegierten Konten Implementierungscode, Upgrade-Kontrolle und Speicherlayout getrennt bestimmen.
Anwendungssalden lokalisieren. ETH andert den nativen Saldo; ERC-20 meist ein Mapping im Tokenvertrag; Allowances, Schulden, Sicherheiten und Rewards konnen in anderen Vertragen und Slots liegen. Dezimalstellen und Logs helfen bei der Interpretation, sind aber keine Kontoblattfelder.
Top-Level-Transaktion dekodieren und vorprufen: Typ, Kettendomain, Signatur, Sender-Nonce, Empfanger oder Erstellung, Wert, Input, Gaslimit, Gebuhrenobergrenzen und optionale Access List oder EIP-7702-Autorisierungen. Der Sender muss Wert plus maximale Gebuhrenbindung decken. Eine abgelehnte Transaktion wird nicht aufgenommen und verbraucht on-chain kein Gas.
Transaktionen aus dem Vorzustand in Blockreihenfolge ausfuhren. Die EVM verarbeitet verschachtelte Message Calls und Erstellungsframes mit jeweiligem Caller, Callee, Wert, Calldata, Gas und Status. Gemeinsame Lese-/Schreibzugriffe machen Ergebnisse reihenfolgeabhangig. Eine EIP-2930 Access List warmt Konten und Slots vor und andert die Gasabrechnung; sie verbietet weder unangemeldete Zugriffe noch beweist sie sichere Parallelitat.
Commit- und Rollback-Grenzen anwenden. Ein erfolgreicher Frame schreibt Zustand und Logs fest, sofern ein Elternframe nicht spater revertiert. REVERT setzt Schreibvorgange, Wertubertragungen und Logs des fehlgeschlagenen Frames zuruck und gibt ungenutztes Gas frei; ein ausserer Vertrag kann den Kindfehler auffangen und dennoch erfolgreich sein. Ein aufgenommener Top-Level-Fehler hat Beleg status = 0, erhoht aber den Sender-Nonce und bezahlt verbrauchtes Gas. EIP-7702-Autorisierungen haben eigene Persistenzregeln trotz spaterem Revert.
Nachzustand abstimmen. Native und Token-Saldoanderungen, Speicher, Belegstatus, Gasverbrauch, effektiven Preis, Logs und Provider-Traces mit den Root-Verpflichtungen des Blocks abgleichen. Traces als Provider-Rekonstruktionen behandeln, nicht als Konsenstransaktionen. Erforderliche Finalitat abwarten und Replacements, Reorgs, Indexer-Korrekturen, Bridges, Rollups und Buchungsstornos explizit behandeln.

Vier Rechenbeispiele

EIP-1559-ETH-Transfer. A startet mit 5 ETH und Nonce 12, B mit 1 ETH. A sendet 1 ETH mit 21,000 gas, Base Fee 20 gwei, Priority Cap 3 gwei und Max Fee 40 gwei. Effektiver Preis: min(40, 20 + 3) = 23 gwei; Gesamtgebuhr: 21,000 × 23 gwei = 0.000483 ETH, davon werden 0.000420 ETH verbrannt und 0.000063 ETH sind Priority Fee. Maximale Anforderung bei Signatur: 1 ETH + 21,000 × 40 gwei = 1.000840 ETH. Endsalden: A 3.999517 ETH, B 2 ETH; A hat Nonce 13.
Aufgenommene Transaktion mit Revert. A startet mit 2 ETH und Nonce 7. A ruft einen Vertrag mit 0.50 ETH auf; die Top-Level-Ausfuhrung revertiert nach 80,000 gas zu effektiv 25 gwei, Gebuhr somit 80,000 × 25 gwei = 0.002000 ETH. Speicher, Logs und die 0.50 ETH-Ubertragung werden zuruckgesetzt, A endet mit 1.998000 ETH, Nonce 8 und Beleg status = 0. Ein aufgefangener Kindfehler kann neben ausserem Beleg status = 1 bestehen.
Token-Saldo ist Vertragsspeicher. Ein Tokenvertrag verzeichnet fur Alice 1,000 units, fur Bob 200 units. Ein erfolgreicher Transfer von 250 units ergibt Alice 750 units und Bob 450 units, zusammen 1,200 units. Verbraucht Alices Transaktion 60,000 gas × 20 gwei = 0.001200 ETH, sinkt ihr nativer ETH-Saldo separat. Der storageRoot des Tokens und globale stateRoot andern sich; der Tokenbetrag war nie Alices nativer Kontosaldo.
EIP-7702-Persistenzgrenze. Ein Sponsor sendet eine Set-Code-Transaktion mit Autorisierung von A bei Nonce 5 zur Delegation an D. Das Protokoll schreibt den 23-byte-Indikator 0xef0100 || 20-byte address und erhoht As Autorisierungs-Nonce auf 6. Revertiert die spatere aussere Ausfuhrung, bleiben Indikator und verarbeiteter Nonce bestehen. Dies ist nicht dieselbe Rollback-Grenze wie normaler EVM-Speicher des fehlgeschlagenen Aufrufs.

Risiken und Kontrollen

Falsche Kette, Fork, Blockhash oder Tag erzeugen eine inkonsistente Momentaufnahme.
Veraltete oder unzuverlassige RPCs konnen Spitzenzustand auslassen oder falsch melden.
Pending-Nonce-Rennen, Lucken und Replacements konnen Warteschlangenannahmen widerlegen.
“Abbrechen” in einer Wallet ist meist eine Ersatztransaktion, keine Protokollloschung.
Fehlender Saldo fur Wert plus maximale Gebuhr verhindert Aufnahme.
Base-Fee-Bewegung oder falscher Fee Cap verzogert Aufnahme oder andert Kosten.
EIP-7702-Code kann alte EOA-Heuristiken fehlklassifizieren lassen.
Bosartiger Delegierter, Initialisierungsfehler oder Replay kann EIP-7702-Konten kompromittieren.
Proxy-Upgrades und Delegate Calls konnen Code- und Speicherinterpretation andern.
Schlussel-, Signaturdomain- oder Chain-ID-Fehler erlauben Diebstahl oder Replay.
Reentrancy und Reihenfolge gemeinsamen Zustands konnen Salden andern.
Ein Kindaufruf kann scheitern und aufgefangen werden, wahrend die aussere Transaktion erfolgreich ist.
Top-Level-Revert oder Out-of-Gas verbraucht Gas und erhoht den Sender-Nonce.
Token-Dezimalstellen, Fee-on-Transfer, Rebasing und Hooks widerlegen einfache Saldoarithmetik.
Allowances, Schulden, Sicherheiten und Rewards fehlen bei reiner Wallet-Saldoabstimmung.
Logs konnen fehlen, revertieren, irrefuhren oder den Endzustand nicht beweisen.
Explorer-“interne Transaktionen” und Provider-Traces konnen als Rekonstruktionen abweichen.
Eine Access List kann unvollstandig, doppelt oder unwirtschaftlich sein und sperrt kein Read/Write-Set.
Shared-State-Reihenfolge, Priority Fees und MEV konnen Ausfuhrungsergebnisse andern.
Reorgs, Pruning, fehlende Proofs, L2-Systemubergange und Bridge-Finalitat konnen Buchungen umkehren oder verdecken.

Haufige Irrtumer

“Die Wallet speichert den On-Chain-Saldo.” Sie halt Credentials und zeigt Netzwerkzustand an.
“Jede Adresse ist dauerhaft codefreie EOA oder normaler Vertrag.” EIP-7702 andert diese Heuristik.
“Jeder angezeigte Transfer ist eine Ethereum-Transaktion.” Tokenereignisse und Call-Traces sind keine signierten Top-Level-Transaktionen.
“Eine fehlgeschlagene Transaktion andert nichts und kostet nichts.” Aufgenommene Fehler konnen Gas verbrauchen und Nonce erhohen.
“Kontomodell oder Access List garantiert schnellere Parallelitat als UTXO.” Leistung und Konflikte hangen von Protokoll und Workload ab.