Ethereum Herzoperation? Vitalik schlägt vor, dass die Ausführungsschicht von Ethereum möglicherweise vollständig EVM ersetzt wird und stattdessen RISC-V verwendet.

In der Zukunftsvision von Ethereum hat ein neuer Vorschlag, der von Vitalik Buterin, einem Mitbegründer von Ethereum, ins Leben gerufen wurde, in der Community lebhafte Diskussionen ausgelöst: die Verwendung von RISC-V anstelle von EVM (Ethereum Virtual Machine) als Sprache für die virtuelle Maschine von Smart Contracts. Diese Idee wird als ein “großes Upgrade auf Beam-Chain-Ebene” für die Ausführungsschicht beschrieben, das nicht nur zur Skalierung dient, sondern auch darauf abzielt, die grundlegenden Engpässe der aktuellen Komplexität und Effizienz der Ausführungsschicht zu lösen.

Was ist RISC-V? Warum soll EVM ersetzt werden?

Der Kern des Vorschlags besteht darin, die derzeit verwendete EVM der Ethereum Smart Contracts durch eine offene, modulare Befehlssatzarchitektur – RISC-V – zu ersetzen. Ein solcher Übergang würde die bestehenden Entwicklerwerkzeuge und -gewohnheiten von Ethereum nicht in Frage stellen, da:

Die bestehenden Kontosysteme, die Inter-Contract-Aufrufe, die Speicherarten und andere Kernabstraktionsschichten bleiben weiterhin erhalten.

Die ursprünglichen Solidity- und Vyper-Sprachen können so umgestellt werden, dass sie in RISC-V als Backend kompiliert werden, was die Entwicklererfahrung nicht wesentlich verändert.

Die alten EVM-Verträge können weiterhin bidirektional mit den neuen RISC-V-Verträgen kommunizieren.

So können Entwickler alles, was sie bereits wissen, weiterhin nutzen, während die Leistung und Einfachheit der Ethereum-Blockchain erheblich verbessert werden kann.

ZK-EVM ist der größte Leistungsengpass

Mit der Einführung mehrerer zukünftiger Skalierungsvorschläge (wie EIP-4444, verzögerte Ausführung und zustandslose Clients) wird sich der tatsächliche Faktor, der die Skalierungsfähigkeit von Ethereum L1 einschränkt, auf Folgendes konzentrieren:

Stabilität von Datenverfügbarkeitsstichproben und historischen Speicherprotokollen

Marktgerechter Wettbewerb in der Blockproduktion

ZK-EVM Nachweis Effizienz

Derzeit beansprucht der Prozess der ZK-EVM zur Prüfung eines Blocks allein durch die Ausführung der EVM Virtuelle Maschine Logik etwa 50 % der Ressourcen. Das bedeutet, wenn es möglich ist, Smart Contracts direkt in einer RISC-V-Umgebung auszuführen, besteht die Chance, die ZK Nachweis-Effizienz um das 50-fache oder sogar 100-fache zu steigern.

Interessanterweise besteht der Nachweisprozess des heutigen ZK-EVM tatsächlich darin, die EVM in RISC-V zu kompilieren und dann das ZK-System zur Validierung zu verwenden. Daher wäre es nicht nur logisch, RISC-V zur nativen virtuellen Maschine der Ethereum-Execution-Ebene zu machen, sondern würde auch den Ressourcenverbrauch für die Zwischenumwandlung einsparen.

Warum ist RISC-V schnell? Vollständige Optimierung vom Hash-Algorithmus bis zum Strukturdesign.

Die aktuellen vier Hauptposten, die Ressourcen für ZK-EVM verbrauchen, sind:

deserialize_inputs

initialize_witness_db

state_root_computation

block_execution

Die ersten drei können durch die Verwendung von benutzerfreundlicheren Hash-Funktionen (wie Poseidon) und binären Statusbäumen erheblich optimiert werden. Zum Beispiel kann Poseidon auf einem Laptop 2 Millionen Hashes pro Sekunde verarbeiten, was weit besser ist als die 15.000 von Keccak. Wenn diese Optimierungen umgesetzt werden, würde dies die Belastung um 50 % erheblich reduzieren.

aber die verbleibenden 50 % stammen weiterhin von

block_execution

Diese Herausforderung kann nur durch ein effizienteres VM-Design, wie z.B. RISC-V, grundlegend gelöst werden.

Drei Implementierungsarten, von konservativ bis radikal gibt es Auswahlmöglichkeiten.

