Was ist die EVM?

Die Ethereum Virtual Machine (EVM), die virtuelle Maschine von Ethereum, ist ein Satz gemeinsamer Regeln zur Ausführung von Smart Contracts. Ethereum-Nodes setzen diese Regeln in ihrer eigenen Software um, rechnen über dieselben Transaktionen und denselben Ausgangszustand und erhalten so ein Ergebnis, das andere Nodes nachprüfen können.

Die EVM ist kein bestimmter physischer Server und auch nicht die einzelne Anwendung, die Entwickelnde auf ihrem Rechner sehen. Sie gleicht eher einer genauen Rechenanleitung: welche Grundoperationen Code ausführen darf, wo Daten liegen, wie viele Rechenressourcen jede Operation verbraucht und wie der Blockchain-Zustand bei erfolgreicher oder fehlgeschlagener Ausführung aktualisiert wird.

Vom Quellcode zum ausführbaren Bytecode

Entwickelnde schreiben Contracts üblicherweise in einer Hochsprache wie Solidity. Der für Menschen lesbare Quellcode muss von einem Compiler in Bytecode umgewandelt werden, den die EVM ausführen kann — eine Folge von Maschinenanweisungen in festem Format.

Beim Bereitstellen eines Contracts enthält die erzeugende Transaktion den Code, aus dem der Contract entsteht. Nach erfolgreicher Ausführung richtet das Netzwerk eine Adresse für den Contract ein und bewahrt den Bytecode, der bei späteren Aufrufen laufen soll. Der Ausführungscode eines bereitgestellten Contracts ist nicht dieselbe Darstellung wie die Quelldateien der Entwickelnden; veröffentlichter Quellcode muss daher noch mit dem Onchain-Bytecode abgeglichen werden, bevor man sagen kann, dass beide einander entsprechen.

Compilerversion und -einstellungen können den endgültigen Bytecode beeinflussen. Zwei ähnlich aussehende Quelldateien können unterschiedliche Ergebnisse erzeugen; denselben Contract-Namen zu sehen ersetzt die Prüfung von Netzwerk und Contract-Adresse noch weniger.

Der Aufruf liefert dem Contract seine Ausführungseingabe

Ruft eine Nutzerin oder ein Nutzer einen Contract auf, wird an die Contract-Adresse eine Transaktion mit Daten gesendet. Diese Daten geben üblicherweise an, welche Funktion aufzurufen ist, und führen die Parameter in einem vereinbarten Format mit. Ein Contract kann während der Ausführung auch einen anderen Contract aufrufen und Werte oder Daten weitergeben.

Die EVM setzt am aktuellen Blockchain-Zustand an, liest die aufrufende Seite, das Ziel, einen etwaigen mitgeführten Wert, die Eingabedaten und die Informationen, deren Nutzung der aktuelle Block zulässt, und führt dann den Bytecode des Zielcontracts Anweisung für Anweisung aus. Jede Anweisung verändert regelkonform die temporären Daten dieser Berechnung oder verlangt das Lesen oder Schreiben des persistenten Zustands des Contracts.

Ein Contract startet nicht von selbst, nur weil ein Zeitpunkt erreicht ist. Es muss eine Transaktion oder der Aufruf eines anderen Contracts einen Ausführungseinstieg bilden; eine auf einer Webseite angezeigte „automatische Ausführung“ erfordert üblicherweise weiterhin, dass ein externer Dienst bei erfüllten Bedingungen eine Transaktion einreicht.

Opcodes sind die Grundaktionen im Bytecode

EVM-Bytecode besteht aus einzelnen Opcodes. Ein Opcode lässt sich als kleinste Aktion verstehen, die die virtuelle Maschine kennt: etwa Rechnen, Werte vergleichen, Aufrufdaten lesen, Speicher lesen oder schreiben und andere Contracts aufrufen.

