Historischer Hintergrund des Coprozessors

Im traditionellen Computerbereich ist ein Coprozessor eine Verarbeitungseinheit, die für die Verarbeitung anderer komplizierter Dinge für das CPU-Gehirn verantwortlich ist. Co-Processing ist im Computerbereich weit verbreitet. Beispielsweise brachte Apple 2013 den M7-Motion-Co-Prozessor auf den Markt, der die Bewegungsempfindlichkeit intelligenter Geräte erheblich verbesserte. Die bekannte GPU ist der 2007 von Nvidia vorgeschlagene Coprozessor, der für die Abwicklung von Aufgaben wie dem Rendern von Grafiken für die CPU verantwortlich ist. Die GPU beschleunigt Anwendungen, die auf der CPU ausgeführt werden, indem sie einige rechenintensive und zeitaufwändige Teile des Codes auslagert, eine Architektur, die als „heterogenes“/„hybrides“ Computing bekannt ist.

Der Coprozessor kann einige komplexe Codes mit einzelnen Leistungsanforderungen oder extrem hohen Leistungsanforderungen auslagern, sodass die CPU flexiblere und veränderbare Teile verarbeiten kann.

In der Ethereum-Kette gibt es zwei Probleme, die die Entwicklung von Anwendungen ernsthaft behindern:

  1. Da für den Vorgang eine hohe Gasgebühr erforderlich ist, ist ein normaler Transfer fest auf die Gasgebühr von 21.000 festgelegt. Dies zeigt, wie hoch die Gasgebühr des Ethereum-Netzwerks ist. Andere Vorgänge, einschließlich der Speicherung, kosten mehr Gas, was die On-Chain-Anwendungen einschränkt Was den Entwicklungsumfang betrifft, sind die meisten Vertragscodes nur für den Asset-Betrieb geschrieben. Sobald komplexe Vorgänge erforderlich sind, ist eine große Menge an Gas erforderlich, was ein ernstes Hindernis für die „Massenakzeptanz“ von Anwendungen und Benutzern darstellt.

  2. Da der Smart-Vertrag in der virtuellen Maschine vorhanden ist, kann der Smart-Vertrag tatsächlich nur auf die Daten der letzten 256 Blöcke zugreifen. Insbesondere beim Pectra-Upgrade im nächsten Jahr, dem EIP-4444-Vorschlag, wird der vollständige Knoten die vergangenen Blöcke nicht mehr speichern. Blockdaten: Der Mangel an Daten hat zu einer Verzögerung bei der Entstehung innovativer datenbasierter Anwendungen geführt. Schließlich basieren Defi-Anwendungen wie Tiktok, Instagram, Multi-Data, LLM usw. alle auf Daten Lens basiert auf der Einführung des Layer-3-Datenprotokolls Momoka, weil wir glauben, dass die Blockchain einen sehr reibungslosen Datenfluss darstellt, aber in Wirklichkeit ist dies nicht der Fall Es ist nur so, dass die Token-Asset-Daten reibungslos fließen, die Datenbestände jedoch aufgrund der Unvollkommenheit der zugrunde liegenden Einrichtungen immer noch ein großes Hindernis darstellen, was auch die Entstehung von „Mass Adoption“-Produkten erheblich einschränken wird.

Aufgrund dieser Tatsache haben wir herausgefunden, dass sowohl Berechnungen als auch Daten die Gründe sind, die die Entstehung des neuen Computerparadigmas „Mass Adoption“ begrenzen. Dies ist jedoch ein Manko der Ethereum-Blockchain selbst und sie wurde nicht für die Bewältigung großer Berechnungsmengen und datenintensiver Aufgaben entwickelt. Doch wie erreicht man die Kompatibilität mit diesen rechen- und datenintensiven Anwendungen? Hier müssen wir einen Co-Prozessor einführen. Die Ethereum-Kette selbst fungiert als CPU, und der Co-Prozessor ähnelt einer GPU. Die Kette selbst kann einige nicht rechenintensive, datenintensive Asset-Daten und einfache Vorgänge verarbeiten Anwendungen, die Daten oder Berechnungen flexibel nutzen möchten, können Coprozessoren nutzen. Mit der Erforschung der ZK-Technologie ist es selbstverständlich, dass die meisten Co-Prozessoren mit ZK als zugrunde liegender Schicht entwickelt werden, um sicherzustellen, dass Co-Prozessoren Berechnungen durchführen und Daten außerhalb der Kette ohne Vertrauen verwenden.

