Wir möchten dem Polygon Zero-Team, dem Consensys Gnark-Projekt, Pado Labs und dem Delphinus Lab-Team für ihre wertvollen Kommentare und Rückmeldungen zu diesem Artikel danken.
Wir haben in den letzten Monaten viel Zeit und Mühe in die Entwicklung einer hochmodernen Infrastruktur investiert, die auf prägnanten zk-SNARK-Beweisen basiert. Diese Innovationsplattform der nächsten Generation ermöglicht es Entwicklern, beispiellose neue Paradigmen für Blockchain-Anwendungen zu entwickeln.
Während unserer Entwicklungsarbeit haben wir mehrere Zero-Knowledge-Proof-Entwicklungsframeworks (ZKP) getestet und verwendet. Obwohl diese Reise lohnend war, sind wir uns darüber im Klaren, dass die Vielfalt der ZKP-Frameworks neue Entwickler häufig vor Herausforderungen stellt, wenn sie versuchen, dasjenige zu finden, das ihren spezifischen Anwendungsfällen und Leistungsanforderungen am besten entspricht. Angesichts dieses Problems glauben wir, dass Bedarf an einer Community-Bewertungsplattform besteht, die umfassende Leistungstestergebnisse liefern kann, was die Entwicklung dieser neuen Anwendungen erheblich erleichtern wird.
Um dieser Nachfrage gerecht zu werden, haben wir die Evaluierungsplattform für wissensfreie Entwicklungsrahmen „Patheon“ ins Leben gerufen, eine gemeinnützige Gemeinschaftsinitiative. Der erste Schritt der Initiative wird die Community dazu ermutigen, reproduzierbare Leistungstestergebnisse verschiedener ZKP-Frameworks zu teilen. Unser oberstes Ziel ist es, gemeinsam ein weithin anerkanntes Testbed zu erstellen und zu pflegen, das Low-Level-Schaltungsentwicklungs-Frameworks, High-Level-zkVM und Compiler und sogar Hardwarebeschleunigungsanbieter bewertet. Wir hoffen, dass diese Initiative es Entwicklern ermöglicht, mehr Referenzen für den Leistungsvergleich bei der Auswahl von Frameworks zu erhalten und so die Förderung von ZKP zu beschleunigen. Gleichzeitig hoffen wir, die Aktualisierung und Iteration des ZKP-Frameworks selbst zu fördern, indem wir eine Reihe allgemeingültiger Leistungstestergebnisse bereitstellen. Wir investieren stark in diese Initiative und laden alle gleichgesinnten Community-Mitglieder ein, sich uns anzuschließen und zu dieser Initiative beizutragen!
Schritt eins: Leistungstest des Circuit Framework mit SHA-256
In diesem Beitrag unternehmen wir die ersten Schritte beim Aufbau von ZKP Patheon und stellen eine Reihe reproduzierbarer Leistungstestergebnisse unter Verwendung von SHA-256 in einer Reihe von Frameworks für die Schaltungsentwicklung auf niedriger Ebene bereit. Obwohl wir anerkennen, dass andere Granularitäten und Primitive für Leistungstests möglich sein könnten, haben wir uns für SHA-256 entschieden, da es für eine Vielzahl von ZKP-Anwendungsfällen geeignet ist, darunter Blockchain-Systeme, digitale Signaturen, zkDID und mehr. Erwähnenswert ist auch, dass wir SHA-256 auch in unserem eigenen System verwenden, das ist also auch für uns praktisch! 😂
Unser Benchmark bewertet die Leistung von SHA-256 auf verschiedenen zk-SNARK- und zk-STARK-Schaltkreisentwicklungsframeworks. Durch diesen Vergleich möchten wir Entwicklern Einblicke in die Effizienz und Praktikabilität jedes Frameworks geben. Unser Ziel ist es, dass diese Erkenntnisse es Entwicklern ermöglichen, fundierte Entscheidungen bei der Auswahl des am besten geeigneten Frameworks für ihre Projekte zu treffen.
Unsere Leistungstests bewerten die SHA-256-Leistung auf verschiedenen zk-SNARK- und zk-STARK-Schaltungsentwicklungs-Frameworks. Durch Vergleiche möchten wir Entwicklern Einblicke in die Effizienz und Nützlichkeit jedes Frameworks geben. Unser Ziel ist es, dass die Ergebnisse dieses Leistungstests Entwicklern als Referenz dienen können, um fundierte Entscheidungen bei der Auswahl des besten Frameworks zu treffen.
Beweissystem
In den letzten Jahren haben wir eine Zunahme wissensfreier Systeme beobachtet. Da es schwierig sein kann, mit all den spannenden Fortschritten auf diesem Gebiet Schritt zu halten, haben wir die folgenden Proof-Systeme sorgfältig als Testobjekte ausgewählt, basierend auf ihrer Reife und der Akzeptanz durch die Entwickler. Unser Ziel ist es, eine repräsentative Auswahl verschiedener Frontend-/Backend-Kombinationen bereitzustellen.
Circom + snarkjs / rapidsnark: Circom ist ein beliebtes DSL zum Schreiben von Schaltkreisen und zum Generieren von R1CS-Einschränkungen, und snarkjs ist in der Lage, Groth16- oder Plonk-Proofs für Circom zu generieren. Rapidsnark ist auch der Prüfer von Circom, es generiert Groth16-Beweise und ist dank der Verwendung der ADX-Erweiterung im Allgemeinen viel schneller als Snarkjs und parallelisiert die Beweiserstellung, wann immer möglich.
Gnark: Gnark ist ein umfassendes Golang-Framework von Consensys, das Groth16, Plonk und viele weitere erweiterte Funktionen unterstützt.
Arkworks: Arkworks ist ein umfassendes Rust-Framework für zk-SNARKs.
Halo2 (KZG): Halo2 ist eine zk-SNARK-Implementierung von Zcash und Plonk. Es verfügt über hochflexible Plonkish-Arithmetik und unterstützt viele nützliche Grundelemente wie benutzerdefinierte Gateways und Nachschlagetabellen. Wir verwenden den Halo2-Fork von KZG mit Ethereum Foundation- und Scroll-Unterstützung.
Plonky2: Plonky2 ist eine SNARK-Implementierung, die auf der PLONK- und FRI-Technologie von Polygon Zero basiert. Plonky2 verwendet kleine Goldlöckchen-Felder und unterstützt eine effiziente Rekursion. Bei unseren Leistungstests streben wir eine spekulative 100-Bit-Sicherheit an und verwenden Parameter, die die besten Beweiszeiten für den Leistungstestaufwand liefern. Konkret verwendeten wir 28 Merkle-Abfragen, einen Verstärkungsfaktor von 8 und eine 16-Bit-Proof-of-Work-Challenge. Zusätzlich setzen wir num_of_wires = 60 und num_routed_wires = 60.
Starky: Starky ist das leistungsstarke STARK-Framework von Polygon Zero. Bei unseren Leistungstests streben wir eine spekulative 100-Bit-Sicherheit an und verwenden Parameter, die die besten Beweiszeiten liefern. Konkret verwendeten wir 90 Merkle-Abfragen, einen 2-fachen Verstärkungsfaktor und eine 10-Bit-Proof-of-Work-Challenge.
Die folgende Tabelle fasst die oben genannten Frameworks und die zugehörigen Konfigurationen zusammen, die in unseren Leistungstests verwendet wurden. Diese Liste erhebt keinen Anspruch auf Vollständigkeit und wir werden uns in Zukunft auch mit vielen hochmodernen Frameworks/Technologien befassen (z. B. Nova, GKR, Hyperplonk).
Bitte beachten Sie, dass diese Leistungstestergebnisse nur für das Schaltungsentwicklungs-Framework gelten. Wir planen, in Zukunft einen separaten Artikel zu veröffentlichen, der Leistungstests verschiedener zkVMs (z. B. Scroll, Polygon zkEVM, Consensys zkEVM, zkSync, Risc Zero, zkWasm) und IR-Compiler-Frameworks (z. B. Noir, zkLLVM) durchführt.
rahmen
Arithmetik
Algorithmus
Zahlenbereich
Andere Konfigurationen
Circom + snarkjs / rapidsnark
R1CS
Groth16
BN254 Skalar
Gnark
R1CS
Groth16
BN254 Skalar
Arkworks
R1CS
Groth16
BN254 Skalar
Halo2 (KZG)
Plonkisch
KZG
BN254 Skalar
Plonky2
Plonk
FR
Goldlöckchen
Aufblasfaktor = 8
Arbeitsnachweisbits = 16
Abfragerunden = 28
Anzahl_der_Kabel = 60 Anzahl_verlegter_Kabel = 60
Starks
LUFT
FR
Goldlöckchen
Aufblasfaktor = 2
Arbeitsnachweisbits = 10
Abfragerunden = 90
Methodik zur Leistungsbewertung
Um Leistungstests auf diesen verschiedenen Beweissystemen durchzuführen, berechnen wir SHA-256-Hashes von N Datenbytes, wobei wir mit N = 64, 128, ..., 64 KB experimentiert haben (Starky ist eine Ausnahme, bei der die Schaltung die Berechnung wiederholt SHA-256 für eine feste 64-Byte-Eingabe, behält aber die gleiche Gesamtzahl an Nachrichtenblöcken bei). Leistungscode und SHA-256-Schaltungskonfiguration finden Sie in diesem Repository.
Darüber hinaus haben wir die Leistung jedes Systems anhand der folgenden Leistungsmetriken getestet:
Beweisgenerierungszeit (einschließlich Zeugengenerierungszeit)
Demonstrieren Sie Spitzen bei der Speichernutzung während des Buildvorgangs
Durchschnittlicher Prozentsatz der CPU-Auslastung während der Proof-Erstellung. (Diese Metrik spiegelt den Grad der Parallelisierung im Beweiserstellungsprozess wider.)
Beachten Sie, dass wir einige „willkürliche“ Annahmen über die Beweisgröße und die Kosten für die Beweisüberprüfung treffen, da diese Aspekte durch die Kombination mit Groth16 oder KZG vor der On-Chain gemildert werden können.
Maschine
Wir haben Leistungstests auf zwei verschiedenen Maschinen durchgeführt:
Linux-Server: 20 Kerne bei 2,3 GHz, 384 GB RAM
MacBook M1 Pro: 10 Kerne mit 3,2 GHz, 16 GB RAM
Linux-Server werden zur Simulation von Szenarien mit vielen CPU-Kernen und ausreichend Speicher verwendet. Und das Macbook M1 Pro, das typischerweise für Forschung und Entwicklung verwendet wird, verfügt über eine leistungsstärkere CPU, aber weniger Kerne.
Wir haben optionales Multithreading aktiviert, in diesem Leistungstest jedoch keine GPU-Beschleunigung genutzt. Wir planen, in Zukunft GPU-Leistungstests durchzuführen.
Ergebnisse der Leistungsbewertung
Anzahl der Einschränkungen
Bevor wir mit der Diskussion der detaillierten Leistungstestergebnisse fortfahren, ist es hilfreich, zunächst die Komplexität von SHA-256 zu verstehen, indem man sich die Anzahl der Einschränkungen in jedem Beweissystem ansieht. Es ist wichtig zu beachten, dass die Anzahl der Einschränkungen in verschiedenen arithmetischen Schemata nicht direkt verglichen werden kann.
Die folgenden Ergebnisse entsprechen einer Originalbildgröße von 64 KB. Während die Ergebnisse bei anderen Vorbildgrößen variieren können, skalieren sie ungefähr linear.
Circom, Gnark und Arkworks verwenden alle denselben R1CS-Algorithmus, und die Anzahl der für 64 KB SHA-256 berechneten R1CS-Einschränkungen liegt ungefähr zwischen 30 Millionen und 45 Millionen. Unterschiede zwischen Circom, Gnark und Arkworks können auf Konfigurationsunterschiede zurückzuführen sein.
Sowohl Halo2 als auch Plonky2 verwenden Plonkish-Arithmetik, wobei die Anzahl der Zeilen zwischen 2^22 und 2^23 liegt. Die SHA-256-Implementierung von Halo2 ist aufgrund der Verwendung von Nachschlagetabellen viel effizienter als die von Plonky2.
Starky verwendet den AIR-Algorithmus, bei dem die Ausführung der Tracking-Tabelle 2^16 Transformationsschritte erfordert.
Beweissystem
Anzahl der Einschränkungen (64 KB SHA-256)
Circom
32M
Gnark
45M
Arkworks
43M
Halo2
4 Mio. Zeilen (K=22)
Plonky2
8M Reihen (K=23)
Starks
2^16 Übergangsschritte
Zeit der Beweisgenerierung
[Abbildung 1] Getestete Proof-Generierungszeit für jeden Frame von SHA-256 auf verschiedenen Rohbildgrößen unter Verwendung eines Linux-Servers. Wir können folgende Erkenntnisse gewinnen:
Für SHA-256 generieren Groth16-Frameworks (Rapidsnark, Gnark und Arkworks) Beweise schneller als Plonk-Frameworks (Halo2 und Plonky2). Dies liegt daran, dass SHA-256 hauptsächlich aus Bitoperationen besteht, bei denen die linearen Werte 0 oder 1 sind. Für Groth16 reduziert dies den größten Teil der Berechnung von der Skalarmultiplikation mit elliptischen Kurven auf die Punktaddition mit elliptischen Kurven. Drahtwerte werden jedoch nicht direkt in den Berechnungen von Plonk verwendet, sodass die spezielle Drahtstruktur in SHA-256 den im Plonk-Framework erforderlichen Rechenaufwand nicht verringert.
Unter allen Groth16-Frameworks sind Gnark und Rapidsnark fünf- bis zehnmal schneller als Arkworks und Snarkjs. Dies ist auf ihre überlegene Fähigkeit zurückzuführen, Beweise parallel mithilfe mehrerer Kerne zu generieren. Gnark ist 25 % schneller als Rapidsnark.
Für das Plonk-Framework ist der SHA-256 von Plonky2 50 % langsamer als der von Halo2, wenn größere Vorbildgrößen >= 4 KB verwendet werden. Dies liegt daran, dass die Implementierung von Halo2 hauptsächlich Nachschlagetabellen verwendet, um bitweise Operationen zu beschleunigen, was zu 2x weniger Zeilen als bei Plonky2 führt. Wenn wir jedoch Plonky2 und Halo2 mit der gleichen Anzahl von Zeilen vergleichen (z. B. über 2 KB SHA-256 in Halo2 vs. über 4 KB SHA-256 in Plonky2), ist Plonky2 50 % schneller als Halo2. Wenn wir SHA-256 in Plonky2 mithilfe von Nachschlagetabellen implementieren, sollten wir davon ausgehen, dass Plonky2 trotz der größeren Proofgröße von Plonky2 schneller als Halo2 ist.
Andererseits ist Halo2 langsamer als Plonky2 (und andere Frameworks), wenn die Größe des eingegebenen Vorbilds klein ist (<=512 Bytes), da die meisten Einschränkungen auf die festen Einrichtungskosten der Nachschlagetabelle zurückzuführen sind. Allerdings wird die Leistung von Halo2 mit zunehmender Anzahl an Vorbildern konkurrenzfähiger, was beweist, dass die Generierungszeit für Vorbildgrößen bis zu 2 KB konstant bleibt, was, wie in der Abbildung dargestellt, nahezu linear skaliert.
Wie erwartet ist die Beweisgenerierungszeit von Starky viel kürzer als bei jedem anderen SNARK-Framework (5x-50x), allerdings geht dies auf Kosten einer größeren Beweisgröße.
Beachten Sie außerdem, dass die Proof-Generierung für SNARKs aufgrund der O(nlogn)-FFT superlinear wächst, selbst wenn die Schaltkreisgröße linear mit der Vorbildgröße skaliert (obwohl dieses Phänomen aufgrund der logarithmischen Skala nicht in der Grafik auftritt). offensichtlich).
Wir haben auch Leistungstests zur Proof-Generierungszeit auf einem MacBook M1 Pro durchgeführt, wie in [Abbildung 2] dargestellt. Es ist jedoch wichtig zu beachten, dass Rapidsnark aufgrund der fehlenden Unterstützung für die ARM64-Architektur nicht in diesen Leistungstest einbezogen wurde. Um snarkjs auf arm64 verwenden zu können, müssen wir Webassembly zum Generieren des Zeugen verwenden, was langsamer ist als die C++-Zeugengenerierung, die auf Linux-Servern verwendet wird.
Ein paar zusätzliche Beobachtungen beim Ausführen von Leistungstests auf einem Macbook M1 Pro:
Mit Ausnahme von Starky leiden alle SNARK-Frameworks unter Out-of-Memory-Fehlern (OOM), wenn die Größe des Vorbilds größer wird oder Swap-Speicher verwendet wird (was zu langsameren Proof-Zeiten führt). Insbesondere beginnen Groth16-Frameworks (snarkjs, gnark, Arkworks) mit der Verwendung von Swap-Speicher, wenn die Größe des Vorbilds >= 8 KB ist, während Gnark keinen Speicher mehr hat, wenn die Größe des Vorbilds >= 64 KB beträgt. Halo2 stößt auf ein Speicherlimit, wenn die Größe des Vorbilds >= 32 KB beträgt. Plonky2 beginnt mit der Verwendung von Swap-Speicher, wenn die Größe des Vorbilds >= 8 KB ist.
Die FRI-basierten Frameworks (Starky und Plonky2) sind auf einem Macbook M1 Pro etwa 60 % schneller als auf einem Linux-Server, während die anderen Frameworks auf beiden Rechnern ähnliche Testzeiten aufweisen. Selbst ohne die Verwendung von Nachschlagetabellen in Plonky2 erreicht es also fast die gleiche Prüfzeit wie Halo2 auf einem Macbook M1 Pro. Der Hauptgrund ist, dass das Macbook M1 Pro über eine leistungsstärkere CPU, aber weniger Kerne verfügt. FRI führt hauptsächlich Hash-Operationen durch und reagiert empfindlicher auf CPU-Taktzyklen, seine Parallelität ist jedoch nicht so gut wie die von KZG oder Groth16.
Spitzenspeichernutzung
[Abbildung 3] und [Abbildung 4] zeigen die maximale Speichernutzung während der Proof-Erstellung auf Linux Server bzw. Macbook M1 Pro. Basierend auf diesen Leistungstestergebnissen können folgende Beobachtungen gemacht werden:
Von allen SNARK-Frameworks ist Rapidsnark das speichereffizienteste. Wir sehen auch, dass Halo2 aufgrund der festen Einrichtungskosten der Nachschlagetabelle mehr Speicher verbraucht, wenn die Vorbildgröße kleiner ist, aber insgesamt weniger Speicher verbraucht, wenn die Vorbildgröße größer ist.
Starky ist mehr als zehnmal speichereffizienter als das SNARK-Framework. Ein Grund dafür ist, dass weniger Zeilen verwendet werden.
Es ist zu beachten, dass die Speicherauslastungsspitzen auf dem MacBook M1 Pro aufgrund der größeren Vorbildgröße bei Verwendung des Swap-Speichers relativ flach bleiben.
CPU-Auslastung
Wir bewerten den Grad der Parallelisierung jedes Proofsystems, indem wir die durchschnittliche CPU-Auslastung von SHA-256 während der Proofgenerierung für 4-KB-Preimage-Eingaben messen. Die folgende Tabelle zeigt die durchschnittliche CPU-Auslastung (durchschnittliche Auslastung pro Kern in Klammern) auf Linux Server (20 Kerne) und Macbook M1 Pro (10 Kerne).
Die wichtigsten Beobachtungen sind wie folgt:
Gnark und Rapidsnark weisen die höchste CPU-Auslastung auf Linux-Servern auf und demonstrieren damit ihre Fähigkeit, mehrere Kerne effizient zu nutzen und die Beweiserstellung zu parallelisieren. Halo2 zeigt auch eine gute Parallelisierungsleistung.
Mit Ausnahme von snarkjs erreichen die meisten Frameworks auf einem Linux-Server eine doppelt so hohe CPU-Auslastung wie auf einem Macbook Pro M1.
Obwohl ursprünglich damit gerechnet wurde, dass die FRI-basierten Frameworks (Plonky2 und Starky) Schwierigkeiten haben könnten, mehrere Kerne effizient zu nutzen, schnitten sie in unseren Leistungstests nicht schlechter ab als einige Groth16- oder KZG-Frameworks. Es bleibt abzuwarten, ob es auf einer Maschine mit mehr Kernen (z. B. 100 Kernen) einen Unterschied in der CPU-Auslastung gibt.
Beweissystem
CPU-Auslastung (durchschnittliche Auslastung pro Kern)
(Linux-Server)
CPU-Auslastung (durchschnittliche Auslastung pro Kern)
(MBP M1)
snarkjs
557 % (27,85 %)
486 % (48,6 %)
Abonnieren
1542 % (77,1 %)
N / A
Gnark
1624 % (81,2 %)
720 % (72 %)
Arkworks
935 % (46,75 %)
504 % (50,4 %)
Halo2 (KZG)
1227 % (61,35 %)
588 % (58,8 %)
Plonky2
892 % (44,6 %)
429 % (42,9 %)
Starks
849 % (42,45 %)
335 % (33,5 %)
Fazit und zukünftige Forschung
Dieser Artikel bietet einen umfassenden Vergleich der SHA-256-Leistungstestergebnisse für verschiedene zk-SNARK- und zk-STARK-Entwicklungsframeworks. Dieser Vergleich bietet Einblicke in die Effizienz und Nützlichkeit jedes Frameworks und soll Entwicklern helfen, die präzise Beweise für SHA-256-Operationen erstellen müssen. Wir haben festgestellt, dass Groth16-Frameworks (z. B. Rapidsnark, Gnark) Beweise schneller generieren als Plonk-Frameworks (z. B. Halo2, Plonky2). Nachschlagetabellen in Plonkish-Arithmetik reduzieren die SHA-256-Einschränkungen und Prüfzeiten erheblich, wenn größere Vorbildgrößen verwendet werden. Darüber hinaus demonstrieren Gnark und Rapidsnark die hervorragende Fähigkeit, mehrere Kerne für den Parallelbetrieb zu nutzen. Andererseits ist die Beweisgenerierungszeit von Starky viel kürzer, allerdings auf Kosten einer viel größeren Beweisgröße. In Bezug auf die Speichereffizienz übertreffen Rapidsnark und Starky andere Frameworks.
Als ersten Schritt beim Aufbau der wissensfreien Evaluierungsplattform „Patheon“ geben wir zu, dass die Ergebnisse dieses Leistungstests bei weitem nicht ausreichen, um die umfassende Testplattform zu werden, die wir letztendlich aufbauen möchten. Wir freuen uns über Feedback und Kritik und laden alle ein, zu dieser Initiative beizutragen, um Entwicklern die Verwendung wissensfreier Beweise zu erleichtern und die Hürden zu senken. Wir sind auch bereit, einzelnen unabhängigen Mitwirkenden Zuschüsse zu gewähren, um die Kosten für Rechenressourcen für groß angelegte Leistungstests zu decken. Wir hoffen, gemeinsam daran zu arbeiten, die Effizienz und Praktikabilität von ZKP zu verbessern und der Gemeinschaft im weiteren Sinne zu helfen.
Abschließend möchten wir dem Polygon Zero-Team, dem Gnark-Team von Consensys, Pado Labs und dem Delphinus Lab-Team für ihre wertvolle Bewertung und ihr Feedback zu den Leistungstestergebnissen danken.
