Zhang Ye, Mitbegründer von Scroll, sprach im ersten Teil über den Entwicklungshintergrund und warum wir zkEVM überhaupt brauchen und warum es in den letzten zwei Jahren so beliebt geworden ist Erklärt, wie ein vollständiger Prozess zum Erstellen von zkEVM arithmetische und Beweissysteme umfasst. Im dritten Teil werden einige interessante Forschungsfragen erläutert, die beim Erstellen von zkEVM auftreten, und schließlich werden einige andere Anwendungen vorgestellt, die zkEVM verwenden.
Bei der herkömmlichen Layer-1-Blockchain werden einige Knoten über das P2P-Netzwerk gemeinsam verwaltet. Wenn sie die Transaktion des Benutzers erhalten, führen sie diese in der virtuellen EVM-Maschine aus, lesen den aufrufenden Vertrag und den Speicher und aktualisieren den globalen Statusbaum entsprechend der Transaktion.
Der Vorteil einer solchen Architektur liegt in der Dezentralisierung und Sicherheit. Der Nachteil besteht darin, dass die Transaktionsgebühren auf L1 hoch sind und die Transaktionsbestätigung langsam ist.
In der ZK-Rollup-Architektur muss das L2-Netzwerk nur die Daten und den Beweis hochladen, um die Richtigkeit der Daten auf L1 zu überprüfen, wo der Beweis über eine wissensfreie Beweisschaltung berechnet wird.
Im frühen ZK-Rollup war die Schaltung für bestimmte Anwendungen konzipiert. Benutzer mussten Transaktionen an verschiedene Prüfer senden, und dann übermittelten ZK-Rollups verschiedener Anwendungen ihre eigenen Daten und Nachweise an L1. Das Problem dabei ist, dass die Zusammensetzbarkeit des ursprünglichen L1-Vertrags verloren geht.
Was Scroll macht, ist eine native zkEVM-Lösung, bei der es sich um ein universelles ZK-Rollup handelt. Dies ist nicht nur benutzerfreundlicher, sondern bietet Entwicklern auch ein besseres Entwicklungserlebnis auf L1. Natürlich ist die Entwicklung dahinter sehr schwierig und auch die Kosten für die aktuelle Beweiserstellung sind sehr hoch.
Glücklicherweise hat sich die Effizienz wissensfreier Beweise in den letzten zwei Jahren erheblich verbessert, weshalb zkEVM in den letzten zwei Jahren so beliebt geworden ist. Es gibt mindestens vier Gründe, warum dies möglich ist. Der erste ist das Aufkommen der Polynombindung. Unter dem ursprünglichen Groth16-Beweissystem war der Umfang der Einschränkungen sehr groß, aber die Polynombindung kann Einschränkungen höherer Ordnung unterstützen und den Umfang verringern Beweis; zweitens kann das Aufkommen von Nachschlagetabellen und benutzerdefinierten Gattern flexiblere Designs unterstützen und Beweise effizienter machen; drittens sind Durchbrüche in der Hardwarebeschleunigung möglich, die die Beweiszeit durch GPU, FPGA und ASIC um ein bis zwei Größenordnungen verkürzen können . Der vierte Beim rekursiven Beweis können mehrere Beweise zu einem Beweis komprimiert werden, wodurch der Beweis kleiner und einfacher zu überprüfen ist. Durch die Kombination dieser vier Faktoren ist die Generierungseffizienz von Zero-Knowledge-Beweisen um drei Größenordnungen höher als vor zwei Jahren, was auch der Ursprung von Scoll ist.
Gemäß der Definition von Justin Drake kann zkEVM in drei Kategorien unterteilt werden: Die erste Kategorie ist die Kompatibilität auf Sprachebene. Der Hauptgrund dafür ist, dass EVM nicht für ZK entwickelt wurde und viele Opcodes enthält, die für ZK nicht geeignet sind viel zusätzlicher Aufwand. Daher entscheiden sich Unternehmen wie Starkware und zkSync dafür, Solidity oder Yul auf Sprachebene in ZK-freundliche Compiler zu kompilieren.
Der zweite Typ ist die von Scroll durchgeführte Kompatibilität auf Bytecode-Ebene, die direkt beweist, ob die Bytecode-Verarbeitung des EVM korrekt ist oder nicht, und die Ausführungsumgebung von Ethereum direkt erbt. Einige Kompromisse, die hier gemacht werden können, bestehen darin, eine andere Statuswurzel als die EVM zu verwenden, beispielsweise die Verwendung einer ZK-freundlichen Datenstruktur. Hermez und Consensys machen etwas Ähnliches.
Die dritte Kategorie ist die Kompatibilität auf Konsensebene. Der Kompromiss besteht darin, dass nicht nur die EVM unverändert bleiben muss, sondern auch die Speicherstruktur einbezogen werden muss, um eine vollständige Kompatibilität mit Ethereum zu erreichen, allerdings auf Kosten einer längeren Prüfzeit. Scroll wird in Zusammenarbeit mit dem PSE-Team der Ethereum Foundation entwickelt, um die ZKisierung von Ethereum zu realisieren.
Im zweiten Teil zeigte Zhang Ye allen, wie man ZKVM von Grund auf erstellt.
Kompletter Prozess
Zunächst müssen Sie im Front-End-Teil von ZKP Ihre Berechnungen durch mathematische Arithmetik ausdrücken. Am häufigsten werden lineare R1CS sowie Plonkish und AIR verwendet. Nachdem Sie die Einschränkungen durch Arithmetik erhalten haben, müssen Sie den Beweisalgorithmus im Backend von ZKP ausführen, um die Richtigkeit der Berechnung zu beweisen. Hier sind die am häufigsten verwendeten polynomialen interaktiven Oracle-Beweise (Polynomial IOP) und das Polynom-Commitment-Schema (PCS).
Hier müssen wir beweisen, dass zkEVM und Scroll eine Kombination aus Plonkish, Plonk IOP und KZG verwenden.
Um zu verstehen, warum wir diese drei Lösungen verwenden. Wir beginnen zunächst mit dem einfachsten R1CS. Die Einschränkung in R1CS besteht darin, dass die Linearkombination mal die Linearkombination gleich der Linearkombination ist. Sie können jede lineare Kombination von Variablen ohne zusätzlichen Aufwand hinzufügen, aber die maximale Reihenfolge in jeder Einschränkung ist 2. Daher sind für Operationen höherer Ordnung mehr Einschränkungen erforderlich.
In Plonkish müssen Sie alle Variablen in die Tabelle eintragen, einschließlich Eingaben, Ausgaben und Zeugen für Zwischenvariablen. Darüber hinaus können Sie verschiedene Einschränkungen definieren. In Plonkish stehen drei Arten von Einschränkungen zur Verfügung.
Die erste Art von Einschränkung ist ein benutzerdefiniertes Gatter. Sie können Polynom-Beschränkungsbeziehungen zwischen verschiedenen Zellen definieren, z. B. va3 * vb3 * vc3 – vb4 =0. Im Vergleich zu R1CS kann die Reihenfolge höher sein, da Sie Einschränkungen für jede Variable definieren können und einige sehr unterschiedliche Einschränkungen definieren können.
Die zweite Art von Einschränkung ist Permulation oder Gleichheitsprüfungen. Es kann verwendet werden, um die Äquivalenz verschiedener Zellen zu überprüfen, und wird häufig verwendet, um verschiedene Gatter in einer Schaltung zuzuordnen, beispielsweise um zu beweisen, dass der Ausgang des vorherigen Gatters gleich dem Eingang des nächsten Gatters ist.
Die letzte Art von Einschränkung ist eine Nachschlagetabelle. Wir können die Nachschlagetabelle als eine Beziehung zwischen Variablen verstehen, die als Tabelle ausgedrückt werden kann. Beispielsweise möchten wir beweisen, dass vc7 im Bereich von 0 bis 15 liegt. In R1CS müssen Sie diesen Wert zunächst in eine 4-Bit-Binärdatei zerlegen und dann beweisen, dass jedes Bit im Bereich von 0 bis 1 liegt erfordert vier Einschränkungen. In Plonkish können Sie alle möglichen Bereiche in derselben Spalte auflisten und müssen nur nachweisen, dass vc7 zu dieser Spalte gehört. Dies ist für Bereichsnachweise sehr effizient. In zkEVM sind Nachschlagetabellen sehr nützlich, um Speicherlese- und -schreibvorgänge nachzuweisen.
Zusammenfassend lässt sich sagen, dass Plonkish auch benutzerdefinierte Gates, Äquivalenzprüfungen und Nachschlagetabellen unterstützt, die sehr flexibel sein können, um unterschiedliche Schaltungsanforderungen zu erfüllen. Ein einfacher Vergleich von STARK. Jede Zeile in STARK ist eine Einschränkung. Die Einschränkung muss den Zustandsübergang zwischen Zeilen darstellen, aber die Flexibilität benutzerdefinierter Einschränkungen in Plonkish ist offensichtlich höher.
Die Frage ist nun, wie wir das Frontend in zkEVM auswählen. Es gibt vier Hauptherausforderungen für zkEVM. Die erste Herausforderung besteht darin, dass das Feld von EVM 256 Bit groß ist, was bedeutet, dass Variablen effizient auf den Bereich beschränkt werden müssen. Die zweite Herausforderung besteht darin, dass EVM viele ZK-unfreundliche Opcodes aufweist, sodass zum Nachweis dieser Operationen sehr umfangreiche Einschränkungen erforderlich sind .Code wie Keccak-256; die dritte Herausforderung ist das Speicherlese- und Schreibproblem. Sie benötigen eine effektive Zuordnung, um zu beweisen, dass das, was Sie lesen, mit dem übereinstimmt, was Sie zuvor geschrieben haben ändert sich dynamisch, daher benötigen wir benutzerdefinierte Gates, um uns an unterschiedliche Ausführungsspuren anzupassen. Aus den oben genannten Gründen haben wir uns für Plonkish entschieden.
Schauen wir uns als Nächstes den gesamten Prozess von zkEVM an. Basierend auf dem anfänglichen globalen Statusbaum liest EVM nach Eingang einer neuen Transaktion den Bytecode der gespeicherten und aufgerufenen Verträge und generiert entsprechende Ausführungsspuren basierend auf der Transaktion, z PUSH, PUSH, STORE, CALLVALUE und aktualisieren Sie dann schrittweise den globalen Status, um nach der Transaktion den globalen Statusbaum zu erhalten. zkEVM verwendet den anfänglichen globalen Statusbaum, die Transaktion selbst und den globalen Statusbaum nach der Transaktion als Eingabe und verwendet die EVM-Spezifikation, um die Richtigkeit der Ausführungsverfolgung zu beweisen.
Wenn wir uns die Details der EVM-Schaltung genauer ansehen, weist jeder Schritt des Ausführungs-Trace entsprechende Schaltungsbeschränkungen auf. Zu den Schaltungsbeschränkungen jedes Schritts gehören insbesondere Schrittkontext, Fallwechsel und Opcode-spezifischer Zeuge. Der Schrittkontext enthält den Code-Hash, das verbleibende Gas und den Zähler, der dem Ausführungs-Trace entspricht. Case Switch enthält alle Opcodes, alle Fehlerbedingungen und die entsprechenden Operationen des Schritts. Spezifischer Zeuge enthält zusätzliche Zeugen, die vom Opcode benötigt werden, z.
Am Beispiel einer einfachen Addition müssen Sie sicherstellen, dass die Steuervariable sADD des Additions-Opcodes auf 1 gesetzt ist und die Steuervariablen anderer Opcodes alle Null sind. Im Schrittkontext wird der Gasverbrauch auf 3 beschränkt, indem Gas' - Gas - 3 = 0 gesetzt wird. In ähnlicher Weise wird der Zähler auf 1 nach dem Schritt beschränkt, die Summe von Die Variablen werden durch den Opcode auf 1 gesteuert. Um diesen Schritt als Additionsoperation in Opcode Specific Witness einzuschränken, beschränken Sie die tatsächliche Addition von Operanden.
Darüber hinaus sind zusätzliche Schaltungsbeschränkungen erforderlich, um die Korrektheit der aus dem Speicher gelesenen Operanden sicherzustellen. Hier müssen wir zunächst eine Nachschlagetabelle erstellen, um zu beweisen, dass der Operand zum Speicher gehört. Und überprüfen Sie die Richtigkeit der Speichertabelle über den Speicherschaltkreis (RAM-Schaltkreis).
Die gleiche Methode kann auf zk-unfreundliche Hash-Funktionen angewendet werden. Erstellen Sie eine Nachschlagetabelle der Hash-Funktion, ordnen Sie die Hash-Eingabe und -Ausgabe im Ausführungs-Trace der Nachschlagetabelle zu und verwenden Sie eine zusätzliche Hash-Schaltung, um die Hash-Funktion zu überprüfen die Richtigkeit der Nachschlagetabelle.
Schauen wir uns nun die Schaltungsarchitektur von zkEVM an, um die Richtigkeit jedes Schritts der Ausführungsverfolgung einzuschränken. An einigen Stellen, an denen EVM-Schaltungseinschränkungen schwierig sind, verwenden wir Nachschlagetabellen, einschließlich Fixed Table, Keccak Tabelle, RAM-Tabelle, Bytecode, Transaktion, Blockkontext und verwenden Sie dann separate Schaltkreise, um diese Nachschlagetabellen einzuschränken, z. B. Keccak-Schaltkreise, um Keccak-Tabellen einzuschränken.
Zusammenfassend ist der vollständige Workflow von zkEVM in der folgenden Abbildung dargestellt.
Beweissystem
Da die direkte Überprüfung der oben genannten EVM-Schaltkreise, Speicherschaltkreise, Speicherschaltkreise usw. auf L1 teuer ist, verwendet das Proof-System von Scroll eine zweischichtige Architektur.
Die erste Schicht ist für den direkten Beweis des EVM selbst verantwortlich, was einen hohen Rechenaufwand zur Generierung des Beweises erfordert. Daher muss das Beweissystem der ersten Ebene benutzerdefinierte Gatter und Nachschlagetabellen unterstützen, die Hardwarebeschleunigung unterstützen, Berechnungen parallel bei geringer Speicherauslastung generieren und über eine kleine Verifizierungsschaltung verfügen, die schnell verifiziert werden kann. Zu den vielversprechenden Alternativen gehören Plonky2, Starky und eSTARK. Sie alle verwenden grundsätzlich Plonk im Frontend, können aber FRI im Backend verwenden und alle erfüllen die oben genannten vier Merkmale. Zu einer weiteren Art alternativer Lösungen gehören Halo2, das von Zcash entwickelt wurde, und die KZG-Version von Halo2.
Es gibt auch einige vielversprechende neue Beweissysteme, wie HyperPlonk, das kürzlich FFT entfernt hat, und das NOVA-Beweissystem kann kleinere rekursive Beweise erzielen. Aber sie unterstützen R1CS nur in der Forschung. Wenn sie Plonkish in Zukunft unterstützen und in der Praxis anwenden können, wird es sehr praktisch und effizient sein.
Das Beweissystem der zweiten Ebene dient zum Nachweis der Korrektheit des Beweises der ersten Ebene und muss im EVM effizient verifiziert werden. Idealerweise sollte es hardwarebeschleunigungsfreundlich sein und einen transparenten oder universellen Aufbau unterstützen. Zu den vielversprechenden Alternativen gehören Groth16 und das spaltenlose Plonkish-Beweissystem. Groth16 ist nach wie vor ein Vertreter der extrem hohen Beweiseffizienz in der aktuellen Forschung, und das Plonkish-Beweissystem kann auch mit einer geringen Anzahl von Spalten eine hohe Beweiseffizienz erreichen.
Bei Scroll verwenden wir das Halo2-KZG-Proof-System in unseren beiden zweischichtigen Proof-Systemen. Da Halo2-KZG benutzerdefinierte Gatter und Nachschlagetabellen unterstützen kann, funktioniert es bei GPU-Hardwarebeschleunigung gut, und die Verifizierungsschaltung ist klein und kann schnell verifiziert werden. Der Unterschied besteht darin, dass wir Poseidon-Hashing im Beweissystem der ersten Schicht verwenden, um die Beweiseffizienz weiter zu verbessern, während das Beweissystem der zweiten Schicht weiterhin Keccak-Hashing verwendet, da es direkt auf Ethereum verifiziert wird. Scroll untersucht außerdem die Möglichkeit eines mehrschichtigen Beweissystems, um die vom Beweissystem der zweiten Ebene generierten aggregierten Beweise weiter zu aggregieren.
In der aktuellen Implementierung verfügt die EVM-Schaltung des Proof-Systems der ersten Ebene über 116 Spalten, 2496 benutzerdefinierte Gatter, 50 Nachschlagetabellen, die höchste Ordnung ist 9 und erfordert 2^18 Zeilen unter 1M Gas, während das Proof-System der zweiten Ebene über The verfügt Die Aggregationsschaltung hat nur 23 Spalten, 1 benutzerdefiniertes Gatter, 7 Nachschlagetabellen und die höchste Ordnung ist 5. Um die EVM-Schaltung, die Speicherschaltung und die Speicherschaltung zu aggregieren, werden 2^25 Zeilen benötigt.
Scroll hat auch umfangreiche Forschungs- und Optimierungsarbeiten zur GPU-Hardwarebeschleunigung durchgeführt. Für EVM-Schaltkreise benötigt der optimierte GPU-Prüfer nur 30 Sekunden, was 9-mal effizienter ist als der CPU-Prüfer dauert 149 Sekunden, was 15-mal effizienter ist als die CPU. Unter den aktuellen Optimierungsbedingungen dauert das Proofsystem der ersten Ebene von 1M Gas etwa 2 Minuten und das Proofsystem der zweiten Ebene etwa 3 Minuten.
Im dritten Teil sprach Zhang Ye über einige interessante Forschungsthemen im Scroll-Prozess zum Aufbau von zkEVM, von der Front-End-Rechenschaltung bis zur Implementierung des Beweisers.
Schaltkreis
Der erste ist die Zufälligkeit in der Schaltung. Da das EVM-Feld 256 Bit groß ist, müssen wir es in 32 8-Bit-Felder aufteilen, um den Bereichsnachweis effizienter durchzuführen. Dann verwenden wir die Methode der zufälligen linearen Kombination (RLC), um 32 Felder mithilfe von Zufallszahlen in 1 zu kodieren. Wir müssen nur dieses Feld überprüfen, um das ursprüngliche 256-Bit-Feld zu überprüfen. Das Problem besteht jedoch darin, dass die Zufallszahl nach der Aufteilung der Felder generiert werden muss, um sicherzustellen, dass sie nicht manipuliert wird. Daher schlugen Scroll und das PSE-Team eine mehrstufige Prüferlösung vor, um sicherzustellen, dass nach der Feldaufteilung Zufallszahlen zum Generieren von RLC verwendet werden. Diese Lösung ist in der Challenge-API gekapselt. RLC hat viele Anwendungsszenarien in zkEVM. Es kann nicht nur das EVM-Feld in ein Feld komprimieren, sondern auch Eingaben variabler Länge verschlüsseln oder das Layout der Nachschlagetabelle optimieren.
Eine zweite interessante Forschungsfrage im Bereich Schaltkreise ist das Schaltungslayout. Der Grund, warum das Scroll-Frontend Plonkish verwendet, liegt darin, dass sich der Ausführungs-Trace von EVM dynamisch ändert und in der Lage sein muss, unterschiedliche Einschränkungen und sich ändernde Äquivalenztests zu unterstützen, und dass das standardisierte Gatter von R1CS einen größeren Schaltungsumfang für die Implementierung erfordert. Allerdings verwendet Scroll derzeit mehr als 2.000 benutzerdefinierte Gates, um sich dynamisch ändernden Ausführungsspuren gerecht zu werden, und untersucht außerdem, wie das Schaltungslayout weiter optimiert werden kann, einschließlich der Aufteilung von Opcode in Micro-Opcode oder der Wiederverwendung von Zellen in derselben Tabelle.
Eine dritte interessante Forschungsfrage im Bereich Schaltkreise ist die dynamische Skalierung. Da die Schaltungsskala verschiedener Opcodes unterschiedlich ist, muss der Opcode jedes Schritts jedoch die maximale Schaltungsskala erfüllen, um der sich dynamisch ändernden Ausführungsverfolgung gerecht zu werden, z. B. beim Keccak-Hashing. Daher zahlen wir tatsächlich zusätzlichen Overhead. Vorausgesetzt, wir können zkEVM dynamisch an sich dynamisch ändernde Ausführungsspuren anpassen, spart dies unnötigen Overhead.
Prüfer
Was Prüfer angeht, hat Scroll viele Optimierungen für MSM und NTT hinsichtlich der GPU-Beschleunigung vorgenommen, aber jetzt hat sich der Engpass auf die Zeugengenerierung und das Kopieren von Daten verlagert. Da davon ausgegangen wird, dass MSM und NTT 80 % der Beweiszeit beanspruchen, wird die ursprüngliche Beweiszeit von 20 % für das Generieren und Kopieren von Daten zu einem neuen Engpass, selbst wenn die Hardwarebeschleunigung diese Effizienz um mehrere Größenordnungen verbessern kann. Ein weiteres Problem des Prüfers besteht darin, dass er viel Speicher benötigt, sodass nach günstigeren und dezentraleren Hardwarelösungen gesucht werden muss.
Gleichzeitig erforscht Scroll auch Hardwarebeschleunigung und Proof-Algorithmen, um die Effizienz von Prüfern zu verbessern. Derzeit gibt es zwei Hauptrichtungen: entweder die Umstellung auf eine kleinere Domäne, z. B. die Verwendung der 64-Bit-Goldlöckchen-Domäne, der 32-Bit-Mersenne-Prime usw., oder das Festhalten an einem neuen Beweissystem, das auf elliptischen Kurven (EC) basiert, beispielsweise SuperNova . Natürlich sind auch andere Wege möglich und Freunde mit Ideen können sich gerne direkt an Scroll wenden.
Sicherheit
Beim Erstellen von zkEVM steht die Sicherheit an erster Stelle. Das von PSE und Scroll gemeinsam erstellte zkEVM verfügt über etwa 34.000 Codezeilen. Aus softwaretechnischer Sicht ist es unmöglich, dass diese komplexen Codebasen für lange Zeit frei von Schwachstellen bleiben. Scroll überprüft derzeit die zkEVM-Codebasis durch eine große Anzahl von Audits, unter anderem durch die führenden Wirtschaftsprüfungsgesellschaften der Branche.
Teil 4 untersucht andere Anwendungen, die zkEVM verwenden.
In der zkRollup-Architektur überprüfen wir durch den Smart Contract auf L1, ob n Transaktionen auf L2 gültig sind.
Wenn wir den L1-Block direkt überprüfen, muss der L1-Knoten die Transaktion nicht wiederholt ausführen, sondern nur die Gültigkeit jedes Blockzertifikats überprüfen. Eine solche architektonische Lösung nennt sich Enshrine Blockchain. Derzeit ist die direkte Implementierung auf Ethereum sehr schwierig, da der gesamte Ethereum-Block überprüft werden muss, was die Überprüfung einer großen Anzahl von Signaturen umfasst, was zu einer längeren Überprüfungszeit und geringerer Sicherheit führt. Natürlich gibt es bereits einige andere öffentliche Ketten, die rekursive Beweise verwenden, um die gesamte Blockchain anhand eines einzigen Beweises zu verifizieren, wie beispielsweise Mina.
Da zkEVM Zustandsübergänge nachweisen kann, kann es auch von White Hats verwendet werden, um zu beweisen, dass sie die Schwachstellen bestimmter Smart Contracts kennen und Kopfgelder von Projektparteien einfordern.
Der letzte Anwendungsfall besteht darin, Behauptungen über historische Daten durch wissensfreie Beweise zu beweisen und diese als Orakel zu nutzen. Axiom stellt derzeit Produkte in diesem Bereich her. Beim jüngsten ETHBeijing Hackathon nutzte das GasLockR-Team diese Funktion, um den historischen Gas-Overhead zu beweisen.
Schließlich entwickelt Scroll die universelle Skalierungslösung von zkRollup für Ethereum, die sehr fortschrittliche arithmetische Schaltkreise und Beweissysteme verwendet und schnelle Verifizierer durch Hardwarebeschleunigung baut, um Rekursion zu beweisen. Derzeit ist das Alpha-Testnetzwerk online und läuft seit langem stabil.
Natürlich müssen noch einige interessante Probleme gelöst werden, darunter Protokolldesign und Mechanismusdesign, wissensfreies Engineering und tatsächliche Effizienz. Jeder ist herzlich willkommen, sich Scroll anzuschließen, um gemeinsam zu bauen!
