Verfasst von: GaryMa Wu sagt Blockchain
Einleitung
Ethereum-Mitbegründer Vitalik Buterin hat kürzlich in der Ethereum Magicians-Community einen langfristigen Vorschlag gemacht, die aktuelle Execution Layer Virtual Machine (EVM) durch die Open-Source-Befehlssatzarchitektur RISC-V zu ersetzen. Er vergleicht diese Idee mit der Beam Chain der Konsensschicht, die er als den einzigen möglichen Weg sieht, um einen Leistungsdurchbruch auf der Ausführungsebene zu erzielen und die Protokolllogik zu vereinfachen. Insbesondere in Bezug auf die Effizienz des Zero-Knowledge-Proofs (ZK-Proof) erwartet Vitalik eine bis zu 100-fache Optimierungsverbesserung durch den Austausch von EVMs. Der Vorschlag zielt darauf ab, die aktuellen Engpässe von Ethereum in Bezug auf die ZK-Proof-Effizienz, die Komplexität der Blockkonstruktion, die Datenverfügbarkeit usw. zu beheben.
Dieser Artikel wird in einfacher Sprache die Motive, technischen Details, Umsetzungswege und Herausforderungen des Vorschlags analysieren, seine Auswirkungen auf den bestehenden Skalierungsansatz von Ethereum untersuchen und die Reaktionen der Community sowie ähnliche Versuche Revue passieren lassen.
EVM Probleme:
Veraltete Architektur: EVM verwendet eine 256-Bit-Stack-Struktur, die nicht mit modernen CPUs kompatibel ist, was zu einer ineffizienten Ausführung von ZK-EVM führt.
ZK-Bescheinigungsengpass: Wie Succinct beschreibt, wird etwa die Hälfte der Ressourcen von ZK-EVM für die Ausführung der ZK-Bescheinigung selbst verwendet, was die Effizienz der ZK-Bescheinigung einschränkt.
Schlechte Wartbarkeit: Über die Jahre angesammelte komplexe Funktionen und chaotische Standards, wie z.B. ist SELFDESTRUCT schwer abzuschaffen.
Entwicklungsbeschränkungen: Nicht-standardisierte Befehlssatzbeschränkungen schränken die plattformübergreifende Unterstützung ein, was es Mainstream-Sprachen erschwert, effizient in EVM-Bytecode zu kompilieren.
Die Vorteile von RISC-V:
Hocheffiziente Leistung: RISC-V ist ein reduziertes Befehlssatzarchitektur von echten CPUs, hardwarefreundlich und kann für JIT-Optimierung oder sogar Hardwarebeschleunigung verwendet werden.
ZK Optimierung: Die direkte Generierung von Schaltkreisen für RISC-V-Anweisungen in ZK-Beweisen ist einfacher als der Nachweis von EVM-Operationen.
Reife Toolchain: Unterstützung für gängige Sprachen wie Rust/C/C++, niedrigere Einstiegshürden und breitere Ökosysteme.
Allgemeiner Standard: Bereits von Blockchains wie Nervos CKB übernommen, mit erfolgreichen Anwendungsfällen.
Vitalik wies darauf hin, dass es besser wäre, RISC-V direkt als Vertragsausführungsarchitektur zu verwenden, anstatt die EVM in ZK-EVM in RISC-V zu kompilieren, um die Ausführungseffizienz und das Erweiterungspotenzial grundlegend zu verbessern.
Zwei, Ersatzwege und Herausforderungen: Wie migriert man von EVM?
Drei Ersatzoptionen:
Dual-VM-Betrieb (die konservativste Variante): EVM und RISC-V laufen parallel, neue Verträge können RISC-V wählen, um die Kompatibilität während der Übergangszeit sicherzustellen.
On-Chain Interpreter Lösung (aggressiv): Alle EVM Verträge werden durch On-Chain RISC-V Verträge interpretiert und ausgeführt.
Erweiterungsmechanismus für Interpreter (Kompromiss): Den Interpreter als Protokollelement verwenden, um zukünftige Einfügungen anderer VMs (z. B. Move) zu ermöglichen.
Technologische Herausforderungen bei der Implementierung:
Risiko des Leistungsabfalls bei der Ausführung: RISC-V muss auf x 86-Chips simuliert werden, was möglicherweise anfänglich weniger effizient ist als ein optimiertes EVM.
Gas-Bewertung muss neu strukturiert werden: Es muss ein neues Gas-Modell für RISC-V-Anweisungen definiert werden, um Fairness und Sicherheit zu gewährleisten.
Sichere Sandbox-Design: Einschränkung der Systemaufrufe, Verhinderung von Selbstmodifikation des Codes, Gewährleistung der deterministischen Ausführung.
Entwicklungstools anpassen: Compiler, Debugger und Sicherheitsprüfwerkzeuge müssen aktualisiert werden, um RISC-V Bytecode zu unterstützen.
Migrationskompatibilitätsprobleme: Einige Verträge hängen von EVM-Funktionen ab, daher muss die Migration sorgfältig mit einer Kompatibilitätsschicht oder einem Rückfallmechanismus entworfen werden.
Vitalik neigt zu Option Eins als Übergangsweg und verspricht, dass die alten und neuen Verträge interoperabel bleiben, um sicherzustellen, dass die Entwicklererfahrung unverändert bleibt und die Benutzer ein nahtloses Upgrade erleben.
Drittens, Auswirkungen auf die bestehende Erweiterungsstrategie: Wird RISC-V L 2, Daten-Sharding usw. ersetzen?
Die Antwort ist negativ: RISC-V ist eine Infrastrukturoptimierung und wird den bestehenden Skalierungsweg nicht ersetzen.
Layer 2:
Rollup ist weiterhin die Hauptkraft für die Skalierung von Ethereum. RISC-V verbessert die Verarbeitungseffizienz von L 1 und die ZK-Validierungsleistung, anstatt direkt die Durchsatzkapazität zu erweitern.
Die schnellere L1-Validierung hilft Rollups, Daten kostengünstiger und schneller zu übermitteln und die allgemeine Skalierbarkeit zu verbessern.
Daten-Sharding und EIP-4844:
Die Engpässe bei der Datenverfügbarkeit müssen weiterhin durch EIP-4844 (Blob) und Danksharding gelöst werden, RISC-V hat keinen Einfluss auf die On-Chain-Datenkapazität.
Die Durchführung von Änderungen an der Architektur verändert nicht die Datenstorage-Anforderungen von L 1.
FaaS, MEV:
Unabhängig von der Architektur der virtuellen Maschine, wird es durch den Fortschritt von RISC-V nicht obsolet.
Zusammenfassung: RISC-V ist “Wechselmotor”, L 2/Sharding ist “Erweiterungsnetz”, die beiden Dimensionen sind unterschiedlich und parallel zueinander.
Vier, Community-Feedback und verwandte Versuche
Gemeinschaftliche Meinungsverschiedenheit:
Befürworter: Sie glauben, dass dies ein notwendiges strategisches Upgrade ist, um den Leistungsherausforderungen von Solana/Sui usw. zu begegnen und traditionelle Entwickler anzuziehen.
Konservative: Sorgen über die Umsetzungsschwierigkeiten, die historische Last und die hohen Kosten für die Aktualisierung der ökologischen Toolchain, zweifeln am Verhältnis von Ressourceneinsatz und -ausbeute.
Ähnliche Projektverweise:
Move VM (Aptos/Sui): Eine brandneue ressourcenorientierte VM, die eine starke Sprachsicherheit bietet, jedoch nicht mit EVM kompatibel ist.
FuelVM: Eine neue VM, die für parallele Verarbeitung entwickelt wurde, mit der Sprache Sway, begrenzte Kompatibilität.
WASM (Stylus): Einführung von WASM als Vertragssprache in L 2, jetzt in Arbitrum implementiert, mit praktischer Durchführbarkeit.
Nervos CKB: Der Einsatz von RISC-V als Vertrags-VM im Hauptnetz ist ein Präzedenzfall und bietet praktische Referenzen für Ethereum.
Vitalik hat vorgeschlagen, dass RISC-V nicht bedeutet, andere Optionen abzulehnen. Er glaubt, dass zukünftige Interpreter-Mechanismen auch verwendet werden können, um VMs wie Move, WASM usw. einzufügen und ein vielfältiges Ausführungsökosystem aufzubauen.
Fünf, Ausblick auf zukünftige Auswirkungen: Wenn Ethereum auf RISC-V umschaltet
Entwicklererfahrung:
Solidity/Vyper und andere Sprachen können weiterhin verwendet werden, der Compiler-Backend ändert sich, nicht die Sprache selbst.
Es könnte möglich sein, neue Sprachen wie Rust/C für das Schreiben von Smart Contracts zu öffnen, aber eine Migration ist nicht zwingend erforderlich.
Betriebskosten und Leistung:
Die Verbesserung der Ausführungseffizienz wird eine höhere Gasgrenze und niedrigere Gebühren mit sich bringen.
RISC-V Verträge könnten die Abhängigkeit von vorcompilierten Verträgen verringern, das Gas-Modell ist näher an den ZK Nachweis-Kosten.
Ökologische Kompatibilität und Entwicklung:
Während der Co-Existenz von zwei VMs können bestehende Verträge weiterhin betrieben werden, neue Verträge werden schrittweise RISC-V übernehmen.
Die Infrastruktur muss das neue Bytecode-Format unterstützen, was möglicherweise zu Änderungen der Interoperabilität zwischen den Blockchains führt (z. B. Probleme mit dem Verbleib oder Nichtverbleib von BSC und Polygon).
Sicherheit und Stabilität:
Die neue Architektur muss umfassend getestet und formal verifiziert werden, um die Zuverlässigkeit des Protokolls zu erhöhen.
Eine einfachere Ausführungsebene begünstigt die Prüfung und die Kontrolle der Angriffsfläche.
Schlusswort
Vitalik schlug vor, RISC-V anstelle der Ethereum EVM zu verwenden, was eine tiefgreifende Überlegung von Ethereum zu den zukünftigen Leistungsgrenzen und der Einfachheit des Protokolls darstellt. Dieser Vorschlag befindet sich noch in der frühen Diskussionsphase, und die Umsetzung wird voraussichtlich ein mehrjähriger Prozess sein, der zahlreiche technische, gemeinschaftliche und ökologische Herausforderungen überwinden muss. Es geht nicht darum, den bestehenden Kurs umzukippen, sondern darum, die Grundlagen zu stärken und sich auf die Zukunft vorzubereiten.
Wie Vitalik sagte: „Um eine Steigerung um Größenordnungen zu erreichen, könnte diese radikale Veränderung der einzige gangbare Weg sein.“
Wir können es als eine Wette auf die Zukunft betrachten, sowie als eine tiefgehende Erkundung der Frage, ob die “Basis neu gestaltet werden sollte”.