1. Konzeptvorstellung

In Bezug auf das Konzept des Co-Prozessors ist ein sehr einfaches und leicht verständliches Beispiel die Beziehung zwischen einem Computer und einer Grafikkarte. Die CPU kann die meisten Aufgaben erledigen, aber sobald eine spezifische Aufgabe auftritt, benötigt die Grafikkarte Hilfe, da die CPU über unzureichende Rechenleistung verfügt, wie z.B. maschinelles Lernen, Grafikrendering oder das Ausführen von Spielen im großen Maßstab. Wenn wir keine Frames fallen lassen oder einfrieren möchten, wenn wir Spiele im großen Maßstab spielen, benötigen wir auf jeden Fall eine Grafikkarte mit guter Leistung. In diesem Szenario ist die CPU der Prozessor und die Grafikkarte der Co-Prozessor. Übertragen auf die Blockchain ist der Smart Contract die CPU und der ZK-Coprozessor die GPU.

Der Schlüsselpunkt besteht darin, spezifische Aufgaben spezifischen Co-Prozessoren zu übergeben. Genau wie in einer Fabrik kennt der Chef die Schritte jedes Gliedes und kann es selbst machen oder den Mitarbeitern den gesamten Produktionsprozess beibringen, aber das ist sehr ineffizient und nur Er kann nur ein Stück auf einmal produzieren, und erst nachdem eins fertig ist, kann er das nächste produzieren, also hat er viele spezifische Mitarbeiter eingestellt. Sie führen jeweils ihre Aufgaben aus und erledigen die Arbeit, die sie in der Produktionskette in ihren eigenen Werkstätten gut können. Die Glieder in der Kette können miteinander interagieren. Kommunizieren und koordinieren, aber sich nicht in die Arbeit des anderen einmischen. Sie tun nur das, was sie am besten können. Diejenigen mit schnellen Händen und starker körperlicher Kraft können Schrauben drehen. Diejenigen, die wissen, wie man Maschinen bedient, können die Maschinen bedienen. Diejenigen, die Buchhaltung kennen, können Produktionsvolumen und -kosten berechnen. Asynchrone Zusammenarbeit zur Maximierung der Arbeitsleistung.

Während der Industriellen Revolution hatten Kapitalisten bereits entdeckt, dass dieses Modell die maximale Produktionskapazität in ihren Fabriken bringen könnte. Wenn jedoch ein Schritt im Produktionsprozess aufgrund von Technologie oder anderen Gründen auf Hindernisse stößt, müssen möglicherweise andere Faktoren ausgelagert werden. Spezialisierte Hersteller übernehmen das. Zum Beispiel könnten für ein Unternehmen, das Mobiltelefone herstellt, die Chips von anderen spezialisierten Chip-Unternehmen hergestellt werden. Das Mobiltelefonunternehmen ist der Hauptprozessor und das Chip-Unternehmen ist der Coprozessor. Coprozessoren können spezifische Aufgaben leicht und asynchron verarbeiten, die für den Hauptprozessor allein zu anspruchsvoll und umständlich sind.

Der ZK-Koprozessor ist im weitesten Sinne relativ breit gefasst. Einige Projekte nennen es ihren eigenen Koprozessor, und einige nennen es ZKVM, haben jedoch alle die gleiche Idee: Smart-Vertragsentwicklern das Möglichkeit zu geben, off-Chain-Berechnungen zu bestätigen, ohne dabei den Status zu verändern. Vereinfacht ausgedrückt, werden einige On-Chain-Berechnungen außerhalb der Kette durchgeführt, um Kosten zu senken und die Effizienz zu steigern. Gleichzeitig wird ZK verwendet, um die Zuverlässigkeit der Berechnungen sicherzustellen und die Privatsphäre spezifischer Daten zu schützen. In der datengetriebenen Welt der Blockchain ist dies besonders wichtig.

2. Warum brauchen wir einen ZK-Koprozessor?

Eines der größten Engpässe, mit denen Smart-Vertragsentwickler konfrontiert sind, bleiben die hohen Kosten, die mit der On-Chain-Berechnung verbunden sind. Da für jede Operation Gas gemessen werden muss, wird der Kosten für komplexe Anwendungslogik schnell zu hoch, um ausgeführt zu werden, denn obwohl die Archivknoten in der DA-Schicht der Blockchain tatsächlich historische Daten speichern können, deshalb können Dinge wie Dune Off-Chain-Analyseanwendungen wie Analytics, Nansen, 0xscope und Etherscan so viele Daten aus der Blockchain haben und lange zurückgehen können, aber es ist nicht einfach für Smart Contracts, auf all diese Daten zuzugreifen. Sie können nur leicht auf Daten zugreifen, die im Zustand der virtuellen Maschine, den neuesten Blockdaten und anderen öffentlichen Smart-Vertragsdaten gespeichert sind. Für weitere Daten müssen Smart Contracts möglicherweise viele Anstrengungen unternehmen, um darauf zuzugreifen:

Smart Contracts in der Ethereum Virtual Machine (EVM) haben Zugriff auf die Block-Header-Hashes der letzten 256 Blöcke. Diese Block-Header enthalten alle Aktivitätsinformationen in der Blockchain bis zum aktuellen Block und werden mithilfe des Merkle-Baums und des Keccak-Hashing-Algorithmus in einen 32-Byte-Hashwert komprimiert.

Obwohl die Daten hash-verpackt sind, können sie dekomprimiert werden – es ist einfach nicht einfach. Beispielsweise, wenn Sie den aktuellen Block-Header nutzen möchten, um vertrauenswürdig auf spezifische Daten im vorherigen Block zuzugreifen, erfordert dies eine komplexe Abfolge von Schritten. Zuerst müssen Sie die Off-Chain-Daten vom Archivknoten erhalten und dann einen Merkle-Baum und einen Gültigkeitsnachweis des Blocks erstellen, um die Echtheit der Daten auf der Blockchain zu überprüfen. Anschließend wird die EVM diese Gültigkeitsnachweise verarbeiten, überprüfen und erklären. Dieser Vorgang ist nicht nur umständlich, sondern dauert auch lange, und das Gas ist ebenfalls besonders teuer.

Der grundlegende Grund für diese Herausforderung besteht darin, dass Blockchain-Virtual-Maschinen (wie z.B. EVM) nicht für die Verarbeitung großer Datenmengen und intensiver Rechenaufgaben, wie die oben genannte Dekomprimierungsarbeit, geeignet sind. Der Designfokus von EVM liegt darauf, Smart-Vertragscode auszuführen, während Sicherheit und Dezentralisierung gewährleistet werden, anstatt große Datenmengen zu verarbeiten oder komplexe Rechenaufgaben durchzuführen. Daher ist es oft notwendig, andere Lösungen zu finden, wie z.B. die Nutzung von Off-Chain-Computing oder anderen Skalierungstechnologien, wenn es um Aufgaben geht, die große Mengen an Rechenressourcen erfordern. In diesem Fall tritt der ZK-Coprozessor auf.

ZK-Rollups sind tatsächlich die frühesten ZK-Coprozessoren, die denselben Typ von Berechnungen unterstützen, die auf L1 in größerem Maßstab und in größerer Menge verwendet werden. Dieser Prozessor befindet sich auf Protokollebene, und der ZK-Coprozessor, über den wir jetzt sprechen, befindet sich auf der DApp-Ebene. Der ZK-Coprozessor verbessert die Skalierbarkeit von Smart Contracts, indem er Smart Contracts ermöglicht, historische On-Chain-Datenzugriffe und Berechnungen unter Verwendung von ZK-Beweisen ohne Vertrauen zu delegieren. Anstatt alle Operationen im EVM durchzuführen, können Entwickler teure Operationen an den ZK-Coprozessor auslagern und einfach die Ergebnisse On-Chain verwenden. Dies bietet Smart Contracts eine neue Möglichkeit zur Skalierung, indem Datenzugriff und Berechnungen von der Blockchain-Konsens abgekoppelt werden.

Der ZK-Coprozessor führt ein neues Designmuster für On-Chain-Anwendungen ein, das die Einschränkung beseitigt, dass Berechnungen in der Blockchain-Virtualmaschine abgeschlossen werden müssen. Dies ermöglicht es Anwendungen, auf mehr Daten zuzugreifen und in einem größeren Maßstab zu arbeiten als zuvor, während die Gasgebühren kontrolliert werden, die Skalierbarkeit und Effizienz von Smart Contracts erhöht werden, ohne die Dezentralisierung und Sicherheit zu beeinträchtigen.

3. Technische Umsetzung

Dieser Teil wird die Axiom-Architektur verwenden, um zu erklären, wie der zk-Coprozessor das Problem technisch löst. Tatsächlich gibt es zwei Kerne: Datenerfassung und Berechnung. In diesen beiden Prozessen gewährleistet ZK gleichzeitig Effizienz und Privatsphäre.

3.1 Datenerfassung

Eines der wichtigsten Aspekte bei der Durchführung von Berechnungen auf dem ZK-Coprozessor besteht darin, sicherzustellen, dass alle Eingabedaten ordnungsgemäß aus der Blockchain-Historie abgerufen werden. Wie bereits erwähnt, ist dies tatsächlich ziemlich schwierig, da Smart Contracts nur auf den aktuellen Blockchain-Zustand in ihrem Code zugreifen können, und auch dieser Zugriff ist der teuerste Teil der On-Chain-Berechnung. Das bedeutet, dass historische On-Chain-Daten wie Transaktionsaufzeichnungen oder frühere Kontostände (interessante On-Chain-Eingaben in Berechnungen) von Smart Contracts nicht nativ verwendet werden können, um die Ergebnisse des Co-Prozessors zu überprüfen.

Der ZK-Coprozessor löst dieses Problem auf drei verschiedene Arten, die Kosten, Sicherheit und Entwicklungsaufwand ausgleichen:

1. Speichern Sie zusätzliche Daten im Blockchain-Status und verwenden Sie das EVM, um alle Daten zu speichern, die On-Chain vom Leseüberprüfungs-Co-Prozessor verwendet werden. Dieser Ansatz ist ziemlich teuer und kostensenkend für große Datenmengen.
2. Vertrauen Sie einem Orakel oder einem Netzwerk von Unterzeichnern, um Eingabedaten an den Coprozessor zu überprüfen. Dies erfordert, dass die Benutzer des Coprozessors dem Orakel oder dem Anbieter der Mehrfachsignatur vertrauen, was die Sicherheit verringert.
3. Verwenden Sie ZK-Beweise, um zu überprüfen, ob die in den Co-Prozessor eingebundenen On-Chain-Daten in der Blockchain-Geschichte verpflichtet worden sind. Jeder Block in der Blockchain verpflichtet alle vergangenen Blöcke und damit alle historischen Daten, und bietet kryptografische Garantien für die Datenvalidität und erfordert keine zusätzlichen Vertrauensannahmen des Benutzers.

3.2 Berechnung

Die Durchführung von Off-Chain-Berechnungen in einem ZK-Koprozessor erfordert die Umwandlung traditioneller Computerprogramme in ZK-Schaltkreise. Derzeit haben alle Methoden zur Erreichung dieses Ziels einen enormen Einfluss auf die Leistung, wobei sich ZK-Beweise im Vergleich zur nativen Programmausführung um einen Overhead von 10.000 bis 1.000.000 bewegen. Andererseits unterscheidet sich das Rechenmodell von ZK-Schaltkreisen von herkömmlichen Computerarchitekturen (z. B. müssen derzeit alle Variablen modulo einer großen kryptografischen Primzahl codiert werden, und die Implementierung kann nicht deterministisch sein), was bedeutet, dass Entwickler Schwierigkeiten haben, sie direkt zu schreiben.

Daher sind die drei Hauptansätze zur Spezifizierung von Berechnungen in ZK-Coprozessoren hauptsächlich Kompromisse zwischen Leistung, Flexibilität und Entwicklungsfreundlichkeit:

1. Benutzerdefinierte Schaltkreise: Entwickler schreiben ihre eigenen Schaltkreise für jede Anwendung. Dieser Ansatz hat das größte Leistungspotenzial, erfordert jedoch erhebliche Entwickleranstrengungen.
2. eDSL/DSL für Schaltungen: Entwickler schreiben Schaltungen für jede Anwendung, abstrahieren jedoch ZK-spezifische Probleme in einem meinungsstarken Rahmen (ähnlich der Verwendung von PyTorch für neuronale Netzwerke). Die Leistung ist jedoch leicht niedriger.
3. zkVM-Entwickler schreiben Schaltungen in bestehenden virtuellen Maschinen und überprüfen deren Ausführung in ZK. Dies bietet Entwicklern das einfachste Erlebnis bei der Verwendung vorhandener VMs, führt jedoch aufgrund der unterschiedlichen Berechnungsmodelle zwischen VMs und ZK zu einer geringeren Leistung und Flexibilität.

4. Anwendung

ZK-Coprozessor hat eine breite Palette von Anwendungen. Der ZK-Coprozessor kann theoretisch alle Anwendungsszenarien abdecken, die Dapp abdecken kann. Solange es sich um eine Aufgabe im Zusammenhang mit Daten und Berechnungen handelt, kann der ZK-Coprozessor die Kosten senken, die Effizienz steigern und die Privatsphäre schützen. Im Folgenden wird aus verschiedenen Blickwinkeln gestartet und erforscht, was der ZK-Prozessor auf der Anwendungsebene tun kann.

4.1 Defi

4.1.1 DEX

Nehmen Sie den Haken in Uniswap V4 als Beispiel:

Hook ermöglicht es Entwicklern, spezifische Operationen an jedem Schlüsselpunkt im gesamten Lebenszyklus des Liquiditätspools durchzuführen - wie z. B. vor oder nach dem Handel mit Tokens, vor oder nach LP-Positionsänderungen, benutzerdefinierten Liquiditätspools, Börsen, Gebühren. Wie man mit LP-Positionen interagiert, zum Beispiel:

• Time Weighted Average Market Maker (TWAMM);
• dynamische Gebühren basierend auf Volatilität oder anderen Eingaben;
• Chain Preislimitorder;
• Einlagen außerhalb des Anwendungsbereichs in Kreditprotokolle einzahlen;
• Individuelle On-Chain-Orakel, wie zum Beispiel geometrische Mittel-Orakel;
• Automatisch LP-Gebühren in LP-Positionen reinvestieren;
• Uniswap's MEV-Gewinne werden an LP verteilt;
• Treuerabattprogramm für LPs oder Trader;

Einfach ausgedrückt handelt es sich um einen Mechanismus, der es Entwicklern ermöglicht, historische Daten auf jeder Chain zu erfassen und sie zu verwenden, um den Pool in Uniswap nach ihren eigenen Vorstellungen anzupassen. Das Aufkommen von Hook bringt mehr Composability und höhere Effizienz für Transaktionen in der Chain. Kapitaleffizienz. Sobald die Codelogik, die diese definiert, jedoch kompliziert wird, wird dies eine enorme Belastung für Benutzer und Entwickler mit sich bringen. Dann ist zkcoprocessor in dieser Zeit praktisch, was dazu beitragen kann, diese Gaskosten zu sparen und die Effizienz zu verbessern.

Aus einer langfristigen Perspektive wird der ZK-Coprozessor die Integration von DEX und CEX beschleunigen. Seit 2022 haben wir gesehen, dass DEX und CEX funktional konsistent geworden sind. Alle großen CEXs akzeptieren diese Realität und übernehmen Web3-Wallets, bauen EVM L2 und übernehmen bestehende Infrastruktur wie das Lightning-Netzwerk oder Open Source, um die On-Chain-Liquiditätsfreigabe zu umarmen. Dieses Phänomen ist untrennbar von der Steigerung des ZK-Coprozessors. Alle Funktionen, die CEX erreichen kann, ob es sich um Grid-Trading, Follow-up, schnelle Kreditaufnahme oder die Verwendung von Benutzerdaten handelt, können auch durch den ZK-Coprozessor von DEX implementiert werden. Und die Komponierbarkeit und Freiheit von Defi sowie die Transaktionen kleiner Währungen auf der Kette sind schwer mit traditionellen CEX zu erreichen. Gleichzeitig kann die ZK-Technologie auch die Privatsphäre der Benutzer während der Ausführung schützen.

4.1.2 Airdrop

Wenn einige Projekte Lufttropfen durchführen möchten, benötigen sie einen Smart Contract, um die historischen Aktivitäten der Adresse abzufragen, möchten jedoch die Adressinformationen des Benutzers nicht offenlegen und ohne zusätzlichen Vertrauensnachweis ausführen. Zum Beispiel möchte ein Defi-Verleihprojekt durch die Interaktion zwischen der Adresse und einer Reihe von Verleihprotokollen wie Aave, Compound, Fraxlend und Spark als Standard für Lufttropfen die historische Datenerfassung und die Datenschutzfunktionen des ZK-Koprozessors leicht lösen.

4.2 ZKML

Ein weiterer aufregender Punkt des ZK-Coprozessors liegt im Bereich des maschinellen Lernens. Da Smart Contracts über Off-Chain-Rechenfähigkeiten verfügen können, wird hoch effizientes maschinelles Lernen in der Chain möglich. Tatsächlich ist der ZK-Coprozessor auch ein unverzichtbarer Bestandteil für die Eingabe und Berechnung von ZKML-Daten. Er kann die für das maschinelle Lernen erforderlichen Eingaben aus den On-Chain/Off-Chain-Historiendaten extrahieren, die im Smart Contract importiert wurden, und dann die Berechnung in einen ZK-Schaltkreis schreiben und auf die Chain werfen.

4.3 KYC

KYC ist ein großes Geschäft, und die Web3-Welt nimmt allmählich die Einhaltung an. Mit dem ZK-Coprozessor ist es möglich, einen intelligenten Vertragsnachweis zu erbringen, indem beliebige Off-Chain-Daten bereitgestellt werden, ohne dass dabei unnötige Informationen der Benutzer preisgegeben werden. Tatsächlich werden einige Projekte implementiert, wie z.B. Uniswaps KYC-Hook, der den ZK-Coprozessor Pado verwendet, um Off-Chain-Daten ohne Vertrauen zu erfassen. Nachweis von Vermögenswerten, Nachweis von akademischen Qualifikationen, Nachweis von Reisen, Nachweis des Fahrens, Nachweis der Strafverfolgung, Nachweis von Spielern, Nachweis von Transaktionen... Alle historischen Verhaltensweisen auf und abseits der Kette können sogar zu einer vollständigen Identität zusammengefasst und mit hoher Glaubwürdigkeit verfasst werden. ZK beweist, dass es auf der Kette ist und gleichzeitig die Privatsphäre der Benutzer schützt.

4.4 Sozial

Das spekulative Attribut von Friend.tech ist tatsächlich stärker als das soziale Attribut. Der Kern liegt in seiner Bonding-Kurve. Ist es möglich, einen Haken an die Bonding-Kurve von Friend.tech anzufügen, damit Benutzer die Richtung der Bonding-Kurve anpassen können, z. B. die Implementierung Nachdem der Hype um den Handel mit Schlüsseln endet und Spekulanten gehen, wird die Bonding-Kurve geglättet, die Einstiegshürde für echte Fans gesenkt und echter privater Domain-Verkehr wird wachsen. Oder lassen Sie den Smart Contract den On-Chain/Off-Chain-Sozialgraphen des Benutzers erhalten und in der Lage sein, Ihren Freunden auf verschiedenen Social Dapps mit einem Klick zu folgen. Oder Sie können einen privaten Club auf der Chain gründen, wie den Degen Club, und nur Adressen, die die historischen Gasverbrauchsbedingungen erfüllen, können eintreten, usw.

4.5 Gaming

In traditionellen Web2-Spielen ist Benutzerdaten ein sehr wichtiger Parameter. Kaufverhalten, Spielstil und Beitrag können das Spiel besser betreiben und eine bessere Benutzererfahrung bieten, wie z.B. der ELO-Matchmaking-Mechanismus in MOBA-Spielen. Die Häufigkeit des Kaufs von Skins usw., aber diese Daten sind schwer zu erfassen von Smart Contracts auf der Blockchain, daher können sie nur durch zentralisierte Lösungen ersetzt oder einfach aufgegeben werden. Die Entwicklung des ZK-Coprozessors macht jedoch dezentrale Lösungen möglich.

5. Projekt Party

Es gibt bereits einige herausragende Spieler auf dieser Strecke. Die Ideen sind tatsächlich ähnlich. Sie generieren ZK-Beweise durch Speicherbeweis oder Konsens und werfen sie dann auf die Kette. Jeder hat jedoch seine eigenen Vorteile in technischen Merkmalen und implementierten Funktionen.

5.1 Axiom

Axiom, der Marktführer bei ZK (Zero-Knowledge) Coprozessoren, konzentriert sich darauf, dass Smart Contracts in der Lage sind, auf die gesamte Ethereum-Historie und alle ZK-Verifizierungsberechnungen ohne Vertrauen zuzugreifen. Entwickler können On-Chain-Anfragen an Axiom stellen, die diese dann über ZK-Verifizierung verarbeiten und die Ergebnisse vertrauenslos an den Smart Contract des Entwicklers zurückgeben. Dies ermöglicht es Entwicklern, reichhaltigere On-Chain-Anwendungen zu erstellen, ohne auf zusätzliche Vertrauensannahmen angewiesen zu sein.

Um diese Abfragen umzusetzen, führt Axiom die folgenden drei Schritte aus:

1. Axiom verwendet ZK-Beweise, um vertrauenswürdig Daten aus Block-Headern, Status, Transaktionen und Quittungen historischer Ethereum-Blöcke zu lesen. Da alle Ethereum-On-Chain-Daten in diesen Formaten codiert sind, kann Axiom auf alles zugreifen, was Archivknoten zugreifen können. Axiom überprüft alle Eingabedaten des ZK-Coprozessors über ZK-Beweise von Merkle-Patricia-Tripeln und Block-Header-Hash-Ketten. Obwohl dieser Ansatz schwieriger zu entwickeln ist, bietet er die beste Sicherheit und Kosten für Endbenutzer, da er sicherstellt, dass alle von Axiom zurückgegebenen Ergebnisse kryptografisch äquivalent zu den On-Chain-Berechnungen sind, die im EVM durchgeführt wurden.
2. berechnen: Nachdem die Daten eingelesen wurden, wendet Axiom bewährte Berechnungen darauf an. Entwickler können ihre Berechnungslogik im JavaScript-Front-End spezifizieren, und die Gültigkeit jeder Berechnung wird im ZK-Beweis überprüft. Entwickler können AxiomREPL besuchen oder die Dokumentation einsehen, um mehr über die verfügbaren Rechenprimitiven zu erfahren. Axiom ermöglicht es Benutzern, auf On-Chain-Daten zuzugreifen und ihre eigenen Berechnungen über eDSL zu spezifizieren. Es ermöglicht Benutzern auch, ihre eigenen Schaltungen mithilfe der ZK-Schaltungs-Bibliothek zu schreiben.
3. verify: Axiom bietet ZK-Gültigkeitsnachweise für jedes Abfrageergebnis. Diese Nachweise gewährleisten, dass (1) die Eingabedaten korrekt aus der Kette extrahiert wurden und (2) die Berechnungen korrekt angewendet wurden. Diese ZK-Nachweise werden in den Axiom-Smart Contracts On-Chain verifiziert, um sicherzustellen, dass die endgültigen Ergebnisse zuverlässig in den Smart Contracts der Benutzer verwendet werden.

Da die Ergebnisse über ZK-Beweise verifiziert werden, sind die Ergebnisse von Axiom kryptografisch genauso sicher wie die Ergebnisse von Ethereum. Dieser Ansatz macht keine Annahmen über Kryptowirtschaft, Anreize oder Spieltheorie. Axiom glaubt, dass dieser Ansatz das höchstmögliche Maß an Sicherheit für Smart Contract-Anwendungen bietet. Das Axiom-Team arbeitete eng mit der Uniswap-Stiftung zusammen und erhielt Uniswap-Stipendien. Es wird ein vertrauenswürdiges Orakel auf Uniswap aufbauen.

5.2 Nullrisiko

Bonsai: Im Jahr 2023 veröffentlichte RISC Zero Bonsai, einen Nachweis-Service, der es On-Chain- und Off-Chain-Anwendungen ermöglicht, zkVM-Nachweise anzufordern und zu erhalten. Bonsai ist ein universeller Zero-Knowledge-Proof-Service, der es jeder Kette, jedem Protokoll und jeder Anwendung ermöglicht, ZK-Nachweise zu nutzen. Es ist hoch parallelisierbar, programmierbar und leistungsstark.

Bonsai ermöglicht es Ihnen, Zero-Knowledge-Beweise direkt in jeden Smart Contract zu integrieren, ohne dass kundenspezifische Schaltungen erforderlich sind. Dies ermöglicht es ZK, direkt in dezentrale Anwendungen auf jeder EVM-Kette zu integrieren, mit dem Potenzial, jedes andere Ökosystem zu unterstützen.

