Ein Entwicklerleitfaden für die zkGalaxy

Ein Entwicklerleitfaden für die zkGalaxy

Quellknoten: 1946171

Einleitung

Vitaliks Kompromisse für zkEVMs zwischen Leistung und Kompatibilität

Dies ist eine äußerst nützliche Heuristik, um Ansätze zur Unterstützung eines zkEVM zu unterscheiden. Allerdings sind zkEVMs eine Teilmenge aller Möglichkeiten, Zero-Knowledge-Anwendungen zu erstellen. Für einen Programmierer, der die einzigartigen Eigenschaften der zk-Berechnung nutzen möchte, nämlich Prägnanz, Nullwissen und Korrektheit, ist ein zkEVM möglicherweise nicht die beste Wahl. Indem ich den gesamten Satz an Entwicklertools darlege, hoffe ich, Ihnen einen Leitfaden zur Verfügung zu stellen, der Sie bei der Entscheidungsfindung rund um den richtigen zk-Stack für Ihre Anwendung unterstützt.

In den letzten ein bis zwei Jahren gab es enorme Fortschritte bei zk-Tools. Sie nähern sich einem Punkt, an dem normale Softwareentwickler die leistungsstarken Eigenschaften von zk nutzen können, ohne ein tiefes Verständnis der einschüchternden zugrunde liegenden Mathematik und Technik zu haben. Auf der anderen Seite gab es eine Zunahme von Tools für Power-User, die zk-Experten eine extrem feine Kontrolle über den zk-Stack geben.

Die Kraft der Abstraktion von Komplexität

Moderne Software baut auf unzähligen Abstraktionsebenen auf, um die Produktivität von Spezialisten zu maximieren. Es gibt viele Vorteile der Abstraktion im Engineering, die etwas intuitiv sind – ein Webentwickler muss nicht verstehen, wie Betriebssysteme im Detail funktionieren. 

Der Schlüssel zum Erstellen guter, wiederverwendbarer Abstraktionsschichten besteht darin, die Komplexität einer Schicht zu kapseln und dann einfache, aber ausdrucksstarke Schnittstellen für Schichten bereitzustellen, die höher im Stapel verwendet werden können. Richtig gemacht, ermöglicht dies Entwicklern mit unterschiedlichen Fachgebieten und Kenntnissen, nützliche Tools für den gesamten Stack zu erstellen.

Es überrascht nicht, dass dieselben Prinzipien auf zk-Systeme zutreffen, und diese Abstraktionsschichten werden immer ausgereifter, sodass ein zk-Neuling heute damit beginnen kann, sie zu verwenden und Anwendungen zu erstellen.

Der zk-Tech-Stack
Der zk Stack mit einigen Beispiel-Tools/Technologien auf jeder Ebene

Low-Level-zk-Entwicklung

Arkworks-rs

Arkworks-rs ist ein Ökosystem von Rust-Bibliotheken, das effiziente und sichere Implementierungen der Unterkomponenten einer zkSNARK-Anwendung bietet. Arkworks bietet die Schnittstellen, die Entwickler benötigen, um den Software-Stack für eine zk-Anwendung anzupassen, ohne Gemeinsamkeiten mit anderen vorhandenen Bibliotheken neu implementieren zu müssen.

Vor Arkworks bestand die einzige Möglichkeit zum Erstellen einer neuen zk-Anwendung darin, alles von Grund auf neu zu erstellen. Die Hauptvorteile von Arkworks-rs gegenüber kundenspezifischen, vertikal integrierten Tools sind das Maß an Flexibilität, die Reduzierung von doppeltem Engineering und die Reduzierung des Prüfungsaufwands. Die vernünftigen Schnittstellenlinien von Arkworks zwischen den Komponenten ermöglichen ein Tempo der Aufrüstbarkeit, das den Stack inmitten des rasanten Innovationstempos bei zk-Technologien relevant halten kann, ohne die Teams zu zwingen, alles von Grund auf neu zu erstellen.

Für wen ist es geeignet?

Arkworks ist für Projekte gedacht, die eine genaue Kontrolle über den gesamten zk-Software-Stack benötigen, aber nicht alle redundanten Teile von Grund auf neu erstellen möchten. Wenn Sie eine benutzerdefinierte Version einer Leitungs-DSL in Betracht ziehen, weil Sie beispielsweise ein neues Proof-System prototypisieren, sich aber bezüglich des Commitment-Schemas oder der entsprechenden elliptischen Kurve nicht sicher sind, können Sie mit arkworks schnell zwischen mehreren Optionen mit gemeinsam genutzten Schnittstellen wechseln als bei Null anzufangen.

Vorteile

  • Flexibilität durch Modularität
  • Weniger Duplizierung von Code
    • Niedrigere Engineering-Kosten
    • Reduzierte Audit-/Bug-Oberfläche
  • Rüsten Sie jede Komponente ohne größere Umgestaltung auf
  • Einfaches Experimentieren mit neuen Primitiven in einer sich schnell entwickelnden zk-Umgebung

Nachteile

  • Erfordert ein tiefes Verständnis des gesamten Software-Stacks
    • Zu viel Kontrolle kann zu Fußpistolen führen, wenn sie nicht richtig verstanden werden
  • Granulare Kontrolle erfordert Fachwissen auf allen Ebenen des Stacks
    • Arkworks bietet einige sinnvolle Standardeinstellungen.

zk Domänenspezifische Sprachen (DSL)

Um einen Beweis über eine Berechnung zu erstellen, muss diese Berechnung zuerst in einer Form ausgedrückt werden, die ein zkSNARK-System verstehen kann. Mehrere domänenspezifische Sprachen haben Programmiersprachen geschaffen, die es Anwendungsentwicklern ermöglichen, ihre Berechnungen auf diese Weise auszudrücken. Diese beinhalten Aztekisches Noir, Starknets KairoZirkomZoKrates, und Aleos Löwe unter anderen. Das zugrunde liegende Beweissystem und mathematische Details werden dem Anwendungsentwickler im Allgemeinen nicht offengelegt.

Die Entwicklererfahrung

zkApp-Entwickler müssen ihre Programme in domänenspezifischen Sprachen schreiben können. Einige dieser Sprachen sehen vertrauten Programmiersprachen sehr ähnlich, während andere ziemlich schwer zu erlernen sein können. Lassen Sie uns einige davon aufschlüsseln:

Kairo – Starkware DSL erforderlich zum Erstellen von Apps auf Starknet. Kompiliert in eine Cairo-spezifische Assemblersprache, die von der Cairo-zkVM interpretiert werden kann.

ZoKrates — ZoKrates ist ein Toolkit für allgemeine SNARK-Anforderungen, einschließlich einer Hochsprache zum Schreiben von Schaltkreisen. ZoKrates hat auch eine gewisse Flexibilität in Bezug auf die Kurven, das Prüfschema und das Backend, sodass Entwickler mit einem einfachen CLI-Argument Hot-Swap durchführen können.

Zirkom — Circom ist eine speziell entwickelte Sprache zum Erstellen von Schaltkreisen. Derzeit ist es die De-facto-Sprache für Schaltkreise in der Produktion. Die Sprache ist nicht besonders ergonomisch. Die Sprache selbst macht Ihnen deutlich, dass Sie Schaltungen schreiben.

Löwe — Leo wurde als Sprache für die Aleo-Blockchain entwickelt. Leo hat eine Rust-ähnliche Syntax und wurde speziell für Zustandsübergänge innerhalb einer Blockchain entwickelt.

Schwarz – Rust-inspirierte Syntax. Entwickelt um die IR und nicht um die Sprache selbst, was bedeutet, dass es ein beliebiges Frontend haben kann. 

Der Aztec Noir Compilation Stack hat insbesondere eine modulare Architektur

Für wen ist es geeignet?

