Ethereum steht vor dem größten Upgrade seiner Geschichte: EVM wird außer Betrieb genommen, RISC-V übernimmt

Originaltitel: Goodbye EVM, Hello RISC-V

Originalautor: jaehaerys.eth, Krypto-Researcher

Originalübersetzung: TechFlow

Zusammenfassung

Ethereum bereitet sich auf die wichtigste architektonische Transformation seit seiner Gründung vor: den Austausch der EVM durch RISC-V.

Der Grund ist einfach – in einer Zukunft, in der Zero-Knowledge (ZK) im Mittelpunkt steht, ist die EVM zum Leistungsengpass geworden:

· Aktuelle zkEVMs sind auf Interpreter angewiesen, was zu einer 50–800-fachen Verlangsamung führt;

· Vorgefertigte Module machen das Protokoll komplexer und erhöhen das Risiko;

· Das 256-Bit-Stack-Design ist bei der Beweiserstellung äußerst ineffizient.

Die Lösung von RISC-V:

· Minimalistisches Design (ca. 47 Basisbefehle) + ausgereiftes LLVM-Ökosystem (unterstützt Rust, C++, Go usw.);

· Ist de facto zum zkVM-Standard geworden (90% der Projekte nutzen es);

· Verfügt über eine formale SAIL-Spezifikation (im Vergleich zum vagen Yellow Paper) → ermöglicht strenge Verifikation;

· Hardware-Beweispfade (ASICs/FPGAs) werden bereits getestet (SP1, Nervos, Cartesi usw.).

Der Migrationsprozess ist in drei Phasen unterteilt:

· Ersatz von RISC-V als vorgefertigtes Modul (risikoarmes Testen);

· Ära der Doppel-VM: EVM und RISC-V koexistieren und sind vollständig interoperabel;

· Reimplementierung der EVM innerhalb von RISC-V (Rosetta-Strategie).

Auswirkungen auf das Ökosystem:

· Optimistische Rollups (wie Arbitrum und Optimism) müssen den Fraud-Proof-Mechanismus neu aufbauen;

· Zero-Knowledge-Rollups (wie Polygon, zkSync, Scroll) werden enorme Vorteile erhalten → günstiger, schneller, einfacher;

· Entwickler können direkt auf Layer 1 Bibliotheken in Rust, Go und Python nutzen;

· Nutzer profitieren von etwa 100-fach niedrigeren Beweiskosten → auf dem Weg zu Gigagas L1 (ca. 10.000 TPS).

Schließlich wird sich Ethereum von einer „Smart Contract Virtual Machine“ zu einer minimalistischen, verifizierbaren Vertrauensebene des Internets weiterentwickeln, mit dem ultimativen Ziel, „alles mit ZK-Snarks zu versehen“.

Der Scheideweg von Ethereum

Vitalik Buterin sagte einst: „Das Ziel ist ... alles mit ZK-Snarks zu versehen.“

Das Endspiel der Zero-Knowledge-Proofs (ZK) ist unvermeidlich, und das zentrale Argument ist einfach: Ethereum wird von Grund auf neu gestaltet, basierend auf Zero-Knowledge-Proofs. Dies markiert das technische Endziel des Protokolls – durch eine Rekonstruktion von Layer 1, angetrieben von einer leistungsstarken zkVM, die von Kernentwicklerteams wie Succinct unterstützt wird.

Mit dieser Vision als Ziel steht Ethereum an der Schwelle zur wichtigsten architektonischen Transformation seit seiner Gründung. Es geht nicht mehr um schrittweise Upgrades, sondern um eine vollständige Rekonstruktion des Rechenkerns – den Austausch der Ethereum Virtual Machine (EVM). Dieser Schritt ist das Fundament der umfassenderen „Lean Ethereum“-Vision.

Die Lean Ethereum-Vision zielt darauf ab, das gesamte Protokoll systematisch zu vereinfachen und in drei Kernmodule zu unterteilen: Lean Consensus, Lean Data und Lean Execution. Im Kern der Lean Execution steht die entscheidende Frage: Ist die EVM, der Motor der Smart-Contract-Revolution, zum Hauptengpass für die zukünftige Entwicklung von Ethereum geworden?

