Die wichtigsten virtuellen Maschinen für Blockchains: EVM, SVM, MoveVM, WebAssembly/RISC-V und CairoVM

Jeder Smart Contract muss irgendwo ausgeführt werden. Dieses „irgendwo“ ist eine virtuelle Maschine (VM) für Blockchains — das abgeschottete Programm, das jeder Node im Netzwerk identisch ausführt, sodass dieselbe Eingabe unabhängig davon, wer sie ausführt, immer dieselbe Ausgabe erzeugt. Die VM, auf der Sie aufbauen, prägt fast alles an einer Chain: in welchen Sprachen Sie schreiben können, ob Transaktionen gleichzeitig oder nur nacheinander laufen und wie viel vom bestehenden Entwicklerökosystem Sie vom ersten Tag an nutzen können.

Dieser Leitfaden führt durch fünf VM-Familien, die zusammen einen großen Teil der Smart-Contract-Aktivität im heutigen Web3 antreiben: die Ethereum Virtual Machine (EVM), Solanas SVM, die von Aptos und Sui verwendete MoveVM, VMs mit portablem Bytecode auf Basis von WebAssembly oder RISC-V wie CosmWasm und PolkaVM sowie Starknets CairoVM.

Was ist eine virtuelle Maschine für Blockchains, und warum ist sie wichtig?

Eine Blockchain-VM ist eine deterministische, abgeschottete Ausführungsumgebung: Jeder Full Node lädt dieselben Transaktionen herunter, führt sie durch dieselbe VM und erhält denselben resultierenden On-Chain-Zustand. Die Ethereum-Dokumentation beschreibt die EVM als „eine dezentrale virtuelle Umgebung, die Code konsistent und sicher über alle Ethereum-Nodes hinweg ausführt“ (ethereum.org) — eine Beschreibung, die sich auf jede VM in diesem Leitfaden übertragen lässt.

Zwei Eigenschaften bestimmen die Design-Abwägungen einer VM:

• Sprache und Toolchain. In welchen Sprachen können Entwickler Contracts schreiben, und wie groß ist die vorhandene Bibliothek aus geprüftem Code, Werkzeugen und Fachkräften, die sie bereits beherrschen?
• Ausführungsmodell. Verarbeitet die VM Transaktionen strikt einzeln (sequenziell), oder können unabhängige Transaktionen gleichzeitig auf mehreren CPU-Kernen laufen (parallele Ausführung)? Über sequenzielle Ausführung lässt sich einfacher nachdenken; parallele Ausführung steigert den theoretischen Durchsatz, erhöht aber die Planungs-Komplexität.

Diese Entscheidungen wirken sich auf Gaskosten, das Verhalten bei Überlastung und darauf aus, welche bestehenden Contracts und Tools ohne Neuschreibung portiert werden können. Deshalb ist die Frage „Welche VM?“ eine der ersten, die jede neue Chain oder jedes darauf aufgebaute tokenisierte Asset beantworten muss.

EVM (Ethereum Virtual Machine)

Die EVM wurde 2015 mit Ethereum eingeführt und gehört heute zu den am weitesten verbreiteten VMs für Smart Contracts. Sie ist eine Stack-basierte Maschine: Laut Ethereum-Dokumentation arbeitet sie als „Stack-Maschine mit einer Tiefe von 1024 Einträgen“, wobei jeder Eintrag ein 256-Bit-Wort ist (ethereum.org). Der Contract-Zustand liegt in einem Merkle-Patricia-Trie, der jedem Konto zugeordnet ist; auch der globale Chain-Zustand ist als modifizierter Merkle-Patricia-Trie organisiert, der alle Konten per Hash verknüpft (ethereum.org).

Sprache. Contracts werden fast immer in Solidity geschrieben, das Ethereums eigene Dokumentation als „objektorientierte Hochsprache für die Implementierung von Smart Contracts“ beschreibt und dessen Syntax stark von C++ beeinflusst ist (ethereum.org). Vyper, eine „Python-artige“ Sprache, die bewusst Funktionen reduziert, um Contracts leichter prüfbar zu machen, ist die wichtigste Alternative (ethereum.org).

Ausführungsmodell. Die EVM verarbeitet Transaktionen innerhalb eines Blocks sequenziell — eine nach der anderen in fester Reihenfolge. Das hält die Zustandsübergangslogik einfach und gut prüfbar, begrenzt aber den Durchsatz auf der Basisschicht.

Gas. Jede Operation kostet Gas, Ethereums Einheit für „den für Operationen erforderlichen Rechenaufwand“. Das bepreist die Ausführung und schützt das Netzwerk vor Spam oder Endlosschleifen (ethereum.org).

Besondere Stärke und Reichweite. Der eigentliche Burggraben der EVM ist ihr Ökosystem: Sie ist die in Krypto am häufigsten implementierte VM, und Dutzende Layer 2s sowie unabhängige Chains (Arbitrum, Optimism, Base, Polygon, BNB Chain, Avalanche C-Chain) liefern EVM-kompatible oder EVM-äquivalente Umgebungen aus. Dadurch lassen sich bestehende Solidity-Contracts, Wallets und Tools mit wenigen oder ganz ohne Änderungen bereitstellen.

SVM (Solana / Sealevel)

Solanas Laufzeitumgebung Sealevel beruht auf einer bestimmten Annahme: Die meisten Transaktionen berühren getrennte Teile des Zustands und können daher gleichzeitig statt einzeln ausgeführt werden. Solanas eigene Ankündigung beschreibt Sealevel als „Solanas Laufzeitumgebung für parallele Smart Contracts“, die „Tausende Contracts parallel verarbeiten kann und dabei so viele Kerne verwendet, wie dem Validator zur Verfügung stehen“ (solana.com).

Wie Parallelität funktioniert. Solana-Transaktionen müssen im Voraus jedes Konto angeben, das sie lesen oder schreiben werden. Diese Angabe ermöglicht die Planung: Die Laufzeit kann „Millionen ausstehender Transaktionen sortieren“ und „alle sich nicht überschneidenden Transaktionen parallel einplanen“, einschließlich mehrerer Transaktionen, die dasselbe Konto nur lesen (solana.com). Zwei Transaktionen werden zueinander sequenziell ausgeführt, wenn sie auf dasselbe Konto zugreifen und mindestens eine von ihnen darauf schreibt; Transaktionen, die dasselbe Konto ausschließlich lesen, können weiterhin gleichzeitig laufen.

Sprache und VM-Interna. Solana-Programme — so nennt Solana Smart Contracts — werden in eine Variante des Berkeley-Packet-Filter-Bytecodes kompiliert. Solana Labs beschreibt die On-Chain-VM als eine Wahl für „eine Variante des Berkeley Packet Filter (BPF)-Bytecodes“ (solana.com). Programme werden am häufigsten in Rust geschrieben, unterstützt werden auch C und C++.

Besondere Stärke. Weil die Parallelität auf Kontoebene eine Eigenschaft der Laufzeit ist und nicht von jedem Contract-Autor von Hand umgesetzt werden muss, kann Solana hohen Durchsatz aufrechterhalten, ohne die Ausführung Off-Chain zu verlagern. Der Preis ist ein strengeres Modell für die Kontendeklaration, das die Art verändert, wie Contracts im Vergleich zum frei gestaltbaren Speicher der EVM geschrieben werden.

MoveVM (Aptos & Sui)

Move ist eine Smart-Contract-Sprache, die ursprünglich für Metas Diem-Projekt entwickelt wurde und heute die Basisschicht für Aptos und Sui bildet, die jeweils eine eigene MoveVM-Variante betreiben. Die Dokumentation von Aptos beschreibt Move als „eine sichere Programmiersprache für Web3, die Knappheit und Zugriffskontrolle in den Mittelpunkt stellt“ (aptos.dev).

Das Ressourcenmodell. Die prägende Idee von Move ist, digitale Assets als Ressourcen zu behandeln — spezielle Struct-Typen, bei denen das Typsystem der Sprache garantiert, dass sie „nicht versehentlich dupliziert oder verworfen werden können“ (aptos.dev). Ein als Move-Ressource modellierter Token oder NFT kann nur kopiert werden, wenn sein Typ die Ability copy besitzt, und nur implizit verworfen werden, wenn er die Ability drop besitzt; ungültige Verwendungen weist der Compiler zurück. Das Modul, das den Typ definiert, kann dennoch neue Werte durch Packen erzeugen, sie durch Entpacken explizit verbrauchen und kontrollierte Mint- oder Burn-Funktionen bereitstellen (Move-Abilities in der Aptos-Dokumentation, Structs und Modulprivilegien im Move Book). Die Abilities verhindern versehentliche Kopier- und Verwerfungsfehler, beweisen jedoch weder die Korrektheit der übrigen Asset-Logik eines Contracts noch schließen sie jeden möglichen Fehler beim Doppelausgeben oder Verbrennen aus.

Parallele Ausführung. Aptos führt Move-Contracts über Block-STM aus, das laut Dokumentation „die gleichzeitige Ausführung von Transaktionen ohne Eingaben des Nutzers“ ermöglicht. Die Laufzeit leitet also während der Ausführung ab, welche Transaktionen unabhängig sind, statt die von Solana verwendeten deklarierten Kontolisten zu verlangen (aptos.dev).

Suis Objektmodell. Sui führt Moves Ressourcenidee mit einer objektzentrierten Speicherschicht weiter: „Ein Objekt ist eine grundlegende Speichereinheit im Netzwerk. Jede Ressource, jedes Asset und jedes Datenelement On-Chain ist ein Objekt“, das über eine eindeutige ID adressierbar ist, statt im Key-Value-Store eines Kontos zu liegen (Sui-Objektmodell). Das aktuelle Objektmodell von Sui kennt fünf Eigentumsformen: adressgebunden (address-owned), unveränderlich (immutable), konsensgebunden an eine Adresse (consensus-address-owned, Party), geteilt (shared) und eingebettet (wrapped). Den direkten Fast Path von Sui ohne Konsensreihenfolge kann eine Transaktion nur nutzen, wenn alle veränderlichen Objekt-Inputs adressgebunden und alle anderen Objekt-Inputs unveränderlich sind. Konsensgebundene und geteilte Objekte werden selbst dann durch den Konsens sequenziert, wenn eine Transaktion sie nur liest; nicht miteinander in Konflikt stehende reine Lesezugriffe können dennoch gleichzeitig ausgeführt werden (adressgebundene Objekte in Sui, Party-Objekte, Lutris-Paper). Unabhängige Fast-Path-Transaktionen können daher gleichzeitig verarbeitet werden, ohne jedes Objekt als global geteilten Zustand zu behandeln.

Besondere Stärke. Moves Ressourcentypen verhindern, dass generischer Code einen Wert ohne copy kopiert oder ihn ohne drop aus dem Gültigkeitsbereich fallen lässt. Das definierende Modul kann dennoch Werte erzeugen und sie durch Entpacken explizit vernichten. Diese Prüfungen beweisen daher weder die Erhaltung von Assets noch schließen sie jeden Fehler in der Asset-Logik aus. Aptos und Sui kombinieren dieses Sicherheitsmodell zudem mit paralleler Ausführung, die von Anfang an eingeplant und nicht nachträglich ergänzt wurde.

VMs mit portablem Bytecode (CosmWasm und PolkaVM)

Statt einen Blockchain-spezifischen Bytecode zu definieren, verwenden einige Chains portable, universell einsetzbare Befehlsformate. CosmWasm führt WebAssembly aus, während PolkaVM von RISC-V abgeleiteten Bytecode ausführt; PolkaVM ist daher keine WASM-basierte VM. Der WebAssembly-Standard beschreibt Wasm als „binäres Befehlsformat für eine Stack-basierte virtuelle Maschine“, das als „portables Kompilierungsziel für Programmiersprachen“ konzipiert ist und „nahezu mit nativer Geschwindigkeit“ ausgeführt werden soll (webassembly.org). Wenn Wasm die Contract-VM bildet, kann jede Sprache mit einem Wasm-Kompilierungsziel — Rust, C, C++, Go — grundsätzlich einen bereitstellbaren Contract erzeugen.

CosmWasm. Als führende Wasm-basierte Smart-Contract-Plattform im Cosmos-Ökosystem bezeichnet sich CosmWasm selbst als „sichere, leistungsfähige und interoperable Smart-Contract-Plattform für die Multi-Chain-Welt“ (cosmwasm.com). Contracts werden in Rust geschrieben und laufen auf „einer hochoptimierten Web-Assembly-Laufzeit“ (cosmwasm.com). CosmWasm ist auf Dutzenden Cosmos-SDK-Chains bereitgestellt, darunter Osmosis, Neutron, Injective, Secret Network und Terra, und übernimmt Cosmos' natives IBC-Cross-Chain-Messaging.

PolkaVM. Polkadots neuere Smart-Contract-VM geht einen anderen Weg: Statt rohes Wasm auszuführen, hat Parity PolkaVM in der eigenen Repository-Beschreibung als „allgemeine virtuelle Maschine auf Nutzerebene, die auf RISC-V basiert“ gebaut (github.com/paritytech/polkavm). Die Begründung in der ink!-Dokumentation ist Leistung: RISC-V-Ausführung „hängt mit Transaktionsdurchsatz und Transaktionskosten zusammen“ und ermöglicht eine schnellere, günstigere Ausführung als der zuvor von ink! verwendete Wasm-Interpreter (use.ink). Bemerkenswert ist, dass Polkadots PolkaVM-Stack (unter dem Namen „Revive“) auch eine EVM-Interpreterebene bereitstellt, sodass Solidity-Contracts auf demselben RISC-V-Backend laufen können.

Besondere Stärke. VMs mit portablem Bytecode ersetzen einen Blockchain-spezifischen Bytecode durch etablierte, universell einsetzbare Kompilierungsziele. Insbesondere Rust bringt starke Garantien für Speichersicherheit in Contract-Code, und sowohl Wasm als auch RISC-V profitieren von Tools, die für wesentlich größere Anwendungsfälle außerhalb der Blockchain entwickelt wurden. CosmWasm und PolkaVM bleiben dabei unterschiedliche Architekturen: Erstere führt Wasm aus, Letztere von RISC-V abgeleiteten Bytecode.

CairoVM (Starknet)

Cairo ist die speziell für die Erzeugung von Zero-Knowledge-Proofs entwickelte Smart-Contract-Sprache und VM, die Starknet, ein Ethereum-Layer 2, zugrunde liegt. Starknets Dokumentation formuliert das Designziel ausdrücklich: „Cairo ist eine STARK-freundliche Von-Neumann-Architektur, die Gültigkeitsbeweise für beliebige Berechnungen erzeugen kann“ (starknet.io). „STARK-freundlich“ bedeutet, dass der Befehlssatz „für das STARK-Beweissystem optimiert ist und zugleich mit anderen Backends für Beweissysteme kompatibel bleibt“ (starknet.io). Das ist die entgegengesetzte Priorität zur EVM oder SVM, die zunächst für Ausführung entworfen und erst später für Skalierung mit Beweissystemen ergänzt wurden.

Ausführungsmodell. Cairo kompiliert zu einem Turing-vollständigen Befehlssatz (der „Cairo-Maschine“), der als Satz algebraischer Zwischendarstellungen spezifiziert ist. Dadurch lässt sich die Ausführungsspur jedes Cairo-Programms in einen kompakten, auf Ethereum L1 überprüfbaren STARK-Proof umwandeln (starknet.io). So kann Starknet Tausende Transaktionen Off-Chain bündeln und einen kompakten Korrektheitsbeweis zurück auf Ethereum posten, statt jede Transaktion erneut auszuführen.

Besondere Stärke. Beweisfreundlichkeit war Cairos grundlegende Designvorgabe: Befehlssatz und Ausführungsspur sind auf effiziente STARK-Beweise ausgelegt. Die tatsächlichen Beweiskosten hängen jedoch vom Programm, der Prover-Implementierung, den Parametern des Beweissystems und dem Vergleichsmaßstab ab; sie liegen daher nicht bei jeder zkEVM-Arbeitslast zwangsläufig niedriger. Der Nachteil ist ein neueres, kleineres Sprachökosystem und für Entwickler aus Ethereum eine steilere Lernkurve als bei Solidity.

Vergleichstabelle

Verbindung zu tokenisierten Domains

Welche VM eine Chain ausführt, ist für die Infrastruktur tokenisierter Domains unmittelbar relevant. Eine als NFT dargestellte Domain ist im Kern ein Smart Contract, der durchsetzt, wem ein Token gehört und was damit geschehen darf. Diese Logik profitiert von Moves Compile-Zeit-Beschränkungen für das Kopieren von Ressourcen und ihr implizites Verwerfen; mit dem ausgereiften Tooling der EVM lässt sie sich zugleich einfach prüfen und in bestehende Wallets und Marktplätze integrieren. Namefis Tokenisierungsmodell zielt bewusst auf das EVM-Ökosystem: EVM-Kompatibilität bedeutet, dass das Eigentums-NFT einer tokenisierten .com- oder .ai-Domain direkt mit dem bestehenden Universum aus EVM-Wallets, Marktplätzen und DeFi-Protokollen funktioniert, statt für jede neue VM eine individuelle Integration zu benötigen. Entdecken Sie tokenisierte Domains auf namefi.io.

Quellen und weiterführende Lektüre

• Die Ethereum Virtual Machine (EVM) — ethereum.org
• Smart-Contract-Sprachen — ethereum.org
• Sealevel — parallele Verarbeitung Tausender Smart Contracts — Solana
• Move — Aptos-Dokumentation
• Move-Abilities — Aptos-Dokumentation
• Structs und Enums — Move Book
• Objektmodell — Sui-Dokumentation
• Adressgebundene Objekte — Sui-Dokumentation
• Party-Objekte — Sui-Dokumentation
• Sui Lutris
• CosmWasm
• PolkaVM — GitHub (paritytech)
• Warum RISC-V und PolkaVM für Smart Contracts — ink!-Dokumentation
• Cairo-Architektur — Die Programmiersprache Cairo / Starknet
• WebAssembly