Die Ethereum Virtual Machine (EVM) ist eine quasi-Turing-vollständige, stackbasierte virtuelle Maschine, die als Laufzeitumgebung für die Ausführung von Smart Contracts auf der Ethereum-Blockchain und allen EVM-kompatiblen Netzwerken dient. Sie ist die Rechenzentrale von Ethereum und verarbeitet jeden Zustandsübergang – von einfachen ETH-Transfers bis hin zu komplexen Interaktionen im Bereich dezentraler Finanzen (DeFi) – deterministisch und in einer Sandbox. Dadurch wird sichergestellt, dass jeder Knoten im Netzwerk für jede Transaktion dasselbe Ergebnis erzielt.
Die EVM arbeitet mit der Ausführung von Low-Level-Befehlen, sogenannten Opcodes, die aus Hochsprachen wie Solidity und Vyper in Bytecode kompiliert werden. Jeder Opcode führt eine spezifische atomare Operation aus – arithmetische Berechnungen, Speichermanipulation, Lese- und Schreibvorgänge, kryptografisches Hashing und Kontrollflusslogik. Wenn ein Benutzer oder ein Smart Contract eine Transaktion initiiert, die einen Smart Contract aufruft, lädt die EVM den Bytecode des Contracts aus dem State Trie der Blockchain und verarbeitet ihn Befehl für Befehl. Dabei wird für jeden Befehl eine abgerechnete Ressource, das sogenannte „Gas“, verbraucht. Dieser Gas-Measurement-Mechanismus verhindert Endlosschleifen und Ressourcenmissbrauch, indem er den Absender der Transaktion verpflichtet, für die benötigte Rechenleistung zu bezahlen.
Entscheidend ist, dass die EVM vollständig deterministisch und isoliert konzipiert ist. Bei identischen Eingaben und gleichem Blockchain-Zustand erzeugt jeder Knoten, auf dem die EVM läuft, exakt dieselbe Ausgabe. Dieser Determinismus ermöglicht es Tausenden von Knoten weltweit, Transaktionen unabhängig voneinander zu verifizieren und den Konsens über den globalen Zustand des Ethereum-Netzwerks aufrechtzuerhalten. Die Sandbox-Architektur der EVM stellt zudem sicher, dass die Ausführung von Smart Contracts nicht auf das Dateisystem, das Netzwerk oder das Betriebssystem des Host-Rechners zugreifen kann. Dadurch wird verhindert, dass bösartige Smart Contracts die Knoten, auf denen sie laufen, kompromittieren.
Der Einfluss der Ethereum Virtual Machine (EVM) reicht weit über Ethereum hinaus. Ihre Architektur hat sich zum De-facto-Standard für die Ausführung von Smart Contracts in der gesamten Blockchain-Branche entwickelt. Bedeutende Netzwerke wie BNB Smart Chain (BSC), Polygon, Avalanche C-Chain, Arbitrum, Optimism, Fantom, Cronos und Dutzende weitere haben die EVM-Kompatibilität übernommen. Dadurch können Entwickler dieselben Solidity-Smart-Contracts mit minimalen Anpassungen auf verschiedenen Blockchains bereitstellen. Diese kettenübergreifende Kompatibilität hat ein riesiges Ökosystem aus gemeinsam genutzten Tools, Entwicklerwissen und kombinierbaren Protokollen geschaffen, die zusammen das Rückgrat des Ökosystems dezentraler Anwendungen (dApps) bilden.
Herkunft & Geschichte
2013: Vitalik Buterin veröffentlichte das Ethereum-Whitepaper, in dem er eine Blockchain mit einer integrierten, Turing-vollständigen Programmiersprache vorschlug, die beliebige Smart Contracts ausführen kann. Das Whitepaper erläuterte das Konzept einer virtuellen Maschine als Ausführungsschicht und grenzte Ethereum damit von Bitcoins eingeschränkter Script-Sprache ab.
2014: Gavin Wood verfasste das Ethereum Yellow Paper, in dem die Architektur der Ethereum Virtual Machine (EVM) formal und mathematisch präzise spezifiziert wurde. Das Yellow Paper definierte den Befehlssatz, die Gaskosten, die Zustandsübergangsfunktion und das Speichermodell, die die Ausführung von Smart Contracts steuern. Diese formale Spezifikation wurde zur maßgeblichen Referenz für alle EVM-Implementierungen.
2015: Ethereum wurde am 30. Juli mit dem Frontier-Release eingeführt. Die EVM ging mit ihren anfänglichen rund 140 Opcodes live und ermöglichte so die Ausführung der ersten Smart Contracts auf einer öffentlichen Blockchain. Die ersten Verträge waren einfach – Token-Emittenten und Multisignatur-Wallets –, aber sie bewiesen die Eignung der EVM als universelle Rechenmaschine.
2016: Der DAO-Hack am 17. Juni legte eine kritische Sicherheitslücke im Smart-Contract-Design der Ethereum Virtual Machine (EVM) offen, die durch rekursive Aufrufe verursacht wurde. Dabei wurden ETH im Wert von ca. 60 Millionen US-Dollar (rund 3.6 Millionen ETH) aus dem DAO-Smart-Contract entwendet. Obwohl die Schwachstelle im Smart-Contract-Code und nicht in der EVM selbst lag, führte der Vorfall zu intensiver Forschung im Bereich der EVM-Sicherheitsmuster und zur Entwicklung von Prüf-Effekt-Interaktionen (CEI) und Schutzmechanismen gegen rekursive Aufrufe. Die Folgen führten außerdem zur umstrittenen Hard Fork von Ethereum, bei der die Blockchain in Ethereum (ETH) und Ethereum Classic (ETC) aufgeteilt wurde.
2017-2018: Der ICO-Boom führte zu einer massiven Verbreitung von Ethereum Smart Contracts und stellte die Ethereum Virtual Machine (EVM) auf eine beispiellose Belastungsprobe. Der ERC-20-Token-Standard entwickelte sich zum am weitesten verbreiteten Vertragstyp, und die EVM verarbeitete Millionen von Token-Transfers. CryptoKitties (Dezember 2017) verursachte bekanntermaßen eine Überlastung des Netzwerks und legte damit die Durchsatzgrenzen der EVM offen.
2019-2020: Der DeFi-Sommer 2020 brachte Protokolle wie Uniswap, Aave und Compound in den Mainstream und zwang die EVM, immer komplexere Interaktionen zwischen mehreren Verträgen zu bewältigen. Die Gaspreise schnellten auf Hunderte von Gwei hoch, und die Gasoptimierung der EVM wurde zu einer entscheidenden Fähigkeit für Solidity-Entwickler.
2021-2022: EVM-kompatible Blockchains erfreuten sich rasant wachsender Beliebtheit. BSC, Polygon, Avalanche, Fantom und Arbitrum stellten jeweils EVM-kompatible Ausführungsumgebungen bereit, die es Entwicklern ermöglichten, Ethereum-dApps mit minimalem Aufwand zu portieren. Der Begriff „EVM-kompatibel“ wurde zu einem Marketingkriterium für neue Layer-1- und Layer-2-Blockchains.
2022-2024: Die Umstellung von Ethereum auf Proof-of-Stake (September 2022) veränderte zwar nicht die Ethereum Virtual Machine (EVM) selbst, aber die darunterliegende Konsensschicht. Die Forschung an Nachfolgearchitekturen für die EVM wurde intensiviert, mit Vorschlägen für ein EOF-Upgrade (EVM Object Format) und Diskussionen über eine mögliche Migration zu eWASM- oder RISC-V-basierten Ausführungsumgebungen. Das Dencun-Upgrade (März 2024) führte EIP-4844-Blob-Transaktionen ein und erweiterte damit die Datenverfügbarkeit der EVM für Rollups.
Einfach ausgedrückt
Man kann sich die EVM wie einen riesigen, gemeinsam genutzten Taschenrechner vorstellen, der dasselbe Programm gleichzeitig auf Tausenden von Computern ausführt. Jeder Computer liefert exakt dasselbe Ergebnis, da die Regeln des Rechners perfekt definiert sind. Versucht jemand zu betrügen, merken das alle anderen Computer sofort, weil ihre Ergebnisse nicht übereinstimmen.
Stellen Sie sich einen Verkaufsautomaten mit einer sehr ausführlichen Bedienungsanleitung vor. Wenn Sie Münzen einwerfen (Gas) und Knöpfe drücken (eine Transaktion senden), folgt der Automat Schritt für Schritt den Anweisungen, um Ihren Artikel auszugeben (den Vertrag auszuführen). Die Bedienungsanleitung ist für alle Verkaufsautomaten weltweit identisch, sodass Sie immer wissen, was das Drücken eines bestimmten Knopfes bewirkt.
Die EVM fungiert als universeller Übersetzer für Smart Contracts. Entwickler schreiben Code in einer für Menschen lesbaren Sprache (Solidity), die EVM übersetzt ihn in Maschinencode (Bytecode), und jeder Ethereum-Knoten spricht diese Maschinensprache. Daher kann ein einmal geschriebener Vertrag auf Ethereum, Polygon, BSC und Arbitrum ausgeführt werden, ohne dass er neu geschrieben werden muss.
Stellen Sie sich einen notariell beglaubigten Treuhandservice mit einem unbestechlichen Roboter als Agenten vor. Sie geben dem Roboter spezifische Regeln vor („Geld erst freigeben, wenn beide Parteien unterschrieben haben“), und der Roboter befolgt diese präzise – keine Bestechung, keine Fehler, keine Ausfallzeiten. Die EVM ist dieser Roboter, und die Regeln sind der Code des Smart Contracts.
Es funktioniert wie bei einem Arcade-Automaten, bei dem jedes Spiel Token kostet. Einfache Spiele (grundlegende Transaktionen) kosten nur wenige Token, während komplexe Spiele (DeFi-Swaps über mehrere Pools) deutlich mehr kosten. Gehen Ihnen mitten im Spiel die Token aus, stoppt der Automat und das Spiel ist vorbei – Sie erhalten Ihre Token aber nicht zurück. So funktioniert das Gasprinzip in der EVM.
Wichtig: Die EVM ist deterministisch, aber nicht unfehlbar. Fehler im Code von Smart Contracts, die auf der EVM ausgeführt werden, können zu Sicherheitslücken und Geldverlusten führen. Die EVM führt exakt die ihr erteilten Anweisungen aus – sind die Anweisungen fehlerhaft, sind auch die Ergebnisse fehlerhaft. Überprüfen Sie Smart Contracts daher immer, bevor Sie mit ihnen interagieren, insbesondere wenn es um hohe Werte geht.
Wichtige technische Merkmale
Stackbasierte Architektur
Die EVM verwendet einen LIFO-Stack (Last-In-First-Out) mit einer maximalen Tiefe von 1,024 Elementen.
Jedes Stapelelement ist 256 Bit (32 Byte) breit und entspricht damit der nativen Wortgröße von Ethereum.
Arithmetische und logische Operationen entfernen Operanden vom Stapel und legen Ergebnisse zurück auf den Stapel.
Das stapelbasierte Design vereinfacht die formale Verifikation und hält die Implementierung kompakt.
Im Gegensatz zu registerbasierten VMs (wie z. B. LLVM) vermeidet die Stack-Architektur die Komplexität der Registerzuweisung.
Opcode-Befehlssatz
Die EVM definiert über 140 Opcodes, die in folgende Kategorien unterteilt sind: Arithmetik, Vergleich, Bitoperationen, Hashing, Umgebungsoperationen, Blockoperationen, Stack-/Speicher-/Speicheroperationen, Protokollierung, Systemoperationen und Push-/Duplizierungs-/Swap-Operationen.
Für jeden Opcode sind feste oder dynamische Gaskosten im Yellow Paper definiert, die durch EIPs aktualisiert werden (z. B. erhöhte EIP-2929 die Kosten für den Zugang zu Kühlhäusern).
Das DELEGATECALL Der Opcode ermöglicht das Proxy-Muster, welches die Grundlage für aktualisierbare Smart Contracts bildet.
Wie die EVM-Ausführung funktioniert
Eine Transaktion wird an das Netzwerk übermittelt und zielt auf eine Vertragsadresse ab. Die Aufrufdaten geben die Funktion und die Parameter an.
Die EVM lädt den Bytecode des Zielvertrags aus dem Weltzustands-Trie in ihren Ausführungskontext.
Es wird ein neuer Ausführungsrahmen mit zugewiesenem Speicher, einem leeren Stack und dem Gaslimit der Transaktion erstellt.
Der Programmzähler beginnt bei Byte 0, und die EVM liest und führt die Opcodes sequenziell aus.
Jeder Opcode verbraucht Gas entsprechend seinen definierten Kosten – wenn das Gas ausgeht, wird die Ausführung mit einer „Out of Gas“-Ausnahme angehalten und alle Zustandsänderungen werden rückgängig gemacht.
Wenn die Ausführung erfolgreich abgeschlossen ist, werden Zustandsänderungen (Speicherschreibvorgänge, Guthabenübertragungen, Bereitstellungen neuer Verträge) im Weltzustand gespeichert.
Es wird eine Transaktionsbestätigung generiert, die den Ausführungsstatus, den Gasverbrauch, die ausgegebenen Ereignisprotokolle und alle Rückgabedaten enthält.
Gasmesssystem
Gas dient als Einheit des Rechenaufwands und bepreist jeden Opcode proportional zu seinem Ressourcenverbrauch.
Einfache Operationen wie ADD kostet 3 Gas, während Speicher schreibt (SSTOREDie Kosten betragen 5,000 bis 20,000 Gas, je nachdem, ob der Slot von Null gesetzt oder modifiziert wird.
Die Basistransaktionskosten betragen 21,000 Gas, zuzüglich Kosten für Anrufdaten (4 Gas pro Nullbyte, 16 Gas pro Nicht-Nullbyte).
EIP-1559 (Londoner Upgrade, August 2021) führte eine Grundgebühr ein, die verbrannt wird, zuzüglich einer optionalen Prioritätsgebühr (Trinkgeld) für den Blockbauer.
Die Blockgasbegrenzung (ca. 30 Millionen ab 2024) begrenzt die gesamte Rechenleistung pro Block und beschränkt damit effektiv den EVM-Durchsatz.
Speicher- und Speichermodell
Stack: Flüchtiger LIFO-Stack mit 1024 Elementen für Zwischenberechnungen – kostenlos nutzbar, aber in seiner Tiefe begrenzt.
Speicher: Flüchtiger, byteadressierbarer linearer Speicher, der sich bei Bedarf erweitert – die Gaskosten sind proportional zum Quadrat der zugewiesenen Größe.
Speicher: Persistenter 256-Bit-Schlüsselwertspeicher, der jeder Vertragsadresse zugeordnet ist – die teuerste Ressource (20,000 Gas für einen neuen Slot-Schreibvorgang).
Calldata: Schreibgeschützte Eingabedaten, die der Transaktion zugeordnet sind – kostengünstiger als Speicher und Datenspeicherung, verwendet für Funktionsparameter
Vorteile Nachteile
Vorteile
Nachteile
Cross-Chain-Portabilität: Für die EVM geschriebene Smart Contracts können mit minimalen Änderungen auf Dutzenden von EVM-kompatiblen Blockchains (BSC, Polygon, Avalanche, Arbitrum, Optimism) eingesetzt werden.
Leistungsbeschränkungen: Die stapelbasierte Architektur und das sequentielle Ausführungsmodell begrenzen den Durchsatz auf etwa 15-30 Transaktionen pro Sekunde im Ethereum-Mainnet.
Riesiges Entwickler-Ökosystem: Solidity ist die bekannteste Smart-Contract-Sprache mit umfangreichen Tools (Hardhat, Foundry, Remix, OpenZeppelin) und Entwicklerressourcen.
Hohe Gaskosten: Komplexe Operationen im Ethereum-Mainnet können während Spitzenzeiten Hunderte von Dollar an Gasgebühren verursachen und dadurch für kleine Nutzer unerschwinglich werden.
Bewährte Sicherheit: Nach fast einem Jahrzehnt Produktionseinsatz und der Sicherung von Milliarden von Dollar hat sich die Kernspezifikation der EVM als bemerkenswert robust gegenüber direkten Angriffen erwiesen.
Overhead durch 256-Bit-Wortgröße: Die native Wortgröße von 256 Bit ist für die meisten Operationen übertrieben, da Ressourcen für Auffüllung verschwendet werden und die Gaskosten für einfache Berechnungen steigen.
Deterministische Ausführung: Garantiert identische Ergebnisse auf allen Knoten, ermöglicht vertrauenslose Verifizierung und Konsensfindung ohne zentrale Koordination.
Eingeschränktes Berechnungsmodell: Keine native Unterstützung für Gleitkommaarithmetik, Parallelverarbeitung oder Datenzugriff außerhalb der Blockchain, wodurch für viele Anwendungsfälle in der Praxis Workarounds erforderlich sind.
Formale Spezifikation: Gavin Woods Yellow Paper liefert eine strenge mathematische Spezifikation, die die perfekte Interoperabilität mehrerer unabhängiger Implementierungen (Geth, Nethermind, Besu, Erigon) ermöglicht.
Unveränderlichkeit von Smart Contracts: Nach der Bereitstellung kann der Bytecode nicht mehr geändert werden – Fehler werden permanent, es sei denn, es werden Proxy-Muster verwendet (die die Komplexität und das Risiko erhöhen).
Umfangreiche Kompositionsfähigkeit: Die standardisierte Schnittstelle der EVM ermöglicht die reibungslose Interaktion von Smart Contracts untereinander und ermöglicht so die „Money Lego“-Kompositionsfähigkeit von DeFi.
Speicheraufblähung: Der Speicherbedarf für persistente Zustände wächst unbegrenzt. Der Speicherbedarf von Standard-Vollknoten ist aufgrund von Bereinigungsmechanismen geringer, spezialisierte Archivknoten (die den gesamten Zustandsverlauf speichern) können jedoch mehr als 1 TB Speicherplatz benötigen.
Upgradefähigkeit durch EIPs: Der Opcode-Satz und der Gasplan können über Ethereum Improvement Proposals aktualisiert werden, wodurch sich die EVM weiterentwickeln kann, ohne bestehende Smart Contracts zu beeinträchtigen.
Reentrancy-Schwachstelle: Die Fähigkeit des CALL-Opcodes, die Ausführung an externe Verträge zu übertragen, erzeugt eine Klasse von Reentrancy-Fehlern, die nach wie vor den häufigsten Angriffsvektor darstellen.
Risikomanagement
Schwachstellenrisiko bei Smart Contracts
Die EVM führt fehlerhaften Code zuverlässig aus – Reentrancy-Angriffe, Integer-Überläufe (vor Solidity 0.8) und Fehler in der Zugriffskontrolle haben zu Milliardenverlusten geführt.
Abhilfemaßnahmen: Vor der Bereitstellung im Hauptnetz sollten professionelle Audits durch Unternehmen wie Trail of Bits, OpenZeppelin oder Certik vorgeschrieben werden; formale Verifizierungswerkzeuge wie Certora und K Framework sollten verwendet werden.
Implementieren Sie das Checks-Effects-Interactions-Muster und verwenden Sie OpenZeppelins ReentrancyGuard für alle externen Aufrufe.
Risiko der Gaspreisvolatilität
Plötzliche Netzüberlastungen können die Gaspreise von 10 Gwei auf über 500 Gwei ansteigen lassen, was Vertragsabwicklungen unerschwinglich macht.
Abhilfemaßnahmen: Implementierung von Gaspreis-Orakeln und maximalen Gaspreisparametern in dApp-Frontends; Verwendung von Layer-2-Lösungen (Arbitrum, Optimism, Base) für kostensensible Operationen
Für datenintensive Rollup-Operationen sollten Sie EIP-4844-Blob-Transaktionen in Betracht ziehen.
Cross-Chain-Kompatibilitätsrisiko
EVM-kompatible Ketten können subtile Unterschiede im Opcode-Verhalten, der Verfügbarkeit von Präkompilierungsdateien oder der Gasverteilung implementieren.
Abhilfemaßnahmen: Testen Sie Verträge im Testnetz jeder Zielkette; seien Sie vorsichtig mit kettenspezifischen Opcodes wie CHAINID und BASEFEE; Konfigurationen für die Bereitstellung pro Kette aufrechterhalten
Staatsaufblähung und Nachhaltigkeitsrisiko
Jeder Vertragseinsatz und jeder Schreibvorgang in den Speicher erhöht dauerhaft den globalen Zustand und damit die Hardwareanforderungen für vollständige Knoten.
Abhilfemaßnahmen: Minimierung des Speicherverbrauchs durch effiziente Datenkomprimierung (mehrere Werte pro 32-Byte-Slot); Unterstützung der Forschung zu zustandslosem Ethereum und Vorschlägen zum Ablauf von Zuständen (EIP-4444)
Kulturelle Relevanz
Die Ethereum Virtual Machine (EVM) hat sich zum prägenden Standard der Smart-Contract-Ära entwickelt und die Architekturentscheidungen von Ethereum als gemeinsame Sprache des dezentralen Rechnens etabliert. Der Begriff „EVM-kompatibel“ hat sich von einer technischen Spezifikation zu einem Marketing-Schlagwort entwickelt – neue Blockchain-Projekte bewerben die EVM-Kompatibilität routinemäßig als Kernmerkmal und erkennen an, dass der Zugang zum Entwickler-Ökosystem von Ethereum und zu bestehenden Smart-Contract-Bibliotheken für die Akzeptanz unerlässlich ist.
Die Programmiersprache Solidity, die zu EVM-Bytecode kompiliert wird, hat eine ganze Berufsgruppe von „Solidity-Entwicklern“ hervorgebracht, die in der Technologiebranche Spitzengehälter erzielen. Bootcamps, Universitätskurse und Online-Plattformen wie CryptoZombies haben zahlreiche Entwickler speziell für die EVM-basierte Entwicklung ausgebildet.
Der Gasmechanismus der EVM hat die Kryptokultur durchdrungen. Begriffe wie „Gaskriege“, „Gasoptimierung“ und „kein Gas mehr“ sind in Krypto-Communities zum alltäglichen Sprachgebrauch geworden. Die Frustration über fehlgeschlagene Transaktionen aufgrund unzureichenden Gases hat unzählige Memes hervorgebracht, und das Streben nach niedrigeren Gasgebühren prägt die gesamte Diskussion um die Skalierung der Layer-2-Ebene.
In der Entwicklergemeinschaft hat sich die Unterscheidung zwischen „EVM-Äquivalenz“ und „EVM-Kompatibilität“ als wichtig erwiesen. Projekte wie der OP Stack von Optimism streben vollständige Äquivalenz (identisches Opcode-Verhalten) an, während andere sich mit Kompatibilität zufriedengeben (derselbe Solidity-Code lässt sich kompilieren und bereitstellen, weist aber geringfügige Verhaltensunterschiede auf). Diese Unterscheidung ist für Sicherheit und Komposition von entscheidender Bedeutung und hat sich zu einem wichtigen Bewertungskriterium für Infrastrukturentscheidungen entwickelt.
Beispiele aus der Praxis
Uniswap Multi-Chain-Bereitstellung
Szenario: Uniswap, die nach Handelsvolumen größte dezentrale Börse, musste über das Ethereum-Mainnet hinaus expandieren, um auch Nutzern, die aufgrund hoher Gasgebühren ausgeschlossen waren, einen Zugang zu ermöglichen.
Implementierung: Da die Smart Contracts von Uniswap in Solidity für die EVM geschrieben wurden, konnte das Protokoll mit minimalen Vertragsanpassungen auf Polygon, Arbitrum, Optimism, BSC, Base, Avalanche und Celo implementiert werden. Die gleiche Kernlogik des AMM (Konstantproduktformel) läuft auf jeder EVM-kompatiblen Blockchain identisch ab.
Ergebnis: Uniswap verarbeitet täglich ein beträchtliches Handelsvolumen über mehrere EVM-Chains hinweg. Nutzer von Arbitrum und Polygon zahlen typischerweise Bruchteile eines Cents pro Swap, verglichen mit mehreren Dollar im Ethereum-Mainnet während Überlastungszeiten. Das Sicherheitsmodell des Protokolls bleibt dabei in allen Implementierungen im Wesentlichen identisch.
Der DAO-Hack und die EVM-Reentrancy
Szenario: Im Juni 2016 nutzte ein Angreifer eine Reentrancy-Schwachstelle im Smart Contract von The DAO aus, der auf der EVM bereitgestellt war. Die Auszahlungsfunktion des Contracts überwies ETH, bevor der Kontostand des Nutzers aktualisiert wurde. Dadurch konnte der Angreifer die Auszahlungsfunktion rekursiv aufrufen, bevor der Kontostand auf null gesetzt wurde.
Implementierung: Der Angreifer erstellte einen bösartigen Vertrag, der beim Empfang von ETH über die EVMs CALL Der Opcode rief umgehend die Auszahlungsfunktion der DAO auf. Die EVM führte jeden rekursiven Aufruf pflichtgemäß aus und zog dabei etwa 3.6 Millionen ETH (damals rund 60 Millionen US-Dollar) ab.
Ergebnis: Die Ethereum-Community führte einen umstrittenen Hard Fork durch, um den Diebstahl rückgängig zu machen und Ethereum (ETH) und Ethereum Classic (ETC) zu erschaffen. Der Vorfall wurde zum wegweisenden Fallbeispiel für die Sicherheit der Ethereum Virtual Machine (EVM) und führte zur Entwicklung von Reentrancy Guards, dem Checks-Effects-Interactions-Muster sowie detaillierten Prüfverfahren, die die Branche bis heute prägen.
Aave auf Arbitrum über EVM-Äquivalenz
Szenario: Aave, ein führendes DeFi-Kreditprotokoll mit einem beträchtlichen Gesamtvermögen an gebundenen Geldern, strebte eine Implementierung auf Arbitrum an, um Nutzern kostengünstigere Kreditaufnahmen und -vergaben zu ermöglichen.
Implementierung: Arbitrums Nitro-Upgrade erreichte nahezu vollständige EVM-Äquivalenz, wodurch Aaves komplexes Multi-Contract-System (einschließlich Flash-Loans, Logik für variable/stabile Zinssätze und Governance-Module) ohne Änderungen eingesetzt werden konnte. Derselbe Solidity-Quellcode, kompiliert zum selben EVM-Bytecode, läuft in Arbitrums optimistischer Rollup-Ausführungsumgebung.
Ergebnis: Aave auf Arbitrum entwickelte sich zu einem der größten DeFi-Projekte auf Layer-2-Ebene, wobei die Gaskosten im Vergleich zum Ethereum-Mainnet um etwa 90–95 % gesenkt wurden. Die reibungslose Implementierung demonstrierte die Leistungsfähigkeit der EVM-Äquivalenz für komplexe Protokollmigrationen.
NFT-Prägung Gaskriege
Szenario: Bei aufsehenerregenden NFT-Launches wie dem Otherside-Mint von Yuga Labs (30. April 2022) versuchten Tausende von Nutzern gleichzeitig, EVM-Transaktionen zur Prägung von NFTs durchzuführen, was zu einem extremen Gaswettbewerb führte.
Implementierung: Nutzer erhöhten die Gaspreise zunehmend, um sicherzustellen, dass ihre Minting-Transaktionen im nächsten Block enthalten waren. Berichten zufolge erreichten die Gaskosten in der Spitze etwa 2–2.5 ETH pro Minting. Die EVM verarbeitete jeden Minting-Aufruf innerhalb jedes Blocks sequenziell, wobei die Blockersteller die Transaktionen nach Gaspreis sortierten.
Ergebnis: Die Otherside-Mint-Plattform verbrauchte innerhalb von etwa 24 Stunden über 150 Millionen US-Dollar an ETH-Gasgebühren (Schätzungen verschiedener Quellen reichen von rund 150 bis 176 Millionen US-Dollar). Dies demonstrierte sowohl die Robustheit der EVM unter extremer Last als auch ihre grundlegenden Durchsatzgrenzen. Das Ereignis beschleunigte die Einführung von EVM-basierten Layer-2-Lösungen für zukünftige NFT-Launches.
Vergleichstabelle
Funktion
EVM (Ethereum)
Solana VM (SVM)
CosmWasm (Kosmos)
VM verschieben (Aptos/Sui)
Architektur
Stapelbasiert, 256-Bit-Wort
Registerbasierter BPF-Bytecode
WebAssembly-basiert
Registerbasiert, ressourcenorientiert
Muttersprache
Solidität, Vyper
Rost, C
Rest
Bewegung
Ausführungsmodell
Sequenziell pro Block
Parallel (Meeresspiegel)
Sequenziell pro Block
Parallel (objektzentriert)
Gas-/Gebührenmodell
Gas mit Grundgebühr + Prioritätsgebühr
Einheiten berechnen + Prioritätsgebühr
Gas mit konfigurierbarer Preisgestaltung
Gasanlagen mit Speicherrabatten
Cross-Chain-Einführung
50+ Ketten (BSC, Polygon, Arbitrum usw.)
SVM-kompatible Ketten entstehen
IBC-verbundene Ketten (50+)
Limited (Aptos, Sui, Movement)
Entwickler-Ökosystem
Größte (Hardhat, Foundry, OpenZeppelin)
Wachstum (Ankerrahmen)
Mittel (CosmWasm-Tools)
Aufstrebend (Zugbeweiser)
Formale Überprüfung
Yellow Paper-Spezifikation; K-EVM
Begrenzte formale Werkzeuge
Mittel (CosmWasm-Prüfungen)
Move Prover (integriert)
Verwandte Begriffe
Solidität – Die am weitesten verbreitete höhere Programmiersprache zum Schreiben von EVM-Smart-Contracts, mit statischer Typisierung, Vererbung und einer umfangreichen Standardbibliothek.
Gas (Ethereum) – Die Einheit des Rechenaufwands, die zur Ausführung von Operationen auf der EVM erforderlich ist und von den Absendern von Transaktionen gezahlt wird, um die Validatoren für die Verarbeitung ihrer Transaktionen zu entschädigen.
Smart Vertrag – Selbstausführende Programme, die auf der Blockchain gespeichert und von der EVM ausgeführt werden und die Geschäftslogik für dezentrale Anwendungen enthalten.
Bytecode – Der aus Solidity oder Vyper kompilierte Maschinencode auf niedriger Ebene, den die EVM direkt ausführt und der aus Sequenzen von Opcodes und deren Argumenten besteht.
EVM-kompatible Blockchain – Jede Blockchain, die die EVM-Spezifikation implementiert und somit die Bereitstellung und Ausführung von Solidity Smart Contracts ohne Modifikation ermöglicht.
Layer-2-Rollup – Skalierungslösungen wie Arbitrum und Optimism, die EVM-Transaktionen außerhalb der Blockchain ausführen und komprimierte Beweise oder Daten zur Sicherheit an Ethereum zurücksenden.
Ethereum Gelbes Papier – Gavin Woods formale mathematische Spezifikation der EVM, die jeden Opcode, die Gaskosten und die Zustandsübergangsregel definiert.
ABI (Application Binary Interface) – Das Standard-Codierungsformat zum Aufrufen von EVM-Smart-Contract-Funktionen und zum Decodieren ihrer Rückgabewerte, wodurch die Interoperabilität zwischen Verträgen und Frontends ermöglicht wird.
EIP-1559 – Der Ethereum Improvement Proposal, der den Gasgebührenmarkt der EVM reformierte, indem er eine verbrannte Basisgebühr und einen optionalen Prioritäts-Trinkgeldmechanismus einführte.
Proxy-Vertrag – Ein Entwurfsmuster, das den DELEGATECALL-Opcode der EVM nutzt, um aktualisierbare Smart Contracts zu erstellen, indem Speicher und Logik getrennt werden.
Opcodes – Der grundlegende Befehlssatz der EVM, von denen jeder eine einzelne atomare Operation ausführt, wie z. B. Addition, Speicherzugriff oder Vertragsaufruf.
State Trie – Die Merkle Patricia Trie-Datenstruktur, die den globalen Zustand (Kontostände, Vertragsspeicher, Bytecode) speichert, auf den die EVM während der Ausführung zugreift.
FAQ
F: Was bedeutet „EVM-kompatibel“ und warum ist das wichtig? A: EVM-Kompatibilität bedeutet, dass eine Blockchain dieselbe Virtual-Machine-Spezifikation wie Ethereum implementiert. Dadurch können in Solidity geschriebene Smart Contracts ohne Änderungen eingesetzt werden. Dies ist wichtig, da neue Chains so sofortigen Zugriff auf Ethereums umfangreiches Ökosystem an Entwicklertools (Hardhat, Foundry, Remix), geprüften Vertragsbibliotheken (OpenZeppelin) und bestehenden dApp-Codebasen erhalten. Chains wie BSC, Polygon, Avalanche C-Chain, Arbitrum und Optimism sind alle EVM-kompatibel, weshalb dieselben Protokolle (Uniswap, Aave, SushiSwap) auf allen diesen Chains funktionieren.
F: Warum verwendet das EVM Gas anstatt einfach feste Gebühren zu erheben? A: Gas existiert, weil verschiedene Operationen sehr unterschiedliche Mengen an Rechenressourcen verbrauchen. Eine einfache Addition erfordert nur minimalen Aufwand, während das Schreiben in einen persistenten Speicher Festplattenzugriffe auf Tausenden von Knoten weltweit erfordert. Gas bepreist jede Operation proportional zu ihren tatsächlichen Ressourcenkosten und verhindert so, dass Angreifer das Netzwerk mit aufwändigen Berechnungen zu niedrigen Kosten überlasten. Der Gasmechanismus bietet zudem eine natürliche Abbruchgarantie: Selbst wenn ein Smart Contract eine Endlosschleife enthält, geht ihm irgendwann das Gas aus und er wird gestoppt. Dadurch wird das Netzwerk vor Denial-of-Service-Angriffen geschützt.
F: Was passiert, wenn einem Smart Contract während der EVM-Ausführung das Gas ausgeht? A: Wenn das Gas während der Ausführung aufgebraucht ist, stoppt die EVM sofort und macht alle während dieser Transaktion vorgenommenen Zustandsänderungen rückgängig – Speicherzugriffe, Guthabenübertragungen und Vertragserstellungen werden rückgängig gemacht, als hätte die Transaktion nie stattgefunden. Die Gasgebühr wird jedoch weiterhin verbraucht und an den Blockvalidator gezahlt, da die Rechenarbeit bereits ausgeführt wurde. Deshalb ist die Festlegung eines angemessenen Gaslimits wichtig: Ist es zu niedrig, schlägt die Transaktion fehl (und das Gas wird verschwendet), ist es zu hoch, besteht das Risiko einer Überzahlung, falls die Operation vorzeitig abgeschlossen wird (nicht verbrauchtes Gas wird jedoch erstattet).
F: Worin unterscheidet sich die EVM von einem herkömmlichen Computerprozessor? A: Im Gegensatz zu einer physischen CPU ist die EVM eine virtuelle Maschine – eine Software, die einen Computer simuliert. Zu den wichtigsten Unterschieden gehören: (1) Die EVM ist vollständig deterministisch, d. h., sie erzeugt auf jeder Maschine identische Ergebnisse, während physische CPUs nicht-deterministisches Verhalten zeigen können; (2) die EVM berechnet jede Operation über Gas, während CPUs Anweisungen in Hardwaregeschwindigkeit verarbeiten; (3) die EVM verfügt über einen persistenten Blockchain-Speicher, während der CPU-Speicher flüchtig ist; (4) die EVM läuft identisch auf Tausenden von Knoten gleichzeitig, während eine CPU nur auf einer einzelnen Maschine läuft. Man kann sie sich als einen bewusst langsamen und bewusst teuren Computer vorstellen, der für einen vertrauenslosen globalen Konsens und nicht für Höchstleistung ausgelegt ist.
F: Können EVM-Smart-Contracts nach der Bereitstellung aktualisiert oder repariert werden? A: Direkt nicht – EVM-Bytecode ist nach der Bereitstellung unveränderlich. Das Proxy-Muster (mittels des Opcodes DELEGATECALL) ermöglicht es Entwicklern jedoch, aktualisierbare Verträge zu erstellen. Ein Proxy-Vertrag speichert den Zustand und delegiert die Ausführung an einen Implementierungsvertrag, der die Logik enthält. Für ein Upgrade stellen Entwickler einen neuen Implementierungsvertrag bereit und aktualisieren den Proxy, sodass er darauf verweist. Dieses Muster wird von den meisten großen DeFi-Protokollen verwendet, birgt aber Risiken hinsichtlich Governance und Zentralisierung (wer das Proxy-Upgrade kontrolliert, kann das Verhalten des Vertrags ändern). Transparente Proxys (EIP-1967) und UUPS-Proxys sind die gängigsten Implementierungen.
F: Was ist der Unterschied zwischen EVM-Äquivalenz und EVM-Kompatibilität? A: EVM-Kompatibilität bedeutet, dass eine Blockchain Solidity-Smart-Contracts ausführen kann, es aber subtile Unterschiede im Opcode-Verhalten, den Gaskosten oder der Verfügbarkeit von Präkompilierungen geben kann. EVM-Äquivalenz bedeutet, dass die Blockchain die EVM-Spezifikation identisch implementiert, Opcode für Opcode, sodass selbst Low-Level-Bytecode und Debugging-Tools genau wie auf Ethereum funktionieren. Optimisms Bedrock-Upgrade und Arbitrum Nitro streben beide EVM-Äquivalenz an, während ältere Blockchains wie BSC zwar EVM-kompatibel, aber nicht vollständig äquivalent sind. Äquivalenz ist wichtig für komplexe Verträge, die von spezifischen Gaskosten oder Opcode-Verhalten abhängen.
F: Wird das EVM irgendwann ersetzt? A: Es gibt aktive Vorschläge und Forschungsarbeiten zu Nachfolgetechnologien für die EVM, darunter eWASM (Ethereum-basiertes WebAssembly), RISC-V und das EOF-Upgrade (EVM Object Format). Die Ablösung der EVM steht jedoch vor einer enormen Herausforderung hinsichtlich der Abwärtskompatibilität: Smart Contracts im Wert von Milliarden von Dollar werden als EVM-Bytecode bereitgestellt, und jede Nachfolgelösung muss entweder bestehende Verträge unterstützen oder einen reibungslosen Migrationspfad ermöglichen. Die wahrscheinlichste kurzfristige Weiterentwicklung ist die EOF-Upgrade-Serie, die das EVM-Bytecode-Format modernisiert und gleichzeitig die Kompatibilität beibehält. Ein vollständiger Ersatz, falls er überhaupt erfolgt, dürfte noch Jahre dauern und müsste über einen längeren Übergangszeitraum parallel zur aktuellen EVM betrieben werden.
Bitcoin-besicherte Kredite treten in ein neues institutionelles Kapitel ein, das die Silicon Valley Bank als solches beschreibt – mit strengeren Kreditvergabestandards und wachsendem Wachstum.
Die Europäische Union überprüft ihre wegweisende Krypto-Regulierung nur drei Jahre nach dem Inkrafttreten des Rahmenwerks „Märkte für Krypto-Assets“ (MiCA).
