Wissen
EVM – einfach erklärt
Aktualisiert 12. Juni 2026
Die Ethereum Virtual Machine (EVM) ist eine dezentrale, virtuelle Laufzeitumgebung, in der Smart Contracts und Transaktionen auf der Ethereum-Blockchain ausgeführt werden. Sie ist kein physisches Gerät an einem bestimmten Ort, sondern eine standardisierte Rechenspezifikation, die von tausenden unabhängiger Netzwerkteilnehmer gleichzeitig betrieben wird.
Was ist die Ethereum Virtual Machine (EVM)?
Die EVM existiert nicht als Server in einem Rechenzentrum und auch nicht als einzelner Supercomputer. Stattdessen läuft sie verteilt auf den Computern der Nodes – also der Teilnehmer, die das Ethereum-Netzwerk betreiben. Jeder dieser Nodes führt dieselbe EVM-Implementierung aus. Das Ergebnis: Tausende voneinander unabhängige Maschinen weltweit verarbeiten identische Anweisungen und gelangen dabei stets zu exakt demselben Ergebnis.
Der Begriff „virtuelle Maschine" beschreibt eine softwarebasierte Abstraktion eines Computers. Die EVM stellt eine klar definierte Ausführungsumgebung bereit – mit eigenem Befehlssatz, eigenem Speichermodell und eigenen Regeln – ohne dass dafür spezifische Hardware erforderlich wäre. Wer einen Ethereum-Node betreibt, führt die EVM auf seiner eigenen Hardware aus, unabhängig davon, ob es sich um einen Heimrechner oder einen Serverpark handelt.
Diese verteilte Architektur ist kein Zufall, sondern Designprinzip: Weil keine zentrale Stelle die EVM kontrolliert, kann sie auch nicht von einer einzelnen Instanz abgeschaltet, zensiert oder manipuliert werden. Die Ausführung von Code auf Ethereum ist damit an keine Erlaubnis gebunden – solange die vorgeschriebenen Regeln eingehalten werden.
Wie funktioniert die EVM?
Deterministisches Ausführungsmodell
Das wichtigste Merkmal der EVM ist ihre Determinismus-Garantie: Gleicher Input liefert auf jedem Node exakt dasselbe Output. Das ist keine Selbstverständlichkeit – in normalen Softwareumgebungen können Faktoren wie Zeitstempel, Zufallszahlen oder Betriebssystemzustand zu unterschiedlichen Ergebnissen führen. Die EVM schließt solche externen Einflüsse systematisch aus. Nur so ist es möglich, dass tausende Nodes unabhängig voneinander eine Transaktion verarbeiten und anschließend denselben Zustand der Blockchain bestätigen.
Dieser Konsens auf Basis deterministischer Ausführung ist das technische Fundament, auf dem das Vertrauen in Ethereum-Transaktionen beruht.
World State
Die EVM verwaltet den sogenannten World State – einen globalen Datensatz, der alle Ethereum-Konten und deren aktuellen Zustand enthält. Dazu zählen unter anderem ETH-Guthaben, Bytecode von Smart Contracts und die im Contract gespeicherten Variablen. Nach jeder Transaktion aktualisieren alle Nodes diesen World State übereinstimmend. Der Zustand der Blockchain ist damit kein lokales Abbild, sondern ein weltweit synchronisiertes Verzeichnis.
Bytecode-Ausführung
Entwickler schreiben Smart Contracts üblicherweise in der Hochsprache Solidity. Diese Programme werden nicht direkt in der EVM ausgeführt – sie müssen zunächst in EVM-Bytecode kompiliert werden. Bytecode ist eine kompakte, maschinenlesbare Folge von Instruktionen, die den EVM-Befehlssatz (die sogenannten Opcodes) verwendet. Erst dieser Bytecode wird auf der Blockchain gespeichert und von der EVM bei Transaktionen ausgeführt.
Der Unterschied ist vergleichbar mit Quellcode und Maschinensprache in der klassischen Softwareentwicklung: Der Bytecode ist das, was tatsächlich läuft; der Solidity-Code ist die menschenlesbare Darstellung dahinter.
Sandboxing und Isolation
Die EVM arbeitet in einer Sandbox: Ausgeführter Code ist vollständig vom Rest des Systems isoliert. Ein Smart Contract kann nicht auf das Dateisystem des Node-Betreibers zugreifen, keine Netzwerkanfragen außerhalb der Blockchain stellen und keine Systemressourcen des Hostrechners direkt beeinflussen. Was innerhalb der EVM passiert, bleibt innerhalb der EVM. Das schützt die Infrastruktur der Netzwerkteilnehmer vor böswilligem oder fehlerhaftem Code.
Wichtig: Die sequenzielle Verarbeitung innerhalb eines Blocks – dazu mehr im Abschnitt über Grenzen – ist ebenfalls Teil dieses kontrollierten Ausführungsmodells.
Gas: Die Recheneinheit der EVM
Gas als Maßeinheit
Gas ist keine Kryptowährung, kein Token und kein Guthaben. Gas ist eine Maßeinheit, die den Rechenaufwand einer Operation in der EVM quantifiziert. Jeder Opcode – also jede einzelne Instruktion, die die EVM ausführt – hat einen festgelegten Gaswert. Eine einfache Addition kostet weniger Gas als das Schreiben von Daten in den Vertragsspeicher.
Die nachfolgende Tabelle zeigt exemplarisch, wie unterschiedlich der Aufwand einzelner Operationen bewertet wird:
| Operationstyp | Relativer Gasaufwand |
|---|---|
| Einfache Arithmetik (ADD, MUL) | Sehr gering |
| Lesezugriff auf Speicher (SLOAD) | Mittel |
| Schreibzugriff auf Speicher (SSTORE) | Hoch |
| Deployment eines neuen Contracts | Sehr hoch |
Schutz vor Missbrauch
Gas erfüllt eine wichtige Schutzfunktion: Es verhindert, dass Schleifen oder absichtlich komplexe Berechnungen das Netzwerk lahmlegen. Jede Transaktion gibt ein Gas-Limit an – die maximale Menge Gas, die für ihre Ausführung verbraucht werden darf. Übersteigt der tatsächliche Aufwand dieses Limit, wird die Transaktion abgebrochen. Das Netzwerk bleibt so vor Endlosschleifen und ressourcenintensiven Angriffen geschützt, ohne dass eine zentrale Instanz eingreifen muss.
Gas und ETH-Transaktionskosten
Der Gaswert einer Operation sagt noch nichts über die tatsächlichen Kosten in Euro oder Dollar aus. Die realen Kosten entstehen durch die Multiplikation:
Transaktionskosten = Gasverbrauch × Gaspreis (in ETH)
Der Gaspreis ist kein fester Wert, sondern wird durch Angebot und Nachfrage im Netzwerk bestimmt. Bei hoher Netzwerkauslastung steigen die Gaspreise, bei geringer Auslastung sinken sie. Diese Dynamik ist vom eigentlichen Gas-Konzept getrennt: Gas misst den Aufwand, der Gaspreis bewertet diesen Aufwand in ETH.
EVM-Kompatibilität: Warum andere Blockchains die EVM übernehmen
Das Konzept der EVM-Kompatibilität
Die EVM ist kein proprietäres System von Ethereum Inc. – sie ist eine offene Spezifikation. Das hat andere Blockchain-Projekte dazu veranlasst, dieselbe Ausführungsumgebung in ihren eigenen Netzwerken zu implementieren. Eine Blockchain gilt als EVM-kompatibel, wenn sie denselben Befehlssatz, dasselbe Speichermodell und dieselbe Ausführungslogik wie die Ethereum-EVM einsetzt.
Bekannte Beispiele für EVM-kompatible Netzwerke sind die BNB Chain, Polygon und die Avalanche C-Chain. Diese Chains sind nicht Teil von Ethereum – sie sind eigenständige Netzwerke mit eigenen Validatoren, eigener Konsenslogik und eigenen nativen Tokens.
Portierbarkeit von Smart Contracts
Der praktische Vorteil: Ein Smart Contract, der für Ethereum in Solidity geschrieben wurde, lässt sich mit geringem Aufwand auf einer EVM-kompatiblen Chain deployen. Der Bytecode-Kompilierungsprozess und die Entwicklerwerkzeuge bleiben weitgehend identisch. Das senkt die Eintrittsbarriere für Entwickler erheblich – statt eine neue Programmiersprache oder eine neue Laufzeitumgebung zu erlernen, können sie ihr bestehendes Wissen direkt anwenden.
Für das EVM-Kompatibilitäts-Konzept und den verwandten Begriff der EVM-Äquivalenz existieren separate Erklärungen im Glossar, da die technischen Feinheiten zwischen verschiedenen Kompatibilitätsstufen relevant sind.
Was EVM-Kompatibilität nicht bedeutet
EVM-Kompatibilität bedeutet ausdrücklich nicht, dass Assets oder Liquidität automatisch zwischen Netzwerken übertragbar sind. Ein ERC-20-Token auf Ethereum ist nicht dasselbe wie ein gleichnamiger Token auf einer EVM-kompatiblen Chain – ohne eine spezifische Bridge-Infrastruktur sind sie voneinander getrennte Vermögenswerte in getrennten Netzwerken. Die gemeinsame Ausführungsumgebung erleichtert die Portierbarkeit von Code, nicht von Werten.
Grenzen und Missverständnisse
Sequenzielle Ausführung
Ein verbreitetes Missverständnis ist die Annahme, die EVM führe Transaktionen parallel aus, um Geschwindigkeit zu gewinnen. Das Gegenteil ist der Fall: Innerhalb eines Blocks verarbeitet die EVM Transaktionen sequenziell, also nacheinander. Jede Transaktion liest den Zustand, der durch die vorherige entstanden ist, und schreibt das Ergebnis zurück. Erst so ist sichergestellt, dass kein Widerspruch im World State entsteht – etwa durch zwei gleichzeitige Zugriffe auf dasselbe Konto.
Diese sequenzielle Verarbeitung ist ein bewusster Kompromiss: Sie sichert Konsistenz auf Kosten von Durchsatz. Lösungen zur Skalierung – wie Layer-2-Netzwerke – greifen dieses Problem an, ohne die EVM-Grundlogik zu verändern.
Keine Garantie für korrekte Logik
Die EVM ist deterministisch und isoliert – aber sie ist kein Filter für fehlerhafte Programme. Sie prüft nicht, ob die Logik eines Smart Contracts wirtschaftlich sinnvoll, mathematisch korrekt oder frei von Sicherheitslücken ist. Die EVM führt aus, was im Bytecode steht – exakt und ohne Interpretation.
Das bedeutet: Wenn ein Smart Contract einen Fehler in seiner Geschäftslogik enthält – etwa eine falsch implementierte Zugangskontrolle oder eine fehlerhafte Berechnung – wird die EVM diesen Fehler genauso deterministisch ausführen wie beabsichtigte Funktionen. Die EVM schützt das Netzwerk vor technischem Missbrauch, nicht vor programmatischen Fehlern.
Sicherheitslücken entstehen im Code, nicht in der EVM selbst. Deshalb sind unabhängige Smart-Contract-Audits ein wichtiger Bestandteil seriöser Projektentwicklung – sie prüfen die Logik des Codes, bevor er auf der Blockchain deployed wird.
Gas-Kosten als UX-Hürde
Das Gas-System ist technisch elegant, stellt Endnutzer aber vor praktische Fragen: Wie hoch soll das Gas-Limit gesetzt werden? Wann sind die Netzwerkgebühren akzeptabel? Bei unzureichendem Gas-Limit schlägt eine Transaktion fehl – das bereits verbrauchte Gas wird dabei nicht erstattet, da die Rechenarbeit bereits geleistet wurde. Diese Eigenschaften erfordern ein Mindestverständnis des Systems, das für Einsteiger eine Hürde darstellen kann.
Zudem können stark schwankende Gaspreise dazu führen, dass kleinere Transaktionen wirtschaftlich unattraktiv werden. Layer-2-Lösungen und alternative EVM-kompatible Netzwerke adressieren dieses Problem durch niedrigere Basisgebühren – das Gas-Prinzip als Maßeinheit bleibt dabei in der Regel erhalten.
Häufige Fragen zu EVM
Was unterscheidet die EVM von einer normalen virtuellen Maschine?
Herkömmliche virtuelle Maschinen – etwa in der Softwareentwicklung oder Cloud-Infrastruktur – laufen auf einem einzelnen Host-System und werden von einem zentralen Anbieter kontrolliert. Die EVM dagegen läuft auf tausenden unabhängigen Nodes gleichzeitig, ohne zentralen Betreiber. Ihr Befehlssatz ist bewusst eingeschränkt, um deterministische und sichere Ausführung in einem Konsensumfeld zu gewährleisten.
Kann man die EVM direkt programmieren?
Smart Contracts können theoretisch direkt in EVM-Opcodes geschrieben werden, was als EVM-Assembly bezeichnet wird. In der Praxis verwenden Entwickler jedoch Hochsprachen wie Solidity oder Vyper, die in EVM-Bytecode kompiliert werden. Direktes Opcode-Schreiben ist aufwendig und fehleranfällig, ermöglicht aber präzise Kontrolle über den Gasverbrauch.
Was passiert, wenn einer Transaktion das Gas ausgeht?
Wird das festgelegte Gas-Limit einer Transaktion überschritten, bricht die EVM die Ausführung ab. Alle Zustandsänderungen, die die Transaktion bis dahin vorgenommen hätte, werden rückgängig gemacht – der World State bleibt unverändert. Das bereits verbrauchte Gas wird jedoch nicht erstattet, da der Rechenaufwand real anfiel.
Ist eine EVM-kompatible Chain sicherer oder unsicherer als Ethereum?
EVM-Kompatibilität bezieht sich ausschließlich auf die Ausführungsumgebung, nicht auf das Sicherheitsmodell des gesamten Netzwerks. Die Sicherheit einer Blockchain hängt maßgeblich von ihrer Konsensmechanik, der Anzahl und Unabhängigkeit der Validatoren sowie dem Ökosystem ab – Faktoren, die sich zwischen EVM-kompatiblen Chains erheblich unterscheiden können.
Warum führt die EVM Transaktionen nicht parallel aus?
Parallele Ausführung würde zu Konflikten führen, wenn zwei Transaktionen gleichzeitig denselben Zustand lesen und schreiben. Das Ergebnis wäre nicht mehr deterministisch – verschiedene Nodes könnten unterschiedliche Endzustände berechnen, was den Konsens unmöglich macht. Die sequenzielle Verarbeitung ist damit keine Schwäche, sondern eine strukturelle Anforderung des Konsensmodells.
Schützt die EVM vor betrügerischen Smart Contracts?
Nein. Die EVM stellt sicher, dass Code korrekt und deterministisch ausgeführt wird – sie bewertet nicht, ob dieser Code ethisch oder sicher ist. Ein betrügerischer Smart Contract wird von der EVM genauso ausgeführt wie ein legitimer. Die Verantwortung für die inhaltliche Prüfung von Smart Contracts liegt bei Entwicklern, Auditoren und Nutzern.
Quellen & weiterführende Links
Für diesen Artikel wurden Primärquellen ausgewertet. Eine Auswahl zum Weiterlesen: