Die Entwickler widerlegen Vitalik: Die Annahmen sind falsch, und RISC-V ist nicht die beste Wahl

Dieser Artikel stammt von: Ethereum Entwickler levochka.eth

compilation|Odaily Planet Daily (@OdailyChina); @azuma_eth Anmerkung der Redaktion

:

Gestern veröffentlichte Ethereum-Mitbegründer Vitalik einen radikalen Artikel über das Upgrade der Ausführungsschicht von Ethereum (siehe "Vitalik's Radical New Article: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the Future), in dem er erwähnte, dass er hofft, es durch RISC-V zu ersetzen EVM als Sprache für virtuelle Maschinen für Smart Contracts.

Sobald dieser Artikel veröffentlicht wurde, sorgte er sofort für einen Aufruhr in der Ethereum-Entwicklergemeinde, und viele technische Größen äußerten unterschiedliche Ansichten zu dem Plan. Kurz nach der Veröffentlichung des Artikels schrieb der Tier-1-Ethereum-Entwickler levochka.eth einen langen Artikel unter dem ursprünglichen Artikel, in dem er Vitaliks Argument widerlegte, dass Vitalik die falschen Annahmen über das Proof-System und seine Leistung getroffen habe und dass RISC-V möglicherweise nicht die beste Wahl sei, weil es "Skalierbarkeit" und "Wartbarkeit" nicht in Einklang bringen könne.

Im Folgenden finden Sie den Originalartikel auf levochka.eth, zusammengestellt von der Tageszeitung Odaily.

Bitte tun Sie das nicht.

Dieser Plan macht keinen Sinn, da Sie die falschen Annahmen über den Nachweis des Systems und seiner Leistung treffen.

Validierungshypothese

So wie ich es verstehe, sind die Hauptargumente für dieses Schema "Skalierbarkeit" und "Wartbarkeit".

Zuerst möchte ich über die Wartbarkeit sprechen.

Tatsächlich erfordern alle RISC-V zk-VMs "Vorkompilierungen", um rechenintensive Vorgänge zu verarbeiten. Die vorkompilierte Liste von SP 1 finden Sie in der Dokumentation von Succinct, und Sie werden feststellen, dass sie fast alle wichtigen "rechnerischen" Opcodes in der EVM abdeckt.

Infolgedessen erfordern alle Modifikationen an den kryptographischen Primitiven der Basisschicht das Schreiben und Prüfen neuer "Schaltkreise" für diese Vorkompilierungen, was eine ernsthafte Einschränkung darstellt.

Wenn die Leistung gut genug ist, kann es in der Tat relativ einfach sein, die Wartungsfreundlichkeit des "Nicht-EVM"-Teils des Clients zu gewährleisten. Ich bin mir nicht sicher, ob es gut genug ist, aber ich bin aus folgenden Gründen weniger zuversichtlich in diesem Teil:

• "State Tree Computation" kann in der Tat mit einer benutzerfreundlichen Vorkompilierung wie Poseidon stark beschleunigt werden.

• Es ist jedoch nicht klar, ob die "Deserialisierung" auf elegante und wartbare Weise gehandhabt werden kann.
  

• Darüber hinaus gibt es einige knifflige Details (wie z. B. Gasmessung und verschiedene Kontrollen), die unter die "Blockbewertungszeit" fallen können, aber eigentlich als "Nicht-EVM"-Teile eingestuft werden sollten, die tendenziell anfälliger für Wartungsdruck sind.

Zweitens der Teil über die Skalierbarkeit.

Ich muss noch einmal betonen, dass es für RISC-V unmöglich ist, EVM-Lasten zu verarbeiten, ohne die Vorkompilierung zu verwenden, absolut nicht.

Die Aussage im Originaltext, dass "die endgültige Beweiszeit von der aktuellen Vorkompilierungsoperation dominiert wird", ist also technisch korrekt, aber sie ist zu optimistisch - sie geht davon aus, dass es in der Zukunft keine Vorkompilierung geben wird, obwohl tatsächlich (in diesem Zukunftsszenario) die Vorkompilierung immer noch existieren wird, und ist genau dasselbe wie die rechenintensiven Opcodes in der EVM (wie Signaturen, Hashes und möglicherweise große Analoga).

Es ist schwer, das Fibonacci-Beispiel zu beurteilen, ohne auf die subtilsten Details einzugehen, aber die Vorteile kommen zumindest teilweise:

• der Unterschied zwischen Interpretation und Ausführung Overhead;

• Zyklische Entladung (Reduzierung des "Kontrollflusses" von RISC-V, es ist ungewiss, ob Solidity implementiert werden kann, aber selbst ein einziger Opcode kann aufgrund des Interpretationsaufwands immer noch eine große Anzahl von Kontrollfluss-/Speicherzugriffen erzeugen);

• Verwenden kleinerer Datentypen;

An dieser Stelle möchte ich darauf hinweisen, dass um die Vorteile von Punkt 1 und Punkt 2 zu realisieren, der "Interpretations-Overhead" entfallen muss. Dies entspricht der Philosophie von RISC-V, aber es handelt sich nicht um das RISC-V, um das wir gerade sprechen, sondern um ein ähnliches "(?)RISC-V" – es erfordert bestimmte zusätzliche Fähigkeiten, wie z.B. die Unterstützung von Vertragskonzepten.

Hier kommt das Problem

, also gibt es hier einige Probleme.

• Um die Wartbarkeit zu verbessern, benötigen Sie ein RISC-V (mit Vorkompilierung), das die EVM kompiliert - das war's auch schon.

• Um die Skalierbarkeit zu verbessern, ist etwas völlig anderes erforderlich – eine neue Architektur, die RISC-V ähneln könnte, die das Konzept der "Verträge" versteht, mit den Laufzeitbeschränkungen von Ethereum kompatibel ist und Vertragscode direkt ausführen kann (ohne den "Interpretations-Overhead").

Ich gehe jetzt davon aus, dass du dich auf den zweiten Fall beziehst (da der Rest des Artikels dies zu implizieren scheint). Ich möchte Sie darauf aufmerksam machen, dass der gesamte Code außerhalb dieser Umgebung weiterhin in der aktuellen RISC-V zkVM-Sprache geschrieben wird, was einen erheblichen Einfluss auf die Wartung hat.

Alternativ

können wir den Bytecode aus dem High-Level-EVM-Opcode kompilieren. Der Compiler ist dafür verantwortlich, sicherzustellen, dass der Generator invariant bleibt, z. B. wenn kein "Stapelüberlauf" auftritt. Ich würde es gerne sehen, wenn dies in einer normalen EVM angezeigt wird. Ordnungsgemäß kompilierte SNARKs können mit Anweisungen zur Vertragsbereitstellung versehen werden.

Wir können auch einen "formalen Beweis" konstruieren, der beweist, dass einige Invarianten erhalten bleiben. Soweit ich das beurteilen kann, wurde dieser Ansatz (nicht "Virtualisierung") in einigen Browserkontexten verwendet. Durch die Generierung von SNARKs dieses formalen Beweises können Sie ähnliche Ergebnisse erzielen. 

Am einfachsten ist es natürlich, in den sauren Apfel zu beißen und ......

Erstellen einer minimalen "verketteten" MMU

, was Sie in diesem Artikel implizit zum Ausdruck bringen können, aber lassen Sie mich warnen, dass Sie, wenn Sie den Virtualisierungs-Overhead eliminieren wollen, den kompilierten Code direkt ausführen müssen – was bedeutet, dass Sie irgendwie verhindern müssen, dass der Vertrag (jetzt ausführbar) in den Kernel-Speicher (keine EVM-Implementierung) schreibt.

Daher benötigen wir eine Art "Memory Management Unit" (MMU). Der Auslagerungsmechanismus herkömmlicher Computer ist möglicherweise nicht erforderlich, da der "physische" Speicherplatz nahezu unbegrenzt ist. Diese MMU sollte so schlank wie möglich sein (da sie sich auf der gleichen Abstraktionsebene wie die Architektur selbst befindet), aber einige Features, wie z. B. die Atomarität von Transaktionen, können auf diese Schicht verschoben werden.

An diesem Punkt wird die beweisbare EVM zum Kernel-Programm, das auf dieser Architektur läuft.

RISC-V ist möglicherweise nicht die beste Option

Interessanterweise ist unter all diesen Bedingungen die beste "Instruction Set Architecture" (ISA) für diese Aufgabe möglicherweise nicht RISC-V, sondern etwas Ähnliches wie EOF-EVM aus den folgenden Gründen:

• "Kleine" Opcodes führen tatsächlich zu einem hohen Speicherzugriff, der für vorhandene Nachweismethoden nur schwer effizient zu handhaben ist.

• Um den Branching-Overhead zu reduzieren, haben wir in unserem kürzlich erschienenen Artikel Morgana gezeigt, wie "Static Jumps"-Code (EOF) mit Leistung auf Precompile-Ebene nachgewiesen werden kann.

Mein Vorschlag ist, eine neue, proof-freundliche Architektur mit einer minimalen MMU zu erstellen, die es ermöglicht, den Vertrag als separate ausführbare Datei auszuführen. Ich glaube nicht, dass es RISC-V sein sollte, sondern eher eine neue ISA, die für die Einschränkungen des SNARK-Protokolls optimiert ist, und sogar eine ISA, die teilweise eine Teilmenge von EVM-Opcodes erbt, könnte besser sein - wie wir wissen, ist die Präkompilierung hier, um zu bleiben, ob wir es wollen oder nicht, also bringt RISC-V hier keine Vereinfachung.