Verschiedene Opcodes haben festgelegte Regeln für Eingabe, Ausgabe und Gasverbrauch. Ein Node muss die fachlichen Bezeichnungen eines Contracts nicht verstehen; in Opcode-Reihenfolge auszuführen genügt, um zu prüfen, ob das von einem anderen Node gelieferte Ergebnis dem Protokoll entspricht.

Eine einzelne Zeile einer Hochsprache kann in mehrere Opcodes übersetzt werden. Umgekehrt lässt sich aus einem einzelnen Opcode keine vollständige fachliche Absicht erkennen; die Prüfung eines Contracts bedeutet daher üblicherweise, Quellcode, Compilereinstellungen, Aufrufdaten und die tatsächliche Bereitstellungsadresse zusammenzunehmen.

Temporäre Daten und persistenter Zustand

Nicht alle während der Ausführung genutzten Daten werden dauerhaft in die Blockchain geschrieben. Sinnvoll ist es, zunächst drei Orte zu unterscheiden:

• Aufrufdaten sind die von diesem Aufruf mitgebrachte Eingabe, die nur gelesen wird;
• der Arbeitsspeicher ist ein während dieser Ausführung genutzter temporärer Arbeitsbereich und bleibt danach nicht erhalten;
• der Speicher gehört einem konkreten Contract und wird nach erfolgreichem Schreiben Teil des Blockchain-Zustands, den spätere Aufrufe lesen können.

Die EVM nutzt außerdem eine temporäre Rechenstruktur nach dem Prinzip zuletzt hinein, zuerst hinaus, genannt Stack. Opcodes nehmen Werte von der Spitze des Stacks und legen das Ergebnis nach der Berechnung zurück. Wer nicht fachlich liest, muss nicht jeden Schritt von Hand verfolgen, sollte aber wissen, dass „eine Änderung im Arbeitsspeicher“ und „der Speicher des Contracts hat sich geändert“ nicht dasselbe sind.

In den persistenten Speicher zu schreiben verbraucht üblicherweise mehr Gas als eine bloß temporäre Berechnung. Speicher zu löschen oder zu ändern ist ebenfalls an Protokollregeln gebunden: Der Onchain-Zustand ist keine lokale Datei, die ein gewöhnliches Programm beliebig überschreiben darf.

Zustandsänderungen müssen nachrechenbar sein

Transaktionen desselben Blocks haben eine festgelegte Reihenfolge. Vom selben Zustand vor dem Block aus und bei Ausführung derselben Transaktionen in Reihenfolge sollten Nodes denselben Zustand nach dem Block erhalten; sonst können sie sich nicht auf ein gemeinsames Journal verständigen.

Ein EVM-Contract kann daher bei der Ausführung nicht unmittelbar auf beliebige Webseiten, die Zeit eines Geräts oder das Zufallsergebnis eines Servers zugreifen. Werden ein Offchain-Preis, Wetterdaten oder andere Informationen benötigt, muss eine externe Partei diese Daten zuerst in Form einer Transaktion auf die Blockchain bringen. Die EVM kann prüfen, wie der Code diese Eingabe verwendet, aber nicht automatisch belegen, dass die zugehörige Offchain-Tatsache wahr ist.

Auch die von einem Block bereitgestellten Angaben wie Zeit und Blocknummer stammen aus der vom Protokoll festgelegten Ausführungsumgebung. Entwickelnde dürfen sie regelkonform lesen, sollten die Werte aber nicht für eine präzise externe Uhr oder eine geheime Zufallsquelle halten, die vom Blockvorschlagsprozess unbeeinflusst wäre.

Gas begrenzt den Arbeitsaufwand jeder Ausführung

Jede EVM-Operation verbraucht eine bestimmte Menge Gas. Gas ist eine Maßeinheit für Rechen- und Speicherarbeit, kein eigenständiger Token; im Ethereum-Mainnet werden die tatsächlichen Ausführungsgebühren üblicherweise mit dem nativen Asset des Netzwerks, ETH, bezahlt.