Wie Justin Drake von der Ethereum Foundation sagte, war das langfristige Ziel von Ethereum immer, „alles zu snarkifizieren“ (Snarkify everything) – ein mächtiges Werkzeug zur Stärkung aller Protokollschichten. Doch lange Zeit schien dieses Ziel wie ein „unerreichbarer Bauplan“, da es das Konzept des Real-Time Proving erforderte. Jetzt, da Real-Time Proving Realität wird, ist die theoretische Ineffizienz der EVM zu einem dringenden praktischen Problem geworden.

Dieser Artikel analysiert die technischen und strategischen Argumente für die Migration von Ethereum L1 zur RISC-V-Befehlssatzarchitektur (ISA). Dieser Schritt verspricht nicht nur beispiellose Skalierbarkeit, sondern vereinfacht auch die Protokollstruktur und richtet Ethereum auf die Zukunft der verifizierbaren Berechnung aus.

Was hat sich eigentlich geändert?

Bevor wir das „Warum“ diskutieren, müssen wir klären, „was“ sich ändert.

Die EVM (Ethereum Virtual Machine) ist die Ausführungsumgebung für Ethereum-Smart-Contracts und wird als „Weltcomputer“ bezeichnet, der Transaktionen verarbeitet und den Blockchain-Status aktualisiert. Ihr Design war über Jahre hinweg revolutionär und legte den Grundstein für DeFi und das NFT-Ökosystem. Doch diese fast zehn Jahre alte, maßgeschneiderte Architektur hat mittlerweile erhebliche technische Schulden angehäuft.

Im Gegensatz dazu ist RISC-V kein Produkt, sondern ein offener Standard – ein kostenloses, universelles Prozessor-Design-„Alphabet“. Wie Jeremy Bruestle auf der Ethproofs-Konferenz betonte, machen seine Grundprinzipien es zur idealen Wahl für diese Rolle:

· Minimalismus: Der Basisbefehlssatz von RISC-V ist äußerst einfach und umfasst nur etwa 40 bis 47 Befehle. Wie Jeremy sagte, macht dies RISC-V „fast perfekt für den Anwendungsfall einer superminimalistischen Universalmaschine“.

· Modulares Design: Komplexere Funktionen werden durch optionale Erweiterungen hinzugefügt. Dies ist entscheidend, da der Kern einfach bleibt und Funktionen je nach Bedarf erweitert werden können, ohne unnötige Komplexität in das Basisprotokoll einzubringen.

· Offenes Ökosystem: RISC-V verfügt über eine große und ausgereifte Toolchain-Unterstützung, einschließlich des LLVM-Compilers, sodass Entwickler gängige Programmiersprachen wie Rust, C++ und Go verwenden können. Wie Justin Drake erwähnte: „Die Tools rund um Compiler sind sehr reichhaltig, und Compiler zu bauen ist extrem schwierig ... Daher ist der Wert dieser Compiler-Toolchains enorm.“ RISC-V ermöglicht es Ethereum, diese Tools kostenlos zu übernehmen.

Das Interpreter-Overhead-Problem

Der Antrieb für den Austausch der EVM ist nicht ein einzelner Fehler, sondern die Konvergenz mehrerer grundlegender Einschränkungen, die im Kontext einer ZK-zentrierten Zukunft nicht mehr ignoriert werden können. Dazu gehören Leistungsengpässe in Zero-Knowledge-Proof-Systemen und die zunehmende Komplexität und das Risiko innerhalb des Protokolls.

Der dringendste Treiber dieser Transformation ist die inhärente Ineffizienz der EVM in Zero-Knowledge-Proof-Systemen. Da Ethereum schrittweise zu einem Modell übergeht, bei dem der L1-Status durch ZK-Proofs verifiziert wird, wird die Leistung der Prover zum größten Engpass.

Das Problem liegt in der aktuellen Arbeitsweise von zkEVMs. Sie führen keine Zero-Knowledge-Proofs direkt auf der EVM aus, sondern beweisen den Interpreter der EVM, der wiederum in RISC-V kompiliert wird. Vitalik Buterin hat dieses Kernproblem offen angesprochen:

„... Wenn die Implementierung der zkVM darin besteht, die Ausführung der EVM in etwas zu kompilieren, das letztlich RISC-V-Code ist, warum sollte man dann nicht einfach die zugrunde liegende RISC-V-Schicht den Smart-Contract-Entwicklern zugänglich machen? So kann man den gesamten Overhead der äußeren VM-Schicht vermeiden.“

Diese zusätzliche Interpretationsschicht führt zu enormen Leistungseinbußen. Schätzungen zufolge kann diese Schicht im Vergleich zum Beweis nativer Programme zu einer 50- bis 800-fachen Verlangsamung führen. Nach der Optimierung anderer Engpässe (z. B. durch Umstellung auf den Poseidon-Hash-Algorithmus) macht dieser Teil der „Blockausführung“ immer noch 80–90% der gesamten Beweiszeit aus, was die EVM zum letzten und schwierigsten Hindernis für die Skalierung von L1 macht. Durch das Entfernen dieser Schicht erwartet Vitalik eine bis zu 100-fache Effizienzsteigerung.

Die Falle der technischen Schulden

Um die Leistungsdefizite der EVM bei bestimmten kryptografischen Operationen auszugleichen, führte Ethereum vorgefertigte Verträge ein – speziell kodierte Funktionen im Protokoll. Obwohl diese Lösung damals pragmatisch war, hat sie laut Vitalik Buterin heute zu einer „schlechten“ Situation geführt:

„Precompiles sind für uns katastrophal ... Sie haben den vertrauenswürdigen Code-Bestand von Ethereum enorm aufgebläht ... und sie haben uns schon mehrmals fast zu Konsensfehlern geführt.“

Diese Komplexität ist erschreckend. Vitalik erklärt, dass der Wrapper-Code eines einzelnen Precompile (wie modexp) komplexer ist als der gesamte RISC-V-Interpreter, während die eigentliche Precompile-Logik noch komplizierter ist. Das Hinzufügen neuer Precompiles erfordert einen langsamen und politisch umstrittenen Hard-Fork-Prozess, was Innovationen, die neue kryptografische Primitive benötigen, stark behindert. Vitalik zieht ein klares Fazit:

„Ich denke, wir sollten ab heute aufhören, neue Precompiles hinzuzufügen.“

Architektonische technische Schulden von Ethereum

Das Kerndesign der EVM spiegelt die Prioritäten einer vergangenen Ära wider, ist aber für moderne Rechenanforderungen nicht mehr geeignet. Die EVM wählte eine 256-Bit-Architektur, um kryptografische Werte zu verarbeiten, aber für die in Smart Contracts üblichen 32- oder 64-Bit-Ganzzahlen ist diese Architektur äußerst ineffizient. Diese Ineffizienz ist in ZK-Systemen besonders teuer. Wie Vitalik erklärt:

„Wenn man kleinere Zahlen verwendet, spart jede Zahl tatsächlich keine Ressourcen, aber die Komplexität steigt um das Zwei- bis Vierfache.“

Darüber hinaus ist die Stack-Architektur der EVM weniger effizient als die Registerarchitektur von RISC-V und modernen CPUs. Sie benötigt mehr Befehle für die gleiche Operation und erschwert Compiler-Optimierungen.

Diese Probleme – Leistungsengpässe bei ZK-Proofs, Komplexität von Precompiles und veraltete Architekturentscheidungen – bilden zusammen einen überzeugenden und dringenden Grund: Ethereum muss über die EVM hinauswachsen und eine zukunftsfähigere technische Architektur annehmen.

RISC-V-Blueprint: Die Zukunft von Ethereum auf stärkerer Basis neu gestalten

Die Vorteile von RISC-V liegen nicht nur in den Schwächen der EVM, sondern vor allem in seiner starken Designphilosophie. Seine Architektur bietet eine robuste, einfache und verifizierbare Grundlage – ideal für eine risikoreiche Umgebung wie Ethereum.