Jeder Anwendungsentwickler, der die einzigartigen Eigenschaften von zk in seiner Anwendung nutzen möchte. Einige dieser Sprachen wurden kampferprobt, wobei Milliarden von Dollar über Ketten wie ZCash und Starknet über sie bewegt wurden. Während einige der Projekte, die wir besprechen werden, noch nicht ganz reif für den Produktionseinsatz sind, ist das Schreiben Ihrer Schaltungen in einer dieser Sprachen derzeit die beste Strategie, es sei denn, Sie benötigen die feineren Steuerungsmöglichkeiten, die ein Toolkit wie Arkworks bietet.

Vorteile

  • Benutzer müssen die zugrunde liegenden zk-Details nicht verstehen
  • Heute verfügbar mit etwas Produktionserfahrung
  • An Kette nachweisbar
  • Ökosystem-Agnostiker

Nachteile

  • Benutzer müssen eine neue DSL lernen
  • Isolierte Tools und Support für jede dieser Sprachen
  • Wenig bis keine Kontrolle über den zugrunde liegenden Prüfstapel (vorerst)

Das Hauptziel eines zkEVM ist es, einen Ethereum-Zustandsübergang zu nehmen und seine Gültigkeit mit einem prägnanten Zero-Knowledge-Proof of Correctness zu beweisen. Wie in Vitaliks Beitrag erwähnt, gibt es eine Reihe von Möglichkeiten, dies mit subtilen Unterschieden und entsprechenden Kompromissen zu tun. 

Der technische Hauptunterschied zwischen all diesen besteht genau darin, wo im Sprachstapel die Berechnung in eine Form (Arithmetisierung) umgewandelt wird, die in einem Beweissystem verwendet werden kann. Bei einigen zkEVMs geschieht dies in den Hochsprachen (Solidity, Vyper, Yul), während andere Ansätze versuchen, die EVM bis auf die Opcode-Ebene zu beweisen. Die Kompromisse zwischen diesen Ansätzen wurden in Vitaliks Beitrag ausführlich behandelt, aber ich fasse es in einem Satz zusammen: Je niedriger die Konvertierung/Arithmetik im Stapel erfolgt, desto größer ist die Leistungseinbuße.

Warum sind die EVM-Opcodes in zk teuer zu beweisen?

Die größte Herausforderung beim Erstellen von Beweisen für eine virtuelle Maschine besteht darin, dass die Größe der Schaltung proportional zur Größe ALLER möglichen Anweisungen für jede ausgeführte Anweisung wächst. Dies liegt daran, dass die Schaltung nicht weiß, welche Anweisungen in jedem Programm ausgeführt werden, also muss sie alle unterstützen.

In universellen Schaltungen hat jeder ausgeführte Befehl Kosten, die proportional zur Summe aller unterstützten Befehle sind.

In der Praxis bedeutet dies, dass Sie (in Leistungskosten) für die teuerste mögliche Anweisung bezahlen, selbst wenn Sie nur die einfachste Anweisung ausführen. Dies führt zu einem direkten Kompromiss zwischen Generalisierbarkeit und Leistung – wenn Sie weitere Anweisungen für die Generalisierbarkeit hinzufügen, zahlen Sie dafür weiter alles, Anweisung, die Sie beweisen!

Dies ist ein grundlegendes Problem bei universellen Schaltungen, aber mit neue Entwicklungen in Technologien Wie bei IVC (inkrementelle verifizierbare Berechnung) kann diese Einschränkung verbessert werden, indem die Berechnung in kleinere Teile aufgeteilt wird, die jeweils spezialisierte, kleinere Teilschaltungen haben.

Die heutigen zkEVM-Implementierungen verwenden unterschiedliche Strategien, um die Auswirkungen dieses Problems zu mildern … Zum Beispiel reißt zkSync die teureren Operationen (hauptsächlich kryptografische Vorkompilierungen wie Hashes und ECDSA) aus der Hauptausführungsprüfungsschaltung in separate Schaltungen, die am zusammengeführt werden Ende über Snark-Rekursion. zkSync hat diesen Ansatz gewählt, nachdem es erkannt hatte, dass der Großteil seiner Kosten durch einige wenige komplexe Anweisungen verursacht wurde.

Die Transaktionskosten werden von den wenigen teuren Operationen dominiert.