Die sendende Seite einer Transaktion legt fest, wie viel Gas diese Transaktion höchstens verbrauchen darf. Bei der Ausführung summiert die EVM das Gas nach den tatsächlich ausgeführten Operationen; reicht das verbleibende Gas nicht für den nächsten Schritt, scheitert die Ausführung durch Gasmangel.

Gas verhindert, dass Endlosschleifen oder ungewöhnlich komplexe Aufrufe die Rechenressourcen aller Nodes kostenlos belegen. Es bedeutet auch, dass dieselbe Funktion je nach Eingabe, aktuellem Zustand und Ausführungspfad unterschiedlich viel verbrauchen kann. Eine Transaktion mit hohem Betrag führt nicht zwangsläufig mehr Code aus als eine mit geringem Betrag.

Erfolg, Rücknahme und Fehlschlag

Ein Contract kann regulär enden und Daten zurückgeben, kann sich bewusst zurücknehmen oder wegen einer ungültigen Operation, Gasmangels oder aus anderem Grund fehlschlagen. Beim Fehlschlag werden die auf diesem Aufrufpfad noch nicht festgeschriebenen Zustandsänderungen regelkonform zurückgenommen, doch die von der Transaktion bereits verbrauchten Rechenressourcen können dennoch Gebühren verursachen.

Eine Transaktion kann mehrere Ebenen von Contract-Aufrufen auslösen. Scheitert ein innerer Aufruf, kann der äußere Contract gemäß seinem Code das zurückgegebene Ergebnis weiterverarbeiten oder die gesamte Transaktion zurücknehmen lassen. „Ein interner Schritt ist fehlgeschlagen“ und „die ganze Transaktion ist letztlich fehlgeschlagen“ sind daher gemeinsam mit den Aufrufergebnissen zu beurteilen.

Eine Zustandsrücknahme hebt auch nicht die Tatsache auf, dass eine Transaktion in einen Block aufgenommen wurde. Ein Block-Explorer kann eine fehlgeschlagene Transaktion und das verbrauchte Gas anzeigen; lediglich die erwarteten Zustandsänderungen des Contracts sind nicht wirksam geworden.

Ergebnisse lesen und Transaktionen einreichen

Eine Wallet oder Anwendung kann einen Node eine Nur-Lese-Anfrage lokal simulieren lassen und das Ergebnis unmittelbar zurückgeben. Eine solche Lesung erreicht keinen neuen Konsens im gesamten Netzwerk und verändert den Onchain-Zustand nicht; sie erfordert üblicherweise keine Signatur und keine Onchain-Gebühr der Nutzenden.

Ein Vorgang, der den Zustand ändern soll, muss dagegen eine Transaktion bilden, von einem Konto signiert und verbreitet werden und nach Aufnahme in einen Block gemeinsam von den Nodes ausgeführt werden. Eine Simulation vor dem Einreichen kann helfen, offensichtliche Fehlschläge zu erkennen, doch das Endergebnis kann weiterhin von Transaktionsreihenfolge, Zustandsänderungen, Gas-Einstellungen und gewähltem Netzwerk beeinflusst werden.

Zeigt eine Anwendungsoberfläche „voraussichtlich erfolgreich“, ist eine Transaktion deshalb nicht bereits bestätigt. Das tatsächliche Onchain-Ergebnis erfordert, im richtigen Netzwerk Transaktionsstatus, Ausführungsergebnis und Contract-Zustand einzusehen.

Die EVM und Ethereum sind nicht derselbe Begriff

Die EVM beschreibt nur einen Teil der Regeln für Smart-Contract-Ausführung und Zustandsübergang. Ethereum umfasst außerdem Konto- und Transaktionsformate, Blockverbreitung, Proof-of-Stake-Konsens, Netzwerkkommunikation und weitere Protokollbestandteile.

Andere Blockchains können die EVM oder eine ihr sehr ähnliche Ausführungsumgebung ebenfalls umsetzen, um Contract-Werkzeuge und Bytecode weiterzuverwenden. Sie werden üblicherweise EVM-kompatible Netzwerke genannt, besitzen aber weiterhin eigene Blockhistorie, eigene Validierungsvorkehrungen, ein eigenes Gebühren-Asset und eine eigene Sicherheitsgrenze.