Warum sind offene Standards besser als maßgeschneiderte Designs?

Im Gegensatz zu maßgeschneiderten ISA, bei denen das gesamte Software-Ökosystem von Grund auf neu aufgebaut werden muss, ist RISC-V ein ausgereifter, offener Standard mit drei entscheidenden Vorteilen:

Ausgereiftes Ökosystem

Durch die Einführung von RISC-V kann Ethereum von jahrzehntelangen kollektiven Fortschritten der Informatik profitieren. Wie Justin Drake erklärt, bietet dies Ethereum die Möglichkeit, erstklassige Tools direkt zu nutzen:

„Es gibt eine Infrastrukturkomponente namens LLVM, eine Compiler-Toolchain, mit der Sie Hochsprachen in verschiedene Backend-Ziele kompilieren können. Eines der unterstützten Backends ist RISC-V. Wenn Sie also RISC-V unterstützen, unterstützen Sie automatisch alle von LLVM unterstützten Hochsprachen.“

Dies senkt die Einstiegshürde erheblich und ermöglicht Millionen von Entwicklern, die mit Rust, C++ und Go vertraut sind, einen einfachen Einstieg.

Minimalistische Designphilosophie Die Minimalismus von RISC-V ist ein bewusstes Feature, kein Nachteil. Der Basisbefehlssatz umfasst nur etwa 47 Befehle, was den Kern der VM extrem schlank hält. Diese Einfachheit bietet erhebliche Sicherheitsvorteile, da ein kleinerer vertrauenswürdiger Code-Bestand leichter geprüft und formal verifiziert werden kann.

De-facto-Standard im Zero-Knowledge-Proof-Bereich Noch wichtiger ist, dass sich das zkVM-Ökosystem bereits entschieden hat. Wie Justin Drake anhand der Ethproofs-Daten zeigt, ist ein klarer Trend zu erkennen:

„RISC-V ist die führende ISA für zkVM-Backends.“

Von zehn zkVMs, die Ethereum-Blöcke beweisen können, haben neun RISC-V als Zielarchitektur gewählt. Diese Marktkonvergenz sendet ein starkes Signal: Durch die Übernahme von RISC-V folgt Ethereum nicht einer spekulativen Wette, sondern richtet sich an einem bereits bewährten und für die Zero-Knowledge-Zukunft anerkannten Standard aus.

Geboren für Vertrauen, nicht nur für Ausführung

Abgesehen vom breiten Ökosystem ist die interne Architektur von RISC-V besonders geeignet, um sichere und verifizierbare Systeme zu bauen. Erstens verfügt RISC-V über eine formalisierte, maschinenlesbare Spezifikation – SAIL. Im Vergleich zur EVM-Spezifikation (hauptsächlich als Text im Yellow Paper) ist dies ein großer Fortschritt. Das Yellow Paper ist teilweise unklar, während die SAIL-Spezifikation einen „Goldstandard“ bietet, der mathematische Korrektheitsbeweise unterstützt – entscheidend für den Schutz wertvoller Protokolle. Wie Alex Hicks von der Ethereum Foundation auf der Ethproofs-Konferenz erwähnte, ermöglicht dies zkVM-Schaltkreisen, direkt „gegen die offizielle RISC-V-Spezifikation zu verifizieren“. Zweitens enthält RISC-V eine privilegierte Architektur – ein oft übersehener, aber sicherheitsrelevanter Aspekt. Sie definiert verschiedene Betriebsmodi, hauptsächlich User Mode (für nicht vertrauenswürdige Anwendungen wie Smart Contracts) und Supervisor Mode (für vertrauenswürdige „Execution Kernels“). Cartesis Diego erklärt dies ausführlich:

„Das Betriebssystem selbst muss sich vor anderen Codes schützen. Es muss verschiedene Programme voneinander isolieren, und all diese Mechanismen sind Teil des RISC-V-Standards.“