Der Grund dafür, dass der Nachweis eines EVM-äquivalenteren Befehlssatzes teurer ist, liegt im Kern darin, dass die EVM nicht für zk-Berechnungen entwickelt wurde. Das Verlassen der EVM früher im Stack ermöglicht es zkEVMs, auf Befehlssätzen zu laufen, die besser für zk optimiert sind und daher billiger zu beweisen sind.

Für wen ist es geeignet?

Die idealen Kunden für ein zkEVM sind intelligente Vertragsanwendungen, die um Größenordnungen günstigere Transaktionen benötigen als das, was auf L1 Ethereum verfügbar ist. Diese Entwickler verfügen nicht unbedingt über das Fachwissen oder die Bandbreite, um zk-Anwendungen von Grund auf neu zu schreiben. Daher schreiben sie ihre Anwendungen lieber in höheren Sprachen, mit denen sie vertraut sind, wie Solidity. 

Warum bauen so viele Teams das?

Ethereum skalieren ist derzeit die am meisten nachgefragte Anwendung der zk-Technologie.

Ein zkEVM ist eine Ethereum-Skalierungslösung, die das Überlastungsproblem, das L1-dApp-Entwickler einschränkt, reibungslos entschärft.

Die Entwicklererfahrung

Das Ziel eines zkEVM ist es, eine Entwicklererfahrung zu unterstützen, die so nah wie möglich an der aktuellen Ethereum-Entwicklung ist. Vollständige Solidity-Unterstützung bedeutet, dass Teams nicht mehrere Codebasen erstellen und pflegen müssen. Dies ist etwas unpraktisch, um dies perfekt zu machen, da zkEVMs einige Kompromisse bei der Kompatibilität eingehen müssen, um in angemessener Zeit Beweise von angemessener Größe generieren zu können.

Schnelle Fallstudie: zkSync vs. Scroll

Der Hauptunterschied zwischen zkSync und Scroll besteht darin, wo/wann im Stack sie Arithmetik durchführen – das heißt, wo sie von normalen EVM-Konstrukten in eine SNARK-freundliche Darstellung konvertieren. Für zkSync geschieht dies, wenn sie den YUL-Bytecode in ihren eigenen benutzerdefinierten zk-Befehlssatz konvertieren. Für Scroll geschieht dies am Ende, wenn die eigentliche Ablaufverfolgung mit tatsächlichen EVM-Opcodes generiert wird.

Für zkSync ist also alles dasselbe wie bei der Interaktion mit der EVM, bis der zk-Bytecode generiert wird. Für Scroll ist alles gleich, bis der eigentliche Bytecode ausgeführt wird. Dies ist ein subtiler Unterschied, der die Leistung zugunsten der Unterstützung eintauscht. Beispielsweise unterstützt zkSync keine EVM-Bytecode-Tools wie einen standardmäßigen Debugger, da es sich um einen völlig anderen Bytecode handelt. Während Scroll größere Schwierigkeiten haben wird, eine gute Leistung aus einem Befehlssatz herauszuholen, wurde dieser nicht für zk entwickelt. Beide Strategien haben Vor- und Nachteile und letztendlich gibt es viele exogene Faktoren, die ihren relativen Erfolg beeinflussen werden.

zkLLVM-Circuit-Compiler

???? Trotz seiner Namensgebung ist LLVM keine VM (virtuelle Maschine). LLVM ist der Name einer Reihe von Compiler-Tools, die durch eine sprachunabhängige Zwischendarstellung (IR) verankert sind.

=null; Stiftung (über den Namen, es ist a Witz über SQL-Injection wenn Sie sich fragen) baut einen Compiler, der jede LLVM-Frontend-Sprache in eine Zwischendarstellung konvertieren kann, die in einem SNARK nachgewiesen werden kann. Die zkLLVM ist als Erweiterung der bestehenden LLVM-Infrastruktur konzipiert, einer Industriestandard-Toolchain, die viele Hochsprachen wie Rust, C, C++ usw. unterstützt.

So funktioniert's

Grobe Skizze der zkLLVM-Architektur

Ein Benutzer, der eine Berechnung beweisen möchte, würde diese Berechnung einfach in C++ implementieren. Die zkLLVM nimmt diesen High-Level-Quellcode, der von ihrem modifizierten Clang-Compiler (derzeit C++) unterstützt wird, und generiert eine Zwischendarstellung der Schaltung. An diesem Punkt ist die Schaltung bereit, geprüft zu werden, aber der Benutzer möchte die Schaltung möglicherweise auf der Grundlage einiger dynamischer Eingaben prüfen. Um dynamische Eingaben zu verarbeiten, verfügt der zkLLVM über eine zusätzliche Komponente, die als Assigner bezeichnet wird, die eine Zuordnungstabelle mit allen Eingaben und Witnesses generiert, die vollständig vorverarbeitet und bereit sind, neben der Schaltung geprüft zu werden.

Diese 2 Komponenten sind alles, was notwendig ist, um einen Beweis zu erzeugen. Ein Benutzer kann theoretisch selbst einen Beweis erstellen, aber da dies eine etwas spezialisierte Rechenaufgabe ist, möchte er vielleicht jemand anderen bezahlen, der über die Hardware verfügt, um dies für ihn zu tun. Für diesen Gegenparteierkennungsmechanismus ist =nil; Foundation hat auch einen „Beweismarkt“ eingerichtet, auf dem Prüfer darum wetteifern, Berechnungen für Benutzer zu beweisen, die sie dafür bezahlen. Diese Dynamik des freien Marktes wird dazu führen, dass Prüfer die wertvollsten Prüfungsaufgaben optimieren.

Kompromisse

Da jede zu beweisende Rechenaufgabe einzigartig ist und einen anderen Schaltkreis erzeugt, gibt es eine unendliche Anzahl von Schaltkreisen, mit denen Beweiser umgehen können müssen. Diese erzwungene Generalisierbarkeit erschwert die Optimierung einzelner Schaltungen. Die Einführung eines Proof-Marktes ermöglicht die Spezialisierung auf Schaltkreise, die der Markt für wertvoll hält. Ohne diesen Markt wäre es aufgrund dieses natürlichen Kaltstartproblems schwierig, einen Prüfer davon zu überzeugen, diese Schaltung zu optimieren.

Der andere Kompromiss ist die klassische Abstraktion vs. Kontrolle. Benutzer, die bereit sind, diese einfach zu verwendende Schnittstelle zu verwenden, geben die Kontrolle über die zugrunde liegenden kryptografischen Primitiven auf. Für viele Benutzer ist dies ein sehr gültiger Kompromiss, da es oft besser ist, diese Entscheidungen von den Kryptografieexperten treffen zu lassen.

Vorteile

  • Benutzer können Code in vertrauten Hochsprachen schreiben
  • Alle zk-Interna werden von den Benutzern abstrahiert
  • Verlässt sich nicht auf eine bestimmte „VM“-Schaltung, die zusätzlichen Overhead hinzufügt

Nachteile

  • Jedes Programm hat eine andere Schaltung. Schwierig zu optimieren. (Beweismarkt löst dies teilweise)
  • Nicht trivial zum Austauschen/Upgrade interner zk-Bibliotheken (Forking erforderlich)

Eine zkVM beschreibt die Obermenge aller zk-virtuellen Maschinen, während eine zkEVM eine bestimmte Art von zkVM ist, die es wert war, aufgrund ihrer heutigen Verbreitung als separates Thema diskutiert zu werden. Neben den maßgeschneiderten Krypto-VMs gibt es einige andere Projekte, die daran arbeiten, allgemeinere zkVMs zu erstellen, die auf ISAs basieren.

Anstatt die EVM zu beweisen, könnte das System eine andere Befehlssatzarchitektur (ISA) wie RISC-V oder WASM in einer neuen VM beweisen. Zwei Projekte, die an diesen generalisierten zkVMs arbeiten, sind RISC Zero und zkWASM. Lassen Sie uns hier ein wenig in RISC Zero eintauchen, um zu demonstrieren, wie diese Strategie funktioniert und einige ihrer Vor- und Nachteile. 

Risc Zero Proof Generation High-Level-Architektur

RISC Zero ist in der Lage, jede Berechnung zu beweisen, die auf einer RISC-V-Architektur ausgeführt wird. RISC-V ist ein Open-Source-ISA-Standard (Instruction Set Architecture), der immer beliebter wird. Die RISC-Philosophie (Reduced Instruction Set Computer) besteht darin, einen extrem einfachen Befehlssatz mit minimaler Komplexität zu erstellen. Das bedeutet, dass die Entwickler auf den höheren Schichten im Stack am Ende eine größere Last bei der Implementierung von Anweisungen mit dieser Architektur übernehmen, während die Hardwareimplementierung einfacher wird.

Diese Philosophie gilt auch für die allgemeine Datenverarbeitung, ARM-Chips nutzen RISC-artige Befehlssätze und haben begonnen, den Markt für mobile Chips zu dominieren. Es stellt sich heraus, dass die einfacheren Befehlssätze auch eine größere Energie- und Chipflächeneffizienz aufweisen.

Diese Analogie gilt ziemlich gut für die Effizienz der Erzeugung von zk-Beweisen. Wie bereits erwähnt, zahlen Sie beim Beweisen eines Ausführungs-Trace in zk für die Summe der Kosten aller Anweisungen für jedes Element im Trace, sodass einfachere und insgesamt weniger Anweisungen besser sind.

So funktioniert's

Aus der Perspektive eines Entwicklers ähnelt die Verwendung von RISC Zero zur Verarbeitung von zk-Proofs der Verwendung von AWS Lambda-Funktionen zur Verarbeitung der Backend-Serverarchitektur. Entwickler interagieren mit RISC Zero oder AWS Lambda, indem sie einfach Code schreiben, und der Service übernimmt die gesamte Backend-Komplexität.

Für RISC Zero schreiben Entwickler Rust oder C++ (eventuell alles, was auf RISC-V abzielt). Das System nimmt dann die während der Kompilierung erzeugte ELF-Datei und verwendet diese als Eingabecode für die VM-Schaltung. Entwickler rufen einfach proof auf, was ein Quittungsobjekt zurückgibt (das den zk-Beweis der Ausführungsverfolgung enthält), das jeder von überall aus „verify“ aufrufen kann. Aus Sicht des Entwicklers muss man nicht verstehen, wie zk funktioniert, das zugrunde liegende System bewältigt all diese Komplexität.

Risc-Zero-Praktikant?

Vorteile

  • Einfach zu verwenden. Öffnet jedem Programmierer die Tür zum Erstellen von zk-Anwendungen
  • Einzelne Schaltung, auf die sich Prüfer spezialisieren können
    • Auch weniger Angriffsfläche und weniger zu prüfen
  • Kompatibel mit jeder Blockchain, posten Sie einfach die Beweise

Nachteile

  • Nimmt viel Overhead (in Proof-Größe und Generierungsgeschwindigkeit) auf sich, um eine solche generische Schnittstelle zu unterstützen
  • Erfordert eine deutliche Verbesserung der Techniken zur Proof-Generierung, um eine breite Unterstützung für bestehende Bibliotheken zu erreichen

Vorgefertigte wiederverwendbare Schaltungen

Für einige grundlegende und wiederverwendbare Schaltungen, die für Blockchain-Anwendungen oder anderswo besonders nützlich sind, haben Teams diese Schaltungen möglicherweise bereits für Sie erstellt und optimiert. Sie können einfach die Eingabe für Ihren speziellen Anwendungsfall bereitstellen. Ein Merkle-Einschlussnachweis wird beispielsweise häufig in Kryptoanwendungen benötigt (Airdrop-Listen, Tornado Cash usw.). Als Anwendungsentwickler können Sie diese kampferprobten Verträge jederzeit wiederverwenden und einfach die darüber liegenden Schichten ändern, um eine einzigartige Anwendung zu erstellen.