„EVM-Contracts ausführen zu können“ zeigt daher nicht, dass es sich um Ethereum handelt, und garantiert nicht, dass unter derselben Adresse in verschiedenen Netzwerken derselbe Code bereitgestellt ist. Bei netzwerkübergreifender Nutzung einer Anwendung sind weiterhin das Netzwerk und seine Netzwerknummer, die Contract-Adresse und der tatsächliche Bytecode zu prüfen.

Gemeinsame Ausführung bedeutet nicht, dass ein Contract sicher ist

Die deterministischen Regeln der EVM erlauben Nodes nachzuprüfen, ob ein Contract gemäß seinem Code ausgeführt wurde, nicht aber zu beurteilen, ob dieser Code dem fachlichen Ergebnis entspricht, das Nutzende wirklich wollten. Fehlerhafte Rechte, ein externer Contract, der vor Abschluss eines vorherigen Vorgangs wiederholt zurückruft, Probleme bei Preiseingaben, Upgrade-Kontrolle oder eine irreführende Oberfläche können jeweils dazu führen, dass eine vollständig regelkonforme EVM-Transaktion eine unbeabsichtigte Folge hat.

Erfolgreiche Kompilierung, erfolgreiche Onchain-Ausführung oder veröffentlichter Quellcode können ebenso jeweils keine Sicherheitsprüfung ersetzen. Die Beurteilung eines konkreten Contracts erfordert, bereitgestellten Bytecode, Initialisierungszustand, Verwaltungsrechte, externe Abhängigkeiten und den realen Aufrufpfad zusammenzunehmen.

Häufig gestellte Fragen

Ist die EVM ein Cloud-Server?

Nein. Sie ist ein Satz von Ausführungsregeln, den die Node-Software gemeinsam umsetzt, und entspricht keiner bestimmten festen Maschine.

Wird Solidity-Code unmittelbar von der EVM ausgeführt?

Üblicherweise nicht. Solidity-Quellcode wird zuerst von einem Compiler in EVM-Bytecode umgewandelt; Nodes führen den bereitgestellten Bytecode aus.

Erfordert das Lesen eines Contracts immer eine Gas-Gebühr?

Eine lokale Nur-Lese-Anfrage bildet üblicherweise keine Onchain-Transaktion und verursacht daher unmittelbar keine Onchain-Gebühr. Ist eine Lesung Teil der Ausführung einer anderen Onchain-Transaktion, zählen die zugehörigen Operationen weiterhin zum Gas dieser Transaktion.

Kann die EVM Daten aus dem Internet unmittelbar lesen?

Nein. Externe Daten müssen von einer Partei oder einem Dienst per Transaktion auf die Blockchain gebracht werden; die EVM kann nur bereits bereitgestellte Eingaben regelkonform verarbeiten.

Bedeutet EVM-Kompatibilität, dass ein Contract ohne Änderung übertragbar ist?

Das ist nicht gesichert. Kompatibilitätsgrad, Protokollversion, verfügbare Opcodes, Gebührenregeln, Systemcontracts und externe Abhängigkeiten können abweichen; Prüfung und Tests im Zielnetzwerk bleiben nötig.

Verwandte Begriffe

Lies weiter über Ethereum, Smart Contract, Gas-Gebühr und Blockchain, oder kehre zum Krypto-Glossar zurück.

Quellen

• Ethereum.org: Ethereum Virtual Machine — EVM, Zustandsübergänge, Ausführungsumgebung, Stack, Arbeitsspeicher und Speicher.
• Ethereum.org: Aufbau eines Smart Contracts — Quellcode, Kompilierung, bereitgestellter Code und Struktur von Contract-Aufrufen.
• Ethereum.org: EVM-Opcodes — Opcodes, Parameter und Gasregeln.
• Ethereum.org: Gas und Gebühren — Gasmessung, Gas-Obergrenze, Ausführungsgebühren und die Folge von Gasmangel.