Zum Inhalt springen
Financial Context Wiki

Ethereum Virtual Machine (EVM)

Fork-sensitiver Leitfaden zu EVM-Transaktionen, Message Calls, Bytecode, Stack, Memory, Storage, Gas, REVERT, DELEGATECALL, Precompiles, Receipts und Zustandsabgleich.

Aktualisiert

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

Direkte Antwort

Die EVM ist die Zustandsübergangsmaschine der Ausführungsschicht, die Bytecode nach den Regeln eines bestimmten Forks interpretiert. Bei gleichem gültigem Vorzustand, gleicher Transaktion oder Message, Blockumgebung und Spezifikation müssen konforme Clients denselben Folgezustand oder Fehler berechnen. Die EVM ordnet keine Transaktionen, liefert keine Finalität und macht EVM-kompatible Chains nicht ebenso sicher wie Ethereum.

Eine extern signierte Transaktion ist ein Protokollobjekt oberster Ebene. Vertragsaktivität besteht aus verschachtelten Message Calls und Call Frames, nicht aus eigenständigen Transaktionen. Jeder Frame hat Code, Program Counter, 256-Bit-Stack, Memory, Calldata, Returndata, Gas und Kontext; persistenter Storage gehört zum Konto, transienter Storage gilt transaktionsweit.

Funktionsweise

  1. Chain und chainId, Netzwerk, Block und Hash, kanonischen oder finalisierten Status, Fork, Client, Revision, Vorzustand, Typ, signierte Bytes, Hash und Receipt festlegen.
  2. Envelope dekodieren und Vorabgültigkeit von Ausführung trennen. Signatur, Absender, Nonce, Ziel oder Erstellung, Value, Calldata, Gaslimit, Gebühren, Access List und Typparameter prüfen. Eine Vorabablehnung ist kein inkludierter Revert.
  3. Top-Level-Message und Call Tree erstellen. CALL, STATICCALL, DELEGATECALL, Erstellung und Precompiles sowie Caller, Kontext- und Codeadresse, msg.sender, msg.value, Value, Daten, Gas und Ergebnis erfassen. „Interne Transaktion“ ist eine Trace-Ansicht.
  4. Program Counter, Stack, Memory, Daten, Logs sowie persistenten und transienten Storage verfolgen. CALL nutzt den Callee-Kontext; DELEGATECALL führt Zielcode im Caller-Kontext aus und erhält Sender und Value; STATICCALL verbietet Zustandsänderung.
  5. Fork-Gasregeln für Intrinsic Gas, Opcodes, Memory, Cold/Warm Access, Calls, Stipends, Precompiles und Refunds anwenden. Gebühr getrennt vom Value berechnen. Eine Schätzung ist keine Garantie.
  6. Ergebnisse nach Scope behandeln. RETURN commitet nur, wenn Vorfahren committen. REVERT setzt Frame und Nachfahren zurück, liefert Daten und kann Gas zurückgeben; Exceptional Halt ist anders. Eltern können Fehler abfangen, daher kann Top-Level-Status 1 sein. Ein inkludierter Fehler verbraucht Nonce und Gas.
  7. Status, Gas, Logs, Erstellungsadresse und Rückgabe mit Salden, Nonces, Code, Storage, Token-Ledgern, Traces und State Root abgleichen. Bei Bedarf re-exekutieren und Proxies, Layouts, Precompiles, Compiler und Forks getrennt von Finalität prüfen.

Durchgerechnete Beispiele

  • Top-Level-Revert und Gebühr. Eine Typ-2-Transaktion hat Limit 80,000, verbraucht 52,000, Base Fee 20 gwei, maximale Priority Fee 3 gwei und Max Fee 40 gwei. Effektiv gilt min(40, 20 + 3) = 23 gwei; bezahlt werden 52,000 * 23 gwei = 0.001196 ETH, davon 52,000 * 20 gwei = 0.001040 ETH verbrannt und 52,000 * 3 gwei = 0.000156 ETH Priority Fee. Die ungenutzten 28,000 gas werden nicht berechnet. Bei Revert rollen Storage, Value und Logs zurück, Nonce und Gebühr bleiben.
  • Abgefangener Kindfehler. A beginnt mit A.x = 5. B schreibt B.y = 9, emittiert ein Log und führt REVERT aus; Schreiben und Log rollen zurück. A sieht success = false, schreibt A.x = 7 und endet normal. Receipt-Status ist 1, final gilt A.x = 7, B behält den Vorwert.
  • DELEGATECALL-Kontext. Proxy hat slot0 = 5, Implementierung slot0 = 99; Code addiert 7. Durch DELEGATECALL wird Proxy slot0 = 12, Implementierung bleibt slot0 = 99; Adresse und Storage des Proxy gelten, Sender und Value bleiben erhalten.
  • Fork-bezogenes SELFDESTRUCT. Unter EIP-6780 führt ein bestehender Vertrag mit 2 ETH SELFDESTRUCT zu B aus. B erhält 2 ETH, der Saldo wird null, Konto, Code und Storage werden aber nicht gelöscht. Löschung bleibt nur bei Erstellung und Selbstzerstörung in derselben Transaktion.

Risiken

  • Gegen falsche Chain, Block, Fork, Client oder Vorzustand re-exekutieren.
  • Nicht kanonischen oder reorganisierten Zustand als final behandeln.
  • Vorabablehnung mit inkludiertem Revert verwechseln.
  • Übereinstimmung ausstehender Simulation mit Inklusion annehmen.
  • Top-Level-Revert, Exceptional Halt oder Out-of-Gas übersehen.
  • Abgefangenen Kindfehler übersehen.
  • Kontext, Codeadresse, Caller, Sender oder Value falsch lesen.
  • Proxy durch Layoutfehler bei DELEGATECALL beschädigen.
  • Reentrancy oder unsichere externe Kontrollübertragung zulassen.
  • Ungeprüften Returndata, Flags oder Fehlern vertrauen.
  • Logs oder Traces als maßgeblichen Zustand behandeln.
  • Access-, Memory- oder weitergeleitetes Gas falsch berechnen.
  • Refunds, Caps, Stipends oder 63/64-Regel falsch anwenden.
  • Falsche Precompile-Adresse, Eingabe, Kosten oder Forkregeln nutzen.
  • Persistent Storage, Memory und Transient Storage verwechseln.
  • Zustandsänderung in STATICCALL erwarten.
  • Alte Löschannahmen für SELFDESTRUCT anwenden.
  • Implementierungs-, Admin- oder Compilerdrift übersehen.
  • Abweichende oder veraltete Clientregeln ausführen.
  • Konsens-, Bridge-, Token- oder Governance-Sicherheit aus EVM-Kompatibilität ableiten.

Häufige Irrtümer

  • Solidity-Quellcode wird direkt onchain ausgeführt.
  • Ein inkludierter Revert kostet nichts und ändert die Nonce nicht.
  • Receipt-Status 1 beweist den Erfolg aller internen Calls.
  • Event oder Trace ist der maßgebliche Zustand.
  • EVM-Kompatibilität garantiert identische Opcodes, Gas, Precompiles, Konsens und Sicherheit.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...