Zum Beispiel können die Schaltkreise von Tornado Cash wiederverwendet werden für a private Airdrop-Anwendung oder eine private Abstimmungsanwendung. Manta und Semaphore bauen ein ganzes Toolkit mit gängigen Schaltungsgeräten wie diesem, die in Solidity-Verträgen mit wenig oder gar keinem Verständnis der zugrunde liegenden ZK-Mond-Mathematik verwendet werden können.

Der Leitfaden – Wählen Sie Ihren Stack

Wie ausführlich besprochen, gibt es unzählige verschiedene Optionen für die Entwicklung einer zk-Anwendung, die alle ihre eigenen einzigartigen Kompromisse haben. Dieses Diagramm hilft dabei, diese Entscheidungsmatrix zusammenzufassen, sodass Sie basierend auf Ihrem zk-Fachwissen und Ihren Leistungsanforderungen das beste Tool für den Job auswählen können. Dies ist keine umfassende Liste, ich plane, sie in Zukunft zu ergänzen, wenn mir bewusst wird, dass weitere Tools in diesem Bereich auftauchen.

Der Leitfaden für Anwendungsentwickler zu zkGalaxy

zk App Dev Cheatsheet

1. Snark-Bibliotheken auf niedriger Ebene

Wann zu verwenden: 

  • Sie benötigen eine genaue Kontrolle über den gesamten Prover-Stack
  • Sie möchten vermeiden, dass gemeinsame Komponenten neu erstellt werden
  • Sie möchten mit verschiedenen Kombinationen experimentieren von Prüfungsschemata, Kurven und anderen Low-Level Primitive

Wann nicht zu verwenden:

  • Sie sind ein Neuling, der nach High-Level-Proving-Schnittstellen sucht

Zubehör: 


3. zk-Compiler

Wann zu verwenden: 

  • Nicht bereit, den Aufwand einer universellen Schaltung zu übernehmen
  • Schaltkreise in vertrauten Sprachen schreiben möchten 
  • Benötigen Sie eine hochgradig angepasste Schaltung

Wann nicht zu verwenden: 

  • Sie möchten die zugrunde liegenden kryptografischen Primitive steuern
  • Benötigen Sie eine Schaltung, die bereits stark optimiert wurde

Zubehör:


5. zkVM

Wann zu verwenden: 

  • Sie möchten Code in Hochsprache schreiben 
  • Muss die Korrektheit dieser Ausführung beweisen 
  • Einige der Eingaben für diese Ausführung müssen vor einem Verifizierer verborgen werden
  • Haben Sie wenig bis gar keine Erfahrung in zk

Wann nicht zu verwenden:

  • In Umgebungen mit extrem niedriger Latenz (es ist immer noch langsam)
  • Du hast (vorerst) ein riesiges Programm

Zubehör:

2. zk-DSLs

Wann zu verwenden: 

  • Sie fühlen sich wohl beim Aufnehmen einer neuen Sprache
  • Einige kampferprobte Sprachen verwenden möchten
  • Benötigen eine minimale Schaltungsgröße und sind bereit, auf Abstraktionen zu verzichten

Wann nicht zu verwenden: 

  • Benötigen Sie eine genaue Kontrolle über das Proving-Back-End (vorerst könnten Back-Ends für einige DSLs ausgetauscht werden)

Zubehör:


4. zkEVM

Wann zu verwenden: 

  • Sie haben eine dApp, die bereits auf der EVM funktioniert
  • Sie brauchen günstigere Transaktionen für Ihre Benutzer 
  • Sie möchten den Aufwand für die Bereitstellung in einer neuen Kette minimieren
  • Kümmern Sie sich nur um die Prägnanz-Eigenschaft von zk (Komprimierung)

Wann nicht zu verwenden: 

  • Sie benötigen eine perfekte EVM-Äquivalenz
  • Sie benötigen die Datenschutzeigenschaft von zk 
  • Sie haben einen Nicht-Blockchain-Anwendungsfall 

Zubehör: 


6. Vorgefertigte wiederverwendbare Schaltungen

