Ethereum steht möglicherweise vor dem größten Upgrade seiner Geschichte: EVM wird abgeschaltet, RISC-V übernimmt.

Originaltitel: Goodbye EVM, Hello RISC-V

Originalautor: jaehaerys.eth, Krypto-Forscher

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 extrem 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 gliedert sich in drei Phasen:

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

· Ära der Dualen Virtual Machine: EVM und RISC-V koexistieren und sind vollständig interoperabel;

· EVM wird innerhalb von RISC-V neu implementiert (Rosetta-Strategie).

Auswirkungen auf das Ökosystem:

· Optimistische Rollups (wie Arbitrum und Optimism) müssen ihre Betrugsnachweis-Mechanismen neu aufbauen;

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

· Entwickler können direkt auf L1-Basis Bibliotheken in Rust, Go und Python verwenden;

· Nutzer profitieren von etwa 100-fach niedrigeren Nachweiskosten → Weg zum Gigagas L1 (ca. 10.000 TPS).

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

Ethereums Scheideweg

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 L1, angetrieben von einer leistungsstarken zkVM, unterstützt von Kernentwicklerteams wie Succinct.

Mit dieser Vision als Ziel steht Ethereum an der wichtigsten architektonischen Weggabelung seit seiner Gründung. Die Diskussion dreht sich 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 es in drei Kernmodule zu unterteilen: Lean Consensus, Lean Data und Lean Execution. Im Kernproblem der Lean Execution ist 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 sagt, war das langfristige Ziel von Ethereum immer, „alles zu snarkifizieren“ (Snarkify everything), ein mächtiges Werkzeug zur Stärkung aller Protokollschichten. Doch lange Zeit war dieses Ziel eher eine „unerreichbare Blaupause“, da es das Konzept des Echtzeit-Nachweises erforderte. Jetzt, da Echtzeit-Nachweise Realität werden, 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 auf die RISC-V-Befehlssatzarchitektur (ISA). Dieser Schritt verspricht nicht nur beispiellose Skalierbarkeit, sondern vereinfacht auch die Protokollstruktur und bringt Ethereum mit der Zukunft der verifizierbaren Berechnung in Einklang.

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-Zustand aktualisiert. Über Jahre war ihr Design revolutionär und legte den Grundstein für DeFi und das NFT-Ökosystem. Doch diese fast zehn Jahre alte, maßgeschneiderte Architektur hat inzwischen 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 Schlüsselprinzipien es zur idealen Wahl für diese Rolle:

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

· Modulares Design: Komplexere Funktionen werden durch optionale Erweiterungen hinzugefügt. Dies ist entscheidend, da es den Kern einfach hält und gleichzeitig die Funktionalität nach Bedarf erweitert, ohne unnötige Komplexität in das Basisprotokoll einzubringen.

· Offenes Ökosystem: RISC-V verfügt über eine umfangreiche 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 vorhandenen Tools kostenlos zu übernehmen.

Interpreter-Overhead-Problematik

Der Antrieb für den Austausch der EVM ist nicht ein einzelner Fehler, sondern das Zusammentreffen 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. Während Ethereum schrittweise auf ein Modell umstellt, bei dem der L1-Zustand durch ZK-Proofs verifiziert wird, wird die Leistung der Prover zum größten Engpass.

Das Problem liegt in der Arbeitsweise aktueller 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 direkt 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 Nachweis nativer Programme zu einer 50- bis 800-fachen Verlangsamung führen. Nach der Optimierung anderer Engpässe (z. B. durch den Wechsel zum Poseidon-Hash-Algorithmus) macht dieser Teil der „Blockausführung“ immer noch 80-90% der gesamten Nachweiszeit aus und macht die EVM zum letzten und schwierigsten Hindernis für die Skalierung von L1. 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 codierte Funktionen im Protokoll. Diese Lösung war damals pragmatisch, hat aber laut Vitalik Buterin heute zu einer „schlechten“ Situation geführt:

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

Diese Komplexität ist erschreckend. Vitalik erklärt, dass der Wrapper-Code eines einzelnen Precompile-Vertrags (wie modexp) komplexer ist als der gesamte RISC-V-Interpreter, während die Precompile-Logik selbst 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.“

Technische Schulden in Ethereums Architektur

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 extrem 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 der 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: Ethereums Zukunft auf stärkerem Fundament

Die Vorteile von RISC-V liegen nicht nur in den Schwächen der EVM, sondern auch in seiner starken Designphilosophie. Seine Architektur bietet eine robuste, einfache und verifizierbare Grundlage, die sich besonders für risikoreiche Umgebungen wie Ethereum eignet.

Warum sind offene Standards besser als maßgeschneiderte Designs?