zkVM ist die Grundlage von Bonsai und unterstützt eine breite Sprachkompatibilität, unterstützt nachweisbaren Rust-Code und potenziell nullwissende nachweisbare Codes in jeder Sprache, die nach RISC-V kompiliert wurde (wie z. B. C++, Rust, Go, usw.). Durch rekursive Beweise, benutzerdefinierte Schaltkreiscompiler, Zustandsfortsetzung und kontinuierliche Verbesserungen von Beweisalgorithmen ermöglicht Bonsai jedem die Erstellung von leistungsstarken ZK-Beweisen für eine Vielzahl von Anwendungen.

RISC Zero zkVM: RISC Zero zkVM, erstmals im April 2022 veröffentlicht, kann die korrekte Ausführung beliebigen Codes nachweisen und ermöglicht es Entwicklern, ZK-Anwendungen in etablierten Sprachen wie Rust und C++ zu erstellen. Dieser Release ist ein bedeutender Durchbruch in der ZK-Softwareentwicklung: zkVM ermöglicht es, ZK-Anwendungen zu erstellen, ohne Schaltungen zu bauen und benutzerdefinierte Sprachen zu verwenden.

Indem Entwicklern die Verwendung von Rust ermöglicht wird und sie die Reife des Rust-Ökosystems nutzen können, ermöglicht zkVM Entwicklern, schnell sinnvolle ZK-Anwendungen zu erstellen, ohne dass sie über Kenntnisse in fortgeschrittener Mathematik oder Kryptographie verfügen müssen.

Diese Anwendungen umfassen:

• JSON: Beweisen Sie den Inhalt eines Eintrags in einer JSON-Datei, während Sie andere Daten privat halten.
• Wo ist Walter: Beweisen Sie, dass Walter in der JPG-Datei vorhanden ist, während andere Teile des Bildes privat bleiben.
• ZK Checkmate: Beweisen Sie, dass Sie einen Zug zum Schachmatt gesehen haben, ohne den Gewinnzug preiszugeben.
• ZK Beweis für Ausnutzung: Beweis dafür, dass Sie ein Ethereum-Konto ausnutzen können, ohne die Schwachstelle preiszugeben.
• ECDSA-Signaturüberprüfung: Beweisen Sie die Gültigkeit der ECDSA-Signatur.

Diese Beispiele werden umgesetzt, indem ein reifes Software-Ökosystem genutzt wird: Die meisten Rust-Toolkits sind out-of-the-box in Risc Zero zkVM verfügbar. Die Kompatibilität mit Rust ist ein Game-Changer für die ZK-Softwarewelt: Projekte, die auf anderen Plattformen Monate oder Jahre dauern könnten, können auf der Plattform von RISC Zero einfach gelöst werden.

RISC Zero ist nicht nur einfacher zu bauen, sondern bietet auch eine gute Leistung. zkVM verfügt über eine GPU-Beschleunigung von CUDA und Metal und realisiert den parallelen Nachweis großer Programme durch Fortsetzung.

Zuvor hatte Risc Zero eine Serie-A-Finanzierung in Höhe von 40 Millionen US-Dollar von Galaxy Digital, IOSG, RockawayX, Maven 11, Fenbushi Capital, Delphi Digital, Algaé Ventures, IOBC und anderen Institutionen erhalten.

5.3 Brevis

Brevis, eine Tochtergesellschaft von Celer Network, konzentriert sich darauf, historische Daten von mehreren Ketten zu erfassen. Es verleiht Smart Contracts die Fähigkeit, ihre vollständigen historischen Daten von jeder Kette zu lesen und umfassende vertrauenslose individuelle Berechnungen durchzuführen. Derzeit unterstützt es hauptsächlich Ethereum POS, Comos Tendermint und BSC.

Anwendungsinterface: Das aktuelle System von Brevis unterstützt effiziente und prägnante ZK-Beweise und stellt die folgenden ZK-beweisgeführten Quellenketteninformationen für dezentrale Anwendungs (dApp)-Verträge, die mit der Blockchain verbunden sind, bereit:

1. Der Block-Hash und die zugehörigen Status-, Transaktions- und Empfangs-Roots eines beliebigen Blocks auf der Quellkette.
2. Slotwert und zugehörige Metadaten für einen bestimmten Block, Vertrag, Slot auf der Quellkette.
3. Transaktionsbelege und zugehörige Metadaten für jede Transaktion auf der Quellkette.
4. Transaktionseingänge und zugehörige Metadaten für jede Transaktion auf der Quellkette.
5. Jede Nachricht, die von einer beliebigen Entität auf der Quellkette an eine beliebige Entität auf der Zielkette gesendet wird.

Architekturübersicht: Die Architektur von Brevis besteht aus drei Hauptteilen:

1. Repeater-Netzwerk: Es synchronisiert Blockheader und On-Chain-Informationen aus verschiedenen Blockchains und leitet sie an das Validierungsnetzwerk weiter, um Gültigkeitsnachweise zu generieren. Anschließend übermittelt es die überprüften Informationen und die zugehörigen Nachweise an die verbundene Blockchain.
2. Prover-Netzwerk: Implementieren von Schaltungen für das Leichtklientenprotokoll jeder Blockchain, Blockupdates und Generieren von Beweisen für angeforderte Schlüsselwerte, Transaktionen, Empfangsbestätigungen und integrierte Anwendungslogik. Um Beweiszeit, Kosten und On-Chain-Verifizierungskosten zu minimieren, können ein Netzwerk von Beweisführern verteilte gleichzeitig generierte Beweise aggregieren. Darüber hinaus kann es Beschleuniger wie GPUs, FPGAs und ASICs nutzen, um die Effizienz zu verbessern.
3. Verbindung von Validierungsverträgen auf der Blockchain: Empfangen von zk-verifizierten Daten und zugehörigen Beweisen, die vom Validierungsnetzwerk generiert wurden, und dann Rückführung der verifizierten Informationen an den dApp-Vertrag.

Diese integrierte Architektur ermöglicht es Brevis, eine hohe Effizienz und Sicherheit bei der Bereitstellung von Cross-Chain-Daten und -Berechnungen zu gewährleisten, was es dApp-Entwicklern ermöglicht, das Potenzial der Blockchain voll auszuschöpfen. Mit dieser modularen Architektur kann Brevis vollständig vertrauenswürdige, flexible und effiziente Datenzugriffs- und Rechenfähigkeiten für On-Chain-Smart Contracts auf allen unterstützten Chains bereitstellen. Dies bietet ein völlig neues Paradigma für die dApp-Entwicklung. Brevis hat eine Vielzahl von Anwendungsfällen wie datengetriebenes DeFi, zkBridges, On-Chain-Benutzerakquise, zkDID, soziale Kontenabstraktion usw., die die Dateninteroperabilität erhöhen.