Vitalik schlug drei technische Implementierungswege vor:

– Option eins: Gleichzeitige Nutzung von zwei virtuellen Maschinen (minimales Risiko): Ermöglicht es Verträgen, zwischen EVM oder RISC-V zu wählen, die beide miteinander kommunizieren und Ressourcen teilen, wodurch Kompatibilität und Innovation gewahrt bleiben.

– Option zwei: RISC-V verpackter EVM-Interpreter (radikale Aufrüstung): Alle EVM-Verträge werden über den in RISC-V integrierten EVM-Interpreter ausgeführt, wodurch die gesamte Ausführungsschicht auf eine einheitliche zugrunde liegende Architektur übergeht.

Option drei: Protokollebene unterstützt Virtuelle Maschinen-Interpreter (mittelweg): Im Protokoll wird ein “Virtuelle Maschine-Modul” entworfen, das standardmäßig einen RISC-V-Implementierung des EVM-Interpreters verwendet und zukünftige Erweiterungen auf andere Sprachen wie Move erlaubt.

Die gemeinsamen Vorteile dieser Pfade sind: Sie können die Spezifikation der Ausführungsebene vereinfachen und die Wartbarkeit sowie die Transparenz der Verifizierung verbessern.

Sui Entwicklungsunternehmen Mysten Labs Mitbegründer: Wenn er die Wahl hätte, würde er sich für Move entscheiden und keine Mehrsprachigkeit in Betracht ziehen.

Zu diesem Vorschlag äußerte sich Sam Blackshear, Mitbegründer von Mysten Labs, dem Entwicklerunternehmen von Sui. Er sagte: “Ich denke, die Einführung eines RISC-V-Backends ist eine gute Wahl für Ethereum (da es die Unterstützung bestehender EVM-Verträge benötigt). Aber wenn ich eine neue Kette von Grund auf neu entwerfen müsste, würde ich immer noch Move wählen, anstatt Mehrsprachigkeit zu unterstützen. Viele Vorteile von Sui ergeben sich gerade daraus, dass in der gesamten Stapelarchitektur stark typisierte Objekte als gemeinsame Abstraktionsschicht verwendet werden.”

Dies spiegelt die historischen Faktoren wider, die die “Auswahlstrategie für virtuelle Maschinen” verschiedener Blockchains beeinflussen. Ethereum wurde in der frühen Entwicklungsphase entworfen, ohne die vielen zukünftigen Anforderungen und Entwicklungen vorherzusehen. Derzeit wird aufgrund der Veränderungen die Kompatibilität und Übergangsgestaltung betont. Die neue öffentliche Blockchain Sui hingegen konzentriert sich auf die vollständige Integration vom Sprach- bis zum Basisschicht, wodurch Entwicklung und Sicherheit eng miteinander verbunden sind.

Typus Finance Wachstum Kyrie teilte auch ein Gespräch, das er in der Vergangenheit auf der EthTaipei-Veranstaltung mit Vitalik hatte. Er erinnerte sich: „Damals fragte ich Vitalik: ‚Glaubst du, dass die Move-Sprache und objektorientierte Einstellungen die Sicherheit der Blockchain erhöhen können?‘

Er antwortete: „Ich glaube nicht, dass sich dadurch irgendetwas ändert. Ein Projekt wird gestohlen, es ist egal in welcher Sprache.“

Aber Kyrie widersprach sofort und stellte fest, dass Move tatsächlich die Wahrscheinlichkeit von Entwicklungsfehlern verringern kann, einfacher zu erlernen ist als Rust und dass das objektorientierte Modell hilft, den Risikobereich einzuschränken. “Wenn ein Vertrag gestohlen wird, können die Verluste möglicherweise auf einen festen Betrag begrenzt werden, anstatt unbegrenzt exponiert zu sein,” fügte er hinzu.

Obwohl Vitalik damals keine Stellungnahme abgegeben hat, scheint sich seine Haltung zum Thema Sprachdesign in Bezug auf die Sicherheit von Blockchains leicht verändert zu haben, seitdem er jetzt bereit ist, RISC-V als eine stärkere, modulare Alternative vorzuschlagen.

Dieser Artikel über Ethereum-Herzoperationen? Vitalik schlägt vor, dass die Ethereum-Ausführungsschicht möglicherweise die EVM vollständig ersetzen könnte, indem sie RISC-V verwendet, was erstmals in Chain News ABMedia erschien.