Für ZK Coporcessor ist die Anwendungsgrenze so groß, dass sie alle realen Dapp-Anwendungsszenarien abdecken kann, wie z. B. soziale Netzwerke, Spiele, DeFi-Bausteine, Risikokontrollsysteme basierend auf On-Chain-Daten, Oracle, Datenspeicherung und Schulungen für große Modellsprachen und Inferenz usw. Theoretisch kann alles, was Web2-Anwendungen tun können, mit dem ZK-Coprozessor erreicht werden, und Ethereum dient als letzte Abrechnungsschicht zum Schutz der Anwendungssicherheit.

In der traditionellen Welt gibt es keine klare Definition des Begriffs „Coprozessor“. Solange ein separater Chip als Hilfsmittel zur Unterstützung bei der Erledigung von Aufgaben verwendet werden kann, wird er als „Coprozessor“ bezeichnet. Die aktuelle Definition von ZK-Co-Prozessoren in der Branche ist nicht genau dieselbe. ZK-Query, ZK-Oracle, ZKM usw. sind alle Co-Prozessoren, die bei der Abfrage vollständiger Daten in der Kette und vertrauenswürdiger Daten außerhalb der Kette helfen können , und Berechnungsergebnisse außerhalb der Kette, nach dieser Definition wird Layer2 tatsächlich als Coprozessor von Ethereum betrachtet. Wir werden im Folgenden auch die Ähnlichkeiten und Unterschiede zwischen Layer2 und dem allgemeinen ZK-Coprozessor vergleichen.

Liste der Coprozessor-Projekte

Einige Projekte des ZK-Coprozessors, Quelle: Gate Ventures

Derzeit ist die in der Branche relativ bekannte Co-Verarbeitung in drei Teile unterteilt, nämlich die drei Hauptanwendungsszenarien On-Chain-Datenindizierung, Oracle-Maschinen und ZKML. Das in allen drei Szenarien enthaltene Projekt ist General-ZKM , und die virtuelle Maschine, die außerhalb der Kette läuft, ist unterschiedlich. Delphinus konzentriert sich beispielsweise auf zkWASM, während sich Risc Zero auf die Risc-V-Architektur konzentriert.

Architektur der Coprozessor-Technologie

Wir nehmen den General ZK-Coprozessor als Beispiel, um seine Architektur zu analysieren, um den Lesern die Ähnlichkeiten und Unterschiede in der Technologie und dem Mechanismusdesign dieser universellen virtuellen Maschine verständlich zu machen und den zukünftigen Entwicklungstrend von Coprozessoren zu beurteilen, der sich hauptsächlich um Risc Three dreht Projekte wie Zero, Lagrange und Succinct wurden analysiert.

Keine Erwärmung

In Risc Zero heißt der ZK-Coprozessor Bonsai.

Bonsai-Architektur, Quelle: Risc Zero

Bonsai-Komponenten, Quelle: Risc Zero

In Bonsai wurde ein vollständiger Satz kettenunabhängiger Zero-Knowledge-Proof-Komponenten erstellt. Ziel ist es, ein kettenunabhängiger Co-Prozessor zu werden, der auf der Risc-V-Befehlssatzarchitektur basiert und über große Vielseitigkeit und unterstützte Sprachen verfügt. Einschließlich Rust, C++, Solidity, Go usw. Zu seinen Hauptfunktionen gehören:

  1. Universelle zkVM, die jede virtuelle Maschine in einer wissensfreien/überprüfbaren Umgebung ausführen kann.

  2. ZK-Proof-Generierungssystem, das direkt in jeden Smart Contract oder jede Smart-Kette integriert werden kann

  3. Ein Allzweck-Rollup, das alle Berechnungen eines Beweises auf Bonsai an die Kette verteilt, sodass Netzwerk-Miner die Beweiserstellung durchführen können.

Zu seinen Bestandteilen gehören:

  1. Prüfernetzwerk: Über die Bonsai-API erhält der Prüfer den ZK-Code, der im Netzwerk überprüft werden muss, und führt dann den Beweisalgorithmus aus, um den ZK-Beweis zu generieren. Dieses Netzwerk wird in Zukunft für jedermann offen sein.

  2. Anforderungspool: Dieser Pool speichert von Benutzern initiierte Zertifizierungsanforderungen (ähnlich dem Mempool von Ethereum, der zum vorübergehenden Speichern von Transaktionen verwendet wird). Anschließend wird dieser Anforderungspool vom Sequenzer sortiert, um Blöcke zu generieren, und viele der Zertifizierungsanforderungen werden auf diese aufgeteilt Verbesserung der Beweiseffizienz.

  3. Rollup-Engine: Diese Engine sammelt die im Prüfernetzwerk gesammelten Beweisergebnisse, packt sie dann in Root Proof und lädt sie in das Ethereum-Hauptnetzwerk hoch, damit die Validatoren in der Kette sie jederzeit überprüfen können.

  4. Image Hub: Dies ist eine visuelle Entwicklerplattform, auf der Funktionen und vollständige Anwendungen gespeichert werden können. Daher können Entwickler die entsprechende API über Smart Contracts aufrufen.

  5. State Store: Bonsai hat auch einen Off-Chain-State-Storage eingeführt, der in Form von Schlüssel-Wert-Paaren in der Datenbank gespeichert wird, was die On-Chain-Speicherkosten senken und mit der ImageHub-Plattform zusammenarbeiten kann, um die Komplexität intelligenter Verträge zu reduzieren.

  6. Prüfmarkt: ZK prüft den mittleren und oberen Bereich der Industriekette, und der Rechenleistungsmarkt wird genutzt, um die Angebots- und Nachfrageseite der Rechenleistung abzugleichen.

Lagrange

Das Ziel von Lagrange besteht darin, eine Co-Prozessor- und überprüfbare Datenbank aufzubauen, die historische Daten zur Blockchain enthält und diese Daten reibungslos zum Erstellen vertrauenswürdiger Anwendungen nutzen kann. Dies ermöglicht die Entwicklung rechen- und datenintensiver Anwendungen.

Dabei handelt es sich um zwei Funktionen:

  1. Überprüfbare Datenbank: Durch die Indizierung der Speicherung des Smart Contracts in der Kette wird der vom Smart Contract generierte On-Chain-Status in die Datenbank übernommen. Im Wesentlichen werden der Speicher, der Status und die Blöcke der Blockchain rekonstruiert und dann auf aktualisierte Weise in einer Off-Chain-Datenbank gespeichert, die leicht abrufbar ist.

  2. Berechnung basierend auf dem MapReduce-Prinzip: Das MapReduce-Prinzip besteht darin, Datentrennung und paralleles Rechnen mit mehreren Instanzen in großen Datenbanken zu verwenden und die Ergebnisse schließlich miteinander zu integrieren. Diese Architektur, die die parallele Ausführung unterstützt, wird von Lagrange zkMR genannt.

Bei der Gestaltung der Datenbank handelt es sich um insgesamt drei Teile von On-Chain-Daten, nämlich Vertragsspeicherdaten, EOA-Statusdaten und Blockdaten.

Struktur der Lagrange-Datenbank, Quelle: Lagrange

Das Obige ist die Zuordnungsstruktur der in seinem Vertrag gespeicherten Daten. Die Statusvariablen des Vertrags werden hier gespeichert, und jeder Vertrag verfügt über einen unabhängigen Speicherversuch. Dieser Trie wird in Form eines MPT-Baums gespeichert. Obwohl der MPT-Baum einfach ist, ist seine Effizienz sehr gering, weshalb die Kernentwickler von Ethereum die Entwicklung von Verkel-Bäumen fördern. In Lagrange kann jeder Knoten mit SNARK/STARK „bewiesen“ werden, und der übergeordnete Knoten enthält den Beweis des untergeordneten Knotens, was den Einsatz rekursiver Beweistechnologie erfordert.

Kontostatus, Quelle: Lagrange

Konten sind EOA- und Vertragskonten, die in Form von Account/Storage Root (Speicherplatz für Vertragsvariablen) gespeichert werden können, um den Kontostatus darzustellen. Es scheint jedoch, dass Lagrange diesen Teil noch nicht vollständig entworfen hat und tatsächlich State Trie hinzufügen muss (Das Stammverzeichnis des Statusspeicherplatzes des externen Kontos).

Blockdatenstruktur, Quelle: Lagrange

In der neuen Datenstruktur hat Lagrange eine Blockdatenstruktur erstellt, die für SNARKs-Beweise geeignet ist. Die Größe dieser Zahl ist festgelegt. Wenn Ethereum alle 12 Sekunden einen Block erzeugt ca. 25 Jahre nutzbar.

In der virtuellen ZKMR-Maschine von Lagrange besteht die Berechnung aus zwei Schritten:

  1. Zuordnen: Eine verteilte Maschine ordnet vollständige Daten zu und generiert Schlüssel-Wert-Paare.

  2. Reduzieren: Verteilte Computer berechnen die Beweise separat und führen dann alle Beweise zusammen.

Kurz gesagt, ZKMR kann Beweise kleinerer Berechnungen kombinieren, um Beweise für die gesamte Berechnung zu erstellen. Dadurch kann ZKMR effizient skaliert werden, um komplexe rechnerische Beweise für große Datensätze durchzuführen, die mehrere Berechnungsschritte oder -ebenen erfordern. Wenn Uniswap beispielsweise auf 100 Ketten eingesetzt wird, sind viele Berechnungen und Integrationen erforderlich, wenn Sie den TWAP-Preis eines bestimmten Tokens auf 100 Ketten berechnen möchten. Zu diesem Zeitpunkt kann ZKMR jede Kette einzeln berechnen Kombinieren Sie einen vollständigen Berechnungsnachweis.

Betriebsprozess des Lagrange-Coprozessors, Quelle: Lagrange

Das Obige ist der Ausführungsprozess:

  1. Der Smart-Vertrag des Entwicklers registriert sich zunächst bei Lagrange und sendet dann eine Beweisanforderung an den On-Chain-Smart-Vertrag von Lagrange. Zu diesem Zeitpunkt ist der Proxy-Vertrag für die Interaktion mit dem Entwicklervertrag verantwortlich.

  2. Off-Chain-Lagrange führt eine Co-Verifizierung durch, indem Anfragen in kleine parallelisierbare Aufgaben aufgeteilt und an verschiedene Prüfer verteilt werden.

  3. Dieser Prüfer ist eigentlich ein Netzwerk, und die Sicherheit seines Netzwerks wird durch die Restaking-Technologie von EigenLayer gewährleistet.

Prägnant

Das Ziel von Succinct Network besteht darin, programmierbare Fakten in jeden Teil des Blockchain-Entwicklungsstapels zu integrieren (einschließlich L2, Co-Prozessoren, Cross-Chain-Brücken usw.).

Prägnanter Bedienungsprozess, Quelle: Succinct

Succinct kann Codes einschließlich Solidity und Fachsprache (DSL) im Zero-Knowledge-Bereich akzeptieren und diese an den Succinct-Coprozessor außerhalb der Kette weitergeben, der den Datenindex der Zielkette vervollständigt und dann den Zertifizierungsantrag an den Succinct-Coprozessor weiterleitet Zertifizierungsmarkt, der CPUs unterstützen kann, Miner von GPU- und ETC-Chips reichen Beweise im Proof-Netzwerk ein. Sein Merkmal besteht darin, dass der Proof-Markt mit verschiedenen Proof-Systemen kompatibel ist, da es in Zukunft einen langen Zeitraum geben wird, in dem verschiedene Proof-Systeme nebeneinander existieren werden.

Der Off-Chain-ZKVM von Succinct heißt SP (Succinct Processor) und kann die Rust-Sprache und andere LLVM-Sprachen unterstützen.

  1. Rekursion + Verifizierung: Die auf der STARK-Technologie basierende rekursive Verifizierungstechnologie kann die ZK-Komprimierungseffizienz exponentiell verbessern.

  2. Unterstützt SNARKs-zu-STARKs-Wrapper: Kann die Vorteile von SNARKs und STARKs gleichzeitig nutzen und so das Kompromissproblem zwischen Proofgröße und Überprüfungszeit lösen.

  3. Vorkompilierungszentrierte zkVM-Architektur: Für einige gängige Algorithmen wie SHA256, Keccak, ECDSA usw. können sie im Voraus kompiliert werden, um die Zeit für die Erstellung des Laufzeitnachweises und die Überprüfungszeit zu verkürzen.

Vergleichen

Beim Vergleich von Allzweck-ZK-Coprozessoren führen wir hauptsächlich Vergleiche durch, die das erste Prinzip der Massenadoption erfüllen. Wir werden auch erklären, warum es wichtig ist:

  1. Probleme bei der Datenindizierung/-synchronisierung: Nur vollständige On-Chain-Daten und synchronisierte Indizierungsfunktionen können die Anforderungen großer datenbasierter Anwendungen erfüllen, andernfalls ist der Anwendungsbereich relativ gering.

  2. Basierend auf der Technologie: SNARKs- und STARKs-Technologie haben unterschiedliche Entscheidungspunkte. Mittelfristig wird die SNARKs-Technologie der wichtigste sein, und langfristig wird die STARKs-Technologie der wichtigste sein.

  3. Ob die Rekursion unterstützt werden soll: Nur durch die Unterstützung der Rekursion können wir Daten stärker komprimieren und einen parallelen Berechnungsnachweis erzielen. Daher ist das Erreichen einer vollständigen Rekursion der technische Höhepunkt des Projekts.

  4. Proof-System: Das Proof-System wirkt sich direkt auf die Größe und Zeit der Proof-Erstellung aus. Dies ist der teuerste Teil der ZK-Technologie. Derzeit sind der selbst erstellte ZK-Cloud-Computing-Leistungsmarkt und das Proof-Netzwerk die wichtigsten.

  5. Ökologische Zusammenarbeit: Kann beurteilen, ob ihre technische Ausrichtung von B-End-Benutzern über die dritte echte Nachfrageseite erkannt wird.

  6. Unterstützende VCs und Finanzierungsstatus: können möglicherweise auf eine spätere Ressourcenunterstützung hinweisen.

Quelle: Gate Ventures

Tatsächlich ist der gesamte technische Weg sehr klar, sodass die meisten Technologien konvergent sind. Beispielsweise verwenden sie alle Wrapper von STARKs bis SNARKs, die gleichzeitig die Vorteile von STARKs und SNARKs nutzen und die Zeit für die Beweiserstellung und Überprüfung verkürzen können und Quantenangriffen widerstehen. Da die Rekursivität des ZK-Algorithmus die Leistung von ZK stark beeinflussen kann, verfügen derzeit alle drei Projekte über rekursive Funktionen. Die Erstellung von Beweisen für den ZK-Algorithmus erfordert den größten Kosten- und Zeitaufwand. Daher sind alle drei Projekte auf ihre starke Nachfrage nach ZK-Rechenleistung angewiesen, um ein Netzwerk von Prüfern und einen Markt für Cloud-Computing-Leistung aufzubauen. Wenn die aktuellen technischen Wege sehr ähnlich sind, kann es daher notwendiger sein, das Team und die dahinter stehenden VCs zu durchbrechen, um bei der ökologischen Zusammenarbeit Ressourcen zur Eroberung von Marktanteilen zu unterstützen.

Ähnlichkeiten und Unterschiede zwischen Coprozessor und Layer2

Im Gegensatz zu Layer2 ist der Coprozessor anwendungsorientiert, während Layer2 weiterhin benutzerorientiert ist. Der Coprozessor kann als Beschleunigungskomponente oder modulare Komponente zur Bildung folgender Anwendungsszenarien eingesetzt werden:

  1. Als Off-Chain-Komponenten virtueller Maschinen von ZK Layer2 können diese Layer2 ihre eigenen VMs durch Co-Prozessoren ersetzen.

  2. Als Co-Prozessor für Anwendungen in der öffentlichen Kette, um Rechenleistung außerhalb der Kette zu verlagern.

  3. Als Orakel für Anwendungen in der öffentlichen Kette, um überprüfbare Daten von anderen Ketten zu erhalten.

  4. Fungiert als kettenübergreifende Brücke zwischen den beiden Ketten zur Übertragung von Nachrichten.

Bei diesen Anwendungsszenarien handelt es sich nur um eine unvollständige Liste. Für den Co-Prozessor müssen wir verstehen, dass er das Potenzial einer Echtzeitsynchronisation von Daten sowie leistungsstarker und kostengünstiger vertrauenswürdiger Datenverarbeitung über die gesamte Kette hinweg mit sich bringt und sicher rekonstruieren kann fast alle Blöcke durch den Co-Prozessor Alle Middleware in der Kette. Einschließlich Chainlink und The Graph entwickeln derzeit ihre eigenen Mainstream-Cross-Chain-Bridges wie Wormhole, Layerzero usw. und entwickeln auch Cross-Chain-Bridge-Technologie auf Basis von ZK; und vertrauenswürdige Argumentation usw.

Probleme von Coprozessoren

  1. Der Einstieg in die ZK-Technologie ist theoretisch möglich, es gibt jedoch immer noch viele technische Schwierigkeiten und das Verständnis von außen ist schwierig. Wenn neue Entwickler in das Ökosystem eintreten, müssen sie daher bestimmte Sprachen und Entwicklertools beherrschen. , kann ein größerer Widerstand sein.

  2. Der Track befindet sich in einem sehr frühen Stadium. Die Leistung von zkVM ist sehr komplex und umfasst mehrere Dimensionen (einschließlich Hardware, Einzelknoten- und Mehrknotenleistung, Speichernutzung, Rekursionskosten, Hash-Funktionsauswahl und andere Faktoren). Im Bau befindliche Projekte in verschiedenen Dimensionen befinden sich in einem sehr frühen Stadium und das Muster ist noch nicht klar.

  3. Voraussetzungen wie Hardware sind noch nicht implementiert. Aus Sicht der Hardware ist die aktuelle Mainstream-Hardware unter Verwendung von ASIC und FPGA aufgebaut. Zu den Herstellern gehören Ingonyama, Cysic usw., die sich noch im Laborstadium befinden und noch nicht kommerzialisiert wurden. Wir glauben, dass die ZK-Technologie die Voraussetzungen für eine groß angelegte Implementierung darstellt.

  4. Die technischen Wege sind ähnlich und es ist schwierig, über Generationen hinweg einen technologischen Vorsprung zu haben. Derzeit besteht die Hauptkonkurrenz in den VC-Ressourcen dahinter und in den BD-Fähigkeiten des Teams sowie in der Frage, ob es die ökologische Nische der Mainstream-Anwendungen und öffentlichen Ketten erobern kann .

Zusammenfassung und Ausblick

Die ZK-Technologie ist äußerst vielseitig und hat auch dazu beigetragen, dass das Ethereum-Ökosystem von einer dezentralen Wertorientierung zu einer vertrauenslosen Wertorientierung übergegangen ist. „Don't Trust, Verify it“, dieser Satz ist die Best Practice der ZK-Technologie. Die ZK-Technologie kann eine Reihe von Anwendungsszenarien wie kettenübergreifende Brücken, Orakel, On-Chain-Abfragen, Off-Chain-Berechnungen, virtuelle Maschinen usw. rekonstruieren, und der universelle ZK-Coprozessor ist eines der Werkzeuge zur Implementierung der ZK-Technologie . Der Anwendungsbereich des ZK-Coprozessors ist so groß, dass er jedes reale Dapp-Anwendungsszenario abdecken kann. Theoretisch kann mit dem ZK-Coprozessor alles erreicht werden, was Web2-Anwendungen können.

Technologiedurchdringungskurve, Quelle: Gartner

Seit der Antike ist die Entwicklung der Technologie hinter der menschlichen Vorstellung von einem besseren Leben zurückgeblieben (wie etwa der Flug von Chang'e zum Mond oder der Auftritt von Apollo auf dem Mond). Wenn etwas wirklich innovativ, subversiv und notwendig ist, dann wird es die Technologie auf jeden Fall tun Erkenne es, es braucht nur Zeit, Frage. Wir glauben, dass der universelle ZK-Coprozessor diesem Entwicklungstrend folgt. Wir haben zwei Indikatoren für die „Mass Adoption“ des ZK-Co-Prozessors: eine in Echtzeit nachweisbare Datenbank über die gesamte Kette und kostengünstiges Off-Chain-Computing. Wenn die Datenmenge ausreichend ist und die Echtzeitsynchronisierung mit kostengünstigen, überprüfbaren Off-Chain-Berechnungen gekoppelt ist, kann das Softwareentwicklungsparadigma vollständig geändert werden. Dieses Ziel ist jedoch langsam iterativ, daher konzentrieren wir uns auf die Suche nach Trends oder Werten Ausrichtungen, die mit diesen beiden Punkten übereinstimmen, und die Implementierung von ZK-Rechenchips sind die Voraussetzung für die groß angelegte kommerzielle Anwendung von ZK-Coprozessoren. Diesem Zyklus mangelt es an Innovation und es ist die Zeitspanne, um wirklich die nächste Generation von „Mass“ zu bauen Einführung von Technologien und Anwendungen. Wir gehen davon aus, dass die ZK-Industriekette in der nächsten Runde des Zyklus kommerzialisiert werden kann. Jetzt ist es an der Zeit, sich wieder auf einige Technologien zu konzentrieren, die es Web3 tatsächlich ermöglichen können, die Interaktionen von einer Milliarde Menschen in der Kette zu übertragen.