5.4 Langrange

Langrange und Brevis haben eine ähnliche Vision und zielen darauf ab, die Interoperabilität zwischen mehreren Ketten durch den ZK Big Data Stack zu verbessern, der universelle Statusnachweise auf allen gängigen Blockchains erstellen kann. Durch die Integration des Langrange-Protokolls können Anwendungen aggregierte Nachweise des Multi-Chain-Status einreichen, die dann von Verträgen auf anderen Ketten nicht-interaktiv überprüft werden können.

Im Gegensatz zu traditionellen Brücken- und Messaging-Protokollen verlässt sich das Langrange-Protokoll nicht auf eine spezifische Gruppe von Knoten, um Informationen zu übermitteln. Stattdessen nutzt es Kryptographie, um in Echtzeit Beweise für den Zustand der Cross-Chain zu koordinieren, einschließlich derjenigen, die von nicht vertrauenswürdigen Benutzern eingereicht wurden. Unter diesem Mechanismus gewährleistet die Anwendung von Verschlüsselungstechnologie die Gültigkeit und Sicherheit des Zertifikats, selbst wenn die Informationsquelle nicht vertrauenswürdig ist.

Das Langrange-Protokoll wird zunächst mit allen EVM-kompatiblen L1- und L2-Rollups kompatibel sein. Darüber hinaus plant Langrange auch die Unterstützung von nicht EVM-kompatiblen Chains in naher Zukunft, einschließlich, aber nicht beschränkt auf Solana, Sui, Aptos und beliebte öffentliche Chains, die auf dem Cosmos SDK basieren.

Der Unterschied zwischen dem Langrange-Protokoll und traditionellen Brückungs- und Messaging-Protokollen:

Traditionelle Brücken- und Messaging-Protokolle werden hauptsächlich verwendet, um Vermögenswerte oder Nachrichten zwischen einem bestimmten Paar von Ketten zu übertragen. Diese Protokolle verlassen sich in der Regel auf eine Gruppe von Zwischenknoten, um den aktuellen Blockheader der Quellkette auf der Zielskette zu bestätigen. Dieser Modus ist hauptsächlich für Einzel-zu-Einzelkettenbeziehungen optimiert, basierend auf dem aktuellen Status der beiden Ketten. Im Gegensatz dazu bietet das Langrange-Protokoll eine allgemeinere und flexiblere Methode der Cross-Chain-Interaktion, die es Anwendungen ermöglicht, in einem breiteren Blockchain-Ökosystem zu interagieren, anstatt auf eine einzelne Kette-zu-Kette-Beziehung beschränkt zu sein.

Das Langrange-Protokoll optimiert speziell den Mechanismus zur Überprüfung des Zustands interner Kettenverträge, anstatt nur die Übertragung von Informationen oder Vermögenswerten. Diese Funktion ermöglicht es dem Langrange-Protokoll, komplexe Analysen des aktuellen und historischen Vertragszustands effizient zu handhaben, die sich über mehrere Ketten erstrecken können. Diese Fähigkeit ermöglicht es Langrange, eine Reihe komplexer Anwendungsszenarien über Ketten hinweg zu unterstützen, wie z.B. die Berechnung des gleitenden Durchschnitts der Vermögenspreise an dezentralen Börsen (DEX) auf mehreren Ketten oder die Analyse der Volatilität der Zinssätze am Geldmarkt auf verschiedenen Ketten.

Daher können Langrange-Zustandsnachweise als Optimierungen für viele-zu-einem (n-zu-1) Kettenbeziehungen angesehen werden. In dieser Cross-Chain-Beziehung verlässt sich eine dezentrale Anwendung (DApp) auf einer Kette auf die Aggregation von Echtzeit- und historischen Zustandsdaten aus mehreren anderen Ketten (n). Diese Funktion erweitert die Funktionalität und Effizienz von DApps erheblich und ermöglicht es ihnen, Daten aus verschiedenen Blockchains zu aggregieren und zu analysieren, um tiefere und umfassendere Einblicke zu bieten. Diese Methode unterscheidet sich erheblich von der traditionellen Einzelkette- oder Eins-zu-Eins-Kettenbeziehung und bietet ein breiteres Potenzial und Anwendungsspektrum für Blockchain-Anwendungen.

Langrange hat zuvor Investitionen von 1kx, Maven11, Lattice, CMT Digital und gumi crypto erhalten.

5.5 Herodot

Herodotus ist darauf ausgelegt, intelligente Verträge mit synchronem On-Chain-Datenzugriff aus anderen Ethereum-Schichten zu ermöglichen. Sie glauben, dass der Nachweis der Speicherung den Zustand mehrerer Rollups vereinheitlichen und sogar synchrone Lesevorgänge zwischen den Ethereum-Schichten ermöglichen kann. Einfach ausgedrückt handelt es sich um die Datenerfassung zwischen der EVM-Hauptkette und dem Rollup. Unterstützt derzeit ETH-Hauptnetz, Starknet, Zksync, OP, Arbitrum und Polygon.

Ein Speicherbeweis, wie von Herodotus definiert, ist ein Verbundbeweis, der verwendet werden kann, um die Gültigkeit eines oder mehrerer Elemente in einem großen Datensatz zu überprüfen, wie z.B. die Daten im gesamten Ethereum-Blockchain.

Der Speicherungsnachweisgenerierungsprozess ist grob in drei Schritte unterteilt:

Schritt 1: Holen Sie sich den Block-Header-Speicher-Akkumulator verifizierbarer Verpflichtungen

• Dieser Schritt dient dazu, eine "Verpflichtung" zu erhalten, die wir überprüfen können. Wenn der Akkumulator noch nicht den letzten Block-Header enthält, den wir nachweisen müssen, müssen wir zunächst die Kontinuität der Kette nachweisen, um sicherzustellen, dass wir den Bereich der Blöcke abdecken, die unsere Zieldaten enthalten. Wenn sich die Daten, die wir nachweisen möchten, beispielsweise in Block 1.000.001 befinden und der im Block-Header gespeicherte Smart Contract nur Block 1.000.000 abdeckt, müssen wir den Header-Speicher aktualisieren.
• Wenn der Zielblock bereits im Akkumulator ist, können Sie direkt mit dem nächsten Schritt fortfahren.

Schritt 2: Beweisen Sie die Existenz eines bestimmten Kontos

