Ethereums RISC-V-Gambit: Warum Vitalik die EVM ersetzen will und was das für jeden dApp-Entwickler bedeutet

Was wäre, wenn der Motor, der Smart Contracts im Wert von 600 Milliarden $ antreibt, Ethereum um Größenordnungen ausbremsen würde? Das ist die provokante These, die Vitalik Buterin im April 2025 aufstellte — und im März 2026 bekräftigte —, als er vorschlug, die Ethereum Virtual Machine (EVM) schrittweise durch RISC-V zu ersetzen, eine quelloffene CPU-Befehlssatzarchitektur. Dieser Schritt könnte 100-fache Effizienzgewinne bei der Zero-Knowledge-Beweisführung freisetzen, droht aber auch die Entwicklererfahrung neu zu gestalten, einen Architekturkrieg mit WebAssembly-Befürwortern zu entfachen und das gesamte Ethereum-Ökosystem dazu zu zwingen, neu zu überdenken, wie eine Virtual Machine für Blockchains aussehen sollte.

Die versteckte Steuer der EVM

Die EVM war im Jahr 2015 revolutionär. Als 256-Bit-Stack-Maschine für vertrauensloses Rechnen konzipiert, brachte sie ein Ökosystem von über 4.000 dezentralen Anwendungen hervor und machte den Begriff „Smart Contract“ weltweit bekannt. Doch ein Jahrzehnt im produktiven Einsatz hat strukturelle Einschränkungen offengelegt, die durch keine noch so große schrittweise Optimierung behoben werden können.

Das Kernproblem ist der Overhead. Die EVM läuft als Software-Interpreter auf modernen 64-Bit-CPUs und übersetzt jeden Opcode durch eine Abstraktionsschicht, die nie für reine Performance ausgelegt war. Für gewöhnliche Transaktionsausführungen ist dieser Overhead handhabbar. Für die Generierung von Zero-Knowledge-Beweisen — die Technologie, von der Ethereums Roadmap zunehmend abhängt — ist er verheerend.

Heutige ZK-Prover arbeiten bereits so, dass sie EVM-Bytecode intern in RISC-V übersetzen, bevor sie Beweise generieren. Diese doppelte Übersetzung führt zu dem, was Buterin als einen „800-fachen Overhead“ bei den zkVM-Beweiszeiten beschreibt. Der State-Tree und die VM zusammen machen mehr als 80 % des Flaschenhalses bei der effizienten Beweiserstellung aus. Das bedeutet, dass egal wie schnell Prover werden, die EVM selbst die Obergrenze bleibt.

Auftritt RISC-V: Die 100-fache Chance

RISC-V ist eine Open-Source-Befehlssatzarchitektur (ISA), die aus zwei Jahrzehnten CPU-Forschung an der UC Berkeley hervorgegangen ist. Im Gegensatz zu proprietären Architekturen von ARM oder Intel ist RISC-V modular, erweiterbar und lizenzfrei. Ihr registerbasiertes Design lässt sich sauber auf moderne Hardware übertragen, und ihre Einfachheit — ein minimaler RISC-V-Interpreter kann in wenigen hundert Zeilen Code geschrieben werden — macht sie ideal für die formale Verifizierung.

Das Argument für die Performance ist überzeugend. Durch die native Ausführung von Smart Contracts in RISC-V anstelle der Interpretation von EVM-Bytecode könnte Ethereum:

• Den Nachteil der doppelten Übersetzung eliminieren: ZK-Prover müssten EVM nicht mehr in RISC-V konvertieren, bevor sie Beweise generieren, was den Beweis-Overhead potenziell um das 50- bis 100-fache reduzieren könnte.
• Das Protokoll vereinfachen: Systemoperationen wie SLOAD und CALL würden zu Syscalls anstatt zu benutzerdefinierten Opcodes werden, was die Angriffsfläche und den Wartungsaufwand verringert.
• Bestehende Tooling-Infrastruktur nutzen: RISC-V verfügt bereits über ausgereifte GCC- und LLVM-Compiler, QEMU-Emulatoren und formal verifizierte Toolchains — ein Unterstützungs-Ökosystem, das die EVM niemals erreichen kann.
• Anpassung an das ZK-Ökosystem: Wichtige zkVMs, darunter SP1 von Succinct, RISC Zero, Jolt von a16z, OpenVM von Axiom und Miden von Polygon, basieren alle auf RISC-V, was einen natürlichen Konvergenzpunkt schafft.

Die Zahlen aus Produktionssystemen bestätigen dies. Der SP1 Hypercube von Succinct kann Zero-Knowledge-Beweise für Ethereum-Blöcke in weniger als 12 Sekunden auf 16 NVIDIA RTX 5090-GPUs generieren. Die R0VM 2.0 von RISC Zero verkürzte die Beweiszeiten von 35 Minuten auf 44 Sekunden. Diese Gewinne wurden erzielt, während man noch über die EVM-Übersetzungsschicht arbeitete — eine native RISC-V-Ausführung würde diese noch weiter verstärken.

Der Drei-Phasen-Migrationsplan

Buterins Vorschlag ist kein leichtfertiges Umschreiben. Es handelt sich um eine sorgfältig gestaffelte Migration, die darauf ausgelegt ist, die Abwärtskompatibilität durchgehend aufrechtzuerhalten:

Phase 1 — Ersatz von Precompiles: RISC-V-Code ersetzt etwa 80 % der bestehenden vorkompilierten Verträge (Precompiles) von Ethereum. Dies sind die kryptografischen und arithmetischen Operationen (wie Elliptic-Curve-Pairings und SHA-256-Hashing), die derzeit als fest kodierte native Funktionen existieren. Durch die Implementierung in RISC-V wird das Protokoll auditierbarer und erweiterbarer, ohne die Performance zu opfern.

Phase 2 — Dual-VM-Bereitstellung: Entwickler erhalten die Möglichkeit, Smart Contracts, die in RISC-V-Bytecode kompiliert wurden, neben bestehenden EVM-Verträgen bereitzustellen. Solidity- und Vyper-Code würden in RISC-V anstatt in EVM-Bytecode kompiliert — die Entwicklererfahrung bleibt vertraut, aber die Ausführungsschicht darunter ändert sich.

Phase 3 — Außerbetriebnahme der EVM: Die EVM selbst wird zu einem in RISC-V geschriebenen Smart Contract. Jeder bestehende EVM-Vertrag läuft weiterhin genau wie zuvor, ausgeführt durch diesen „EVM-in-RISC-V“-Interpreter. Die einzige für Benutzer sichtbare Änderung wären Verschiebungen bei den Gas-Kosten, da die neue Architektur die Operationen neu bewertet.

Diese letzte Phase ist der eleganteste Teil des Vorschlags. Anstatt die Abwärtskompatibilität zu brechen, bleibt sie vollständig erhalten — die EVM verschwindet nicht; sie wird zu einer Bibliothek, die auf einem effizienteren Fundament läuft.

Der Begleiter zu EIP-7864: Binäre Zustandsbäume

Im März 2026 erweiterte Buterin den Vorschlag um EIP-7864, das die andere Hälfte des Flaschenhalses bei der Beweiserstellung adressiert: Ethereums Zustandsbaum (State Tree). Der aktuelle hexäre Keccak Merkle Patricia Tree würde durch einen binären Baum ersetzt, der eine effizientere Hash-Funktion verwendet – entweder Blake3 oder eine Poseidon-Variante.

Die Auswirkungen sind erheblich:

• Merkle-Zweige werden viermal kürzer, was die Datenbandbreite für Light-Clients wie Helios drastisch reduziert
• Die Substitution der Hash-Funktion liefert eine zusätzliche 3- bis 100-fache Verbesserung der Effizienz bei der Beweiserstellung
• In Kombination mit der VM-Änderung zielen die beiden Upgrades auf die über 80 % der Beweiskosten ab, die derzeit die Skalierung von Ethereum einschränken

Buterins Sequenzierung ist bewusst gewählt: zuerst binäre Bäume (potenziell in den Upgrades Glamsterdam oder Hegota im Jahr 2026), gefolgt vom Austausch der VM, sobald die Infrastruktur für die Beweiserstellung ausgereift ist.

Das WASM-Gegenargument

Nicht jeder ist davon überzeugt, dass RISC-V die richtige Antwort ist. Im November 2025 veröffentlichten Forscher von Offchain Labs – dem Team hinter Arbitrum – eine detaillierte technische Widerlegung, in der sie argumentierten, dass WebAssembly (WASM) die bessere langfristige Wahl sei.

Ihr Kernargument stützt sich auf eine wichtige Unterscheidung: Die „Delivery ISA“ (das Format, in dem Verträge gespeichert und verteilt werden) und die „Proof ISA“ (das für die ZK-Beweisführung verwendete Format) müssen nicht identisch sein. Offchain Labs demonstriert dies bereits in der Praxis – Arbitrum-Blöcke, einschließlich WASM-basierter Stylus Smart Contracts, werden mittels ZK bewiesen, indem WASM zum Zeitpunkt der Beweiserstellung in RISC-V kompiliert wird.

Das WASM-Lager äußert mehrere Bedenken:

• Hardwarekompatibilität: Den meisten Ethereum-Nodes fehlen RISC-V-CPUs, was eine Emulation erforderlich machen würde, während WASM nativ in Milliarden von Ausführungsumgebungen läuft.
• Ökosystem-Lock-in: Die Verankerung von RISC-V auf L1 könnte Ethereum an eine spezifische Beweistechnologie binden, gerade wenn bessere Alternativen entstehen.
• Ausgereiftheit der Tools: Das Tooling-Ökosystem von WASM ist in Webbrowsern, Cloud-Infrastrukturen und Edge-Computing praxiserprobt.
• Aufkommende Alternativen: WASM-basierte ZK-VMs wie Ligetron von Ligero zeigen bereits Vorteile, mit denen hardwarefokussierte ISAs möglicherweise nicht mithalten können.

Die Debatte ist noch lange nicht entschieden. Beide Seiten sind sich einig, dass sich die EVM weiterentwickeln muss; sie sind sich uneinig darüber, ob das Ausführungsformat für die Beweiserstellung (RISC-V) oder für die Flexibilität bei der Bereitstellung (WASM) optimiert werden sollte.

Polkadots parallele Wette

Ethereum ist nicht die einzige Blockchain, die auf RISC-V setzt. Polkadots JAM-Protokoll, das sich seiner Spezifikation 1.0 nähert, verwendet PolkaVM – einen auf RISC-V basierenden Ahead-of-Time-Recompiler – als Ausführungs-Engine. Das JAM-Mainnet-Upgrade ist für das erste Quartal 2026 geplant, wobei die Blockgeschwindigkeiten um das Zehnfache auf 500-Millisekunden-Blöcke steigen sollen.

Das Revive-Projekt von Polkadot kombiniert das RISC-V PolkaVM-Backend mit einem voll kompatiblen EVM-Interpreter, sodass Entwickler zwischen Ethereum-Kompatibilität und maximaler Polkadot-Performance wählen können. Dieser Dual-Mode-Ansatz spiegelt die Übergangsphase wider, die Buterin für Ethereums Phase 2 vorsieht.

Die Konvergenz ist bemerkenswert: Zwei der größten Blockchain-Ökosysteme sind unabhängig voneinander zu dem Schluss gekommen, dass RISC-V den besten Weg für eine hochperformante Ausführung von Smart Contracts bietet.

Was sich für Entwickler ändert

Für den durchschnittlichen Solidity-Entwickler sind die unmittelbaren Auswirkungen überraschend gering. In der RISC-V-Zukunft gilt:

• Solidity und Vyper überleben: Entwickler schreiben weiterhin in vertrauten Sprachen. Das Compiler-Backend ändert sich von EVM-Bytecode zu RISC-V-Bytecode, aber der Quellcode und der Entwicklungsworkflow bleiben weitgehend gleich.
• Neue Sprachoptionen entstehen: Rust – die Sprache, die bereits in der Solana-, Polkadot- und NEAR-Entwicklung dominiert – wird zu einem erstklassigen Bürger für Ethereum Smart Contracts. Dies könnte Entwickler aus konkurrierenden Ökosystemen anziehen.
• Gaskosten verschieben sich: Operationen werden neu bewertet, um die RISC-V-Ausführungskosten anstelle der EVM-Opcode-Kosten widerzuspiegeln. Einige Operationen werden billiger, andere könnten teurer werden.
• Anpassung von Tests und Tools: Frameworks wie Hardhat und Foundry benötigen RISC-V-Kompilierungsziele, obwohl die bestehende LLVM-Infrastruktur dies einfacher macht als den Aufbau von EVM-Tooling von Grund auf.

Die größere Änderung ist philosophischer Natur. Ethereums Ausführungsschicht bewegt sich von einer maßgeschneiderten, Blockchain-spezifischen virtuellen Maschine hin zu einer Allzweck-Rechenarchitektur, die auf jahrzehntelanger akademischer Forschung und industriellen Tools basiert. Dies ist nicht nur ein Performance-Upgrade – es ist die Wette darauf, dass Blockchains mit dem Mainstream-Computing konvergieren sollten, anstatt eine separate Infrastruktur beizubehalten.

Der Weg in die Zukunft

Der RISC-V-Vorschlag hat innerhalb der Ethereum-Entwicklergemeinschaft noch keinen Konsens gefunden. Die für 2026 erwarteten Upgrades Glamsterdam und Hegota werden wahrscheinlich den Zustandsbaum-Änderungen aus EIP-7864 Vorrang einräumen, während der Austausch der VM ein längerfristiges Ziel bleibt.

Aber die Richtung ist klar. Das ZK-Beweis-Ökosystem hat sich bereits auf RISC-V standardisiert. Die Leistungsdaten sind eindeutig. Und das Design zur Abwärtskompatibilität bedeutet, dass Ethereum diesen Übergang vollziehen kann, ohne einen einzigen bestehenden Vertrag zu zerstören.

Die eigentliche Frage ist nicht, ob Ethereum sich irgendwann über die EVM hinausentwickeln wird, sondern wie schnell sich die Community auf den Ersatz einigen kann – und ob RISC-V oder WASM diese Debatte gewinnt. Für Entwickler, die heute auf Ethereum bauen, ist die Botschaft beruhigend: Ihre Solidity-Verträge werden in jedem Fall weiterlaufen. Doch die klügsten Entwickler bereiten sich bereits auf eine Welt vor, in der Ethereum nativ RISC-V spricht und die damit verbundene 100-fache Effizienz bei der Beweiserstellung nutzt.

BlockEden.xyz bietet RPC- und API-Infrastruktur der Enterprise-Klasse für Ethereum und führende Layer-2-Netzwerke. Während sich die Ausführungsschicht weiterentwickelt, passt sich unsere Infrastruktur an – so stellen wir sicher, dass Entwickler am Puls der Zeit bauen können, ohne die zugrunde liegende Komplexität verwalten zu müssen. Entdecken Sie unsere Ethereum-API-Dienste, um Ihre dApp-Infrastruktur zukunftssicher zu machen.