Die Ethereum Virtual Machine (EVM) ist eine dezentrale, sandboxartige Laufzeitumgebung, die Smart Contracts im Ethereum-Blockchain-Netzwerk ausführt. Als quasi-Turing-vollständige, virtuelle Maschine ermöglicht sie deterministische und sichere Ausführung von Code auf jedem Knoten unabhängig von der zugrunde liegenden Hardware oder dem Betriebssystem [1]. Die EVM bildet das Herzstück von Ethereum und ermöglicht dessen Funktion als programmierbare Blockchain, wodurch Anwendungen wie DeFi, NFTs, DAOs und Token-Standards wie ERC-20 und ERC-721 möglich werden [2]. Ihre Architektur basiert auf einem Stack, verwendet 256-Bit-Wörter für kryptografische Operationen und verarbeitet Anweisungen über einen Satz von etwa 140 Opcodes, darunter ADD, SSTORE und JUMP [3]. Um Ressourcenmissbrauch zu verhindern, implementiert die EVM ein Gas-System, bei dem jede Operation eine vordefinierte Menge an Gas verbraucht, das in ETH bezahlt wird [4]. Die deterministische Ausführung stellt sicher, dass alle Knoten zu identischen Zustandsänderungen gelangen, was für das Erreichen von Konsens entscheidend ist [5]. Die formale Spezifikation der EVM findet sich im Ethereum Yellow Paper von Dr. Gavin Wood, das die technischen und mathematischen Grundlagen beschreibt [6]. Entwickler schreiben Smart Contracts meist in Solidity oder Vyper, die dann in EVM-Bytecode kompiliert werden, und nutzen Tools wie Hardhat, Foundry oder Remix zur Entwicklung und Bereitstellung [7]. Zu den jüngsten Entwicklungen gehören das EVM Object Format (EOF) (EIP-7692), Optimierungen von kryptografischen Precompiles (EIP-7666) und die Roadmap „The Splurge“ unter der Leitung von Vitalik Buterin, die Verbesserungen bei der Account-Abstraktion und kryptografischen Flexibilität anstrebt [8].
Architektur und Ausführungsmodell
Die Ethereum Virtual Machine (EVM) ist eine dezentrale, sandboxartige Laufzeitumgebung, die als quasi-Turing-vollständige virtuelle Maschine fungiert und die Ausführung von Smart Contracts im Ethereum-Netzwerk ermöglicht [1]. Ihre Architektur basiert auf einem Stack und verwendet eine feste Wortgröße von 256 Bit, um kryptografische Operationen effizient zu unterstützen. Dieser Entwurf gewährleistet deterministische Ausführung über alle Knoten hinweg, was für die Erreichung von Konsens in einem dezentralen Netzwerk unerlässlich ist [10].
Stack-basierte Architektur und Datenstrukturen
Die EVM ist eine stackbasierte Maschine, was bedeutet, dass sie einen Last-in-First-out-Stack (LIFO) zur temporären Speicherung und Manipulation von Werten während der Berechnung verwendet [10]. Der Stack hat eine maximale Tiefe von 1024 Elementen, wobei jedes Element 256 Bit groß ist. Operationen wie ADD oder MUL greifen auf die obersten Elemente des Stacks zu, führen die Berechnung durch und legen das Ergebnis zurück auf den Stack [3]. Diese Architektur vereinfacht die Befehlsdecodierung und -ausführung und trägt zur Vorhersagbarkeit und Konsistenz der Ausführung bei.
Neben dem Stack verfügt die EVM über mehrere andere Speicherbereiche:
- Speicher (Memory): Ein flüchtiger, linearer Speicher, der während der Ausführung eines Smart Contracts verwendet wird.
- Speicherung (Storage): Ein persistenter Schlüssel-Wert-Speicher, in dem der Zustand des Vertrags auf der Blockchain gespeichert wird.
- Calldata: Ein unveränderlicher Eingabedatenbereich, der die Daten einer Transaktion enthält und verwendet wird, um zu bestimmen, welche Funktion aufgerufen werden soll [13].
Ausführungsmodell und Bytecode
Smart Contracts werden in Hochsprachen wie Solidity oder Vyper geschrieben und dann in EVM-Bytecode kompiliert – eine Folge von Binäranweisungen, die direkt von der EVM interpretiert werden können [14]. Jeder Befehl im Bytecode entspricht einem Opcode, einem niedrigstufigen Befehl wie PUSH, ADD, JUMP oder SSTORE, der eine spezifische Aufgabe ausführt [15]. Die Ausführung ist deterministisch, sodass alle Knoten bei denselben Eingaben und Zuständen zu identischen Ergebnissen gelangen, was für die Integrität des Netzwerks entscheidend ist [10].
Der erste Schritt bei der Ausführung eines Vertrags besteht darin, die Funktion auszuwählen, die aufgerufen werden soll. Dazu analysiert die EVM die ersten vier Bytes der calldata, die den Funktions-Selektor enthalten – einen Keccak-256-Hash der Funktions-Signatur [13]. Nach der Identifizierung wird der entsprechende Teil des Bytecodes ausgeführt, wobei die EVM den Stack, Memory und Storage entsprechend verändert.
Quasi-Turing-Vollständigkeit und Ausführungssicherheit
Die EVM wird als quasi-Turing-vollständig bezeichnet, da sie theoretisch jede berechenbare Funktion ausführen kann, jedoch durch das Gas-System praktische Grenzen für die Ausführungszeit und -ressourcen gesetzt sind [18]. Ohne diese Einschränkung könnte ein Smart Contract in einer Endlosschleife hängen bleiben, was zu Netzwerküberlastung oder einem Konsensversagen führen würde. Das Gas-System verhindert dies, indem jede Operation eine vordefinierte Menge an Gas verbraucht, und die Ausführung stoppt, sobald das Gaslimit erreicht ist [4].
Diese Mechanik löst das Halteproblem – die Unmöglichkeit, vorherzusagen, ob ein Programm jemals endet – durch wirtschaftliche Anreize. Da jede Operation in ETH bezahlt werden muss, ist es für Angreifer unwirtschaftlich, das Netzwerk durch unendliche Berechnungen zu überlasten [20]. Außerdem begrenzt die maximale Gasmenge pro Transaktion auf 16.777.216 Einheiten (2^24), was zusätzliche Sicherheit gegen übermäßige Ressourcennutzung bietet [21].
Sicherheitsaspekte der Architektur
Die stackbasierte Architektur bringt jedoch auch spezifische Sicherheitsrisiken mit sich, insbesondere Stack-Underflow und Stack-Overflow. Wenn ein Opcode versucht, mehr Werte vom Stack zu entfernen, als vorhanden sind, kann dies zu undefiniertem Verhalten führen. Um dieses Problem zu beheben, führt EIP-5450 eine statische Stack-Validierung zur Bereitstellungszeit ein, die sicherstellt, dass die Stack-Tiefe während der gesamten Ausführung innerhalb zulässiger Grenzen bleibt [22]. Dies eliminiert eine ganze Klasse von Exploits, die auf unsachgemäßer Stack-Verwaltung beruhen.
Weitere Vorschläge wie EIP-7979 zielen darauf ab, den Kontrollfluss zu verbessern, indem strukturierte Aufruf-/Rückgabe-Mechanismen eingeführt werden, um Risiken durch dynamische Sprünge und tiefe Aufrufstapel zu reduzieren [23]. Diese kontinuierlichen Verbesserungen zeigen die Entwicklung hin zu sichereren Ausführungsumgebungen, in denen statische Garantien die Laufzeitprüfungen ergänzen.
Vergleich mit alternativen Ausführungsmodellen
Im Vergleich zu anderen Blockchain-Ausführungsumgebungen wie Solana’s Sealevel oder Polkadot’s WebAssembly (Wasm)-basiertem Runtime, ist die EVM durch ihre sequenzielle, single-threaded Ausführung limitiert [24]. Während die EVM Transaktionen nacheinander ausführt, ermöglicht Sealevel parallele Ausführung, was zu einer viel höheren Transaktionsrate führt. Ebenso bietet Wasm eine registerbasierte Architektur, die eine schnellere Ausführung und bessere Sprachunterstützung (z. B. für Rust oder C++) ermöglicht [25].
Trotz dieser Leistungsnachteile bietet die EVM durch ihre starke Determinismus und Reife eine robuste Grundlage für komplexe, komponierbare Anwendungen. Die Einführung von Projekten wie Parallel-EVM (z. B. in Sei v2) zeigt jedoch, dass die Architektur weiterentwickelt wird, um die Vorteile der Parallelität zu nutzen, während die Sicherheit und Konsistenz gewahrt bleiben [26].
Gas-System und Ressourcenverwaltung
Das Gas-System ist ein zentrales Element des Ethereum-Netzwerks und bildet die Grundlage für die sichere und effiziente Verwaltung von Ressourcen innerhalb der Ethereum Virtual Machine. Es fungiert als ökonomischer Mechanismus, der sicherstellt, dass jede Berechnung, jeder Speicherzugriff und jede Transaktion einen vordefinierten Preis in Form von Gas hat, der in ETH bezahlt wird [4]. Dieses Modell schützt das Netzwerk vor Missbrauch, verhindert Endlosschleifen und sorgt dafür, dass alle Knoten eine faire Vergütung für die von ihnen geleistete Arbeit erhalten. Die Einführung von EIP-1559 im Rahmen des London-Hardforks revolutionierte das Gas-Modell, indem es eine algorithmisch angepasste Basisgebühr einführte, die pro Block variiert und automatisch verbrannt wird, was zu einer stabileren und vorhersehbareren Transaktionskostenerfahrung führt [28].
Funktionsweise des Gas-Systems
Jeder Opcode, der von der EVM ausgeführt wird, verbraucht eine bestimmte Menge an Gas, die nach seiner rechnerischen Komplexität und Ressourcennutzung kalibriert ist. Einfache arithmetische Operationen wie ADD oder SUB kosten beispielsweise 3 Gas-Einheiten, während komplexere Operationen wie MUL 5 Gas verbrauchen. Speicherintensive Operationen wie SLOAD (Lesen aus dem Speicher) oder SSTORE (Schreiben in den Speicher) sind deutlich teurer, da sie den globalen Zustand des Netzwerks beeinflussen und eine höhere Belastung für die Knoten darstellen [3]. Um sicherzustellen, dass Transaktionen nicht unendlich lange laufen, muss jeder Benutzer eine maximale Gasmenge (Gas-Limit) festlegen. Falls die Ausführung die verfügbare Gasmenge überschreitet, wird die Transaktion zurückgesetzt (reverted), und alle Zustandsänderungen werden rückgängig gemacht – das bereits verbrauchte Gas bleibt jedoch verloren [1]. Dieser Mechanismus löst das theoretische Problem des „Halteproblems“ in einer dezentralen Umgebung, indem er jede Berechnung auf eine endliche Ressource begrenzt, wodurch die EVM als „quasi-Turing-vollständig“ gilt [18].
Dynamische Gaspreise und EIP-1559
Vor der Einführung von EIP-1559 basierte das Gebührenmodell auf einem ersten Preisgebotssystem, bei dem Benutzer konkurrierend Gebühren boten, um ihre Transaktionen in den nächsten Block aufgenommen zu bekommen. Dies führte oft zu volatilen und unvorhersehbaren Transaktionskosten, insbesondere in Zeiten hoher Netzwerkbelastung. EIP-1559 ersetzte dieses Modell durch ein zweigliedriges Gebührensystem, das aus zwei Komponenten besteht: der Basisgebühr und dem Prioritätstipp (Priority Tip). Die Basisgebühr wird automatisch angepasst – steigt die Blockauslastung über das Ziel von 15 Millionen Gas, erhöht sich die Gebühr um bis zu 12,5 %; bei geringerer Auslastung sinkt sie. Diese dynamische Anpassung stabilisiert die Netzwerkbelastung und verbessert die Vorhersagbarkeit der Transaktionskosten erheblich [32]. Der Prioritätstipp ist eine optionale zusätzliche Gebühr, die direkt an den Blockvalidierer gezahlt wird, um die Einbeziehung der Transaktion zu beschleunigen, insbesondere in Zeiten hoher Nachfrage. Die Einführung von EIP-1559 führte nicht nur zu einer Verbesserung der Nutzererfahrung, sondern auch zu einer deflationären Druck auf ETH, da Milliarden Dollar an ETH durch das Verbrennen der Basisgebühr aus dem Umlauf genommen wurden [33].
Gasoptimierung und Sicherheitsimplikationen
Die Optimierung von Gasverbrauch ist ein zentraler Aspekt der Entwicklung von Smart Contracts, da hohe Gaspreise die Benutzerfreundlichkeit und Rentabilität von Anwendungen beeinträchtigen können. Entwickler nutzen verschiedene Techniken, um die Effizienz zu steigern, darunter das Packen von Variablen in Strukturen, um Speicherplatz zu sparen, das Caching von Werten im Speicher, um wiederholte Lesevorgänge zu vermeiden, und das Vermeiden von unbeschränkten Schleifen über dynamische Arrays [34]. Allerdings können aggressive Optimierungsstrategien auch Sicherheitsrisiken mit sich bringen. So kann beispielsweise die Verwendung von unchecked-Blöcken in Solidity, die arithmetische Über- und Unterläufe deaktivieren, zu kritischen Fehlern führen, wenn sie nicht sorgfältig eingesetzt werden [35]. Ebenso kann die Verwendung von Inline-Assembly, die direkten Zugriff auf EVM-OpCodes ermöglicht, zu Speicherkorruption und unsicheren Zustandsänderungen führen, wenn nicht ordnungsgemäß validiert wird [36]. Tools wie Slither und Echidna helfen dabei, solche risikoreichen Muster zu erkennen, indem sie tiefgehende Analysen des Bytecodes und der Ausführungssemantik durchführen [37].
Weiterentwicklung des Gas-Modells
Das Gas-Modell unterliegt kontinuierlichen Anpassungen durch Ethereum Improvement Proposals (EIPs), um den sich ändernden Anforderungen des Netzwerks gerecht zu werden. Beispielsweise erhöhte EIP-2929 die Gaspreise für Zustandszugriffs-OpCodes wie SLOAD und BALANCE, um den wachsenden Aufwand für den Zugriff auf den globalen Zustand besser widerzuspiegeln [38]. EIP-3529 reduzierte die maximale Gasrückerstattung von 50 % auf 20 % und eliminierte Rückerstattungen für SELFDESTRUCT, um Missbrauch von Rückerstattungsmechanismen in Denial-of-Service-Angriffen zu verhindern [39]. Zukünftige Vorschläge wie EIP-7778 und EIP-8918 zielen darauf ab, Gasrückerstattungen von der Gesamtblock-Gasnutzung auszuschließen, um Manipulationen des Block-Gas-Limits zu verhindern [40]. Außerdem wird mit EIP-7825 ein hartes Transaktions-Gas-Limit von 16.777.216 Gas (2^24) vorgeschlagen, um extrem große oder komplexe Transaktionen einzudämmen, die das Netzwerk destabilisieren könnten [21]. Diese kontinuierlichen Verbesserungen stellen sicher, dass das Gas-System robust, wirtschaftlich sinnvoll und resistent gegenüber ökonomischen Angriffen bleibt, während es die Skalierbarkeit und Sicherheit des Ethereum-Ökosystems unterstützt.
Programmierung und Entwicklungstools
Die Entwicklung von Smart Contracts für die Ethereum Virtual Machine erfolgt in der Regel nicht direkt in EVM-Bytecode, sondern in benutzerfreundlicheren Hochsprachen, die anschließend in maschinennahe Anweisungen kompiliert werden. Dieser Ansatz ermöglicht es Entwicklern, komplexe dezentrale Anwendungen (dApps) effizient zu schreiben, während gleichzeitig die Sicherheit und Determinismus des Ausführungsmodells gewahrt bleiben. Die Wahl der richtigen Programmiersprache und Entwicklungsumgebung spielt eine entscheidende Rolle für die Effizienz, Sicherheit und Wartbarkeit von Smart Contracts.
Hochsprachen für die EVM
Entwickler verwenden verschiedene Hochsprachen, um Smart Contracts zu verfassen, die dann in EVM-kompatiblen Bytecode übersetzt werden. Die am weitesten verbreiteten Sprachen sind Solidity, Vyper und Yul, jede mit eigenen Stärken und Anwendungsbereichen.
Solidity ist die dominierende Sprache im Ethereum-Ökosystem und weist eine Syntax auf, die an JavaScript erinnert. Sie unterstützt objektorientierte Konzepte wie Vererbung, Bibliotheken und Interfaces, was die Entwicklung komplexer Anwendungen wie DeFi-Protokolle oder DAOs erleichtert [42]. Solidity wird kontinuierlich weiterentwickelt und von einem umfangreichen Tooling-Ökosystem unterstützt, einschließlich Compiler, Testframeworks und IDEs. Seit Version 0.8.0 bietet Solidity integrierte Überlauf- und Unterlaufschutzmechanismen, die die Sicherheit von arithmetischen Operationen erhöhen und die Notwendigkeit externer Bibliotheken wie OpenZeppelin’s SafeMath reduzieren [43].
Als sicherheitsorientierte Alternative dient Vyper, eine Python-ähnliche Sprache, die bewusst auf komplexe Features wie Vererbung und Funktionenüberladung verzichtet. Dieser minimalistische Ansatz verringert die Angriffsfläche und verbessert die Lesbarkeit und Prüfbarkeit des Codes, was Vyper besonders für sicherheitskritische Anwendungen wie Finanzprotokolle geeignet macht [44]. Die Sprache zielt darauf ab, den Entwicklern eine klare und transparente Logik zu ermöglichen, um Fehler und Sicherheitslücken zu minimieren.
Yul fungiert als Zwischensprache innerhalb des Solidity-Toolchains und ermöglicht eine feingranulare Kontrolle über die EVM-Ausführung. Yul kann entweder eigenständig oder als Inline-Assembly innerhalb von Solidity verwendet werden, um optimierten Code für spezifische Anwendungsfälle zu schreiben [45]. Eine erweiterte Variante, Yul+, wird experimentell für fortgeschrittene Optimierungen eingesetzt [46]. Yul spielt eine zentrale Rolle bei der Implementierung von Kompilierungspipelines wie Via-IR, die die Effizienz und Sicherheit des resultierenden Bytecodes verbessern.
Zudem entstehen neue Sprachen wie Fe, die die Sicherheit von Vyper mit der Expressivität von Solidity kombinieren sollen, was die kontinuierliche Weiterentwicklung des Entwicklerökosystems widerspiegelt [46].
Entwicklungsumgebungen und Frameworks
Die Entwicklung, das Testen und die Bereitstellung von Smart Contracts werden durch leistungsstarke Tools und Frameworks erheblich vereinfacht. Zu den wichtigsten gehören Remix, Hardhat und Foundry, die unterschiedliche Ansätze und Stärken bieten.
Remix ist eine webbasierte IDE, die sich besonders für Einsteiger und schnelle Prototypen eignet. Sie bietet integrierte Funktionen wie Kompilierung, Debugging, Tests und die Bereitstellung auf lokalen oder öffentlichen Netzwerken. Remix ermöglicht es Entwicklern, Code direkt im Browser zu schreiben und zu testen, ohne eine lokale Umgebung einrichten zu müssen [7].
Hardhat ist ein lokales Entwicklungsumgebung für Ethereum, die auf Node.js basiert und eine hohe Flexibilität durch ein Plugin-System bietet. Seit der Einführung des in Rust geschriebenen Ethereum Development Runtime (EDR) in Version 2.21.0 hat sich die Leistung von Hardhat deutlich verbessert, mit Berichten über bis zu zehnfach schnellere Testläufe [49]. Hardhat integriert sich nahtlos in bestehende JavaScript/TypeScript-Workflows und ist besonders beliebt bei Full-Stack-Teams. Ein nützliches Plugin ist der Hardhat Gas Reporter, der detaillierte Gasverbrauchsberichte generiert und die Optimierung unterstützt [50].
Foundry, im Gegensatz dazu, ist vollständig in Rust implementiert und zeichnet sich durch hohe Geschwindigkeit und eine native Solidity-Testumgebung aus. Entwickler können Tests direkt in Solidity schreiben, was Kontextwechsel zwischen Sprachen vermeidet und die Fehlersuche erleichtert [51]. Foundry bietet leistungsstarke Funktionen wie Fuzzing, Invariantentests und Gas-Snapshots, die es ermöglichen, Leistungsregressionen über Commits hinweg zu erkennen [52]. Die Veröffentlichung von Foundry v1.0 im Jahr 2025 unterstrich seine Reife als professionelles Werkzeug [53].
Visualisierung und Optimierung von Gas-Kosten
Der Gasverbrauch ist ein zentraler Faktor in der Smart Contract-Entwicklung, da er direkt die Transaktionskosten beeinflusst. Eine präzise Analyse und Optimierung des Gasverbrauchs ist entscheidend, um wirtschaftliche und benutzerfreundliche Anwendungen zu schaffen. Neben den bereits erwähnten Tools wie dem Hardhat Gas Reporter und Foundry’s Gas Reports bietet Tenderly mit seinem Gas Profiler eine interaktive Visualisierung des Gasverbrauchs auf Opcode-Ebene [54]. Diese detaillierte Darstellung hilft dabei, teure Operationen wie Speicherzugriffe oder Schleifen zu identifizieren.
Weitere Tools wie solx, ein auf LLVM basierender, gasoptimierter Solidity-Compiler, können bereits während des Kompilierungsprozesses Optimierungen vornehmen [55]. Die Integration von Gas-Analysen in den CI/CD-Prozess, beispielsweise durch die Verwendung von foundry-gas-diff in GitHub-Pull-Requests, ermöglicht es Teams, Leistungsregressionen frühzeitig zu erkennen und zu verhindern [56]. Selbst kleine Änderungen, wie die Neuanordnung von Variablenzuweisungen, können erhebliche Gasersparnisse von bis zu 20.000 Gas pro Transaktion bewirken [57].
Herausforderungen und zukünftige Entwicklungen
Trotz der Fortschritte in der Tooling-Landschaft bestehen weiterhin Herausforderungen. Das Debugging bleibt komplex, da die meisten Tools nur eingeschränkte Einblicke in die Opcode-Ausführung und den Speicherzustand bieten. Entwickler sind oft auf lokale Archivknoten oder kommerzielle Dienste wie Tenderly angewiesen, um tiefgehende Analysen durchzuführen [58]. Die Testabdeckung ist ebenfalls eingeschränkt, da symbolische Ausführungswerkzeuge wie hevm bei unendlichen Schleifen oder tiefer Rekursion an ihre Grenzen stoßen [59].
Ein weiterer kritischer Bereich ist die Entwicklung für mehrere Ketten. Obwohl Ketten wie Polygon, Arbitrum und Optimism EVM-kompatibel sind, unterscheiden sie sich in ihrer Architektur, Gasmodellen und RPC-Verhalten, was zu unerwartetem Verhalten führen kann [60]. Die Interoperabilität über Brücken birgt zudem erhebliche Sicherheitsrisiken [61].
Die Zukunft der EVM-Entwicklung liegt in der Integration fortschrittlicher Technologien wie KI-gestützter Tools. Initiativen wie EVMbench und OpDiffer erforschen den Einsatz von großen Sprachmodellen (LLMs) zur automatisierten Erkennung von Schwachstellen und zur Optimierung von Code [62][63]. Diese Entwicklungen versprechen, die Sicherheit und Effizienz der Smart Contract-Entwicklung auf ein neues Niveau zu heben.
Sicherheitsaspekte und häufige Angriffe
Die Ethereum Virtual Machine (EVM) bietet eine sichere, deterministische Ausführungsplattform für Smart Contracts, doch ihre architektonischen Merkmale wie die stackbasierte Architektur und das Gas-System können auch Sicherheitsanfälligkeiten begünstigen. Entwickler müssen diese Risiken verstehen, um kritische Schwachstellen in dezentralen Anwendungen (dApps) zu vermeiden. Zu den häufigsten Angriffen gehören Reentrancy-Angriffe, Denial-of-Service (DoS), Integer-Überläufe und -Unterläufe sowie Gas-Griefing.
Reentrancy-Angriffe
Reentrancy ist eine der bekanntesten Sicherheitsanfälligkeiten im EVM-Ökosystem. Sie tritt auf, wenn ein böswilliger Vertrag eine Funktion rekursiv erneut aufruft, bevor die ursprüngliche Ausführung abgeschlossen ist, insbesondere bevor Zustandsänderungen wie die Aktualisierung von Kontoständen vorgenommen werden. Dies geschieht häufig über externe Aufrufe, bei denen ein Angreifer eine Rückruffunktion (fallback) definiert, die sofort eine empfangende Funktion erneut aufruft, um veraltete Zustände auszunutzen [64]. Der berühmte DAO-Hack von 2016 nutzte genau dieses Muster, um Millionen an ETH abzuziehen, bevor der Saldo aktualisiert wurde [65].
Die Stack-basierte Architektur der EVM ermöglicht solche rekursiven Aufrufe, da jeder externe Aufruf einen neuen Aufrufrahmen auf dem Ausführungsstack erstellt. Die EVM erlaubt bis zu 1024 Aufruftiefen, was ausreicht, um Reentrancy-Angriffe durchzuführen, solange der Gaslimit nicht überschritten wird [66]. Um solche Angriffe zu verhindern, sollten Entwickler das Checks-Effects-Interactions-Muster anwenden, bei dem der interne Zustand vor externen Aufrufen aktualisiert wird. Zusätzlich können Reentrancy-Guards, wie die von OpenZeppelin bereitgestellte Bibliothek, verwendet werden, um wiederholte Funktionsaufrufe zu blockieren [67].
Denial-of-Service durch Gas-Ausnutzung
Ein weiterer häufiger Angriffsvektor ist der Denial-of-Service (DoS) durch Gas-Ausnutzung, bei dem ein Angreifer eine Funktion so manipuliert, dass sie mehr Gas verbraucht, als im Blocklimit erlaubt ist, wodurch die Transaktion fehlschlägt und die Funktion unbrauchbar wird. Dies geschieht oft in Funktionen, die über dynamische Arrays oder Abbildungen iterieren, ohne Paginierung oder Gasbegrenzungen einzubauen [68]. Ein Angreifer kann beispielsweise die Teilnehmerliste einer Belohnungsverteilung aufblähen, sodass die Funktion unmöglich ausgeführt werden kann, was zu einem effektiven Einfrieren des Vertrags führt [69].
Um solche Angriffe zu verhindern, sollten Entwickler Schleifen mit fester Obergrenze verwenden, die Verarbeitung in Blöcken aufteilen (batching) oder Push-Zahlungen durch Pull-Modelle ersetzen, bei denen Nutzer ihre Belohnungen selbst abrufen [70]. Außerdem zielen Vorschläge wie EIP-7825 darauf ab, das Transaktions-Gaslimit auf 16.777.216 Einheiten zu begrenzen, um die Auswirkungen großer Operationen einzudämmen [21].
Integer-Überläufe und -Unterläufe
Integer-Überläufe und -Unterläufe stellen eine kritische Sicherheitsanfälligkeit dar, die auf der festen Bitgröße von Ganzzahltypen in der EVM beruht. Wenn eine arithmetische Operation einen Wert außerhalb des darstellbaren Bereichs erzeugt, wird dieser stillschweigend „umgebrochen“ (wraparound). Zum Beispiel führt das Addieren von 1 zum Maximalwert eines uint8 (255) zu einem Überlauf, der den Wert auf 0 zurücksetzt. Solche Angriffe können dazu führen, dass Angreifer Token aus dem Nichts erschaffen oder Kontostände manipulieren [72]. Der BeautyChain-Token-Angriff von 2018 ermöglichte es Angreifern, durch einen Überlauf unendlich viele Token zu minten [73].
Die Einführung integrierter Überlaufprüfungen in Solidity ab Version 0.8.0 hat diese Anfälligkeit erheblich reduziert. Seit dieser Version führt jede arithmetische Operation, die zu einem Überlauf oder Unterlauf führen würde, automatisch zu einem Revert [43]. Dadurch ist die Verwendung externer Bibliotheken wie OpenZeppelin's SafeMath weitgehend obsolet geworden [75]. Allerdings können Entwickler mit dem unchecked-Block gezielt Überlaufschutz deaktivieren, was erneut Angriffsflächen schafft, wenn nicht sorgfältig verwendet [76].
Gas-Griefing und wirtschaftliche DoS-Angriffe
Gas-Griefing ist ein Angriff, bei dem ein Angreifer die Gas-Kosten manipuliert, um die Funktionalität eines Vertrags zu stören, ohne direkt Vermögen zu stehlen. Dies kann beispielsweise geschehen, wenn ein Vertrag Gas an Nutzer zurückerstattet. Ein Angreifer kann dann einen teuren Ausführungspfad auslösen, um den Erstattungspool zu leeren oder die Kosten für andere zu erhöhen [77]. Ein weiteres Beispiel ist der Missbrauch von externen Aufrufen mit unzureichendem Gasforwarding, wodurch ein böswilliger Empfänger alle verfügbaren Gasressourcen verbraucht und den Aufruf fehlschlagen lässt [78].
Um solche Angriffe zu verhindern, sollten Verträge ausreichend Gas weiterleiten (z. B. 2300 für ERC-20-Übertragungen) und Pull-über-Push-Zahlungsmodelle bevorzugen, bei denen die Ausführungsbelastung beim Nutzer liegt [69].
Werkzeuge zur Schwachstellenanalyse
Zur Erkennung dieser und anderer Anfälligkeiten nutzen Entwickler fortschrittliche Sicherheitswerkzeuge, die tiefes Wissen über EVM-Bytecode und Ausführungsszenarien nutzen. Slither analysiert Solidity-Code über eine interne Darstellung (SlithIR), die EVM-Semantik widerspiegelt, um Muster wie Reentrancy oder unsichere Typumwandlungen zu erkennen [80]. Echidna verwendet symbolische Ausführung über die hevm-Engine, um Tausende von Ausführungspfaden zu erkunden und Schwachstellen zu finden, die bei zufälligem Fuzzing unentdeckt bleiben würden [81]. Diese Werkzeuge sind unverzichtbar, um Anfälligkeiten zu finden, die auf der Oberfläche des Solidity-Codes nicht sichtbar sind, aber aus der EVM-Ausführungsemantik resultieren.
Formale Verifikation und deterministische Ausführung
Die Ethereum Virtual Machine (EVM) ist durch ihr deterministisches Ausführungsmodell gekennzeichnet, das sicherstellt, dass alle Knoten im Netzwerk bei identischen Eingaben und Anfangszuständen zu identischen Ergebnissen gelangen [10]. Diese Eigenschaft ist entscheidend für die Erreichung von Konsens in einem dezentralen Umfeld, da sie die Integrität und Verlässlichkeit des globalen Zustands gewährleistet. Die Determinismusgarantie ermöglicht es, formale Verifikationsmethoden anzuwenden, um die Korrektheit von Smart Contracts mathematisch zu beweisen.
Formale Modelle zur Beschreibung der EVM
Zur formalen Analyse der EVM existieren mehrere rechnergestützte Modelle, die präzise Ausführungssemantik bereitstellen. Ein zentrales Beispiel ist KEVM, eine vollständige formale Semantik der EVM, die im K-Framework entwickelt wurde. KEVM ermöglicht Erreichbarkeitslogik-basierte Verifikation, wodurch Eigenschaften wie die Abwesenheit von Überläufen, Reentrancy oder unberechtigtem Zustandszugriff nachgewiesen werden können [83]. Das Modell verwendet kleinschrittige operationelle Semantik, bei der jede Opcode-Übergangsregel den Zustand von Stapel, Speicher, Storage und Gas definiert [84].
Ein weiteres vertrauenswürdiges Modell wurde in der Beweisassistenten-Sprache Lean 4 von Nethermind entwickelt und ist auf den Cancun-Hardfork abgestimmt [85]. Dieses Modell erreicht eine Testabdeckung von 99,99 % der offiziellen Ethereum-Tests und integriert auch die Zwischensprache Yul, was eine End-to-End-Verifikation von Hochsprachen-Code bis zum Bytecode ermöglicht [86]. Durch maschinengeprüfte Beweise stellt es sicher, dass alle Ableitungen logisch konsistent sind.
Ein drittes Modell ist in der Verifikationssprache Dafny implementiert, die Spezifikation und Ausführung kombiniert. Es bietet automatisierte Verifikation durch SMT-Löser und ist gleichzeitig ausführbar, was Conformitätstests und Simulationen erlaubt [87]. Diese Modelle bilden die Grundlage für hochsichere Smart Contracts, wie beispielsweise ERC20-Token oder Komponenten von MakerDAO [88].
Determinismus und seine Bedeutung für die Konsensbildung
Der EVM gelingt es, perfekten Determinismus zu gewährleisten, indem alle Operationen mit festem Präzisionsarithmetic (256-Bit-Integer) arbeiten und jede Opcode-Semantik exakt definiert ist [89]. Auch das Gas-System trägt dazu bei, da jede Operation eine deterministische Menge an Gas verbraucht, was verhindert, dass Transaktionen unendlich laufen [90]. Obwohl die EVM theoretisch Turing-vollständig ist, wird in der Praxis durch die Gasbegrenzung sichergestellt, dass alle Ausführungen terminieren [91].
Die formale Zustandsübergangsfunktion der EVM ist im Ethereum Yellow Paper definiert, wo der Übergang von einem Zustand σ unter einer Transaktion τ zu einem neuen Zustand σ' beschrieben wird (Υ(σ, τ) → σ') [6]. Formale Modelle verfeinern diese Spezifikation, indem sie unklare Semantiken auflösen, etwa Randfälle bei Speichererweiterung oder Aufrufen leerer Funktionen [93]. Tools wie hevm, ein symbolischer EVM-Evaluator, nutzen diese Semantik, um alle möglichen Ausführungspfade zu erkunden und Sicherheitslücken zu finden [94].
Praktische Herausforderungen der formalen Verifikation
Trotz der theoretischen Stärke der formalen Modelle gibt es praktische Hürden bei der Anwendung auf reale Smart Contracts. Eine zentrale Herausforderung ist die Gasbegrenzung, die die Terminierung zwar sicherstellt, aber die Vorhersagbarkeit erschwert. Verifikationstools wie hevm müssen künstliche Grenzen für Schleifeniterationen und Aufruftiefen setzen, was bedeutet, dass Ergebnisse oft nur teilweise gültig sind [59]. EIP-7825, das eine Transaktions-Gas-Obergrenze von 16,777,216 einführt, könnte hier Abhilfe schaffen, indem es die Unsicherheit reduziert [96].
Ein weiteres Problem ist die Korrespondenz zwischen Quellcode und Bytecode. Compiler-Optimierungen, Inline-Assembly oder Konstruktorargumente können Diskrepanzen verursachen, die formale Beweise ungültig machen. Während KEVM und Dafny direkt auf Bytecode operieren, bleibt die Sicherstellung der End-to-End-Korrektheit eine große Herausforderung [97]. Projekte wie Blanc versuchen, diese Lücke zu schließen, indem sie eine minimale, EVM-ähnliche Sprache in Lean bereitstellen.
Zudem erschweren moderne Vertragsmuster wie Proxy-basierte Upgrades oder Diamonds die Verifikation, da sie dynamisches Dispatching und komplexe Speicherlayouts erfordern. Auch Zero-Knowledge-Anwendungen und zkEVMs erhöhen die Komplexität, da kryptografische Beweise in die Semantik integriert werden müssen [98].
Werkzeuge zur Unterstützung der formalen Analyse
Zur Unterstützung der formalen Verifikation stehen mehrere Werkzeuge zur Verfügung. Echidna, ein property-basierter Fuzzer, kombiniert konkrete und symbolische Ausführung über die hevm-Engine, um Invarianten zu testen und Gegenbeispiele zu finden [81]. Es unterstützt zwei Modi: Verifikation, um zu beweisen, dass eine Eigenschaft immer gilt, und Exploration, um Assertions in zustandsbehafteten Kontexten zu verletzen [100].
Slither, ein statisches Analyse-Framework, übersetzt Solidity-Code in eine interne Darstellung (SlithIR), die EVM-Semantik widerspiegelt [80]. Diese Zwischenrepräsentation ermöglicht präzise Datenfluss- und Taint-Analysen, um Schwachstellen wie Reentrancy oder Zeitstempelabhängigkeit zu erkennen [102]. Obwohl Slither keinen Bytecode direkt analysiert, bleibt es durch seine semantische Nähe zur EVM ein leistungsfähiges Werkzeug.
Die Integration formaler Methoden in Standardentwicklungsworkflows bleibt jedoch herausfordernd. Werkzeuge wie MythX verwenden symbolische Ausführung, leiden aber unter hohen Rechenkosten und Skalierbarkeitsproblemen [103]. Slither hingegen ist schnell, aber auf Mustererkennung beschränkt und kann keine komplexen zeitlichen Eigenschaften verifizieren [104]. Die effektivste Sicherheitsstrategie kombiniert daher formale Verifikation für kritische Invarianten mit Fuzzing, statischer Analyse und manueller Überprüfung.
Entwicklungen und zukünftige Upgrades
Die Ethereum Virtual Machine (EVM) unterliegt kontinuierlichen Verbesserungen, um Skalierbarkeit, Sicherheit und Entwicklerfreundlichkeit zu erhöhen. Aktuelle Entwicklungen konzentrieren sich auf die Optimierung der Ausführungseffizienz, die Verbesserung der Sicherheitsmechanismen und die Vorbereitung auf zukünftige Architekturänderungen, die Ethereum als „World Computer“ weiterentwickeln sollen. Zu den wichtigsten Initiativen gehören das EVM Object Format (EOF), die Einführung neuer Opcodes, Anpassungen des Gasmodells und langfristige Roadmaps wie „The Splurge“ unter der Leitung von Vitalik Buterin [8].
EVM Object Format (EOF)
Ein zentraler Schritt zur Modernisierung der EVM ist die Einführung des EVM Object Format (EOF), das durch EIP-3540 und weiterentwickelt in EIP-7692 vorgeschlagen wurde [106][107]. EOF führt ein strukturiertes Containerformat für EVM-Bytecode ein, das mehrere Codeabschnitte, Metadaten und Versionsinformationen unterstützt. Dadurch wird die statische Analyse, Validierung und Erweiterbarkeit des Bytecodes bei der Bereitstellung verbessert. EOF ermöglicht beispielsweise die Trennung von Init-Code und Laufzeit-Code, was die Fehlererkennung erleichtert und die Kompatibilität mit zkEVM-Systemen und Cross-Chain-Anwendungen erhöht [108]. Obwohl EOF als wichtiger Schritt zur Verbesserung der Codequalität und Sicherheit gilt, gibt es auch Kritik, dass die erhöhte Komplexität die Implementierung erschweren könnte [109].
Optimierungen von Opcodes und Ausführungseffizienz
Zahlreiche Ethereum Improvement Proposals (EIPs) zielen darauf ab, die Effizienz der EVM durch Optimierungen bestehender Opcodes und die Einführung neuer Befehle zu verbessern. Beispielsweise strebt EIP-7666 eine Vereinfachung kryptografischer Precompiles an, um deren Wartungskosten zu senken und die Ausführung zu beschleunigen [110]. Weitere Vorschläge wie EIP-7937 („EVM64“) schlagen die Einführung von 64-Bit-Arithmetik-Opcodes vor, um rechenintensive Operationen effizienter zu gestalten, insbesondere für Anwendungsfälle, die nicht auf kryptografische 256-Bit-Operationen angewiesen sind [111]. Darüber hinaus zielt EIP-7979 auf die Verbesserung der Steuerfluss-Sicherheit ab, indem strukturierte Call- und Return-Opcodes eingeführt werden, um Risiken durch dynamische Sprünge und tiefe Aufrufstacks zu reduzieren [23].
Anpassungen des Gasmodells und Ressourcenkontrolle
Die präzise Abrechnung von Ressourcenverbrauch bleibt ein zentrales Thema. Um Missbrauch durch Denial-of-Service-(DoS-)Angriffe zu verhindern, wurden mehrere EIPs vorgeschlagen, die das Gasmodell verfeinern. EIP-7686 schlägt lineare Speicherlimits vor, die die Speichernutzung auf das Niveau des Transaktions-Gaslimits begrenzen, um unvorhersehbare Speicherkosten zu reduzieren [113]. EIP-7825 führt eine harte Obergrenze von 16.777.216 Gas (2^24) pro Transaktion ein, um zu verhindern, dass einzelne Transaktionen die Knotenressourcen übermäßig belasten [21]. Zudem zielt EIP-7706 darauf ab, die Kosten für Calldata besser an die tatsächliche Netzwerkbelastung anzupassen, insbesondere im Hinblick auf die wachsende Nutzung von Layer-2-Lösungen wie Rollups, die große Mengen an Transaktionsdaten erfordern [115].
Langfristige Roadmaps: The Surge und The Splurge
Die zukünftige Entwicklung der EVM ist in die breiteren Roadmaps „The Surge“ und „The Splurge“ eingebettet, die von Vitalik Buterin und dem Ethereum-Entwicklerkollektiv vorangetrieben werden [116]. Während „The Surge“ die Skalierung durch Sharding und verbesserte Datenverfüglichkeit fokussiert, zielt „The Splurge“ auf eine Reihe von Verbesserungen ab, die die Benutzerfreundlichkeit und Flexibilität erhöhen sollen. Dazu gehören Fortschritte bei der Account-Abstraktion (z. B. durch EIP-7701), die Einführung von Frame-Transaktionen (EIP-8141) und die Standardisierung von Ausführungsschicht-Anfragen (EIP-7685) [117][118][119]. Diese Maßnahmen zielen darauf ab, Ethereum zu einer modulareren und flexibleren Plattform für standardisierte On-Chain-Berechnungen zu machen [120].
Zustandsverwaltung und Statelessness
Ein weiterer kritischer Entwicklungspfad betrifft die Zustandsverwaltung. Aufgrund des kontinuierlichen Wachstums des globalen Zustands, das die Hardwareanforderungen für Validatoren erhöht, werden Konzepte wie „State Expiry“ und „stateless Clients“ erforscht. Vorschläge wie EIP-7736 (Zustandsablauf auf Blattebene in Verkle Trees) und EIP-7748 (Zustandskonvertierung zu Verkle Trees) zielen darauf ab, inaktive Zustandsdaten nach einer Inaktivitätsperiode zu entfernen, um die aktive Zustandsgröße zu reduzieren [121]. Dies würde die Dezentralisierung fördern, indem die Anforderungen an Knotenhardware gesenkt werden. Der Übergang zu stateless Clients wird durch die Einführung von EIP-6800 vorbereitet, das einen einheitlichen Verkle-Baum für den Zustand vorschlägt, der konstant große Beweise ermöglicht [122].
Perspektiven: Ersatz durch eWASM oder evolutionäre Verbesserungen?
Obwohl die eWASM-Initiative als potenzieller Ersatz für die EVM diskutiert wurde, um eine registerbasierte Architektur und Unterstützung für Sprachen wie Rust und C++ zu ermöglichen, hat sich der Fokus auf inkrementelle Verbesserungen der bestehenden EVM verschoben [123]. Benchmarktests zeigten, dass eWASM zwar Geschwindigkeitsvorteile bieten kann, jedoch auch mit Sicherheits- und Standardisierungsproblemen konfrontiert ist [24]. Stattdessen verfolgt Ethereum einen evolutionären Ansatz, der die EVM kontinuierlich optimiert, anstatt sie durch eine neue VM zu ersetzen. Dieser pragmatische Weg spiegelt die Stärke des bestehenden Ökosystems wider, das auf Millionen von bereitgestellten Verträgen und einer reifen Tooling-Infrastruktur wie Hardhat und Foundry basiert [53].
Vergleich mit anderen Ausführungsumgebungen
Die Ethereum Virtual Machine (EVM) unterscheidet sich in mehreren zentralen Aspekten von anderen Blockchain-Ausführungsumgebungen wie Bitcoins UTXO-Modell, Solanas Sealevel oder Polkadots WebAssembly-basiertem Runtime. Diese Unterschiede betreffen die Programmierbarkeit, Leistung, Sicherheit und Skalierbarkeit und spiegeln divergierende Designphilosophien wider, die jeweils spezifische Anwendungsfälle priorisieren.
Architektonische Unterschiede: Stack-basiert vs. Register-basiert
Die EVM ist eine stackbasierte virtuelle Maschine, was bedeutet, dass sie Operationen durch Pushen und Poppen von Werten aus einem Last-in-First-out-(LIFO)-Stapel ausführt. Dieses Design gewährleistet eine einfache, deterministische Ausführung, die für die Erreichung von Konsens entscheidend ist. Allerdings führt es zu Leistungseinbußen, da komplexe Steuerungsstrukturen und Speicherzugriffe ineffizient sein können [24]. Die Stapelarchitektur begrenzt zudem die maximale Tiefe auf 1024 Elemente, was zu Fehlern wie „stack too deep“ führen kann, wenn zu viele lokale Variablen oder Funktionsaufrufe verwendet werden [66].
Im Gegensatz dazu verwenden Plattformen wie Polkadot WebAssembly (WASM), eine registerbasierte virtuelle Maschine, die direkten Zugriff auf Operanden ermöglicht und eine engere Anbindung an native Maschinensprache bietet. Dies führt zu einer signifikant höheren Ausführungsgeschwindigkeit – Schätzungen zufolge bis zu 10–100 Mal schneller als die EVM – und ermöglicht die Nutzung leistungsfähigerer Programmiersprachen wie Rust oder C++ [24]. Die registerbasierte Architektur verbessert auch die Effizienz bei der Gas-Abrechnung, da die Kosten genauer an den tatsächlichen Ressourcenverbrauch angepasst werden können.
Ausführungsmodell: Serialisierung vs. Parallelisierung
Ein weiterer entscheidender Unterschied betrifft das Ausführungsmodell. Die EVM führt Transaktionen sequenziell aus, was zwar die globale Zustandskonsistenz sicherstellt, aber die Transaktionsdurchsatzrate auf etwa 15–30 Transaktionen pro Sekunde (TPS) begrenzt. Diese Serialisierung verhindert Race Conditions und ermöglicht deterministische Ergebnisse, führt jedoch zu Netzwerküberlastung und hohen Gebühren in Zeiten hoher Nachfrage [129].
Anders hingegen ist Solanas Sealevel-Runtime, die parallele Ausführung von Tausenden von Smart Contracts ermöglicht. Sealevel erreicht dies, indem Transaktionen vorab deklarieren, auf welche Konten sie lesend oder schreibend zugreifen, sodass nicht-konkurrierende Transaktionen gleichzeitig verarbeitet werden können. Dieses Modell ermöglicht über 50.000 TPS und drastisch reduzierte Latenzzeiten, verlangt aber eine sorgfältige Programmierung, um Konflikte zu vermeiden [130].
Ausdruckskraft und Verifizierbarkeit
Die EVM gilt als Turing-vollständig, was bedeutet, dass sie im Prinzip jeden Algorithmus berechnen kann, sofern ausreichend Ressourcen zur Verfügung stehen. Diese hohe Ausdruckskraft ermöglicht komplexe dezentrale Anwendungen wie DeFi-Protokolle oder DAOs. Allerdings führt die Turing-Vollständigkeit theoretisch zu dem Halteproblem, weshalb die EVM das sogenannte Gas-System benötigt, um unendliche Schleifen zu verhindern [18].
Im Vergleich dazu ist WebAssembly zwar nicht per se Turing-vollständig, wird aber in der Praxis durch Gas-Metering auf Blockchains wie Polkadot funktional äquivalent gemacht. WASM bietet jedoch eine klarere Binärformat- und Speicherstruktur, die die statische Analyse und formale Verifizierung erleichtert. Die EVM hingegen profitiert von einem ausgereifteren Ökosystem formaler Modelle wie KEVM, das eine vollständige formale Semantik der EVM in der K-Framework-Umgebung bereitstellt und die Verifikation kritischer Eigenschaften wie Sicherheit und Korrektheit ermöglicht [132].
Widerstandsfähigkeit gegen Denial-of-Service-Angriffe
Die EVM verwendet ein Gas-Metering-System, um Ressourcenmissbrauch zu verhindern. Jede Operation verbraucht eine vordefinierte Menge an Gas, und Transaktionen, die ihr Limit überschreiten, werden zurückgesetzt. Dies verhindert, dass ein einzelner Benutzer das Netzwerk durch unendliche Schleifen lahmlegt. Allerdings ist das Gas-Modell nicht perfekt mit den tatsächlichen Rechenkosten abgestimmt, was Angriffe wie den „Broken Meter“ ermöglicht, bei dem Angreifer disproportional teure Berechnungen durchführen [133].
Alternative Umgebungen wie WASM können durch präzisere dynamische Gas-Abrechnung und statische Analyse eine genauere Kostenkontrolle ermöglichen. Sealevel hingegen nutzt parallele Ausführung und Prioritätsgebühren, um DoS-Risiken zu mindern, ist aber anfällig für Angriffe, die auf Konflikte bei gemeinsam genutztem Zustand abzielen [134].
Zustandsmodell: Konto-basiert vs. UTXO-basiert
Die EVM verwendet ein konto-basiertes Modell, bei dem jeder Account einen direkt lesbaren Saldo, einen Nonce und Speicher besitzt. Dieses Modell ähnelt einem traditionellen Bankbuch und vereinfacht die Entwicklung von Smart Contracts erheblich, da Entwickler direkt auf den Zustand zugreifen und ihn ändern können [135]. Im Gegensatz dazu verwendet Bitcoin ein UTXO-Modell (Unspent Transaction Output), bei dem jeder Wert als diskrete, unteilbare Einheit behandelt wird, die vollständig verbraucht werden muss. Dies ermöglicht eine höhere Parallelisierbarkeit und verbesserte Privatsphäre, erschwert aber komplexe Zustandslogik, da der Zustand durch die Kette unverbrauchter Ausgaben kodiert wird [136].
Entwicklererfahrung und Tooling
Die EVM profitiert von einem reifen Ökosystem an Entwicklungstools wie Hardhat, Foundry und Remix, die die Entwicklung, Tests und Bereitstellung erheblich vereinfachen. Die Verwendung von Solidity als dominierender Sprache bietet eine große Community und umfangreiche Bibliotheken wie OpenZeppelin. Allerdings erfordert die Stapelarchitektur ein tiefes Verständnis der Opcode-Semantik, um ineffizienten Code zu vermeiden.
WASM-basierte Umgebungen ermöglichen die Nutzung moderner Sprachen wie Rust, die starke Typensicherheit und Speichersicherheit bieten, was die Erstellung sicherer Smart Contracts erleichtert. Allerdings ist das Tooling noch nicht so ausgereift wie im EVM-Ökosystem, und die formale Verifizierung ist weniger verbreitet.
Zukunftsperspektiven und Hybridansätze
Obwohl die EVM leistungsmäßig hinter fortschrittlicheren VMs zurückbleibt, bleibt sie aufgrund ihres Netzwerkeffekts und ihrer Sicherheit die dominierende Plattform. Zukünftige Entwicklungen zielen darauf ab, die Grenzen zu überwinden: Vorschläge wie EVM Object Format (EOF) sollen die Bytecode-Struktur verbessern, während EIP-7937 die Einführung von 64-Bit-Arithmetik-Opcodes (EVM64) vorschlägt, um die Effizienz zu steigern [111]. Langfristig wird sogar die Einführung einer RISC-V-basierten VM diskutiert, um bessere Hardware-Kompatibilität und geringere Kosten für ZK-Beweise zu ermöglichen [138].
Parallel dazu entwickeln Plattformen wie Arbitrum hybride Ansätze, die sowohl EVM- als auch WASM-Unterstützung kombinieren, um Leistungsgewinne zu erzielen, ohne die Interoperabilität aufzugeben [139]. Diese Entwicklungen deuten auf eine Zukunft hin, in der Ausführungsumgebungen zunehmend modular und spezialisierbar sind, wobei die EVM als Kompatibilitätsschicht innerhalb eines vielfältigeren Ökosystems fungiert.
Herausforderungen und Skalierbarkeit
Die Ethereum Virtual Machine (EVM) steht vor erheblichen Herausforderungen hinsichtlich Skalierbarkeit, Effizienz und langfristiger Nachhaltigkeit, die durch ihre architektonischen Entscheidungen und das Wachstum des Ökosystems verstärkt werden. Während die EVM eine robuste und sichere Ausführungsumgebung für Smart Contracts bietet, führen Faktoren wie Zustandsbloat, Gas-Ineffizienzen und die monolithische Verknüpfung von Ausführung und Konsens zu fundamentalen Engpässen. Um diese Probleme zu bewältigen, werden kontinuierlich Protokoll-Upgrades und theoretische Rahmenwerke entwickelt, die eine skalierbare und dezentrale Zukunft für Ethereum ermöglichen sollen.
Zustandsbloat und Speicherprobleme
Ein zentrales Hindernis für die Skalierbarkeit der EVM ist das sogenannte Zustandsbloat (state bloat). Dies bezeichnet das kontinuierliche Wachstum des globalen Zustands, der aus Kontoständen, Contract-Code und Speicherdaten besteht und von jedem Full Node gespeichert werden muss. Mit einem Zustand, der mittlerweile über 35 GB beträgt, steigen die Hardwareanforderungen für Validatoren kontinuierlich, was die Dezentralisierung gefährdet [140]. Da der Zustand durch jede Transaktion dauerhaft erweitert wird und nur selten durch Mechanismen wie SELFDESTRUCT reduziert wird, entsteht eine permanente Inflation des Zustands.
Um diesem Problem entgegenzuwirken, wird an Konzepten wie Zustandsablauf (state expiry) gearbeitet. Dieses System sieht vor, dass ungenutzte Zustandsdaten nach einem bestimmten Zeitraum (z. B. einem Jahr) aus dem aktiven Zustand entfernt werden. Um auf diese Daten zuzugreifen, müssen Benutzer kryptografische „Zeugen“ (witnesses) vorlegen, was die Speicherlast auf die Nutzer verlagert [121]. Ergänzend zielen Vorschläge wie EIP-8037 darauf ab, die Gas-Kosten für die Erstellung von Zustand zu erhöhen, um unnötige Datenspeicherung wirtschaftlich unattraktiv zu machen [142].
Ausführungsschicht-Kopplung und Verifikationsengpässe
Ein weiteres fundamentales Problem ist die enge Kopplung der Ausführungsschicht (execution layer coupling). Derzeit müssen alle Validatoren auf der Ethereum-Blockchain jede einzelne Transaktion erneut ausführen und den vollständigen Zustand verwalten, um die Blockgültigkeit zu überprüfen. Dies schafft einen Verifikationsengpass, der die Skalierbarkeit unabhängig von Verbesserungen in der Konsens- oder Datensicherungsebene begrenzt [143].
Die Lösung liegt in der Abstraktion der Ausführungsschicht, einem Paradigma, das die Ausführung von der Verifikation entkoppelt. Dies wird durch die Einführung von EIPs wie EIP-7701 (Native Account Abstraction) und EIP-7685 (General Purpose Execution Layer Requests) vorangetrieben. Diese Vorschläge ermöglichen es, die Validierungslogik von Konten direkt im Protokoll zu programmieren und standardisierte Ausführungsanfragen zu definieren, was zu einer flexibleren und modulareren Architektur führt [117][119]. Ziel ist es, Ethereum zu einer Plattform für standardisierte On-Chain-Berechnungen zu entwickeln, die verschiedene Ausführungsumgebungen integrieren kann [120].
Stateless Clients und Verkle Trees
Die radikalste Antwort auf Zustandsbloat und Ausführungskopplung ist das Konzept der stateless clients (zustandslosen Clients). In diesem Modell verifizieren Validatoren Blöcke, ohne den gesamten globalen Zustand lokal zu speichern. Stattdessen verlassen sie sich auf kryptografische Zeugen, die jede Transaktion begleiten und die Korrektheit von Lese- und Schreibzugriffen auf den Zustand belegen [147].
Die Umsetzung dieses Konzepts ist nur mit effizienten Datenstrukturen möglich. Hier kommen Verkle Trees ins Spiel, die im Gegensatz zu den derzeit verwendeten Merkle Patricia Trees Vektor-Commitments nutzen, um konstant große Beweise (typischerweise unter 1 KB) zu erzeugen, unabhängig von der Größe des Zustands [148]. EIP-6800 schlägt vor, den aktuellen Zustandsbaum von Ethereum durch einen einheitlichen Verkle Tree zu ersetzen, was die Grundlage für vollständige Zustandslosigkeit bildet [122]. Obwohl vollständig zustandslose Clients noch vor Herausforderungen wie der Beweisgenerierungsgeschwindigkeit stehen, zeigen Prototypen wie Ress bereits vielversprechende Ergebnisse [150].
Skalierbarkeit durch Parallelisierung und alternative VMs
Die leistungsbezogene Skalierbarkeit der EVM wird auch durch ihre stackbasierte, single-threaded Architektur eingeschränkt. Die sequenzielle Ausführung von Transaktionen begrenzt die Transaktionsgeschwindigkeit (TPS) auf etwa 15–30, was bei Spitzenlast zu Überlastung und hohen Gebühren führt. Forschung zeigt jedoch, dass etwa 64,85 % der Ethereum-Transaktionen nicht in Konflikt stehen und theoretisch parallel ausgeführt werden könnten [151].
Dies hat zu Innovationen wie parallelen EVMs geführt, die Abhängigkeitsanalysen nutzen, um unabhängige Transaktionen gleichzeitig auszuführen. Projekte wie Sei v2 und Neon EVM setzen diese Ansätze bereits um [26][153]. Im Vergleich dazu nutzen alternative Plattformen wie Solana mit Sealevel oder Polkadot mit WebAssembly (WASM) von Anfang an Architekturen, die Parallelität und höhere Leistung (bis zu 50.000 TPS bei Solana) ermöglichen [130][24]. Diese Umgebungen bieten auch Vorteile in Bezug auf Programmiersprachenflexibilität (z. B. Rust) und dynamische Gas-Messung, stehen aber vor Herausforderungen bei der Komponierbarkeit und formalen Verifizierbarkeit.
Zukunftsperspektiven: Modularität und Evolution
Die Zukunft der EVM-Skalierbarkeit liegt in einer evolutionären, modulareren Architektur. Statt eine vollständige Ablösung durch eine neue VM wie eWASM voranzutreiben, konzentriert sich die Roadmap auf inkrementelle Verbesserungen. Dies umfasst die Integration von RISC-V als Ausführungsschicht, um die Hardwarekompatibilität und die Effizienz von ZK-Beweisen zu verbessern [138], sowie die Entwicklung hybrider Modelle, die EVM-Kompatibilität mit der Leistung von WASM kombinieren, wie es Arbitrum erforscht [139]. Diese Entwicklungen deuten darauf hin, dass die EVM sich von einer monolithischen Ausführungsumgebung zu einer Kompatibilitätsschicht innerhalb eines diversifizierten und skalierbaren Ausführungsökosystems entwickeln wird [158].