In der RISC-V-Architektur können Smart Contracts, die im User Mode laufen, nicht direkt auf den Blockchain-Status zugreifen. Stattdessen müssen sie über eine spezielle ECALL (Environment Call)-Instruktion Anfragen an den vertrauenswürdigen Kernel im Supervisor Mode stellen. Diese Mechanik schafft eine durch Hardware erzwungene Sicherheitsgrenze, die robuster und leichter zu verifizieren ist als das rein softwarebasierte Sandbox-Modell der EVM.

Vitaliks Vision

Diese Transformation ist als schrittweiser, mehrstufiger Prozess konzipiert, um Systemstabilität und Rückwärtskompatibilität zu gewährleisten. Wie Ethereum-Gründer Vitalik Buterin erläutert, zielt dieser Ansatz auf eine „evolutionäre“ Entwicklung ab, nicht auf eine vollständige „revolutionäre“ Veränderung.

Schritt 1: Precompile-Ersatz

Die Anfangsphase ist sehr konservativ und führt nur begrenzte Funktionen der neuen VM ein. Wie Vitalik Buterin vorschlägt: „Wir können mit begrenzten Szenarien für die neue VM beginnen, z. B. als Ersatz für Precompiles.“ Konkret bedeutet dies, dass keine neuen EVM-Precompiles mehr hinzugefügt werden, sondern die benötigten Funktionen durch whiteliste RISC-V-Programme bereitgestellt werden. Diese Methode ermöglicht es, die neue VM im Mainnet in einer risikoarmen Umgebung zu testen, wobei Ethereum-Clients als Vermittler zwischen beiden Ausführungsumgebungen fungieren.

Schritt 2: Koexistenz von zwei VMs

In der nächsten Phase wird die „neue VM direkt für Nutzer geöffnet“. Smart Contracts können durch Markierung angeben, ob ihr Bytecode EVM oder RISC-V ist. Ein zentrales Merkmal ist die nahtlose Interoperabilität: „Beide Vertragstypen können sich gegenseitig aufrufen.“ Dies wird durch Systemaufrufe (ECALL) ermöglicht, sodass beide VMs im selben Ökosystem zusammenarbeiten können.

Schritt 3: EVM als simulierte Verträge („Rosetta“-Strategie)

Das endgültige Ziel ist die radikale Vereinfachung des Protokolls. In dieser Phase „wird die EVM als eine Implementierung innerhalb der neuen VM betrachtet“. Die standardisierte EVM wird zu einem formal verifizierten Smart Contract, der nativ auf RISC-V L1 läuft. Dies gewährleistet nicht nur dauerhafte Unterstützung für Legacy-Anwendungen, sondern ermöglicht es Client-Entwicklern, nur noch eine vereinfachte Ausführungs-Engine zu pflegen – was Komplexität und Wartungskosten erheblich reduziert.

Welleneffekte im Ökosystem

Der Übergang von der EVM zu RISC-V ist nicht nur eine Veränderung des Kernprotokolls, sondern wird das gesamte Ethereum-Ökosystem tiefgreifend beeinflussen. Diese Transformation wird nicht nur das Entwicklererlebnis neu gestalten, sondern auch das Wettbewerbsumfeld der Layer-2-Lösungen grundlegend verändern und neue wirtschaftliche Verifizierungsmodelle ermöglichen.

Neupositionierung der Rollups: Optimistic vs. ZK

Die Einführung der RISC-V-Ausführungsschicht auf L1 wird sich auf die beiden Haupttypen von Rollups unterschiedlich auswirken.

Optimistic Rollups (wie Arbitrum, Optimism) stehen vor architektonischen Herausforderungen. Ihr Sicherheitsmodell beruht darauf, strittige Transaktionen auf der L1-EVM erneut auszuführen, um Fraud-Proofs zu liefern. Wird die L1-EVM ersetzt, bricht dieses Modell zusammen. Diese Projekte stehen vor der Wahl: Entweder sie führen umfangreiche technische Umbauten durch, um ein Fraud-Proof-System für die neue L1-VM zu entwickeln, oder sie verlassen das Sicherheitsmodell von Ethereum vollständig.

Im Gegensatz dazu werden ZK-Rollups einen enormen strategischen Vorteil erlangen. Die überwiegende Mehrheit der ZK-Rollups nutzt bereits RISC-V als interne ISA. Ein „L1, das dieselbe Sprache spricht“, ermöglicht eine engere und effizientere Integration. Justin Drake skizziert die Zukunft der „nativen Rollups“: L2 wird zu einer spezialisierten Instanz der L1-Ausführungsumgebung und nutzt die eingebaute VM von L1 für nahtlose Abwicklung. Diese Angleichung bringt folgende Veränderungen:

· Vereinfachung des Tech-Stacks: L2-Teams müssen keine komplexen Brücken mehr zwischen ihrer internen RISC-V-Ausführungsumgebung und der EVM bauen.

· Wiederverwendung von Tools und Code: Compiler, Debugger und formale Verifikationstools, die für die L1-RISC-V-Umgebung entwickelt wurden, können direkt von L2 genutzt werden, was die Entwicklungskosten erheblich senkt.

· Wirtschaftliche Anreizangleichung: Die Gasgebühren von L1 spiegeln die tatsächlichen Kosten der RISC-V-basierten ZK-Verifikation wider und schaffen so ein gerechteres Wirtschaftsmodell.

Eine neue Ära für Entwickler und Nutzer

Für Ethereum-Entwickler wird diese Transformation schrittweise und nicht disruptiv verlaufen.

Entwickler erhalten Zugang zu einem breiteren und ausgereifteren Software-Ökosystem. Wie Vitalik Buterin betont, können Entwickler „Smart Contracts in Rust schreiben, während diese Optionen koexistieren“. Gleichzeitig erwartet er, dass „Solidity und Vyper wegen ihrer eleganten Gestaltung für Smart-Contract-Logik weiterhin beliebt bleiben“. Die Nutzung von Mainstream-Programmiersprachen und deren umfangreichen Bibliotheken über die LLVM-Toolchain ist revolutionär. Vitalik vergleicht dies mit einer „NodeJS-ähnlichen Erfahrung“, bei der Entwickler sowohl On-Chain- als auch Off-Chain-Code in derselben Sprache schreiben und so eine einheitliche Entwicklung ermöglichen.

Für Nutzer wird diese Transformation letztlich zu niedrigeren Kosten und höherer Netzwerkleistung führen. Die Beweiskosten werden voraussichtlich um das 100-fache sinken – von mehreren Dollar pro Transaktion auf nur wenige Cent oder weniger. Dies führt direkt zu niedrigeren L1- und L2-Abwicklungskosten. Diese wirtschaftliche Machbarkeit ebnet den Weg für die „Gigagas L1“-Vision mit ca. 10.000 TPS und schafft die Grundlage für komplexere und wertvollere On-Chain-Anwendungen in der Zukunft.

Succinct Labs und SP1: Die Zukunft des Beweisens wird gebaut

Ethereum steht in den Startlöchern. „L1 skalieren, Blöcke skalieren“ ist eine strategisch dringende Aufgabe innerhalb des EF-Protokollclusters. In den nächsten 6 bis 12 Monaten werden erhebliche Leistungssteigerungen erwartet.

Teams wie Succinct Labs demonstrieren bereits in der Praxis die theoretischen Vorteile von RISC-V und liefern damit einen starken Beweis für diesen Vorschlag.

SP1 von Succinct Labs ist eine leistungsstarke, quelloffene zkVM auf RISC-V-Basis, die die Machbarkeit des neuen Architekturansatzes belegt. SP1 verfolgt eine „precompile-zentrierte“ Philosophie und löst das kryptografische Nadelöhr der EVM perfekt. Im Gegensatz zu herkömmlichen, langsamen und fest kodierten Precompiles lagert SP1 rechenintensive Operationen wie Keccak-Hashing in speziell entwickelte, manuell optimierte ZK-Schaltkreise aus, die über Standard-ECALLs aufgerufen werden. Dieser Ansatz kombiniert die Leistung von maßgeschneiderter Hardware mit der Flexibilität von Software und bietet Entwicklern eine effizientere und skalierbare Lösung.

