Vollständiger Text des langfristigen L1-Executive-Layer-Vorschlags von Vitalik: Ersatz des EVM durch RISC-V

Quelle: Vitalik Buterin

Zusammenstellung: KarenZ, Foresight News

Am 20. April präsentierte Vitalik Buterin einen wichtigen Vorschlag auf der Ethereum Magicians-Plattform für die langfristige L1-Ausführungsschicht von Ethereum. Er schlug vor, die bestehende EVM (Ethereum Virtual Machine) durch die RISC-V-Architektur als virtuelle Maschinensprache zum Schreiben von Smart Contracts zu ersetzen, mit dem Ziel, die betriebliche Effizienz der Ausführungsschicht von Ethereum grundlegend zu verbessern, einen der aktuellen großen Skalierungsengpässe zu durchbrechen und die Einfachheit der Ausführungsschicht erheblich zu vereinfachen.

Foresight News hat den vollständigen Text des Vorschlags zusammengestellt, um den Lesern zu helfen, diese technische Vision zu verstehen. Im Folgenden finden Sie eine Zusammenstellung des ursprünglichen Vorschlags:

Dieses Papier stellt eine radikale Idee über die Zukunft der Ausführungsschicht von Ethereum vor, die nicht weniger ehrgeizig ist als die Beam Chain-Initiativen der Konsensschicht. Der Vorschlag zielt darauf ab, die Effizienz der Ausführungsschicht von Ethereum drastisch zu verbessern, einen der größten Skalierungsengpässe zu beheben und die Ausführungsschicht erheblich zu vereinfachen – tatsächlich könnte dies der einzige Weg sein, dies zu erreichen.

Kernidee: EVM durch RISC-V als Sprache für virtuelle Maschinen für Smart Contracts ersetzen.

Wichtige Hinweise:

• Konzepte wie Account-System, Cross-Contract-Calling, Storage usw. werden vollständig beibehalten. Diese abstrakten Designs funktionieren gut und Entwickler sind es gewohnt, sie zu verwenden. OPCODES WIE SLOAD, SSTORE, BALANCE, CALL USW. WERDEN IN RISC-V-SYSTEMAUFRUFE KONVERTIERT.

• In diesem Modus können Smart Contracts in Rust geschrieben werden, aber ich gehe davon aus, dass die meisten Entwickler weiterhin Verträge in Solidity (oder Vyper) schreiben werden, die sich an RISC-V als neues Backend anpassen werden. Denn Smart Contracts, die in Rust geschrieben wurden, sind tatsächlich weniger lesbar, während Solidity und Vyper klarer und leichter zu lesen sind. Die Entwicklungserfahrung wird möglicherweise kaum beeinträchtigt, und Entwickler bemerken die Änderung möglicherweise nicht einmal.

• Der alte EVM-Vertrag läuft weiter und ist vollständig bidirektional mit dem neuen RISC-V-Vertrag kompatibel. Hierfür gibt es mehrere Möglichkeiten, auf die weiter unten in diesem Artikel näher eingegangen wird.

Nervos CKB VM hat einen Präzedenzfall geschaffen und ist im Wesentlichen eine RISC-V-Implementierung.

Warum?

Kurzfristig werden kommende EIPs (z. B. Zugriffslisten auf Blockebene, verzögerte Ausführung, verteilte Verlaufsspeicherung und EIP-4444) die größten Skalierungsengpässe von Ethereum L1 beheben. Mit Staatenlosigkeit und ZK-EVM werden mittelfristig weitere Probleme gelöst werden. Langfristig werden die wichtigsten limitierenden Faktoren für die Skalierung von Ethereum L1 sein:

1. Stabilität von Datenverfügbarkeit, Sampling und historischen Speicherprotokollen

2. Aufrechterhaltung der Wettbewerbsnachfrage auf dem Markt der Blockproduktion

3. Nachweis der ZK-EVM

Ich werde argumentieren, dass der Ersatz von ZK-EVM durch RISC-V die wichtigsten Engpässe in (2) und (3) beheben kann.

Die folgende Tabelle zeigt die Anzahl der Zyklen, die für jeden Schritt der Succinct ZK-EVM Proof EVM-Ausführungsschicht erforderlich sind:

Diagrammbeschreibung: Die vier wichtigsten zeitaufwändigen Segmente sind deserialize_inputs, initialize_witness_db, state_root_computation und block_execution

initialize_witness_db und state_root_computation beziehen sich auf Zustandsbäume, und deserialize_inputs den Prozess der Umwandlung von Block- und Zeugendaten in interne Darstellungen umfassen – mehr als 50 % davon sind tatsächlich proportional zur Größe der Zeugendaten.

Diese Abschnitte können stark optimiert werden, indem der aktuelle keccak 16-ary Merkle Patricia-Baum durch einen Binärbaum ersetzt wird, der eine leicht zu beweisende Hash-Funktion verwendet. Wenn wir Poseidon verwenden, können wir 2 Millionen Hashes pro Sekunde auf einem Laptop nachweisen (im Vergleich zu etwa 15.000 Hashes/s bei keccak). Neben Poseidon gibt es noch viele weitere Möglichkeiten. Insgesamt gibt es bei diesen Komponenten viel Raum für Optimierungen. Darüber hinaus können wir accrue_logs_bloom beseitigen, indem wir die Ausblühung entfernen.

Die verbleibende block_execution macht etwa die Hälfte der aktuellen Gärzyklen aus. Um eine 100-fache Steigerung der Gesamtproof-Effizienz zu erreichen, ist eine EVM-Proof-Effizienz von mindestens 50x erforderlich. Eine Lösung besteht darin, eine effizientere Proof-Implementierung für die EVM zu erstellen, und die andere besteht darin, zu bemerken, dass der aktuelle ZK-EVM-Prover die EVM tatsächlich zu Proof-Zwecken in RISC-V kompiliert, wodurch Smart-Contract-Entwickler direkten Zugriff auf die virtuelle RISC-V-Maschine erhalten.

Einige Daten zeigen, dass es in bestimmten Situationen zu Effizienzsteigerungen von mehr als dem 100-fachen kommen kann:

In der Praxis kann die verbleibende Testzeit hauptsächlich durch den aktuellen Vorkompilierungsvorgang belegt werden. Mit RISC-V als primärer VM spiegelt der Gasplan die tatsächliche Proofzeit wider, und der wirtschaftliche Druck wird Entwickler dazu veranlassen, den Einsatz von kostenintensiven Vorkompilierungen zu reduzieren. Selbst dann werden die Gewinne nicht so groß sein, aber wir haben guten Grund zu der Annahme, dass sie erheblich sein werden.

(Es ist erwähnenswert, dass die Zeit, die für "EVM-Operationen" und "andere Operationen" bei der regulären EVM-Ausführung benötigt wird, ebenfalls nahe bei 50/50 liegt, so dass wir intuitiv davon ausgehen, dass das Entfernen der EVM als "Zwischenschicht" einen ebenso signifikanten Gewinn bringt.)

Details zur Implementierung

Es gibt mehrere Möglichkeiten, diesen Vorschlag umzusetzen. Die am wenigsten störende Lösung besteht darin, beide virtuellen Maschinen zu unterstützen und das Schreiben des Vertrags in einer von ihnen zu ermöglichen. Beide Arten von Verträgen haben Zugriff auf die gleichen Funktionen: persistenter Speicher (SLOAD/SSTORE), die Möglichkeit, ETH-Guthaben zu halten, Anrufe zu initiieren/empfangen und vieles mehr. EVM- und RISC-V-Verträge können gegenseitig aufgerufen werden - aus der RISC-V-Perspektive entspricht der Aufruf des EVM-Vertrags dem Ausführen eines Systemaufrufs mit speziellen Parametern. Der EVM-Vertrag, der die Nachricht empfängt, interpretiert sie als CALL.

Ein radikalerer Ansatz aus Protokollsicht besteht darin, einen vorhandenen EVM-Vertrag in einen Aufruf eines in RISC-V geschriebenen EVM-Interpretervertrags umzuwandeln, um den vorhandenen EVM-Code auszuführen. Das heißt, wenn ein EVM-Vertrag den Code C hat und sich der EVM-Interpreter an Adresse X befindet, wird der Vertrag durch eine Logik der obersten Ebene ersetzt, die bei einem Aufruf von außen mit einem Aufrufargument D X aufruft und (C, D) übergibt, dann auf den Rückgabewert wartet und weiterleitet. Wenn der EVM-Interpreter selbst den Vertrag aufruft und darum bittet, CALL oder SLOAD/SSTORE auszuführen, führt der Vertrag diese Vorgänge aus.

Der Kompromiss ist die zweite Option, aber mit ausdrücklicher Unterstützung des Konzepts eines "Interpreters für virtuelle Maschinen" durch ein Protokoll, das erfordert, dass seine Logik in RISC-V geschrieben wird. EVM wird die erste Instanz sein, mit Unterstützung für andere Sprachen in der Zukunft (Move könnte ein Kandidat sein).

Der Hauptvorteil der zweiten und dritten Option besteht darin, dass sie die Spezifikation der Ausführungsschicht erheblich vereinfachen. ANGESICHTS DER SCHWIERIGKEIT, INKREMENTELLE VEREINFACHUNGEN WIE SELBSTZERSTÖRUNG ÜBERHAUPT ZU ENTFERNEN, KÖNNTE DIESE DENKWEISE DER EINZIGE GANGBARE WEG ZUR VEREINFACHUNG SEIN. Tinygrad hält sich an die harte Regel "nicht mehr als 10.000 Zeilen Code", und die optimale zugrunde liegende Blockchain sollte in der Lage sein, dieses Limit problemlos einzuhalten und weiter zu rationalisieren. Die Beam-Chain-Initiative verspricht, die Konsensschicht von Ethereum drastisch zu vereinfachen, und eine solche radikale Änderung könnte der einzige Weg sein, einen ähnlichen Schub auf der Ausführungsebene zu erreichen.