Vorwort
Bisher gehen die meisten Protokolle, die wir in Web3 kennen, von einem gewissen Grad an Vertrauen aus. Wenn wir die „Dezentralisierung“ weiter vorantreiben wollen, müssen wir zwangsläufig etwas auf die Privatsphäre verzichten. Wenn ein Protokoll beispielsweise MEV-Schutz bietet, müssen Benutzer höchstwahrscheinlich davon ausgehen, dass dieser Teil des Knotenanbieters ehrlich funktioniert, d. h., dass dies tatsächlich der Fall ist Gilt für alle Protokolle. - Es wird ein gewisses Maß an Vertrauen vorausgesetzt. Laut unserer Beobachtung in einem früheren Forschungsbericht ist der Schutz der Privatsphäre für Institutionen und Großinvestoren einer der wichtigen Faktoren, wenn sie überlegen, ob Vermögenswerte in die Kette migriert werden sollen. Dies bedeutet auch, dass einige On-Chain-Datenplattformen Dritter die gezielten Angriffe von MEV-Searcher und Hackern auf große Haushalte und Institutionen verstärken können, sodass die Einführung des On-Chain-Datenschutzes zweifellos ihren Bedürfnissen natürlich gerecht wird.
Zuvor haben wir auch einen Forschungsbericht zu Singularity geschrieben, einem Projekt im Bereich Datenschutz, das auf Dark-Pool-Transaktionen abzielt (Erweiterte Lektüre: Detaillierte Erläuterung von Singularity: Private Transaktionen auf transparenten Blockchains).
Die Frage ist also: Was können wir tun, um die Privatsphäre zu schützen?
Die vier am häufigsten verwendeten Privacy-Computing-Lösungen sind: Fully Homomorphic Encryption (FHE), Multi-Party Computation (MPC), Trusted Execution Environment (TEE) und Zero-Knowledge Proof (ZKP, Zero Knowledge Proof). Was sie tatsächlich lösen, sind die Szenarioanforderungen in verschiedenen Situationen.
Erstens wird bei verschlüsselten Daten das Eigentum an den Daten dadurch bestimmt, wer der Besitzer des Entschlüsselungs-/Verschlüsselungsschlüssels ist. Im Allgemeinen können private Daten in persönliche Sichtbarkeit und Gruppensichtbarkeit unterteilt werden.
Persönlich sichtbare Daten (Personal Private State): Daten können nur von einer Person eingesehen und geändert werden, z. B. der persönliche Kontostand.
Sichtbare Gruppendaten (gemeinsamer privater Status): Daten können von mehreren Einheiten für Berechnungen verwendet werden, wobei die Privatsphäre gewährleistet ist, beispielsweise der Saldo in einem Liquiditätspool.
Für FHE, MPC und TEE können sie alle das Problem der gruppensichtbaren Daten lösen. Allerdings erfordert FHE teure Rechenressourcen, MPC erfordert, dass alle Validatoren online sind und TEE muss dem Dienstanbieter vertrauen. Die derzeitige Erforschung dieser Lösungen durch die Branche eignet sich nur für wenige Szenarien, wie z. B. Dark-Pool-Transaktionen, private Schlüsselverwaltung usw. Obwohl die von ZKP ausgegebenen Ergebnisinformationen begrenzt sind (d. h. „wahr oder falsch“-Fragen) und größtenteils nur auf persönliche sichtbare Daten anwendbar sind, werden seine Anwendungsszenarien von aktuellen Benutzern vollständig erforscht, wie z. B. Cross-Chain-Brücken, Layer 2, KYC , usw. Selbst wenn FHE und MPC oder sogar andere Privacy-Computing-Lösungen in Zukunft populär werden, wird ZKP aufgrund des Kannibalisierungseffekts/Marktwettbewerbs nicht aufgegeben, denn:
ZKP + FHE: Beispielsweise verwendet die ZKVM-Kette das UTXO-Modell. Wenn Sie jede Transaktion überprüfen möchten, muss der Prüfer vor der Überprüfung den gesamten Merkle-Baum herunterladen und einzeln dekodieren. Daher wird FHE eingeführt, um ohne Dekodierung zu berechnen. ergibt das gleiche Ergebnis.
ZKP + MPC: Ein Dark Pool, der MPC + ZKP verwendet, ermöglicht es Benutzern beispielsweise, die Atomizität von Transaktionen weiter sicherzustellen und gleichzeitig ihre eigene Privatsphäre zu schützen.
ZKP + TEE: Beispielsweise kann für ZK-SNARK die Generierung einer gemeinsamen Referenzzeichenfolge durch den Knoten durchgeführt werden, auf dem TEE ausgeführt wird, um sicherzustellen, dass die Zwischeninformationen nicht verloren gehen.
Wir können davon ausgehen, dass eine Vielzahl von ZKP-Anwendungsszenarien explodieren werden. Diese Nachfrage ist jedoch auf der Grundlage des aktuellen Mainstream-Layer1 immer noch schwer zu decken. Es müssen nicht nur hohe Gasgebühren anfallen, sondern es muss auch auf die Netzwerkverifizierung gewartet werden . Modular ZK As A Service (MZaaS) löst als Design-Framework eines ZKP-Dienstanbieters die oben genannten Probleme gut. MZaaS bietet eine Reihe von ZKP-bezogenen Diensten an, um die Komplexität der ZKP-Erzeugung zu reduzieren und die Effizienz zu verbessern. Diese Dienste können weiter in die folgenden Unterkategorien unterteilt werden:
Proof-Marktplatz: Es basiert hauptsächlich auf dem Konzept der Trennung zwischen Antragsteller und Prüfer und teilt den Prüfer in verschiedene Szenarien auf, um ungenutzte Prüfer-Ressourcen zu nutzen und so einen öffentlichen Proof-Markt bereitzustellen. Zu den Projekten, auf die verwiesen werden kann, gehören Mina, =nil; und ZKPool.
Verifizierungsschicht: Der Prüfer basiert hauptsächlich auf dem Konzept der Aggregation. Er sammelt mehrere Beweise und generiert einen neuen Beweis, um die Gültigkeit des ursprünglichen Beweises zu beweisen, und reduziert die Kosten des Verifizierungsprozesses durch die Bereitstellung einer Verifizierungsschicht. Zu den Projekten, auf die verwiesen werden kann, gehören Aligned Layer, Horizen, Cloaking Layer (zCloak Network) und Nebra.
Wie ist ZKP zu verstehen?
Bevor wir den ZKP-Markt verstehen, wollen wir uns ein Gesamtkonzept des ZKP-Lebenszyklus verschaffen. Grundsätzlich folgt das ZKP-Prüfsystem dem folgenden Prozess:
Der Prüfer erklärt, dass er bestimmte Informationen kennt und drückt sie in einem auf diesem Problem basierenden Einschränkungssystem aus.
Erzeugen Sie Schaltkreise gemäß dem formulierten Randsystem
Beweiser Geben Sie die Lösungsantwort (Zeuge) ein, die mit der Schaltung zur Berechnung des ZK-Beweises übereinstimmt
Der Validator kann ZKP überprüfen, um festzustellen, ob der Prüfer die Informationen wirklich kennt
Gehen wir davon aus, dass wir jetzt über einen Merkle Tree verfügen, der zum Aufzeichnen des Kontostands der Benutzer verwendet wird. Um den Kontostand zu aktualisieren, müssen wir normalerweise den folgenden Prozess befolgen:
Überprüfen Sie Sender- und Empfängerdatensätze in Blattknoten
Überprüfen Sie die Signatur des Absenders
Aktualisieren Sie die Salden von Sender und Empfänger
Aktualisieren Sie die Merkle-Wurzel des Merkle-Baums
Doch mit dem Segen des ZKP läuft dieser Prozess wie folgt ab:
Konstruieren Sie den Merkle Tree-Verifizierungsprozess vollständig in eine Schaltung
Berechnen Sie den ZKP, indem Sie den Merkle-Baum vor und nach der Aktualisierung und den Transaktionsdatensatz (jemand hat 10 $ an A gesendet) als Eingabe verwenden
Der Verifizierer verifiziert ZKP (unter Verwendung von ZKP, Verifizierungsschlüssel und öffentlicher Eingabe als Eingabe), und wenn das Ausgabeergebnis korrekt ist, gilt die Transaktion als glaubwürdig.
In diesem Prozess muss der Verifizierer selbst den Merkle-Baum nicht wiederholt überprüfen, sondern muss nur an die Verifizierungsergebnisse glauben (vorausgesetzt, die Schaltung ist korrekt aufgebaut).
Wenn ZKP aus einer hohen Perspektive weiter zerlegt wird, wird der Prozess von der Definition des Problems bis zum Aufbau der Schaltung vom Front-End (kompiliert in einer Hochsprache) und vom Back-End (kompiliert in einer Low-Level-Sprache) durchgeführt ) ist für die Einbettung/Kombination dieser Schaltung mit einem bestimmten Beweissystem verantwortlich, um ZKP zu generieren. Insbesondere wird die Schaltung zunächst mit dem informationstheoretischen Protokoll kombiniert und dann mithilfe eines kryptografischen Compilers wie Groth16 in ein geeignetes ZKP-System kompiliert.
Sexualität und Integrität. Solidität besagt, dass eine Aussage wahr ist, wenn sie in einem Beweissystem bewiesen wird. Vollständigkeit garantiert, dass eine Aussage, wenn sie wahr ist, im System beweisbar ist.
Interaktiver Beweis (IP): Der Prüfer stellt dem Prüfer eine Reihe „zufälliger“ Fragen. Der Prüfer antwortet. Dies wird viele Runden lang fortgesetzt, bis der Prüfer davon überzeugt ist, dass die Aussage des Prüfers richtig ist.
Probabilistic Checkable Proofs (PCP): Der Beweis wird in ein Format mit fester Größe umgewandelt, das als „Probekopie“ bezeichnet wird. Der Verifizierer kann nach dem Zufallsprinzip eine kleine Datenmenge im Replikat abfragen, um einen Verifizierungsnachweis zu erhalten. Um zu verhindern, dass der Prüfer den Abfragewert im Voraus vorhersagt und einen gefälschten Beweis erstellt, kann ein Orakel eingeführt werden, um Zufallswerte zu generieren, die der Prüfer für zufällige Abfragen verwenden kann. Aus theoretischer Sicht ist diese Methode effektiver, aus Sicht des Prüfprozesses jedoch relativ ineffizient.
Interactive Oracle Proof (IOP): Prüfer und Prüfer interagieren miteinander und haben Zugriff auf zufällige Beispiele. IOP verbessert die Effizienz interaktiver Beweise durch die Verwendung teilweiser Datenkopien, um die Kommunikations- und Abfragekomplexität zu reduzieren. Dies ist auch das häufig verwendete Beweissystem im ZKP-System.
Das zuvor erwähnte informationstheoretische Beweissystem basiert allesamt auf idealen Annahmen, die im wirklichen Leben nur schwer umzusetzen sind. Es könnte beispielsweise davon ausgegangen werden, dass der Prüfer vertrauenswürdig ist und der Zugriff auf die Bescheinigung eingeschränkt ist. Die Eigenschaften von Cryptograph machen diese Annahmen jedoch unter bestimmten Umständen möglich, beispielsweise bei häufigen mathematischen Problemen:
Das Ganzzahlfaktorisierungsproblem: Beispielsweise beruht die Sicherheit von RSA auf der Faktorisierung großer Zahlen.
Das Problem des diskreten Logarithmus: Der Diffie-Hellman-Schlüsselaustausch basiert auf diskreten Logarithmusberechnungen großer Zahlen.
Das Problem des diskreten Logarithmus mit elliptischen Kurven: Die Kryptographie mit elliptischen Kurven (ECC) basiert auf elliptischen Kurven in endlichen Feldern und komplexen diskreten Logarithmen mit elliptischen Kurven.
Nach der Kombination des informationstheoretischen Beweissystems und des kryptografischen Compilers kann das ZKP-System erhalten werden, sodass sich die Eigenschaften von ZKP bei unterschiedlichen Kombinationen ändern:
Rechenmethoden: Es gibt zwei Hauptmodi des allgemeinen Rechnens: Schaltkreise und Turing-Maschinen. Obwohl die meisten gängigen Programmiersprachen versuchen, den Rechenpfad einer Turing-Maschine zu beschreiben, ist eine Turing-Maschine nicht das effizienteste Programmiermodell für kryptografische Berechnungen, und alle effizienteren Programmiermodelle erhöhen in der Regel die Komplexität erheblich und erschweren so die Änderung kryptografischer Protokolle . Daher werden Schaltkreise anstelle von Turingmaschinen verwendet, da Schaltkreise viele direkte Aussagen sehr einfach ausdrücken können. Der Nachteil besteht jedoch darin, dass der Benutzer die verarbeiteten Berechnungen vorverarbeiten muss.
Rechenaufwand: Bei verschiedenen Kombinationen fallen die Kosten für Prüfer, Prüfer und Kommunikation unterschiedlich aus. Im ZKP-System in Kombination mit PCP + Collision-Resistant Hash Function (CRFS) betragen die Berechnungskosten beispielsweise wie folgt:
Anti-Quantum: Einige Verschlüsselungsalgorithmen können Brute-Force-Cracking durch Quantencomputer wirksam widerstehen. Beispielsweise kann die von ZK-STARK verwendete kollisionsresistente Hash-Funktion von Quantencomputern, die sich derzeit in der Entwicklung befinden, nicht direkt geknackt werden. Es besteht jedoch immer noch die Gefahr, geknackt zu werden. Beispielsweise haben zwei Wissenschaftler der Shandong-Universität in einem 2009 veröffentlichten Artikel beschrieben, wie man SHA1 und MD5 knackt. Wir brauchen also immer noch Vertrauensannahmen.
Vertrauenswürdige Konfiguration: Die vertrauenswürdige Konfiguration lässt sich in der Regel in zwei Kategorien einteilen: Die von URS generierten Zufallszahlen sind öffentlich sichtbar, was bedeutet, dass die „Zufälligkeit“ in zwei Typen unterteilt ist: Universal Setup und Specific Setup: Ersteres ermöglicht die Teilnahme mehrerer Probanden an der Generierung von Zufallszahlen, normalerweise in Form von MPC, und letzteres ermöglicht die Teilnahme an der Generierung von Zufallszahlen für ein bestimmtes Szenario.
Wenn in einem Peer-to-Peer-Szenario der böswillige Akteur den Zufallswert kennt, kann er die Ausgabe des Systems fälschen und den richtigen ZKP generieren.
Aus dem oben Gesagten ist auch ersichtlich, dass verschiedene Kombinationen auf verschiedene Arten von ZKP-Systemen erweitert werden können. Zusammenfassend kann es hauptsächlich in ZK-SNARK, ZK-STARK und Bulletproof unterteilt werden. Die folgenden Kernunterschiede können uns helfen, besser zu verstehen:
Vertrauenswürdige Konfiguration: ZK-SNARKs verwenden normalerweise eine vertrauenswürdige Konfiguration, ZK-STARKs und Bulletproof erfordern eine solche Konfiguration nicht.
Berechnen Sie die Kosten:
Beweiszeit: Bulletproof > ZK-SNARKs > ZK-STARKs
Überprüfungszeit: Bulletproof > ZK-STARKs > ZK-SNARKs
Kommunikationskomplexität/Beweisgröße: ZK-STARKs > Bulletproof > ZK-SNARKs, aber wenn die Datenmenge zunimmt, ist der von ZK-STARKs und Bulletproof benötigte Speicherplatz kleiner als der von ZK-SNARKs.
Quantenresistenz: ZK-STARKS sind im Allgemeinen quantenresistent, ZK-SNARKs und Bulletproof erfordern solche Eigenschaften nicht.
Bildquelle: https://github.com/matter-labs/awesome-zero-knowledge-proofs?ref=blog.pantherprotocol.io
Bildquelle: https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa Zero-Knowledge Proof Marktpotenzial und -umfang
Derzeit entwickelt sich der ZKP-Track hauptsächlich in zwei Hauptrichtungen: Privatsphäre und Erweiterung.
Expansionsplan
Es bezieht sich hauptsächlich auf die Einführung von ZKP als Lösung zur Verbesserung der Skalierbarkeit, einschließlich Layer2-Verfügbarkeitsnachweis, Cross-Chain usw. Zu den gängigen Lösungen gehören derzeit Starknet, ZKsync, Polyhedra usw. Es kann normalerweise in zwei Konstruktionssysteme unterteilt werden: Layer1/Layer2 und Protokoll. Im Layer1/Layer2-Bausystem werden Rollup-Transaktionen und -Anwendungen auf ZKEVM ausgeführt und verfügen über Zero-Knowledge-Proof-Eigenschaften. Ein ideales ZKEVM sollte EVM entsprechen, was bedeutet, dass es vollständig mit den vorhandenen Protokollen und der Entwicklungserfahrung von EVM kompatibel sein kann. Laut Vitaliks Blog lässt sich das aktuelle ZKEVM in 5 Kategorien einteilen:
Typ 1: Völlig identisch mit Ethereum, es werden keine Änderungen an seinem Status oder Transaktionsbaum, Hash-Code oder einer anderen Logik in seinem Konsens vorgenommen. Typ 1 wird mit allen nativen Ethereum-Anwendungen vollständig kompatibel sein, erfordert jedoch längere Proof-Zeiten, da keine Vorkompilierung zur Beschleunigung der Proof-Generierung erfolgt. Zu den derzeit als Referenz verfügbaren Projekten gehören Scroll und Taiko.
Typ 2: Ähnlich wie Ethereum im Aussehen, jedoch mit geringfügigen internen Änderungen, wie z. B. Zustandsbaum, Blockstruktur usw., um die Entwicklung zu erleichtern und die Beweiserstellung zu beschleunigen. Zu den aktuellen Referenzprojekten gehört Polygon Hermez.
Typ 2.5: Beschränken Sie einige ZK-Funktionen durch Erhöhung der Gasgebühr, um die potenzielle Überprüfungszeit zu verkürzen, wodurch im Wesentlichen die Symptome, aber nicht die Grundursache behandelt werden.
Typ 3: Einige Funktionen, die in der ZK-EVM-Implementierung besonders schwer zu implementieren sind, werden möglicherweise entfernt. Darüber hinaus gibt es manchmal geringfügige Unterschiede in der Handhabung von Vertragscode, Speicher oder Stacks, sodass die Kompatibilität mit Ethereum schwächer sein wird. Diese Kategorie ähnelt eher einer Übergangsphase der Produktentwicklung als einer Produktpositionierung.
Typ 4: Der in einer Hochsprache (z. B. Solidity) geschriebene Smart-Contract-Quellcode wird in eine Sprache kompiliert, die explizit für ZKP-Systemfreundlichkeit konzipiert ist, z. B. Cairo. Obwohl sich herausstellt, dass die Zeit beschleunigt werden kann. Allerdings ist die Kompatibilität am schlechtesten. Beispielsweise können einige mit Ethereum-Bytecode entwickelte DApps möglicherweise nicht migriert werden. Zu den derzeit als Referenz verfügbaren Projekten gehören ZKsync und Starknet.
Bildquelle: https://vitalik.eth.limo/general/2022/08/04/zkevm.html
Zu Beginn des Entwurfs von Ethereum war nicht vorgesehen, dass ZKEVM in Zukunft zur Erweiterung verwendet wird, daher ist die Entwicklungsschwierigkeit zweifellos sehr hoch. Daher haben sich ZKsync und Starknet auch für die Einführung eines Allzweck-ZKEVM entschieden Tatsächlich sollten sie so schnell wie möglich auf den Markt kommen. Sie werden ZKVM genannt, weil ihre Kompatibilität mit Ethereum (für Entwickler) relativ gering ist, aber im Gegenzug verfügen sie über eine höhere architektonische Flexibilität und niedrigere ZKP-Erzeugungskosten.
Diese Art von ZKVM kann sich von den Einschränkungen des EVM-Systems lösen und zu Layer 1 werden. Entwickler verwenden Hochsprachen, um Codes für bestimmte Architekturen virtueller Maschinen zu schreiben und diese dann in ZK-Schaltkreise zu kompilieren oder domänenspezifisch zu verwenden Sprachen (DSL) (z. B. Circom) zum direkten Generieren von ZK-Schaltkreisen.
Bildquelle: https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
Wenn wir allein die Marktgröße von ZK Layer2 berücksichtigen, beträgt der aktuelle TVL von ZK Layer2 (einschließlich ZK Rollup und Validium) laut L2Beat-Daten etwa 5,015 Milliarden US-Dollar, was 10 % bzw. 7 % des gesamten Layer2-TVL von Layer2 und Ethereum TVL ausmacht jeweils. Wenn der Marktanteil von OP Rollup als Maßstab herangezogen wird, hat ZK Rollup derzeit Raum für ein Wachstum von etwa dem Zehnfachen von TVL, und es wird erwartet, dass weitere 10 bis 12 neue ZK Layer 2-Linien auf den Markt kommen.
Unter ihnen liegen Linea, Starknet und ZKsync mit einem Anteil von 1,22 Milliarden US-Dollar, 1,06 Milliarden US-Dollar bzw. 855 Millionen US-Dollar an der Spitze . Betrachtet man weiter das Wachstum von Layer2 TVL, so fand das TVL-Wachstum hauptsächlich am 20. Februar 2024 statt. Der Grund dafür ist der Zufluss und die Aufwertung der nativen Starknet-Token. Derzeit werden noch 75 % der nativen Starknet-Token in der Kette behalten.
Unter diesen gehört Linea zum Typ-2-ZKEVM und Starknet und ZKsync gehören zum Typ-4-ZKEVM. Und die ersten drei sind alle ZK Rollup anstelle von Validium. Ersteres verwendet Ethereum als DA, und letzteres DA wird außerhalb der Kette platziert und von DAC verwaltet. Bei Validium steht Immutable X mit einem TVL von fast 200 Millionen US-Dollar an erster Stelle. Es ist auch erwähnenswert, dass im OP-Rollup die meisten der Top-10-Layer-2s mit dem höchsten TVL OP-Stack verwenden, was bedeutet, dass ein bestimmter Stack einen hohen Marktanteil hat. Aber im ZK Rollup entscheiden sich die Top 10 Layer2s mit dem höchsten TVL grundsätzlich dafür, ihren eigenen ZK Stack zu entwickeln.
Bildquelle: https://l2beat.com/scaling/summary
Bildquelle: https://l2beat.com/scaling/summary
Zu den Hauptszenarien für die ZKP-Erweiterung gehören neben dem oben genannten Layer1/Layer2 auch die Protokollschicht, beispielsweise Cross-Chain. Die Einführung von ZKP in Cross-Chain dient hauptsächlich der Cross-Chain-Infrastruktur der Light-Node-Verifizierung und Maker & Sender, wie Polyhedra, Orbiter Finance usw. Während des ursprünglichen Verifizierungsprozesses des Light Nodes muss der auf der Zielkette bereitgestellte Vertrag kontinuierlich den Blockheader der Quellkette für die anschließende kettenübergreifende Informationsverifizierung abrufen, was jedoch zwangsläufig Gas verbraucht Off-Chain: Wenn nur eine Verpflichtung in der Kette gespeichert wird, werden die Speicherkosten erheblich reduziert. Je höher die Aktualisierungshäufigkeit der Quellkette, desto höher sind die Gaskosten. Mit ZKP kann ein Commitment erstellt werden, das eine oder mehrere Transaktionen effektiv komprimieren kann. Im Maker&Sender-Modus wird ZKP mit Betrugsnachweisen kombiniert, um die ZKP-Erzeugung weiter zu reduzieren. Was die Marktgröße angeht, nehmen wir als Beispiel Orbiter Finance: Obwohl das Unternehmen derzeit ein monatliches Transaktionsvolumen von etwa 628 Millionen US-Dollar und einen TVL von 1,48 Millionen US-Dollar aufweist, wird die Nachfrage nach ZKP bei hohen Umsätzen ebenfalls steigen.
Datenschutzplan
Bezieht sich hauptsächlich auf Protokolle/Netzwerke, die ZKP als Datenschutz-Sicherheitslösung verwenden, einschließlich Zcash, Aztec und Tornado Cash.
Datenschutzorientierte Lösungen erfordern weniger Entwicklungsaufwand als skalierungsorientierte Entwicklungsrichtungen. Bestehende Datenschutzanwendungen konzentrieren sich hauptsächlich auf den Zahlungsschutz und sind nicht in hohem Maße programmierbar. Die Kombination von Datenschutz und Programmierbarkeit ist eine anspruchsvolle Aufgabe. Datenschutzorientierte Lösungen können auf zwei Arten erstellt werden:
Protokolle: Diese Protokolle verwenden ZKP hauptsächlich zur Erstellung privater Fondspools. Benutzer nutzen diese privaten Fondspools als Datenschutzlösungen, wie zum Beispiel Tornado Cash. Bei diesen Anwendungen erfolgt der Nachweis durch den Benutzer und die Verifizierung erfolgt in der Kette. Da Layer1 nicht für kryptografische Berechnungen konzipiert ist, sind die Verifizierungskosten für Mainstream-Benutzer oft hoch, was die Akzeptanz dieser Anwendungen einschränkt. Die intuitive Lösung besteht darin, private Transaktionsanwendungen in Rollup zu verschieben, um die Gasgebühren zu senken. In diesem Fall muss der private Transaktionsnachweis in den Rollup-Beweis, also den rekursiven Beweis, einbezogen werden, was derzeit mit dem regulären ZK-Rollup auf Ethereum nicht möglich ist.
Layer1/Layer2: Diese Layer1/Layer2 implementieren hauptsächlich den Datenschutz über ZKP, wie z. B. Manta Network und Aztec. Die meisten datenschutzorientierten Ketten können noch keine allgemeine Datenverarbeitung unterstützen und können sich nur auf bestimmte Anwendungsfälle konzentrieren. Penumbra und Renegade konzentrieren sich beispielsweise auf private Transaktionen. Die von diesen Layer1/Layer2 verwendeten Kontomodelle können unterteilt werden in: Kontobasiert und UTXO-basiert. Beide haben ihre eigenen Mängel: Ersteres kann aufgrund der Transaktionsroute zu einem gewissen Datenschutzverlust führen und erfordert eine serielle Verarbeitung, während letzteres die Entschlüsselung jedes Unterknotens erfordert, bevor er bei der Überprüfung und Aktualisierung des Transaktionssaldos korrekt abgefragt werden kann.
Laut Defilama beträgt der aktuelle TVL des Datenschutzbereichs etwa 709 Millionen US-Dollar, und die Drei-Firmen-Konzentrationsrate macht fast 99 % aus, nämlich Tornado Cash (595 Millionen US-Dollar), Railgun (96,97 Millionen US-Dollar) und Aztec (9,45 Millionen US-Dollar). Darunter sind Tornado Cash und Railgun Protokolle und Aztec gehört zur Schicht 2.
Bildquelle: https://defillama.com/protocols/Privacy
Unter anderem steht Tornado Cash vor einer Compliance-Unterdrückung, was auch bedeutet, dass viele „Compliance-Datenschutz“-Anforderungen nach und nach auf andere Protokolle und Netzwerke verlagert werden und die Konzentrationsrate nur allmählich sinken wird. Darüber hinaus untergraben derzeit viele Datenplattformen Dritter und zentralisierte Knotenanbieter auf dem Markt den Zensurwiderstand, und einige große Investoren und Institutionen hoffen, große Geldbeträge sicherer und privater zu transferieren. Zum 3. Juni unterlagen etwa 37 % der Blöcke einer OFAC-Überprüfung, was der öffentliche Mempool nicht vermeiden kann.
Bildquelle: https://www.mevwatch.info
Dadurch werden auch die Compliance-Anforderungen weiter ausgeweitet, sodass auch Dienstleister wie KYC eine große Bedeutung haben. Benutzer möchten jedoch häufig weiterhin ihre Privatsphäre im größtmöglichen Umfang wahren. Die potenziellen Szenarien von ZKP + KYC werden mit der Verbesserung der Datenschutztransaktionen zunehmen. Die wichtigsten Dienstanbieter auf dem aktuellen Markt sind zCloak, zkMe usw. Wenn wir im traditionellen KYC-Prozess mehrere KYC-Dienstanbieter beauftragen müssen, müssen wir wiederholte Überprüfungen durchführen. Im Fall von ZKP + KYC können jedoch andere Dienstanbieter versuchen, den ZKP zu überprüfen, um die Gültigkeit der Identität sicherzustellen. Darüber hinaus müssen Dienstanbieter während des KYC-Prozesses einige notwendige Informationen aufzeichnen, beispielsweise sensible Informationen wie Ausweise. Wenn dieser Prozess bei mehreren Dienstanbietern durchgeführt wird, steigt auch das Risiko von Informationslecks linear an.
Vor welchen Problemen steht ZKP jetzt?
Wie bereits erwähnt, erfordert die ZKP-Generierung erhebliche Rechenressourcen. Am Beispiel des gängigen ZK-Rollups beträgt die ZKP-Generierungszeit von ZKsync etwa 1 Stunde. Wenn man es weiter zerlegt, umfasst der ZKP-Erzeugungsprozess von ZK-SNAKS hauptsächlich die multiskalare Multiplikation (MSM) und die zahlentheoretische Transformation (NTT). Diese beiden Prozesse können 80 bis 95 % der Zeit für die Beweiserstellung ausmachen. Obwohl ZK-STARKs unterschiedliche Algorithmen verwendet, besteht auch das Problem einer geringen Effizienz.
Darüber hinaus bieten ZKP-Systeme in den letzten Jahren ein breites und ständig wachsendes Spektrum an Optionen mit unterschiedlichen Kompromissen. Der Kompromiss für eine schnellere Proof-Geschwindigkeit ist beispielsweise eine größere Proof-Größe oder eine größere Speicherauslastung. Die Vielfalt an Proofsystemen mit unterschiedlichen Anpassungsmöglichkeiten ist groß und wächst ständig. Aber Ethereum ist nicht in der Lage, das sich entwickelnde Beweissystem zu unterstützen. Beispielsweise können nur elliptische BN-254-Kurven kostengünstig unterstützt werden. Aber die Migration zu einer sichereren Kurve (wie BLS12-381) ist eine sehr komplizierte Aufgabe, ganz zu schweigen von der Kompatibilität mit dem neuen ZKP-System.
Darüber hinaus betragen die Kosten für die Verifizierung von STARK im Hinblick auf die Layer-1-Verifizierung ZKP etwa 5.000.000 Gas, während der Plonk-basierte Nachweis weniger als 290.000 Gas kostet. Wenn das Beweissystem direkt in Ethereum verifiziert wird, gibt es derzeit mehrere Einschränkungen, zum Beispiel Beweissysteme, die auf inneren Produktargumenten basieren, wie Minas Kimchi (Implementierung einer effizienten Rekursion durch Pickles) oder Brakedown-basiertes Binius (Beweise mit Quadratwurzelgröße). Der Rechenaufwand bzw. die Beweisgröße ist relativ groß, so dass die Verifizierungskosten sehr hoch sein werden. Dazu müssen wir möglicherweise auf Ethereum-freundliches ZKP umstellen.
Wie modulare ZK-Services den ZKP-Prozess beschleunigen
Daher ist die Frage, wie die Effizienz verbessert werden kann, die Richtung, die in der nächsten Entwicklung von ZKP diskutiert werden soll. Neben Änderungen an Algorithmen/Schaltungen können die aktuellen Hauptlösungen in zwei Kategorien unterteilt werden:
Hardwarebeschleunigung: Verbessern Sie den ZKP-Generierungsprozess durch Verbesserung der Hardware. Die GPU verbessert die ZKP-Überprüfungszeit normalerweise nur begrenzt. Eine weitere Option besteht darin, dedizierte Hardware wie FPGA oder ASIC zu verwenden und dann die Hardware-Abstraktionsschicht zu erweitern, die auf den AI-Cloud-Dienst verwiesen werden kann. Da der Schwerpunkt dieses Artikels nicht auf der Diskussion der Hardwarebeschleunigung liegt, werden wir nicht im Detail darauf eingehen.
Modularer ZK-As-A-Service (MZaaS): Reduziert die Komplexität der ZKP-Generierung und verbessert die Effizienz durch die Bereitstellung einer Reihe von ZKP-bezogenen Diensten. Diese Dienste können weiter in die folgenden Unterkategorien unterteilt werden:
Proof-Marktplatz: Es basiert hauptsächlich auf dem Konzept der Trennung zwischen Antragsteller und Prüfer und teilt den Prüfer in verschiedene Szenarien auf, um ungenutzte Prüfer-Ressourcen zu nutzen und so einen öffentlichen Proof-Markt bereitzustellen. Zu den Projekten, auf die verwiesen werden kann, gehören Mina, =nil und ZKPool.
Verifizierungsschicht: Der Prüfer basiert hauptsächlich auf dem Konzept der Aggregation und sammelt mehrere Beweise und generiert einen neuen Beweis, um die Gültigkeit des ursprünglichen Beweises zu beweisen. Durch die Bereitstellung einer Verifizierungsschicht werden die Kosten des Verifizierungsprozesses gesenkt. Zu den Projekten, auf die verwiesen werden kann, gehören Aligned Layer, Horizen, Cloaking Layer (zCloak Network) und Nebra.
Proof-Marktplatz
Zunächst können wir aus den oben genannten Anwendungsszenarien feststellen, dass nicht alle Transaktionen in ZKP-Anwendungsszenarien generiert werden, sodass wir sie in zwei Generierungsmethoden einteilen können (am Beispiel von Cross-Chain):
Vollständiger ZK: ZKP wird für jede Transaktion generiert. Beispielsweise generiert Maker für jede Transaktion auf ZK Bridge ZKP zur Verifizierung.
Halber ZK: ZKP wird nur generiert, wenn bestimmte Bedingungen erfüllt sind. Orbiter Finance muss beispielsweise nur dann ZKP generieren, wenn falsche oder nicht vertrauenswürdige Transaktionsinformationen angezeigt werden.
Im Half-ZK-Szenario sind also nicht alle Prüfer vollständig ausgelastet. Wenn wir die Rolle des Beweisgebers in Anforderer und Beweisgeber aufteilen und eine gemeinsame Plattform/einen Marktplatz für den Beweisgeber erstellen, können wir die Nutzung des Beweisgebers verbessern und möglicherweise die Zeit reduzieren, die für die ZKP-Generierung in vollständigen ZK-Szenarien erforderlich ist. Die Frage ist jedoch: Wie wählt man einen Prüfer aus?
Das spezifische Design der Auswahl von Prover kann tatsächlich in mehreren Dimensionen betrachtet werden: Leistung, Kosten und Dezentralisierung. Es ähnelt im Wesentlichen dem unmöglichen Dreieck des Konsensmechanismus. Beispielsweise wird die Überprüfung mit mehreren Knoten gewählt, um die Dezentralisierung sicherzustellen, aber eine wiederholte Überprüfung erhöht zweifellos nur die Überprüfungszeit (geringere Leistung). Basierend auf den verschiedenen ZKP-Wirtschaftsmodellen, die Taiko untersucht hat, haben sie die folgende Grafik zusammengefasst. Der Autor wird hier nicht zu sehr ins Detail gehen.
Bildquelle: https://www.theblockbeats.info/news/45260 Verifizierungsschicht
Zunächst müssen wir den Unterschied zwischen der Aggregations- und der Verifizierungsschicht klären: Erstere komprimiert ZKP lediglich auf irgendeine Weise, z. B. durch Rekursion und Faltung, letztere fügt auf dieser Basis einen vorläufigen Verifizierungsprozess (Soft Finality) hinzu. Der Prozess der Soft Finality kann auf externen Verträgen/Netzwerken basieren, was ein gewisses Maß an Vertrauen voraussetzt.
Im eigentlichen Aggregationsprozess unterscheidet sich die Architektur verschiedener Projekte geringfügig, es gibt jedoch im Allgemeinen die folgenden vier Verknüpfungen (am Beispiel von ZKTree, das von Polymer verwendet wird):
ZKP-Zusammensetzung: Kombinieren Sie eine beliebige Schaltung zu einem neuen ZKP, möglicherweise mit Hilfe von Rekursion und Faltung.
ZKP-Vereinheitlichung: Vereinheitlichung des oben genannten Prozesses in einem neuen ZKP.
ZKP-Rekursion: Rekursieren Sie den neu generierten Stapel untergeordneter Knoten (einheitliches ZKP) erneut und verwenden Sie diesen ZKP-Stapel als Überprüfungsnachweis, um weiche Gültigkeit/Endgültigkeit zu erreichen.
ZKP-Transformation: Wenn sie eine bestimmte VM bedienen müssen, verfügen sie möglicherweise über eine eigene Anpassungsfähigkeit an verschiedene ZKP-Systeme und werden je nach Situation weiter auf ZKP verschiedener Systeme abgebildet, um die Verifizierungskosten zu senken.
Die Verifizierungsschicht kann durch Soft Finality eine sofortige Verifizierung ermöglichen und sich in verschiedene Systeme integrieren (nicht beschränkt auf Ethereum). Bei der Verfolgung relativ geringer Sicherheitsanforderungen kann Soft Finality zur Erzielung einer höheren Effizienz eingesetzt werden. Und durch die Verifizierungsschicht kann auch paralleles Rechnen ermöglicht werden, wodurch die technischen Schulden von Ethereum weiter abgebaut werden. Noch wichtiger ist, dass dadurch die Verifizierungskosten gesenkt werden können. Laut tatsächlichen Nebra-Tests kann jeder in der Ethereum-Kette eingereichte Beweis bis zu 184.000 Gas (ungefähr 75 %) einsparen, und jeder außerhalb der Kette eingereichte Beweis kann bis zu 207.000 Gas (ungefähr 85 %) einsparen. Darüber hinaus schätzt Aligned Layer auch, dass die Kosten für die Verifizierung auf Groth16 und STARKs 29-mal und 80-mal geringer sein werden als die ursprüngliche Verifizierung auf Ethereum, und es wird Hardware der Heimklasse verwendet.
Cloaking Layer So implementieren Sie die Verification Layer
Einführung
Cloaking Layer ist ein neues Produkt von zCloak Network, das sich auf die Bereitstellung von Verifizierungsschichtdiensten für ZKP konzentriert. Die Kernidee besteht darin, die extrem hohe Effizienz und die extrem niedrigen Kosten von Internet Computer (ICP) zu nutzen und den auf WebAssembly (WASM) basierenden Canister-Vertrag zu verwenden, um jeden ZKP direkt zu überprüfen. Basierend auf derselben Vertrauensannahme wird dann die Schwellenwertsignaturtechnologie verwendet, um die Verifizierungsergebnisse an eine beliebige öffentliche Zielkette zu senden, um ZKP-Verifizierungsdienste zu erreichen, die die gesamte Kette abdecken. (Erweiterte Lektüre: Cloaking Layer – eine ZK-Verifizierungsinfrastruktur für alle Ketten)
Hauptarchitektur
Bildquelle: https://zcloaknetwork.medium.com/cloaking-layer-a-zk-verification-infra-for-all-chains-1162d3fcc37b
Der Kern der Cloaking-Schicht ist zunächst der ICP-Kanister, der den Verifizierer (Verifier) von ZKP direkt in WASM-Form ausführen kann, um die Beweise „SNARK“ und „STARK“ direkt zu überprüfen. ICP Canister kann als intelligenter Vertrag in der EVM-Kette verstanden werden. Er kann nach der Bereitstellung nicht manipuliert werden, und die Betriebsergebnisse erfordern den Konsens des gesamten Netzwerks. Im Gegensatz zu EVM-Verträgen, die in der Solidity-Sprache geschrieben werden müssen, können Canister-Verträge WASM-kompilierte Objekte gut unterstützen. Da die überwiegende Mehrheit der aktuellen ZKVM-Systeme wie Polygon Miden, RISC0, SP1, Jolt usw. in der Programmiersprache Rust geschrieben sind und problemlos in WASM kompiliert werden können, eignet sich Canister sehr gut als Validator von ZKP.
Die öffentliche ICP-Kette besteht aus mehreren Subnetzen (Subnetzen), und jedes Subnetz enthält eine große Anzahl von Knoten (Replikat). Nachdem ein Canister-Vertrag bereitgestellt wurde, wird in jedem Subnetzknoten eine Kopie gespeichert und in jedem Knoten unabhängig ausgeführt. Anschließend vergleicht das Subnetz die Betriebsergebnisse aller Knoten und erzielt einen Konsens, um sicherzustellen, dass die Betriebsergebnisse von Canister korrekt sind. Wenn die Cloaking-Schicht den ZKP empfängt, berechnet und überprüft der in jedem Knoten bereitgestellte Validatorkanister den ZKP unabhängig. Sobald das Attestierungsergebnis innerhalb des Subnetzes einen Konsens erreicht, signiert das Subnetz das Verifizierungsergebnis digital mithilfe der Threshold ECDSA-Signaturtechnologie. Die signierten Verifizierungsergebnisse können zur Verwendung an jede öffentliche Kette gesendet werden, die die ECDSA-Signaturverifizierung unterstützt, wie z. B. Bitcoin, Ethereum und Solana.
Wettbewerbsanalyse
Kernpunkte:
Derzeit klafft eine große Diskrepanz zwischen den Bewertungen der Lösungen auf dem Markt.
Derzeit sind die meisten Lösungen bereits auf Testnet verfügbar
Es wird geschätzt, dass die durchschnittlichen Verifizierungskosten um mehr als das Zehnfache reduziert werden, wobei Cloaking Layer die höchste Leistung bietet.
Die meisten Vertrauensannahmen basieren auf Layer1
Die meisten Projekte führen nur eine „Verifizierungserweiterung“ für Ethereum durch
auswerten
Der größte Unterschied zwischen Cloaking Layer und anderen aktuellen Verification Layer-Lösungen liegt in der Vertrauensannahme. Derzeit ist die Bewerbung als Replikat (ICP-Knoten) äußerst anspruchsvoll. Sie erfordert die Genehmigung der ICP Foundation und höhere Anforderungen an die Knotenhardware (höher als Layer 1 mit schwereren Knotenkonfigurationen wie Solana und Sui). bestimmte Vertrauensgrenze in der Effizienz der ECDSA-Schwellenwertsignatur, die im Wesentlichen immer noch auf 2/3 der ehrlichen Knoten im Netzwerk angewiesen ist. Aufgrund der Leistungsvorteile von ICP-Knoten muss Cloaking Layer außerdem nicht auf komplizierte ZKP-Rekursionsschemata zurückgreifen, um eine ZKP-Komprimierung zu erreichen. Diese Methode ist auch die direkteste und bequemste.
ausführliche Diskussion
Wie kann ich Zensurresistenz in den Verification Layer einbauen?
Der einfachste und effektivste Weg ist die Verwendung des Anti-Zensur-Mechanismus von Schicht 1. Solange der Verifizierer/Unified Prover in der Verifizierungsschicht die übermittelte Transaktion nicht abfangen kann, kann die Anti-Zensur-Fähigkeit von Schicht 1 geerbt werden. Das eigentliche Verständnis besteht darin, dass der Benutzer/das Protokoll ZKP direkt an den Smart Contract der Verifizierungsschicht in Schicht 1 (Kanister auf ICP) übermitteln und es in einer Warteschlange speichern kann, die darauf wartet, von Verifier/Unified Prover gepackt zu werden. Aus Sicht von Arbitrum kann jeder nach einer gewissen Zeit ohne entsprechenden Sequencer eine Transaktion in den Transaktionsverlauf der Schicht 2 einbinden.
Was ist der ZKP-EV-Markt?
Durch die oben genannten Überlegungen können wir zusätzliche Bearbeitungsgebühren zur Priorisierung der Verpackung bereitstellen. Wenn der Umfang relativ groß ist, ist es möglich, einen ZKP-EV-Markt (Extractable Value) zu entwickeln, der dem MEV-Markt ähnelt.
Wie gehen Soft Finality und Hard Finality einen Kompromiss ein?
Alle Verifizierungsschichten bieten Soft Finality, und da die Leistung dieser Verifizierungsschichten höher ist als die von Ethereum, ist auch die Verifizierungsgeschwindigkeit besser als die von Ethereum. Wenn Sie jedoch die harte Endgültigkeit von Schicht 1 durchlaufen müssen, ist diese Zeit länger als die Zeit ohne Verwendung der Verifizierungsschicht. Dies ist auch ein Nachteil der Beibehaltung von harter Endgültigkeit + aggregierter ZKP. Daher ist die aktuelle Verifizierungsschicht für Protokolle, die bei Hard Finality mehr Vorsicht erfordern, möglicherweise keine ausreichend gute Lösung. Es sollten Slashing-Module, Reputationssysteme und Versicherungsmechanismen eingeführt werden, um ein Gleichgewicht zwischen Effizienz und Sicherheit herzustellen. Sie können auf unsere früheren Artikel verweisen (erweiterte Lektüre: TeleportDAO: The Game of Data Verification Security and Efficiency, die neuesten Praktiken im Light-Node-Design).
Was sind die Einnahmequellen für ZK-As-A-Service?
Das aktuelle Geschäftsmodell aller ZaaS ist noch relativ vage. Neben der Möglichkeit, einen Teil der Provision im ZKP-Prozess abzuschöpfen, besteht es darin, Coins auszugeben. Der Cashflow des Unternehmens ist jedoch im Wesentlichen vom Token-Wert entkoppelt, sofern er nicht durch eine starke Rückkaufverpflichtung (wie MKR von MakerDAO) gebunden ist. Obwohl erwartet wird, dass der aktuelle Markt groß sein wird, muss die tatsächliche Umsatzentwicklung daher noch vom Markt überprüft werden.
Referenz
https://medium.com/casperblockchain/verified-merkle-tree-updates-without-zk-90d8f5100ccd
https://www.zkcamp.xyz/blog/information-theory
https://x.com/iam_preethi/status/1656411033366396929 https://crypto.stackexchange.com/questions/92018/which-is-the-relation-between-zero-knowledge-proofs-of-knowledge-and-schaltungen https://web.archive.org/web/20090521024709/http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa
https://www.paradigm.xyz/2022/04/zk-hardware
https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4?ref=blog.pantherprotocol.io
https://x.com/jaosef/status/1730313497513476326
https://l2beat.com/scaling/summary
https://defillama.com/protocols/Privacy
https://docs.zksync.io/zk-stack/concepts/finality.html#finality-on-zksync-era
https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
https://dune.com/nebra/zkp-verify-spending
https://medium.com/@eternal1997L/Die Gründe für den Rückgang von ICP – einzigartige Technologie und dünne Ökologie – 51dd7a9362fb
