Was ist die Ethereum Virtual Machine (EVM)? Warum ist es wichtig?

Kernarchitektur des EVM

1. Die EVM fungiert als dezentrale, deterministische Ausführungsumgebung, die auf jedem vollständigen Knoten im Ethereum-Netzwerk repliziert wird.

2. Es implementiert ein stapelbasiertes Rechenmodell, bei dem jeder Stapeleintrag genau 32 Bytes belegt und die maximale Tiefe auf 1024 Einträge begrenzt ist.

3. Es gibt drei verschiedene Speicherschichten: flüchtiger Speicher für vorübergehende Berechnungen, persistenter Speicher pro Vertragskonto und unveränderliche Aufrufdaten für Eingabeparameter.

4. Jede vom EVM ausgeführte Anweisung verbraucht eine vorgegebene Menge an Gas, wodurch eine strikte Ressourcenverantwortung erzwungen wird und Endlosschleifen oder DoS-Angriffe verhindert werden.

5. Der Programmzähler verfolgt die Ausführungsposition auf Byte-Ebene innerhalb des kompilierten Bytecodes und ermöglicht so eine präzise Sprungsteuerung und bedingte Verzweigung über JUMP- und JUMPI-Opcodes.

Ausführungsworkflow innerhalb der EVM

1. Der Solidity-Quellcode wird in EVM-kompatiblen Bytecode kompiliert, der Sequenzen von Ein-Byte-Opcodes enthält.

2. Bei der Übermittlung der Transaktion lädt die EVM den Vertragsbytecode zusammen mit dem aktuellen Weltstatus, einschließlich Kontoständen und Speicherwerten.

3. Jeder Opcode löst einen bestimmten Zustandsübergang aus – etwa eine arithmetische Operation, einen Speicherschreibvorgang oder einen Speicherlesevorgang –, wobei Nebenwirkungen erst nach erfolgreichem Abschluss aufgezeichnet werden.

4. Wenn während der Ausführung eine Gaserschöpfung auftritt, werden alle Zustandsänderungen seit der Transaktionseinleitung atomar rückgängig gemacht, wodurch die Blockchain-Konsistenz gewahrt bleibt.

5. Rückgabedaten von Funktionsaufrufen werden im Speicher codiert und vor der endgültigen Zustandsübernahme in den Ausgabepuffer kopiert.

Sicherheits- und Isolationseigenschaften

1. Die EVM erzwingt striktes Sandboxing: kein Dateisystemzugriff, keine Netzwerk-E/A und keine direkte Interaktion mit den Ressourcen des Host-Betriebssystems.

2. Der Vertragscode kann den Speicher eines anderen Vertrags ohne expliziten Schnittstellenaufruf und geeignete Zugriffskontrolllogik nicht direkt manipulieren.

3. Alle externen Aufrufe – einschließlich Delegatecall – unterliegen Gaslimits und Revert-Propagation-Regeln, wodurch die rekursive Aufruftiefe und der vertragsübergreifende Einfluss eingeschränkt werden.

4. Die Speicherzuweisung ist linear und begrenzt. Lesevorgänge außerhalb der Grenzen geben Null zurück, während Schreibvorgänge über den zugewiesenen Speicherplatz hinaus eine gasintensive Expansion auslösen.

5. Die Rücksemantik stellt sicher, dass ein teilweiser Ausfall keine inkonsistenten Zwischenzustände hinterlässt – entweder vollständigen Erfolg oder vollständigen Rollback.

Opcode-Klassifizierung und Funktionalität

1. Stapelmanipulations-Opcodes wie PUSH1, POP, DUP1 und SWAP1 steuern die Positionierung und Duplizierung von Operanden während der Auswertung.

2. Arithmetische und bitweise Anweisungen – einschließlich ADD, MUL, AND, XOR – führen Berechnungen auf niedriger Ebene für 256-Bit-Wörter durch.

3. Die Speicheroperationen SLOAD und SSTORE interagieren mit dem persistenten Schlüsselwertspeicher, der an jede Vertragsadresse gebunden ist.

4. Umgebungs-Opcodes wie CALLER, ORIGIN, BLOCKHASH und TIMESTAMP stellen kontextbezogene Blockchain-Metadaten für laufende Verträge bereit.

5. Kontrollflussprimitive wie JUMPDEST, JUMP und JUMPI ermöglichen einen strukturierten Programmablauf und dynamischen Versand basierend auf Laufzeitbedingungen.

Gasbuchhaltung und wirtschaftliche Durchsetzung

1. Gaskostenpläne werden pro Opcode definiert und durch Verbesserungsvorschläge von Ethereum aktualisiert, um die sich entwickelnde Hardwareeffizienz und Angriffsflächenanalyse widerzuspiegeln.

2. Transaktionsinitiatoren müssen sowohl das Gaslimit als auch den Gaspreis angeben und dabei das maximale Rechenbudget und die Priorität bei der Blockeinbindung festlegen.

3. Nicht verbrauchtes Gas wird dem Absender nach der Ausführung zurückerstattet, was Anreize für effiziente Kodierungspraktiken und eine genaue Gasschätzung bietet.

4. Bestimmte Vorgänge – wie SSTORE beim Überschreiben von Werten ungleich Null – verursachen asymmetrische Kosten, um Spam zu verhindern und ein durchdachtes Zustandsdesign zu fördern.

5. Die Selbstzerstörungsfunktion bietet einen Mechanismus zur Vertragsauflösung mit teilweiser Gasrückerstattung und reduziert so die langfristige Aufblähung des Speichers.

Häufig gestellte Fragen

F: Kann der EVM-Bytecode durch Reverse Engineering in eine lesbare Solidity-Quelle umgewandelt werden? Die Wiederherstellung der ursprünglichen High-Level-Logik ist aufgrund verlustbehafteter Kompilierung, Optimierungstransformationen und fehlender Symboltabellen oder Kommentare im bereitgestellten Bytecode im Allgemeinen nicht möglich.

F: Warum verwendet EVM eine stapelbasierte statt einer registerbasierten Architektur? Das stapelbasierte Design vereinfacht die Befehlscodierung, reduziert den Overhead der Opcode-Größe und ermöglicht die deterministische Ausführung auf heterogener Hardware, ohne dass Registerzuweisungsstrategien erforderlich sind.

F: Was passiert, wenn zwei Verträge gleichzeitig versuchen, in denselben Speichersteckplatz zu schreiben? Die Speicherplätze werden je nach Vertragsadresse festgelegt. Zwischen Verträgen besteht kein gemeinsamer veränderlicher Zustand, es sei denn, dies wird ausdrücklich durch Funktionsaufrufe und vereinbarte Schnittstellen vermittelt.

F: Wie geht die EVM mit Ganzzahlüber- oder -unterlauf um? Vor dem Istanbul-Upgrade wurden arithmetische Operationen stillschweigend ausgeführt. Nach dem Upgrade sorgen integrierte Überlaufprüfungen dafür, dass ungültige arithmetische Ergebnisse sofort wiederhergestellt werden.