Wann zu verwenden: 

  • Sie haben eine intelligente Vertragsanwendung, die auf gängigen zk-Bausteinen wie der Merkle-Inklusion basiert
  • Sie haben wenig bis gar kein Fachwissen in den zugrunde liegenden zk-Sachen

Wann nicht verwenden:

  • Sie haben hochspezialisierte Bedürfnisse
  • Ihr Anwendungsfall wird von den vorgefertigten Schaltungen nicht unterstützt 

Zubehör: 

Zusammenfassung

zk ist führend in mehreren Technologien, und der Aufbau erfordert ein tiefgreifendes Verständnis von Mathematik, Kryptografie, Informatik und Hardwaretechnik. Da jedoch jeden Tag mehr und mehr Abstraktionsschichten verfügbar sind, können App-Entwickler die Leistungsfähigkeit von zk ohne einen Doktortitel nutzen. Da die Einschränkungen der Prüfzeiten im Laufe der Zeit durch Optimierungen auf allen Ebenen des Stacks langsam aufgehoben werden, werden wir wahrscheinlich noch einfachere Tools für den durchschnittlichen Entwickler sehen.

Ich hoffe, ich habe Sie, den neugierigen Softwareentwickler, davon überzeugt, dass Sie heute damit beginnen können, zk in Ihren Anwendungen zu verwenden. Viel Spaß beim Hacken 🙂

Worauf warten Sie noch, bauen Sie ein paar zk-Apps

Offenlegungen: Blockchain Capital ist ein Investor in mehreren der oben genannten Protokolle.

Die in jedem Blogbeitrag geäußerten Ansichten können die persönlichen Ansichten des jeweiligen Autors sein und spiegeln nicht unbedingt die Ansichten von Blockchain Capital und seinen verbundenen Unternehmen wider. Weder Blockchain Capital noch der Autor garantieren die Genauigkeit, Angemessenheit oder Vollständigkeit der Informationen, die in jedem Blogbeitrag bereitgestellt werden. Es wird keine Zusicherung oder Gewährleistung, weder ausdrücklich noch stillschweigend, von oder im Namen von Blockchain Capital, dem Autor oder einer anderen Person hinsichtlich der Genauigkeit und Vollständigkeit oder Fairness der in einem Blogbeitrag enthaltenen Informationen gegeben, und es wird keine Verantwortung oder Haftung übernommen für solche Informationen. Nichts, was in den einzelnen Blog-Beiträgen enthalten ist, stellt eine Anlage-, Regulierungs-, Rechts-, Compliance- oder Steuer- oder sonstige Beratung dar, noch darf man sich darauf verlassen, um eine Anlageentscheidung zu treffen. Blog-Beiträge sollten nicht als aktuelle oder frühere Empfehlungen oder Aufforderungen zur Abgabe eines Angebots zum Kauf oder Verkauf von Wertpapieren oder zur Annahme einer Anlagestrategie angesehen werden. Die Blogbeiträge können Prognosen oder andere zukunftsgerichtete Aussagen enthalten, die auf Überzeugungen, Annahmen und Erwartungen beruhen, die sich aufgrund vieler möglicher Ereignisse oder Faktoren ändern können. Wenn eine Änderung eintritt, können die tatsächlichen Ergebnisse erheblich von den in den zukunftsgerichteten Aussagen zum Ausdruck gebrachten Ergebnissen abweichen. Alle zukunftsgerichteten Aussagen beziehen sich nur auf das Datum, an dem solche Aussagen gemacht wurden, und weder Blockchain Capital noch jeder Autor übernimmt die Pflicht, solche Aussagen zu aktualisieren, es sei denn, dies ist gesetzlich vorgeschrieben. Soweit Dokumente, Präsentationen oder andere Materialien, die von Blockchain Capital produziert, veröffentlicht oder anderweitig vertrieben werden, in einem Blogbeitrag referenziert werden, sollten diese Materialien unter besonderer Berücksichtigung der darin enthaltenen Haftungsausschlüsse gelesen werden.

Zeitstempel:

Mehr von Blockchain Capital