Im Gegensatz zu maßgeschneiderten Befehlssatzarchitekturen (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 auf jahrzehntelange kollektive Fortschritte der Informatik zurückgreifen. Wie Justin Drake erklärt, bietet dies Ethereum die Möglichkeit, Weltklasse-Tools direkt zu nutzen:

„Es gibt eine Infrastrukturkomponente namens LLVM, eine Compiler-Toolchain, mit der man Hochsprachen in verschiedene Backends kompilieren kann. Eines der unterstützten Backends ist RISC-V. Wenn man also RISC-V unterstützt, unterstützt man automatisch alle von LLVM unterstützten Hochsprachen.“

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

Minimalistische Designphilosophie Der Minimalismus von RISC-V ist ein bewusstes Feature, kein Nachteil. Der Basisbefehlssatz umfasst nur etwa 47 Befehle, wodurch der Kern der VM extrem schlank bleibt. Diese Einfachheit bringt erhebliche Sicherheitsvorteile, da ein kleinerer vertrauenswürdiger Codebestand leichter geprüft und formal verifiziert werden kann.

De-facto-Standard im Zero-Knowledge-Proof-Bereich Wichtiger noch: Das zkVM-Ökosystem hat sich bereits entschieden. Wie Justin Drake betont, zeigt sich aus den Ethproofs-Daten ein klarer Trend:

„RISC-V ist die führende Befehlssatzarchitektur (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: Ethereum übernimmt mit RISC-V keinen spekulativen Versuch, sondern richtet sich an einem bereits bewährten und für die Zero-Knowledge-Zukunft akzeptierten Standard aus.

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

Neben dem breiten Ökosystem ist auch 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 vage, 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 den User Mode (für nicht vertrauenswürdige Anwendungen wie Smart Contracts) und den Supervisor Mode (für den vertrauenswürdigen „Execution Kernel“). 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-Zustand zugreifen. Stattdessen müssen sie eine spezielle ECALL (Environment Call)-Anweisung an den vertrauenswürdigen Kernel im Supervisor Mode senden. Dieser Mechanismus schafft eine 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.

Erster Schritt: Precompile-Ersatz

Die Anfangsphase ist äußerst 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, etwa als Ersatz für Precompile-Funktionen.“ Konkret bedeutet dies, dass keine neuen EVM-Precompiles mehr hinzugefügt werden, sondern die benötigten Funktionen durch von einer Whitelist genehmigte 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 den beiden Ausführungsumgebungen fungieren.

Zweiter Schritt: Koexistenz beider 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. Das Schlüsselmerkmal 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.

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

Das Endziel ist die maximale Vereinfachung des Protokolls. In dieser Phase „wird die EVM als eine Implementierung innerhalb der neuen VM ausgeführt.“ Die standardisierte EVM wird zu einem formal verifizierten Smart Contract, der nativ auf RISC-V L1 läuft. Dies stellt nicht nur die dauerhafte Unterstützung älterer Anwendungen sicher, 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 die Entwicklererfahrung 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 die beiden Haupttypen von Rollups unterschiedlich beeinflussen.

Optimistic Rollups (wie Arbitrum, Optimism) stehen vor architektonischen Herausforderungen. Ihr Sicherheitsmodell basiert darauf, strittige Transaktionen auf der L1-EVM erneut auszuführen, um Betrugsnachweise zu erbringen. Wird die L1-EVM ersetzt, bricht dieses Modell zusammen. Diese Projekte stehen vor der Wahl: Entweder sie führen umfangreiche technische Überarbeitungen durch, um ein neues Betrugsnachweissystem 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 verwendet bereits RISC-V als interne Befehlssatzarchitektur (ISA). Ein L1, das „die gleiche Sprache spricht“, ermöglicht eine engere und effizientere Integration. Justin Drake entwirft die Zukunftsvision der „nativen Rollups“: L2 wird tatsächlich zu einer spezialisierten Instanz der L1-Ausführungsumgebung, 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ückenmechanismen 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.

· Ausrichtung der wirtschaftlichen Anreize: Die Gas-Gebühren von L1 spiegeln die tatsächlichen Kosten der RISC-V-basierten ZK-Verifikation genauer wider und schaffen so ein besseres Wirtschaftsmodell.

Eine neue Ära für Entwickler und Nutzer

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

Entwickler erhalten Zugang zu einem breiteren und ausgereifteren Softwareentwicklungs-Ökosystem. Wie Vitalik Buterin betont, werden Entwickler „in der Lage sein, Verträge in Rust zu schreiben, während diese Optionen koexistieren können“. Gleichzeitig prognostiziert er, dass „Solidity und Vyper aufgrund ihrer eleganten Gestaltung für Smart-Contract-Logik weiterhin beliebt bleiben werden“. 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 einer leistungsfähigeren Netzwerkerfahrung führen. Die Nachweiskosten werden voraussichtlich um das 100-fache sinken, von mehreren Dollar pro Transaktion auf nur noch 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 dem Ziel, etwa 10.000 TPS zu erreichen und so den Weg für komplexere und wertvollere On-Chain-Anwendungen zu ebnen.

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 überzeugenden Beweis für diesen Vorschlag.

SP1 von Succinct Labs ist eine leistungsstarke, quelloffene zkVM auf RISC-V-Basis, die die Machbarkeit des neuen Architekturansatzes bestätigt. SP1 verfolgt eine „precompile-zentrierte“ Philosophie und löst das kryptografische Nadelöhr der EVM perfekt. Im Gegensatz zu herkömmlichen, langsamen und hartcodierten Precompiles lagert SP1 rechenintensive Operationen wie Keccak-Hashing in speziell entwickelte, manuell optimierte ZK-Schaltkreise aus und ruft sie über Standard-ECALL-Anweisungen auf. Dieser Ansatz kombiniert die Leistung von Spezialhardware 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-Proof-Fähigkeiten (ZK-ify) auszustatten. Wie Succinct-Mitgründer Uma Roy erklärt:

„Mit Rollups, die den OP Stack nutzen, muss man 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 zentralen Schmerzpunkt im gesamten OP Stack-Ökosystem. Darüber hinaus ist Succincts Infrastruktur – das Succinct Prover Network – als dezentraler Markt für Beweiserstellung konzipiert und demonstriert 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 – die mathematische Beweisbarkeit der Systemkorrektheit – erreichbar macht. Die EVM-Spezifikation ist im Yellow Paper in natürlicher Sprache verfasst und schwer zu formalisieren. RISC-V hingegen verfügt über eine offizielle, maschinenlesbare SAIL-Spezifikation, die als klare „Goldreferenz“ für das Verhalten dient.

Dies ebnet den Weg für mehr 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 für die formale Verifikation zu extrahieren“. Dies ist ein Meilenstein, der das Vertrauen von fehleranfälligen menschlichen Implementierungen auf verifizierbare mathematische Beweise verlagert und neue Maßstäbe für die Blockchain-Sicherheit setzt.

Hauptrisiken der Transformation

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

Gas-Messungsproblem

Für eine universelle Befehlssatzarchitektur (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 minimalem Gasverbrauch hohe Ressourcen beanspruchen. Solche Probleme stellen eine große Herausforderung für die Netzstabilität und das Wirtschaftsmodell dar.

Toolchain-Sicherheit und das Problem der „reproduzierbaren Builds“

Dies ist das wichtigste und am meisten unterschätzte Risiko im Transformationsprozess. Das Sicherheitsmodell verlagert sich von der On-Chain-VM auf Off-Chain-Compiler (wie LLVM), die extrem komplex sind und bekannte Schwachstellen aufweisen. Angreifer könnten Compiler-Schwachstellen ausnutzen, um scheinbar harmlosen Quellcode in bösartigen Bytecode zu verwandeln. Zudem ist es äußerst schwierig sicherzustellen, dass die On-Chain-Binärdatei nach der Kompilierung exakt mit dem veröffentlichten Quellcode übereinstimmt – das Problem der „reproduzierbaren Builds“. Schon kleinste Unterschiede in der Build-Umgebung können zu unterschiedlichen Binärdateien führen, was Transparenz und Vertrauen beeinträchtigt. 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 zentrale Strategie zur Risikominimierung. Indem RISC-V zunächst als Precompile-Ersatz eingeführt und dann in einer Dual-VM-Umgebung betrieben wird, kann die Community in einer risikoarmen Umgebung Erfahrungen sammeln und Vertrauen aufbauen, ohne irreversible Änderungen vorzunehmen. Dieser graduelle 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-Telefonkonferenz zeigte, hat ihr Argus-Fuzzing-Tool bereits 11 kritische Sicherheits- 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 eine 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 steigert nicht nur die Effizienz der Entwickler, sondern legt auch ein solides Fundament für die langfristige Entwicklung des Ökosystems.

Ethereums verifizierbare Zukunft

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, tiefgreifende Skalierungsengpässe zu lösen, die Protokollkomplexität zu reduzieren und die Plattform mit dem breiteren Ökosystem der universellen Berechnung in Einklang zu bringen. Trotz der enormen technischen und sozialen Herausforderungen sind die langfristigen strategischen Vorteile ausreichend, um dieses kühne Unterfangen zu rechtfertigen.

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

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

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

· Die Wahl zwischen der Leistungsfähigkeit eines universellen Ö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 sagt: „Das Ziel ist ... alles mit ZK-snark zu versehen.“

Projekte wie Ethproofs liefern objektive Daten und eine Kooperationsplattform für diese Transformation, während das Team von Succinct Labs mit seiner 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: