Vitaliks neuer Vorschlag: RISC-V als virtuelle Maschinensprache für EVM-Smart Contracts

Quelle: Vitalik Buterin, Ethereum Magicians; Zusammenstellung: Tao Zhu, Bitchain Vision

Dieser Artikel enthält eine aggressive Idee für die Zukunft der Ausführungsschicht von Ethereum, die ebenso ehrgeizig ist wie die Bemühungen der Strahlkette zur Konsensschicht.Ziel ist es, die Effizienz der Ethereum -Ausführungsschicht erheblich zu erhöhen, einen der wichtigsten Skalierungsgpässe zu lösen und die Einfachheit der Ausführungsschicht erheblich zu verbessern. Tatsächlich ist dies möglicherweise der einzige Weg.

Idee: Verwenden Sie RISC-V als virtuelle Maschinensprache zum Schreiben von EVM-Smart Contracts.

Wichtige Klarstellung:

• Die Konzepte von Konten, Übertragungsanrufen, Speicher usw. bleiben genau gleich. Diese Abstraktionen funktionieren gut und Entwickler gewöhnen sich an sie. STOAD, SSTORE, BALIGKEIT, CALL UND ANDERE OPCODES werden RISC-V-Systemanrufe.

• In einer solchen Welt können intelligente Verträge in Rost geschrieben werden, aber ich erwarte, dass die meisten Entwickler weiterhin intelligente Verträge in Solidität (oder Vyper) schreiben, die sich an das Hinzufügen von RISC-V als Backend anpassen. Dies liegt daran, dass intelligente Verträge in Rost tatsächlich ziemlich hässlich sind, während Solidity und Vyper viel lesbarer sind. Vielleicht ist die Änderung des Devex gering, und Entwickler können diese Änderung kaum bemerken.

• EVM-Verträge im alten Stil sind weiterhin gültig und sind mit den neuen RISC-V-Verträgen vollständig bidirektional interoperabel. Es gibt verschiedene Möglichkeiten, dies zu tun, die ich später in diesem Artikel behandeln werde.

Ein Präzedenzfall ist der Nervos CKB VM, der im Grunde genommen RISC-V ist.

Warum tun das?

Kurzfristig werden die wichtigsten Engpässe in der Skalierbarkeit von Ethereum L1 mit bevorstehenden EIPs wie Block-Level-Zugriffslisten, Latenzausführung und verteiltem historischem Speicher sowie EIP-4444 behandelt. Mittelfristig werden wir weitere Fragen der Staatenlosigkeit und des ZK-EVM angehen. Langfristig sind die wichtigsten Grenzfaktoren für die Expansion der Ethereum Layer1:

• Datenverfügbarkeitsabtastung und Stabilität historischer Speicherprotokolle

• Ich hoffe, den Blockproduktionsmarkt wettbewerbsfähig zu halten

• ZK-EVM-Überprüfungsfähigkeit

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

Dies ist die Anzahl der Loops, die von prägnantem ZK-EVM verwendet werden, um verschiedene Teile der EVM-Ausführungsschicht zu beweisen:

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 beziehen sich beide mit Zustandsbäumen, und Deserialize_inputs bezieht sich auf den Prozess des Umwandlung von Blöcken und Zeugendaten in interne Darstellungen. Tatsächlich sind mehr als 50% proportional zur Zeugenskala.

Diese Teile können stark optimiert werden, indem der aktuelle 16-köpfige Merkle Patricia Tree von Keccak durch einen binären Baum ersetzt wird, der prover-freundliche Hash-Funktionen verwendet. Wenn wir Poseidon verwenden, können wir auf unserem Laptop 2 Millionen Hashes pro Sekunde nachweisen (und Keccak -Hashes etwa 15.000 Hashes pro Sekunde). Neben Poseidon gibt es viele andere Optionen. Alles in allem haben wir die Möglichkeit, diese Komponenten drastisch zu reduzieren. Als Bonus können wir ACCGRUE_LOGS_BLOOM entfernen, indem wir Blüte loswerden.

Der Rest ist Block_execution, der etwa die Hälfte des heute ausgegebenen Beweiszyklus ausmacht. Wenn wir die Effizienz des Gesamtprovers um das 100 -fache erhöhen möchten, können wir nicht vermeiden, dass wir die Effizienz des EVM -Provers um mindestens 50 Mal erhöhen müssen. Eine Sache, die wir tun können, ist zu versuchen, EVM -Implementierungen zu erstellen, die in Beweiszyklen effizienter sind. Eine andere Sache, die wir tun können, ist zu beachten, dass der ZK-EVM-Prover heute gearbeitet hat, indem er beweist, dass die EVM-Implementierung in RISC-V zusammengestellt wurde und Smart Contract-Entwickler direkten Zugriff auf diese RISC-V VM ermöglicht.

Einige Daten legen nahe, dass dies in begrenzten Fällen die Effizienz um mehr als das 100 -mal erhöhen kann:

Tatsächlich erwarte ich, dass die verbleibende Beweiszeit von der heutigen Vorkompilierung dominiert wird. Wenn wir RISC-V als primäre virtuelle Maschine verwenden, spiegelt der Gasplan die Nachweiszeit wider, sodass wirtschaftlicher Druck auf die Verwendung teurerer Vorkompiloren eingestellt werden. Trotzdem werden die Vorteile nicht so beeindruckend sein, aber wir haben guten Grund zu der Annahme, dass die Vorteile sehr wichtig sein werden.

(Übrigens erscheint der Aufteil zwischen „EVM“ und „Other Stuff“ auch in der regulären EVM -Ausführung, und wir erwarten intuitiv, dass die Vorteile des Entfernens von EVM als „The Middleman“ gleich groß sein sollten)

Implementierungsdetails

Es gibt verschiedene Möglichkeiten, solche Vorschläge umzusetzen. Der am wenigsten disruptive Ansatz besteht darin, zwei virtuelle Maschinen zu unterstützen und Verträge in beiden virtuellen Maschinen zu ermöglichen. Beide Arten von Verträgen können dieselbe Art von Einrichtungen verwenden: Persistente Speicherung (STOAD und SSTORE), die Fähigkeit, ETH-Guthaben zu halten, die Fähigkeit, Anrufe zu tätigen und zu empfangen, usw. Die EVM- und RISC-V-Verträge können sich gegenseitig anrufen. Aus Sicht der RISC-V-Sicht scheint es den EVM-Vertrag zu berufen, einen Systemanruf mit einigen speziellen Parametern zu tätigen. Der EVM -Vertrag, der die Nachricht empfängt, interpretiert sie als Anruf.

Aus Protokollperspektive besteht ein radikalere Ansatz darin, einen bestehenden EVM-Vertrag in einen Vertrag umzuwandeln, der einen in RISC-V geschriebenen EVM-Interpreter-Vertrag bezeichnet, der seinen vorhandenen EVM-Code ausführt. Wenn der EVM-Vertrag Code C hat und der EVM-Interpreter an der Adresse X ist, wird der Vertrag durch die Logik der obersten Ebene ersetzt. Wenn Sie von außen von dem Anrufparameter D aufgerufen werden, wird X mit (c, d) aufgerufen, und warten Sie dann auf den Rückgabewert und leiten Sie ihn weiter. Wenn der EVM -Dolmetscher selbst den Vertrag anruft und Anruf oder Sload/SSTORE ausführt, tut dies der Vertrag.

Die Zwischenroute besteht darin, die zweite Option zu übernehmen, aber eine klare Protokollfunktion dafür erstellen – im Grunde wird das Konzept des „Virtual Machine Interpreter“ als Leitfaden genommen und seine Logik muss in RISC -V geschrieben werden. EVM wird der erste sein, aber es kann andere geben (z. B. kann ein Kandidat sein).

Einer der Hauptvorteile des zweiten und dritten Vorschlags besteht darin, dass sie die Spezifikationen für Ausführungsschicht erheblich vereinfachen. Tatsächlich kann diese Idee der einzig praktikable Ansatz sein, da selbst eine fortschreitende Vereinfachung wie das Entfernen von Selbstentrudent sehr schwierig ist. Tinygrad hat eine strenge Regel, dass das Codevolumen nie 10.000 Zeilen überschreitet. Die beste Blockchain -Grundschicht sollte in der Lage sein, sich gut an diese Grenzen anzupassen, sogar kleiner. Die Bemühungen der Strahlketten haben große Hoffnung, die Konsensschicht von Ethereum stark zu vereinfachen. Für die Ausführungsschicht kann diese radikale Veränderung jedoch der einzig praktikable Weg sein, um ähnliche Vorteile zu erzielen.