Vitaliks neuer Vorschlag: RISC-V anstelle der aktuellen EVM verwenden

Dieser Artikel präsentiert eine radikale Idee für die Zukunft der Ethereum-Ausführungsschicht, die ebenso ehrgeizig ist wie die Bemühungen von Beam Chain um die Konsensschicht. Ziel ist es, die Effizienz der Ethereum-Ausführungsschicht erheblich zu steigern, eines der Hauptengpässe bei der Skalierung zu lösen und die Einfachheit der Ausführungsschicht erheblich zu verbessern – in der Tat könnte dies der einzige Weg sein.

Idee: RISC-V als virtuelle Maschinen-Sprache zur Erstellung von Smart Contracts anstelle von EVM verwenden (Anmerkung des Übersetzers: RISC-V bezieht sich auf eine offene Befehlssatzarchitektur, die auf dem Prinzip des reduzierten Befehlssatzes RISC basiert, wobei V für die fünfte Generation von RISC steht).

Wichtige Klarstellung:

• Konten, intercontractuelle Aufrufe, Speicherung und andere Konzepte werden vollständig gleich bleiben. Diese Abstraktionen funktionieren gut und Entwickler sind daran gewöhnt. Operationen wie SLOAD, SSTORE, BALANCE, CALL werden zu RISC-V-Systemaufrufen.
• In einer solchen Welt können Smart Contracts in Rust geschrieben werden, aber ich gehe davon aus, dass die meisten Entwickler weiterhin Smart Contracts in Solidity (oder Vyper) schreiben werden, was die Hinzufügung von RISC-V als Backend ermöglicht. Das liegt daran, dass Smart Contracts, die in Rust geschrieben sind, eigentlich ziemlich hässlich sind, während Solidity und Vyper viel besser lesbar sind. Vielleicht sind die Änderungen an DevEx so klein, dass Entwickler sie kaum bemerken.
• Alte EVM-Verträge bleiben weiterhin gültig und werden vollständig bidirektional mit neuen RISC-V-Verträgen interoperabel sein. Es gibt mehrere Möglichkeiten, dies zu erreichen, die ich später in diesem Artikel vorstellen werde.

Ein Beispiel ist Nervos CKB VM, das im Grunde genommen RISC-V ist.

Warum das?

Kurzfristig wird das Hauptengpass der Skalierbarkeit von Ethereum L1 durch die bevorstehenden EIPs gelöst, wie z.B. Blockzugriffslisten, verzögerte Ausführung und verteilte historische Speicherung sowie EIP-4444. Mittelfristig werden wir weitere Probleme mit dem zustandslosen und ZK-EVM angehen. Langfristig sind die Hauptbeschränkungen der Skalierung von Ethereum Layer1:

• Stabilität von Datenverfügbarkeits-Sampling und historischen Speicherprotokollen
• Hoffen, die Wettbewerbsfähigkeit des Blockproduktionsmarktes zu erhalten.
• ZK-EVM Validierungsfähigkeit

Ich denke, dass der Ersatz von ZK-EVM durch RISC-V einen wichtigen Engpass in (2) und (3) lösen kann.

Dies ist die Tabelle der Schleifenanzahl für verschiedene Teile der EVM-Ausführungsschicht, die von Succinct ZK-EVM verwendet wird:

Es gibt vier Teile, die viel Zeit in Anspruch nehmen: deserialize_inputs, initialize_witness_db, state_root_computation und block_execution.

initialize_witness_db und state_root_computation hängen beide mit dem Zustandbaum zusammen, deserialize_inputs bezieht sich auf den Prozess, bei dem Block- und Zeugeninformationen in interne Darstellungen umgewandelt werden; daher ist tatsächlich mehr als 50 % proportional zur Größe des Zeugen.

Diese Teile können erheblich optimiert werden, indem der aktuelle keccak 16 Merkle patricia Baum durch einen binären Baum ersetzt wird, der eine zeugenfreundliche Hash-Funktion verwendet. Wenn wir Poseidon verwenden, können wir auf einem Laptop 2 Millionen Hash-Werte pro Sekunde nachweisen (während keccak etwa 15.000 Hash-Werte pro Sekunde schafft). Neben Poseidon gibt es viele andere Optionen. Zusammenfassend haben wir die Möglichkeit, diese Komponenten erheblich zu reduzieren. Als Bonus können wir durch die Beseitigung von bloom auch accrue_logs_bloom loswerden.