Die tatsächlichen Auswirkungen von Succinct Labs sind bereits sichtbar. Ihr OP Succinct-Produkt nutzt SP1, um Optimistic Rollups mit Zero-Knowledge-Proofs auszustatten (ZK-ify). Wie Mitgründerin Uma Roy erklärt:

„Rollups, die den OP Stack verwenden, müssen nicht mehr sieben Tage auf die endgültige Bestätigung und Auszahlung warten ... Jetzt dauert die Bestätigung nur noch eine Stunde. Dieser Geschwindigkeitsschub ist großartig.“

Dieser Durchbruch löst einen entscheidenden Schmerzpunkt im gesamten OP Stack-Ökosystem. Darüber hinaus ist die Infrastruktur von Succinct – das Succinct Prover Network – als dezentraler Markt für Beweiserstellung konzipiert und zeigt ein tragfähiges Wirtschaftsmodell für verifizierbare Berechnungen der Zukunft. Ihre Arbeit ist nicht nur ein Proof-of-Concept, sondern eine umsetzbare Blaupause für die in diesem Artikel beschriebene Zukunft.

Wie Ethereum Risiken reduziert

Ein großer Vorteil von RISC-V ist, dass es den heiligen Gral der formalen Verifikation – den mathematischen Beweis der Systemkorrektheit – erreichbar macht. Die EVM-Spezifikation ist in natürlicher Sprache im Yellow Paper verfasst und schwer zu formalisieren. RISC-V hingegen verfügt über eine offizielle, maschinenlesbare SAIL-Spezifikation, die als eindeutige „Goldreferenz“ für das Verhalten dient.

Dies ebnet den Weg für stärkere Sicherheit. Wie Alex Hicks von der Ethereum Foundation betont, wird derzeit daran gearbeitet, „die zkVM-RISC-V-Schaltkreise mit der offiziellen RISC-V-Spezifikation in Lean formal zu verifizieren“. Dies ist ein Meilenstein, der das Vertrauen von fehleranfälligen menschlichen Implementierungen auf überprüfbare mathematische Beweise verlagert und neue Maßstäbe für die Blockchain-Sicherheit setzt.

Hauptrisiken der Transformation

Obwohl die RISC-V-Architektur auf L1 viele Vorteile bietet, bringt sie auch neue komplexe Herausforderungen mit sich.

Gas-Messungsproblem

Für eine generische ISA ein deterministisches und faires Gas-Modell zu schaffen, ist ein ungelöstes Problem. Eine einfache Befehlszählung ist anfällig für Denial-of-Service-Angriffe. Angreifer könnten Programme entwerfen, die wiederholt Cache-Misses auslösen und so mit minimalen Gasgebühren hohe Ressourcen verbrauchen. Dies stellt eine ernsthafte Herausforderung für die Netzwerkstabilität und das Wirtschaftsmodell dar.

Sicherheit der Toolchain und „Reproduzierbare Builds“-Problem

Dies ist das wichtigste und am meisten unterschätzte Risiko im Transformationsprozess. Das Sicherheitsmodell verlagert sich von der On-Chain-VM auf den Off-Chain-Compiler (wie LLVM), der äußerst komplex ist und bekannte Schwachstellen aufweist. Angreifer könnten Compiler-Bugs ausnutzen, um scheinbar harmlosen Quellcode in bösartigen Bytecode zu verwandeln. Außerdem ist es äußerst schwierig, sicherzustellen, dass das On-Chain-kompilierte Binärfile exakt mit dem veröffentlichten Quellcode übereinstimmt („reproduzierbare Builds“). Kleinste Unterschiede in der Build-Umgebung können zu unterschiedlichen Binaries führen und so Transparenz und Vertrauen beeinträchtigen. Diese Probleme stellen erhebliche Herausforderungen für die Sicherheit von Entwicklern und Nutzern dar.

Strategien zur Risikominderung

Der Weg nach vorn erfordert mehrschichtige Verteidigungsstrategien.

Stufenweise Einführung