• Dieser Schritt erfordert die Erzeugung eines Nachweises der Einbeziehung aus dem State Trie, der aus allen Konten im Ethereum-Netzwerk besteht. Die Zustands-Wurzel ist ein wichtiger Bestandteil der Ableitung des Block-Commitment-Hashes und ist auch Teil des Header-Speichers. Es ist wichtig zu beachten, dass der Block-Header-Hash im Akkumulator vom tatsächlichen Hash des Blocks abweichen kann, da möglicherweise eine andere Hash-Methode aus Effizienzgründen verwendet wurde.

Schritt 3: Beweisen Sie spezifische Daten im Kontobaum

• In diesem Schritt können Beweise für die Einbeziehung von Daten wie Nonces, Kontoständen, Speicherwurzeln oder Codehashes generiert werden. Jedes Ethereum-Konto hat ein Speichertripel (Merkle-Patricia-Baum), das verwendet wird, um die Speicherdaten des Kontos zu speichern. Wenn die Daten, die wir nachweisen wollen, im Kontospeicher enthalten sind, müssen zusätzliche Einbeziehungsnachweise für die spezifischen Datenpunkte in diesem Speicher generiert werden.

Nachdem alle notwendigen Einbeziehungsnachweise und Berechnungsnachweise erstellt wurden, wird ein vollständiger Speichernachweis gebildet. Dieser Nachweis wird dann an die Kette gesendet, wo er gegen eine einzige anfängliche Verpflichtung (wie z.B. ein Blockhash) oder die im Header gespeicherte MMR-Wurzel überprüft wird. Dieser Prozess gewährleistet die Authentizität und Integrität der Daten und gewährleistet gleichzeitig die Effizienz des Systems.

Herodot wird bereits von Geometry, Fabric Ventures, Lambda Class und Starkware unterstützt.

5.6 HyperOracle

Hyper Oracle ist speziell für programmierbare Zero-Knowledge-Oracles konzipiert, um die Blockchain sicher und dezentral zu halten. Durch seinen zkGraph-Standard macht Hyper Oracle praktische, überprüfbare und schnell verbindliche On-Chain-Daten und On-Chain-äquivalente Berechnungen. Es bietet Entwicklern eine völlig neue Möglichkeit, mit der Blockchain zu interagieren.

Hyper Oracles zkOracle-Node besteht hauptsächlich aus zwei Komponenten: zkPoS und zkWASM.

1. zkPoS: Diese Komponente ist dafür verantwortlich, den Blockheader und den Datenstamm der Ethereum-Blockchain durch Zero-Knowledge (zk) Proof zu erhalten, um die Richtigkeit des Ethereum-Konsenses sicherzustellen. zkPoS fungiert auch als externer Schaltkreis für zkWASM.
2. zkWASM: Es verwendet Daten, die von zkPoS erhalten wurden, als Schlüsseleingabe für die Ausführung von zkGraphs. zkWASM ist verantwortlich für die Ausführung von benutzerdefinierten Datenkarten, die von zkGraphs definiert werden, und die Generierung von Zero-Knowledge-Beweisen für diese Operationen. Betreiber von zkOracle-Knoten können die Anzahl der zkGraphs auswählen, die sie ausführen möchten, und zwar von einem bis zu allen bereitgestellten zkGraphs. Der Prozess der Generierung von zk-Beweisen kann an ein verteiltes Netzwerk von Beweisen delegiert werden.

Die Ausgabe von zkOracle sind Off-Chain-Daten, die Entwickler über den zkGraph-Standard von Hyper Oracle nutzen können. Die Daten werden auch mit zk-Zertifikaten geliefert, um die Gültigkeit der Daten und Berechnungen zu überprüfen.

Um die Netzwerksicherheit zu gewährleisten, benötigt das Hyper Oracle-Netzwerk nur einen zkOracle-Knoten. Es können jedoch mehrere zkOracle-Knoten im Netzwerk vorhanden sein, die gegen zkPoS und jeden zkGraph arbeiten. Dadurch können parallel zk-Proofs generiert werden, was die Performance deutlich verbessert. Im Allgemeinen bietet Hyper Oracle Entwicklern eine effiziente und sichere Blockchain-Interaktionsplattform, indem es fortschrittliche ZK-Technologie und flexible Knotenarchitektur kombiniert.

Im Januar 2023 gab Hyper Oracle bekannt, dass es eine Vorfinanzierungsrunde in Höhe von 3 Millionen US-Dollar erhalten hat, an der Dao5, Sequoia China, Foresight Ventures und FutureMoney Group gemeinsam teilgenommen haben.

5.7 Pfad

Pado ist eine besondere Existenz unter den ZK-Co-Prozessoren. Andere Co-Prozessoren konzentrieren sich darauf, On-Chain-Daten zu erfassen, während Pado einen Weg zur Erfassung von Off-Chain-Daten bietet, um alle Internetdaten in Smart Contracts zu bringen. Es ersetzt die Funktion des Orakels in gewissem Maße, gewährleistet jedoch die Privatsphäre und beseitigt die Notwendigkeit, externen Datenquellen zu vertrauen.

5.8 Vergleich zwischen ZK-Coprozessor und Orakel-Maschine

• Latenz: Das Orakel ist asynchron, sodass die Latenz beim Zugriff auf flache Daten im Vergleich zum ZK-Coprozessor länger ist.
• Kosten: Obwohl viele Oracles keine Rechenbeweise erfordern und daher weniger kostspielig sind, sind sie weniger sicher. Das Speichern von Beweisen ist teurer, aber sicherer.
• Sicherheit: Die maximale Sicherheit der Datenübertragung wird durch das Sicherheitsniveau des Orakels selbst begrenzt. Im Gegensatz dazu entspricht der ZK-Koprozessor der Sicherheit der Kette. Darüber hinaus sind Orakel aufgrund der Verwendung von Off-Chain-Beweisen anfällig für Manipulationsangriffe.

Die Abbildung unten zeigt den Workflow von Pado:

Pado verwendet Krypto-Knoten als Backend-Beweise. Um Vertrauensannahmen zu reduzieren, wird das Pado-Team eine evolutionäre Strategie verfolgen und die Dezentralisierung des Prüfdienstes schrittweise verbessern. Der Prüfer beteiligt sich aktiv am Abruf und der Weitergabe von Benutzerdaten und weist gleichzeitig die Authentizität von Benutzerdaten nach, die aus Netzwerkdatenquellen stammen. Das Besondere daran ist, dass Pado MPC-TLS (Transport Layer Secure Multi-Party Computation) und IZK (Interactive Zero-Knowledge Proof) nutzt, um es Prüfern zu ermöglichen, Daten "blind" zu beweisen. Das bedeutet, dass Validatoren keine Originaldaten sehen können, einschließlich öffentlicher und privater Benutzerinformationen. Der Verifizierer kann jedoch weiterhin die Datenherkunft der übertragenen TLS-Daten durch kryptographische Verfahren sicherstellen.

