2023 ist das erste Jahr des ZK-Ausbruchs und es gibt bereits einige Meinungen. In diesem Artikel konzentrieren wir uns auf die Diskussion verschiedener Arten von zkEVM- und ZKP-Hardwarespuren usw. und analysieren sie einzeln. Auf dem von ChainTimes letzte Woche initiierten Investment-Research-Meeting zum Thema ZK haben alle aktiv kommuniziert. In diesem Artikel wird die von MetaStone Capital geteilte Analyse zu zkEVM und Hardware erläutert.

01.Über zk-rollup

Als Skalierbarkeitslösung von Ethereum kann Rollup Transaktionen über sein eigenes Netzwerk bündeln, komprimieren und zur Überprüfung an die Ethereum-Kette senden. Es kann die Betriebseffizienz des Netzwerks erhöhen, indem mehrere Transaktionen im Netzwerk gleichzeitig überprüft werden. Dies ist auch der Fall um die Anzahl der Transaktionsausführungen zu erhöhen und eine Expansion zu erreichen.

Durch die Anzahl der gleichzeitig von Rollups selbst ausgeführten Transaktionen kann das von Ethereum kritisierte TPS-Problem verbessert werden. Aufgrund der Sicherheit von Ethereum selbst kann die Anzahl der ausführbaren Transaktionen um mehrere Größenordnungen erhöht werden.

zkRollups kann Datenschutz mit Lösungen durch Zero-Knowledge-Proof-Technologie kombinieren, die es einer Partei ermöglicht, einer anderen Partei etwas zu beweisen, ohne die Informationen preiszugeben, die diese Partei beweisen, und so Privatsphäre zu gewährleisten. Natürlich nutzen nicht alle zkRollups die Datenschutzeigenschaften der Zero-Knowledge-Technologie. Gleichzeitig bietet zkRollups im Vergleich zu L1 stärkere Skaleneffekte. Die Kosten und die Verarbeitungsgeschwindigkeit von L1 sind im Allgemeinen nicht für immer mehr Benutzer geeignet. Für zkRollups werden die Kosten weiter gesenkt das Netzwerk zu nutzen und den ursprünglichen Zweck zu erreichen.

Die offensichtlichen Vorteile der Anwendung von zk-rollup an der ETH sind:

1. Gemeinsame Nutzung der Sicherheit der Ethereum-Konsensschicht

2. Lösen Sie das Skalierbarkeitsproblem im unmöglichen Dreieck der Blockchain

3. Riesige Netzwerkeffekte

02. Wie EVM und zkEVM funktionieren

a. Funktionsprinzip von EVM

Der Smart-Contract-Bytecode wird aus dem Speicher der EVM geladen und von Peer-to-Peer-Knoten auf der EVM ausgeführt.

EVM-Opcodes interagieren mit verschiedenen Teilen des EVM-Status und führen Lese- und Schreibvorgänge aus (einschließlich Speicher und Stapel).

Der EVM-Opcode führt Berechnungen für den aus dem Zustandsspeicher erhaltenen Wert durch, bevor er den neuen Wert zurückgibt, um den Zustandsübergang abzuschließen.

b. Wie zkEVM funktioniert

Das heißt, es wird ein wissensfreier Beweis erstellt, um jeden der oben genannten Prozesse zu überprüfen, ein Gültigkeitszertifikat wird generiert und dem ETH-Verifizierungsvertrag zur Überprüfung vorgelegt. Zur Überprüfung gehört die Prüfung, ob der korrekte Wert aus dem alten Zustand ermittelt wird, ob eine Abweichung in der Berechnung vorliegt usw. Der Prozess der Generierung eines Gültigkeitsnachweises ist auch der Prozess der Erstellung einer wissensfreien Beweisschaltung.

3.zkEVM-Ausführungsprogramm

01. Die Grundbedingungen von zkEVM erfordern eine EVM-kompatible virtuelle Maschine, um Opcodes auszuführen und Smart Contracts auszuführen.

02. Es gibt eine Verifizierungsschaltung, die wissensfreie Beweise generiert. Schließen Sie den Beweiserstellungsprozess ab, indem Sie Vorzustands-, Transaktionseingabe- und Nachzustandsinformationen als Eingabe verwenden

4. Kompatibilitätsprobleme zwischen Scroll und zkSync, Starknet und Polygon

Da EVM das Problem der ZKP-Berechnung beim ursprünglichen Entwurf nicht berücksichtigte, gibt es zwei Möglichkeiten, ZK + ZVM zu kombinieren:

a. Kompilierungsmethode

Starknet selbst verwendet die Kairo-Sprache (Zero-Knowledge-Proof-Systemsprache). Wenn Entwickler Eth-Anwendungen nach Starknet verschieben möchten, müssen sie den Compiler des Starknet-Teams zur Kompilierung ausleihen, damit in Solidity geschriebene Projekte ihre Codebasis mit einem Klick erstellen können ” Übersetzt nach Kairo.

Zksync wird auch in der Sprache YUL kompiliert. Mithilfe des LLVM-Frameworks wird der Soliditätsvertragsbytecode in die YUL-Sprache kompiliert und dann in den ausführbaren Bytecode von zksync ZKEVM kompiliert, der über den YUL-Bytecode festgelegt wird.

Polygon wird auf Bytecode kompiliert, und der Open-Source-Solidity-Bytecode wird in ausführbaren Polygon-UVM-Mikrooperationscode kompiliert, der tatsächlich den nativen EVM-Operationscode ersetzt. Der Sinn des Fortschritts besteht jedoch darin, die EVM-Kompatibilität auf der Bytecode-Ebene zu vervollständigen.

b.scroll ist der Prozess des Entwurfs wissensfreier Schaltkreise für EVM-Opcodes

Scroll führt den Smart Contract auf dem EVM aus, überträgt den Smart Contract-Bytecode in den Speicher, führt ihn einzeln mit den Opcodes aus, ruft den Merkle-Baum ab und passt eine Schaltung für jeden Baum an. Jeder Opcode verfügt über einen Schaltkreis, und wenn er kombiniert wird, gibt es keinen Übersetzungsschritt und keine Notwendigkeit, etwas zu ändern.

Das zkEVM auf Bytecode-Ebene ist entwicklerfreundlich: Die Bereitstellung mit niedrigem Schwellenwert ist ein Punkt. Darüber hinaus können Entwickler ohne Konvertierung von Solidity-Code in eine andere Programmiersprache direkt gängige Ethereum-Entwicklungstools, Bibliotheken, Wallets (wie MetaMask), Market usw. verwenden Debugger, das ist am kritischsten. Im Gegenteil, die Verwendung der Kompatibilität auf Sprachebene wird Entwicklern gewisse Schwierigkeiten bereiten, Eth-Tools zu verwenden und ökologische Ethereum-Anwendungen zu migrieren, und die Kompatibilität wird schlechter sein.

Abgesehen von der Kompatibilität, wie man ZK-EVM vergleicht:

In einer Open-Source-Umgebung sind die Unterschiede zwischen den verschiedenen ZK-Lösungen des gesamten Prove-Systems sehr gering und die Unterschiede sind nicht signifikant, was sich nur schwach auf die Effizienz von Prove auswirkt. Aus technischer Sicht wird es anhand der Beweiskomplexität, der Verifizierungskomplexität, der Kommunikationskomplexität usw. sowie der allgemeinen Ideen zur Schaltungsentwicklung gemessen. Es ist unmöglich zu beurteilen, wer am Ende gewinnen wird. Denn Netzwerkeffekte, Gemeinschaftskultur, Betriebsförderung, Vermögenseffekte, Entwicklerunterstützung usw. sind allesamt die wichtigsten Elemente des Ökosystems.

5. Aktuelle ZKP-Typen

Um eine Berechnung durch ZK zu beweisen, müssen Sie normalerweise ein traditionelles Programm in ein ZK-freundliches Programm übersetzen.

Je komplexer die Berechnung ist und nicht für ZK geeignet ist, desto langsamer ist der Prozess der Beweiserstellung. Einige Operationen sind für ZK nicht geeignet (sha/bitweise Operation). Je schneller die Berechnung ist Das Beweissystem sind derzeit PLONK, Spartan und STARK. Diese Beweissysteme können einen Beweis basierend auf Eingaben ausgeben.

Der derzeitige Engpass bei der Beweiserstellung ist jedoch nichts anderes als einer der beiden Algorithmen: FFT und MSM. Der Hauptfaktor, der die Geschwindigkeit der beiden Algorithmen begrenzt, hängt derzeit von den Hardware- und Bandbreitenkosten ab.

Die aktuellen Hardwaretypen umfassen hauptsächlich die folgenden drei Arten von GPU-FPGA-ASICs. Derzeit befindet sich ZKP noch in der frühen Entwicklungsphase. Es gibt noch wenig Standardisierungsarbeiten an den Systemparametern (z. B. der FFT-Breite oder der Bitgröße). Beweissystem ist auch Es gibt keinen relevanten Standard.

Basierend auf den oben genannten Faktoren verfügt FPGA für ZKP-Szenarien über zwei Kernattribute, die es besser als ASIC machen:

01Mehrfach schreiben“ VS „Einmal schreiben“

Die Geschäftslogik auf dem ASIC ist einmal beschreibbar. Wenn Änderungen an der ZKP-Logik vorgenommen werden, müssen Sie von vorne beginnen. FPGA kann innerhalb von 1 Sekunde erneut flashen und unterstützt unzählige Male erneutes Flashen, was bedeutet, dass dieselbe Hardware zwischen verschiedenen Ketten, auf denen inkompatible Proofsysteme ausgeführt werden (z. B. wenn Sie MEV über Ketten hinweg extrahieren möchten), und derselben Hardware wiederverwendet werden kann jederzeit wiederverwendbar. Passen Sie sich flexibel an Änderungen im ZK „Meta“ an.

02Gesündere Versorgung:

Das Design, die Herstellung und der Einsatz von ASICs dauern in der Regel 12 bis 18 Monate oder länger. Die FPGA-Lieferkette ist in Ordnung. Führende FPGA-Lieferanten wie Xilinx ermöglichen die Online-Aufgabe von Großbestellungen (d. h. es ist kein weiterer Kontakt erforderlich) und kommen innerhalb von 16 Wochen an. Dadurch können FPGA-zentrierte Betriebe eine engere Rückkopplungsschleife zu ihren Produkten haben und ihren Betrieb durch den Kauf und Einsatz weiterer FPGAs erweitern.

Und wir erwarten auch, dass die FPGA-Leistung besser sein wird als die der GPU, hauptsächlich aus zwei Gründen:

1) Hardware-Overhead: Top-FPGAs (führende Verarbeitungsknoten, Taktraten, Energieeffizienz und Speicherbandbreite) sind etwa dreimal günstiger als Top-GPUs. Die weltweite Nachfrage nach GPUs verschärft das Problem zusätzlich.

2) Stromverbrauchseffizienz: Der Energieverbrauch von FPGA ist mehr als zehnmal höher als der von GPU. Der Hauptgrund dafür ist, dass die GPU an ein Host-Gerät angeschlossen werden muss, das normalerweise viel Strom verbraucht.

Wir glauben, dass die zukünftigen Gewinner auf dem Markt sein werden: FPGA > ASIC (oder GPU). Wenn in Zukunft nur eine oder eine kleine Anzahl von ZK L1- oder L2-Lösungen die Skala dominieren und sich das ZK-Proof-System bei einer einzigen Implementierung stabilisieren wird, dann könnte ASIC FPGA übertreffen. Aber derzeit wird diese Situation nicht in ein paar Jahren eintreten.

Bitcoin-Miner verdienten über 15 Milliarden US-Dollar und Ethereum-Miner verdienten etwas mehr als 17 Milliarden US-Dollar. Zero-Knowledge-Proofs werden schließlich zum De-facto-Medium für Computerintegrität und Datenschutz im Web. In diesem Fall könnten die Chancen für ZK-Miner/Provers ähnlich groß sein wie der Proof-of-Work-Mining-Markt.

ZKP ist langsam und erfordert Hardwarebeschleunigung, um komplexe Berechnungen durchzuführen. Wir glauben, dass die wichtigste Technologie für die ZK-Hardwarebeschleunigung FPGA ist, nicht GPU (eingeschränkt durch Kosten und Energieeffizienz) oder ASIC (eingeschränkt durch seine Inflexibilität und seinen langen Iterationszyklus).