Das Übrige ist block_execution, das etwa die Hälfte des heute verwendeten Beweiszyklus ausmacht. Wenn wir die Gesamteffizienz des Beweisers um das 100-fache steigern wollen, können wir der Tatsache nicht entkommen, dass wir die Effizienz des EVM-Beweisers um mindestens das 50-fache steigern müssen. Eine Sache, die wir tun können, ist, zu versuchen, eine effizientere EVM-Implementierung in Bezug auf den Beweiszyklus zu erstellen. Eine andere Sache, die wir tun können, ist, zu bemerken, dass der ZK-EVM-Beweiser heute bereits funktioniert, indem er den Beweis in eine RISC-V-EVM-Implementierung kompiliert, und den Entwicklern von Smart Contracts direkten Zugang zu dieser RISC-V-VM zu gewähren.

Einige Daten zeigen, dass dies unter bestimmten Bedingungen die Effizienz um mehr als das 100-fache steigern kann:

! JuLOouHUiv8vXajoUnYsOnYyFtRiCpO8cvkOUhPu.jpeg eigentlich erwarte ich, dass die verbleibende Proof-Zeit von der heutigen Vorkompilierung dominiert wird. Wenn wir RISC-V als primäre virtuelle Maschine nehmen, spiegelt der Gasplan die Testzeit wider, so dass finanzieller Druck besteht, die teurere Vorkompilierung nicht mehr zu verwenden. Aber selbst dann werden die Gewinne nicht so beeindruckend sein, aber wir haben guten Grund zu der Annahme, dass sie signifikant sein werden.

(Übrigens tritt eine etwa 50/50-Verteilung zwischen “EVM” und “anderen Dingen” auch in der regulären EVM-Ausführung auf, und wir erwarten intuitiv, dass die Gewinne, die durch die Entfernung von EVM als “Mittelsmann” erzielt werden, ebenfalls groß sein sollten.)

Umsetzung Details

Es gibt eine Reihe von Möglichkeiten, solche Empfehlungen umzusetzen. Der am wenigsten störende Ansatz besteht darin, zwei virtuelle Computer zu unterstützen und das Schreiben von Verträgen in beiden virtuellen Computern zuzulassen. Beide Arten von Verträgen können die gleiche Art von Einrichtungen nutzen: persistente Speicherung (SLOAD und SSTORE), die Möglichkeit, ETH-Guthaben zu halten, die Möglichkeit, Telefonanrufe zu tätigen und zu empfangen usw. EVM- und RISC-V-Verträge können sich gegenseitig frei aufrufen; Aus der Sicht von RISC-V scheint der Aufruf des EVM-Vertrags ein Systemaufruf mit einigen speziellen Parametern zu sein. Der EVM-Vertrag, der die Nachricht empfängt, interpretiert sie als CALL.

Aus der Perspektive des Protokolls wäre ein radikalerer Ansatz, bestehende EVM-Verträge in Verträge umzuwandeln, die einen in RISC-V geschriebenen EVM-Interpreter aufrufen, der seinen bestehenden EVM-Code ausführt. Das bedeutet, wenn ein EVM-Vertrag den Code C hat und der EVM-Interpreter sich an Adresse X befindet, wird dieser Vertrag durch die oberste Logik ersetzt, wenn er mit den externen Aufrufparametern D aufgerufen wird, indem (C, D) an X aufgerufen wird und dann auf den Rückgabewert gewartet und dieser weitergeleitet wird. Wenn der EVM-Interpreter selbst einen Vertrag aufruft und die Ausführung von CALL oder SLOAD/SSTORE anfordert, wird der Vertrag dies tun.

Die mittlere Route besteht darin, die zweite Option zu wählen, jedoch ein klares Protokoll-Feature dafür zu schaffen – im Grunde genommen wird das Konzept des „Virtuellen Maschineninterpreters“ als Maßstab genommen und seine Logik muss in RISC-V geschrieben werden. EVM wird die erste sein, aber es könnte auch andere geben (zum Beispiel könnte Move ein Kandidat sein).

EIN GROSSER VORTEIL DES ZWEITEN UND DRITTEN VORSCHLAGS IST, DASS SIE DIE SPEZIFIKATION DER EXEKUTIVEN SCHICHT STARK VEREINFACHEN - IN DER TAT KÖNNTE DIESE IDEE DER EINZIGE WEG SEIN, DA SELBST PROGRESSIVE VEREINFACHUNGEN WIE DAS ENTFERNEN DER SELBSTZERSTÖRUNG SEHR SCHWIERIG SIND. Tinygrad hat eine strenge Regel, dass die Menge an Code nie mehr als 10.000 Zeilen betragen sollte. Die optimale Blockchain-Basisschicht sollte in der Lage sein, sich gut an diese Grenzen anzupassen, oder sogar noch kleiner. Die Bemühungen von BeamChain sind vielversprechend, um die Konsensschicht von Ethereum erheblich zu vereinfachen. Aber für die Führungsebene könnte eine solch radikale Veränderung der einzige gangbare Weg sein, um ähnliche Vorteile zu erzielen.