1. MPC-TLS: TLS ist ein Sicherheitsprotokoll, das zum Schutz der Privatsphäre und Datenintegrität der Internetkommunikation verwendet wird. Wenn Sie eine Website besuchen und das "Schloss"-Symbol und "https" in der URL sehen, bedeutet dies, dass Ihr Besuch durch TLS gesichert ist. MPC-TLS ahmt die Funktionalität eines TLS-Clients nach, sodass der Authentifikator von Pado mit dem TLS-Client zusammenarbeiten kann, um die folgenden Aufgaben auszuführen: \
   Es ist wichtig zu beachten, dass diese TLS-bezogenen Operationen zwischen dem Client und dem Verifizierer durch das Zwei-Parteien-Berechnungs (2PC)-Protokoll durchgeführt werden. Das Design von MPC-TLS basiert auf einigen Verschlüsselungstechnologien wie Verschleierungsschaltung (GC), Vergessenübertragung (OT), IZK usw.
   • Eine TLS-Verbindung herstellen, einschließlich Berechnung des primären Schlüssels, des Sitzungsschlüssels und der Überprüfungsinformationen.
   • Führen Sie Abfragen über einen TLS-Kanal aus, einschließlich der Generierung verschlüsselter Anfragen und der Entschlüsselung von Serverantworten.
2. EXC: Interaktiver Zero-Knowledge-Beweis ist ein Zero-Knowledge-Beweis, bei dem der Beweiser und der Überprüfer interagieren können. Im IZK-Protokoll ist das Ergebnis des Überprüfers, die Behauptung des Beweisers zu akzeptieren oder abzulehnen. Im Vergleich zu einfachen NIZKs (wie z.B. zk-STARKs oder zk-SNARKs) hat das IZK-Protokoll mehrere Vorteile, wie z.B. hohe Skalierbarkeit für große Behauptungen, geringe Rechenkosten, keine Notwendigkeit für vertrauenswürdiges Setup und minimierten Speicherplatzbedarf.

Pado entwickelt aktiv Uniswaps kyc-Hook, sucht nach mehr Daten zu On-Chain-Anwendungsszenarien und wurde in das erste Batch des Consensys Fellowship-Programms aufgenommen.

6. Zukünftige Perspektive

Der ZK-Coprozessor ermöglicht es der Blockchain, mehr Daten zu erfassen und Off-Chain-Computing-Ressourcen zu geringeren Kosten zu erhalten, ohne die Dezentralisierung zu beeinträchtigen. Es entkoppelt auch den Workflow von Smart Contracts und erhöht die Skalierbarkeit und Effizienz.

Allein von der Nachfrageseite aus betrachtet ist ein ZK-Koprozessor eine Notwendigkeit. Aus der Perspektive des DEX-Tracks allein hat dieser Hook großes Potenzial und kann viele Dinge tun. Wenn Sushiswap keine Hooks hat, wird es nicht in der Lage sein, mit Uniswap zu konkurrieren, und es wird sehr bald eliminiert werden. Wenn der ZK-Koprozessor nicht für Hooks verwendet wird, wird Gas für Entwickler und Benutzer sehr teuer sein, weil Hooks neue Logik einführen und Smart Contracts komplexer machen, was kontraproduktiv ist. Daher ist die Verwendung des ZK-Koprozessors im Moment die beste Lösung. Sowohl aus der Perspektive der Datenerfassung als auch der Berechnung haben mehrere Methoden unterschiedliche Vor- und Nachteile. Der für spezifische Funktionen geeignete Koprozessor ist ein guter Koprozessor. Der Markt für verifizierbare On-Chain-Berechnungen hat breite Perspektiven und wird in mehreren Bereichen neuen Wert widerspiegeln.

In der zukünftigen Entwicklung der Blockchain hat sie das Potenzial, die traditionellen Datenbarrieren des Web2 zu durchbrechen. Informationen werden nicht mehr isolierte Inseln sein und eine stärkere Interoperabilität erreichen. ZK-Co-Prozessoren werden zu leistungsstarken Middleware, um Sicherheit, Datenschutz und vertrauensfreie Bedingungen zu gewährleisten, um die Kosten zu senken und die Effizienz bei der Datenerfassung, -berechnung und -verifizierung von Smart Contracts zu erhöhen, das Datennetz zu befreien, mehr Möglichkeiten zu eröffnen und zur Infrastruktur für echte Anwendungen und On-Chain-KI-Agenten zu werden. Nur wenn man es sich nicht vorstellen kann, kann man es nicht tun.

Stellen Sie sich ein Szenario in der Zukunft vor: Mithilfe der hohen Zuverlässigkeit und Privatsphäre von ZK für die Datenverifizierung können Online-Fahrdienstanbieter ein Aggregationsnetzwerk zusätzlich zu ihren eigenen Plattformen aufbauen. Dieses Datenetzwerk kann Uber, Lyft, Didi, Bolt usw. abdecken, und Online-Fahrdienstanbieter können Daten auf ihren eigenen Plattformen bereitstellen. Du nimmst ein Stück, ich nehme ein Stück, und setze es auf der Blockchain zusammen. Langsam etabliert sich ein Netzwerk, das unabhängig von ihrer eigenen Plattform ist und aggregiert wird. Alle Fahrerdaten sind zu einem großen Aggregator für Online-Fahrdienstdaten geworden und können gleichzeitig die Fahrer anonymisieren und ihre Privatsphäre nicht preisgeben.

7. Inhaltsverzeichnis

https://blog.axiom.xyz/was-ist-ein-zk-coprozessor/

https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

https://dev.risczero.com/api

https://blog.uniswap.org/uniswap-v4

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/

https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol

https://docs.herodotus.dev/herodotus-docs/

https://docs.padolabs.org/

Verzichtserklärung:

1. Dieser Artikel wurde aus [ wieder abgedrucktForesightResearch]. Alle Urheberrechte gehören dem Originalautor [Mike]. Wenn Einwände gegen diesen Nachdruck bestehen, wenden Sie sich bitte an den Gate LearnTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.