Ein schrittweiser, mehrstufiger Übergangsplan ist die Kernstrategie zur Risikominderung. Durch die Einführung von RISC-V zunächst als Precompile-Ersatz und dann im Dual-VM-Betrieb kann die Community in einer risikoarmen Umgebung Erfahrungen sammeln und Vertrauen aufbauen, ohne irreversible Änderungen vorzunehmen. Dieser schrittweise Ansatz bietet eine stabile Grundlage für die technische Transformation.

Umfassende Audits: Fuzzing und formale Verifikation

Obwohl die formale Verifikation das Endziel ist, muss sie mit kontinuierlichen, intensiven Tests kombiniert werden. Wie Valentine von Diligence Security in der Ethproofs-Telko zeigte, hat ihr Argus-Fuzzing-Tool bereits 11 kritische Soundness- und Integritätslücken in führenden zkVMs entdeckt. Das zeigt, dass selbst die am besten gestalteten Systeme Schwachstellen aufweisen können, die nur durch rigorose, gegnerische Tests entdeckt werden. Die Kombination aus Fuzzing und formaler Verifikation bietet einen stärkeren Schutz für die Systemsicherheit.

Standardisierung

Um eine Fragmentierung des Ökosystems zu vermeiden, sollte die Community eine einheitliche, standardisierte RISC-V-Konfiguration übernehmen. Wahrscheinlich wird dies die Kombination aus RV64GC und einer Linux-kompatiblen ABI sein, da diese in den wichtigsten Programmiersprachen und Tools am besten unterstützt wird und die Vorteile des neuen Ökosystems maximiert. Standardisierung erhöht nicht nur die Effizienz der Entwickler, sondern legt auch ein solides Fundament für die langfristige Entwicklung des Ökosystems.

Die verifizierbare Zukunft von Ethereum

Der Vorschlag, die Ethereum Virtual Machine (EVM) durch RISC-V zu ersetzen, ist nicht nur ein schrittweises Upgrade, sondern eine grundlegende Rekonstruktion der Ausführungsschicht von Ethereum. Diese ehrgeizige Vision zielt darauf ab, tiefe Skalierungsengpässe zu lösen, die Protokollkomplexität zu reduzieren und die Plattform mit dem breiteren Ökosystem der allgemeinen Berechnung abzustimmen. Trotz der enormen technischen und sozialen Herausforderungen sind die langfristigen strategischen Vorteile ausreichend, um diese kühne Initiative zu rechtfertigen.

Diese Transformation konzentriert sich auf eine Reihe zentraler Abwägungen:

· Das Gleichgewicht zwischen enormen Leistungssteigerungen durch ZK-native Architektur und dem dringenden Bedarf an Rückwärtskompatibilität;

· Der Kompromiss zwischen den Sicherheitsvorteilen einer vereinfachten Protokollstruktur und der Trägheit der enormen Netzwerkeffekte der EVM;

· Die Wahl zwischen der Leistungsfähigkeit eines allgemeinen Ökosystems und den Risiken, die mit der Abhängigkeit von komplexen Drittanbieter-Toolchains einhergehen.

Letztlich ist diese architektonische Transformation der Schlüssel zur Einlösung des Versprechens der „Lean Execution“ und ein wichtiger Bestandteil der „Lean Ethereum“-Vision. Sie verwandelt Ethereums L1 von einer einfachen Smart-Contract-Plattform in eine effiziente und sichere Abwicklungs- und Datenverfügbarkeitsschicht, die speziell für das breite Universum der verifizierbaren Berechnung konzipiert ist.

Wie Vitalik Buterin sagte: „Das Ziel ist ... ZK-snarks für alles bereitzustellen.“

Projekte wie Ethproofs liefern objektive Daten und eine Kooperationsplattform für diese Transformation, während das Team von Succinct Labs mit der praktischen Anwendung ihrer SP1 zkVM eine umsetzbare Blaupause für diese Zukunft bietet. Durch die Übernahme von RISC-V löst Ethereum nicht nur seine eigenen Skalierungsengpässe, sondern positioniert sich auch als grundlegende Vertrauensebene für das nächste Internet – angetrieben vom dritten großen kryptografischen Primitive nach Hashes und Signaturen: SNARK.

Die Software der Welt beweisen, das Krypto-Zeitalter einläuten.

Mehr erfahren: