Da das Konzept der Coprozessoren in den letzten Monaten populär geworden ist, erhält dieser neue ZK-Anwendungsfall immer mehr Aufmerksamkeit.

Wir haben jedoch festgestellt, dass die meisten Menschen mit dem Konzept von Coprozessoren noch relativ unbekannt sind, insbesondere mit der genauen Positionierung von Coprozessoren – was ein Coprozessor ist und was nicht, ist noch relativ vage. Was den Vergleich der technischen Lösungen mehrerer Co-Prozessor-Tracks auf dem Markt betrifft, hat ihn noch niemand systematisch geklärt. Dieser Artikel soll dem Markt und den Benutzern ein klareres Verständnis der Co-Prozessor-Spur vermitteln.

1. Was ist ein Co-Prozessor und was nicht?

Wenn Sie gebeten würden, einem Laien oder Entwickler Coprozessoren in nur einem Satz zu erklären, wie würden Sie es beschreiben?

Ich denke, was Dr. Dong Mo gesagt hat, könnte der Standardantwort sehr nahe kommen – um es ganz klar auszudrücken: Ein Coprozessor „gibt intelligenten Verträgen die Möglichkeit, Dune Analytics durchzuführen“.

Wie kann man diesen Satz dekonstruieren?

Stellen Sie sich das Szenario vor, in dem wir Dune verwenden: Sie möchten LP in Uniswap V3 machen, um einige Bearbeitungsgebühren zu verdienen, also öffnen Sie Dune und finden das aktuelle Handelsvolumen verschiedener Handelspaare auf Uniswap, den effektiven Jahreszins der Bearbeitungsgebühren in den letzten 7 Tagen. und die Mainstream-Handelspaare Die oberen und unteren Schwankungsbereiche usw.

Oder vielleicht begannen Sie, als StepN populär wurde, mit Schuhen zu spekulieren und waren sich nicht sicher, wann Sie sie verkaufen sollten, also starrten Sie jeden Tag auf die StepN-Daten auf Dune, das tägliche Transaktionsvolumen, die Anzahl neuer Benutzer, den Mindestpreis von Schuhen … und geplant, sobald es Wachstum gab. Wenn sich der Trend verlangsamt oder sinkt, laufen Sie schnell.

Natürlich starren Sie möglicherweise nicht nur auf diese Daten, sondern auch die Entwicklungsteams von Uniswap und StepN achten auf diese Daten.

Diese Daten sind sehr aussagekräftig – sie können nicht nur dabei helfen, Trendänderungen zu beurteilen, sondern sie auch zur Entwicklung weiterer Tricks nutzen, genau wie der „Big Data“-Ansatz, der häufig von großen Internetunternehmen verwendet wird.

Basierend auf dem Stil und Preis der Schuhe, die Benutzer häufig kaufen und verkaufen, werden beispielsweise ähnliche Schuhe empfohlen.

Beispielsweise wird ein „Benutzertreue-Belohnungsprogramm“ gestartet, das auf der Zeitspanne basiert, die Benutzer Creation Shoes besitzen, um treuen Benutzern mehr Airdrops oder Vorteile zu bieten.

Beispielsweise kann ein VIP-Plan ähnlich wie bei Cex basierend auf dem TVL oder dem von LP auf Uniswap oder Trader bereitgestellten Handelsvolumen gestartet werden, was dem Händler eine Reduzierung der Transaktionsgebühr oder eine Erhöhung der LP-Gebührenbeteiligung verschafft …

Zu diesem Zeitpunkt tritt das Problem auf: Big Data + KI der großen Internetunternehmen ist im Grunde eine Blackbox. Sie können tun und lassen, was sie wollen. Benutzer können es nicht sehen und es ist ihnen egal.

Aber hier bei Web3 sind Transparenz und Vertrauenslosigkeit unsere natürliche politische Korrektheit, und wir lehnen Black Boxes ab!

Wenn Sie also das obige Szenario realisieren möchten, stehen Sie vor einem Dilemma: Entweder können Sie es mit zentralisierten Mitteln erreichen, Dune „manuell“ verwenden, um die Indexdaten im Hintergrund zu zählen, und sie dann bereitstellen und implementieren; Oder Sie können einen Smart Contract einrichten, um diese Daten in der Kette automatisch zu erfassen, Berechnungen durchzuführen und Punkte automatisch bereitzustellen.

Ersteres führt Sie zu „politisch inkorrekten“ Vertrauensproblemen.

Die durch Letzteres in der Kette generierte Gasgebühr wird eine astronomische Zahl sein, die sich Ihr (projektseitiger) Geldbeutel nicht leisten kann.

Dies ist die Zeit, in der der Co-Prozessor auf die Bühne kommt. Kombinieren Sie jetzt die beiden Methoden und verwenden Sie gleichzeitig den Schritt „Backend-Handbuch“, um mit technischen Mitteln „die Unschuld selbst zu zertifizieren“. Mit anderen Worten: Verwenden Sie die ZK-Technologie, um den Teil „Indizierung +“ „zu beweisen, dass er unschuldig ist“ und geben Sie ihn dann an den Smart Contract weiter. Auf diese Weise wird das Vertrauensproblem gelöst und die massiven Benzingebühren fallen weg. Perfekt!

Warum wird es „Coprozessor“ genannt? Tatsächlich stammt dies von der „GPU“ in der Entwicklungsgeschichte von Web2.0. Der Grund, warum die GPU zu dieser Zeit als separate Computerhardware eingeführt wurde und unabhängig von der CPU existierte, lag darin, dass ihre Designarchitektur einige Berechnungen verarbeiten konnte, die für die CPU grundsätzlich schwierig zu handhaben waren, wie z. B. umfangreiche parallele wiederholte Berechnungen und Grafiken Berechnungen usw. . Gerade aufgrund dieser „Co-Prozessor“-Architektur haben wir heute wunderbare CG-Filme, Spiele, KI-Modelle usw., diese Co-Prozessor-Architektur ist also tatsächlich ein Sprung in der Computerarchitektur. Nun hoffen verschiedene Co-Prozessor-Teams, diese Architektur auch in Web3.0 einzuführen. Die Blockchain ähnelt hier der CPU von Web3.0. Unabhängig davon, ob es sich um L1 oder L2 handelt, sind sie von Natur aus ungeeignet für solche „schweren Daten“ und „komplexen Berechnungslogik“-Aufgaben. Daher wird ein Blockchain-Coprozessor eingeführt, der bei der Abwicklung solcher Berechnungen hilft, wodurch die Möglichkeiten von Blockchain-Anwendungen erheblich erweitert werden.

Was der Coprozessor tut, lässt sich also in zwei Dinge zusammenfassen:

1. Holen Sie sich die Daten aus der Blockchain und verwenden Sie ZK, um zu beweisen, dass die Daten, die ich erhalten habe, wahr und nicht verfälscht sind.
2. Führen Sie entsprechende Berechnungen auf der Grundlage der Daten durch, die ich gerade erhalten habe, und verwenden Sie erneut ZK, um zu beweisen, dass die von mir berechneten Ergebnisse wahr und nicht verfälscht sind. Die Berechnungsergebnisse können durch den Smart Contract „Low Fee + Trustless“ abgerufen werden.

Vor einiger Zeit hatte Starkware ein beliebtes Konzept namens Storage Proof, auch State Proof genannt. Im Grunde wird Schritt 1 ausgeführt, dargestellt durch Herodot, Langrage usw. Der technische Schwerpunkt vieler Cross-Chain-Brücken auf Basis der ZK-Technologie liegt ebenfalls in Schritt 1.1.

Der Co-Prozessor ist nichts anderes als Schritt 1, gefolgt von Schritt 2. Nachdem Sie die Daten ohne Vertrauen extrahiert haben, führen Sie eine vertrauenswürdige Berechnung durch und fertig.

Um es also mit einem relativ technischen Begriff genau zu beschreiben: Der Coprozessor sollte eine Obermenge von Storage Proof/State Proof und eine Teilmenge von Verfiable Computation sein.

Zu beachten ist, dass der Coprozessor kein Rollup ist.

Technisch gesehen ähnelt der ZK-Proof von Rollup Schritt 2 oben, und der Prozess von Schritt 1 „Daten abrufen“ wird direkt über Sequencer implementiert. Sogar ein dezentraler Sequenzer verwendet lediglich eine Art Wettbewerbs- oder Konsensmechanismus, um dies zu erreichen. Nehmen Sie anstelle von Storage Proof diese Form von ZK. Wichtiger ist, dass ZK Rollup zusätzlich zur Berechnungsschicht auch eine Speicherschicht ähnlich der L1-Blockchain implementieren muss. Dieser Speicher ist dauerhaft, während der ZK-Coprozessor „zustandslos“ ist. Nach Abschluss der Berechnung bleibt der Status „Alle“ erhalten.

Aus Sicht des Anwendungsszenarios kann der Coprozessor als Service-Plug-In für alle Layer1/Layer2 betrachtet werden, während Rollup eine Ausführungsschicht neu erstellt, um die Erweiterung der Abrechnungsschicht zu unterstützen.

2. Warum muss ich ZK verwenden? Ist es in Ordnung, OP zu verwenden?

Nachdem Sie das oben Gesagte gelesen haben, haben Sie möglicherweise Zweifel: Muss ZK als Coprozessor verwendet werden? Es klingt so sehr nach einer „Grafik mit hinzugefügtem ZK“, und wir scheinen keine „großen Zweifel“ an den Ergebnissen der Grafik zu haben.

Das liegt daran, dass es bei der Nutzung von Graph grundsätzlich nicht um echtes Geld geht. Diese Indizes dienen Off-Chain-Diensten. Was Sie auf der Front-End-Benutzeroberfläche sehen, sind Transaktionsvolumen, Transaktionsverlauf usw. Daten können über mehrere Datenindexanbieter wie Graph, Alchemy, Zettablock usw. bereitgestellt werden, aber diese Daten können nicht zurück in den Smart Contract gestopft werden, da Sie durch das erneute Einfügen zusätzliches Vertrauen in den Indexdienst schaffen. Wenn Daten mit echtem Geld verknüpft werden, insbesondere mit TVL mit großem Volumen, wird dieses zusätzliche Vertrauen wichtig. Stellen Sie sich vor, wenn Sie das nächste Mal von einem Freund gebeten werden, sich 100 Yuan zu leihen, leihen Sie es einfach, ohne mit der Wimper zu zucken. Ja, was ist, wenn ich Sie bitte, mir 10.000 Yuan oder sogar 1 Million Yuan zu leihen?

Aber müssen wir wirklich ZK verwenden, um alle oben genannten Szenarien gemeinsam zu verarbeiten? Schließlich haben wir im Rollup zwei technische Routen, OP und ZK. Auch das neuerdings populäre ZKML verfügt über das OPML-Konzept entsprechender Zweigrouten. Auf die Frage: Verfügt der Coprozessor auch über einen OP-Zweig, z. B. einen OP-Coprozessor?

Tatsächlich gibt es das tatsächlich – wir halten die konkreten Details jedoch vorerst vertraulich und werden in Kürze detailliertere Informationen veröffentlichen.

3. Welcher Coprozessor ist der beste – Vergleich mehrerer gängiger technischer Coprozessorlösungen auf dem Markt

Brevis

Die Architektur von Brevis besteht aus drei Komponenten: zkFabric, zkQueryNet und zkAggregatorRollup.

Das Folgende ist ein Brevis-Architekturdiagramm:

zkFabric: Sammelt Blockheader von allen verbundenen Blockchains und generiert ZK-Konsensnachweise, die die Gültigkeit dieser Blockheader beweisen. Durch zkFabric implementiert Brevis einen interoperablen Coprozessor für mehrere Ketten, der es einer Blockchain ermöglicht, auf alle historischen Daten einer anderen Blockchain zuzugreifen.

zkQueryNet: Ein offener ZK-Abfrage-Engine-Marktplatz, der Datenabfragen von dApps akzeptiert und verarbeitet. Datenabfragen verarbeiten diese Abfragen mithilfe verifizierter Blockheader von zkFabric und generieren ZK-Abfragenachweise. Diese Engines verfügen sowohl über hochspezialisierte Funktionen als auch über allgemeine Abfragesprachen, um unterschiedliche Anwendungsanforderungen zu erfüllen.

zkAggregatorRollup: Eine ZK-Faltungsblockchain, die als Aggregations- und Speicherschicht für zkFabric und zkQueryNet fungiert. Es verifiziert die Beweise beider Komponenten, speichert die verifizierten Daten und übergibt seinen zk-validierten Statusstamm an alle verbundenen Blockchains.

ZK Fabric ist ein wichtiger Teil der Beweiserstellung für den Blockheader. Es ist sehr wichtig, die Sicherheit dieses Teils zu gewährleisten. Das Folgende ist das Architekturdiagramm von zkFabric:

Der Zero-Knowledge-Proof (ZKP)-basierte Light-Client von zkFabric macht es völlig vertrauenswürdig, ohne auf eine externe Verifizierungsinstanz angewiesen zu sein. Es besteht keine Notwendigkeit, sich auf eine externe Verifizierungsstelle zu verlassen, da die Sicherheit vollständig auf der zugrunde liegenden Blockchain und mathematisch zuverlässigen Beweisen beruht.

Das zkFabric Prover-Netzwerk implementiert Schaltkreise für das Lightclient-Protokoll jeder Blockchain und das Netzwerk generiert Gültigkeitsnachweise für Blockheader. Prüfer können Beschleuniger wie GPUs, FPGAs und ASICs nutzen, um Prüfzeit und -kosten zu minimieren.

zkFabric stützt sich auf die Sicherheitsannahmen der Blockchain und der zugrunde liegenden kryptografischen Protokolle sowie auf die Sicherheitsannahmen der zugrunde liegenden kryptografischen Protokolle. Um jedoch die Wirksamkeit von zkFabric sicherzustellen, ist mindestens ein ehrlicher Relayer erforderlich, der den richtigen Fork synchronisiert. Daher verwendet zkFabric ein dezentrales Relay-Netzwerk anstelle eines einzelnen Relays, um die Effektivität von zkFabric zu optimieren. Dieses Relay-Netzwerk kann bestehende Strukturen nutzen, beispielsweise das State Guard-Netzwerk im Celer-Netzwerk.

Zuweisung von Prüfern: Das Prüfernetzwerk ist ein dezentrales ZKP-Prüfernetzwerk, das für jede Beweiserstellungsaufgabe einen Prüfer auswählt und diesen Prüfern Gebühren zahlt.

Aktuelle Bereitstellung:

Als Beispiele und Proof-of-Concepts dienen Light-Client-Protokolle, die derzeit für verschiedene Blockchains implementiert sind, darunter Ethereum PoS, Cosmos Tendermint und BNB Chain.

Brevis hat derzeit mit Uniswap Hook zusammengearbeitet, das in großem Umfang benutzerdefinierte Uniswap-Pools hinzufügt. Im Vergleich zu CEX mangelt es UnisWap jedoch immer noch an effektiven Datenverarbeitungsfunktionen, um Projekte zu erstellen, die auf großen Benutzertransaktionsdaten basieren (z. B. Treueprogramme basierend auf dem Transaktionsvolumen). Funktion.

Mit der Hilfe von Brevis löste Hook die Herausforderung. Hooks können jetzt aus den gesamten Verlaufskettendaten eines Benutzers oder LPs lesen und anpassbare Berechnungen auf völlig vertrauenswürdige Weise ausführen.

Herodot

Herodotus ist eine leistungsstarke Middleware für den Datenzugriff, die Smart Contracts mit den folgenden Funktionen ausstattet, um synchron auf aktuelle und historische Daten in der Kette über die Ethereum-Ebene zuzugreifen:

1. L1-Zustände von L2s
2. L2-Zustände sowohl von L1s als auch von anderen L2s
3. L3/App-Chain-Zustände zu L2s und L1s

Herodot schlug das Konzept des Speichernachweises vor, der Einschlussnachweis (Bestätigung der Existenz von Daten) und rechnerischen Beweis (Überprüfung der Ausführung eines mehrstufigen Arbeitsablaufs) kombiniert, um zu beweisen, dass ein großer Datensatz (z. B. die gesamte Ethereum-Blockchain oder das gesamte Ethereum-Rollup) oder die Gültigkeit mehrerer Elemente.

Der Kern der Blockchain ist die Datenbank, in der die Daten mithilfe von Datenstrukturen wie Merkle-Bäumen und Merkle-Patricia-Bäumen verschlüsselt und geschützt werden. Das Besondere an diesen Datenstrukturen ist, dass nach der sicheren Übertragung der Daten Beweise generiert werden können, die bestätigen, dass die Daten in der Struktur enthalten sind.

Die Verwendung von Merkle-Bäumen und Merkle-Patricia-Bäumen erhöht die Sicherheit der Ethereum-Blockchain. Durch kryptografisches Hashing der Daten auf jeder Ebene des Baums ist es nahezu unmöglich, die Daten unbemerkt zu ändern. Alle Änderungen an einem Datenpunkt erfordern die Änderung des entsprechenden Hashs im Baum in den Root-Hash, der im Blockchain-Header öffentlich sichtbar ist. Dieses grundlegende Merkmal der Blockchain bietet ein hohes Maß an Datenintegrität und Unveränderlichkeit.

Zweitens ermöglichen diese Bäume eine effiziente Datenüberprüfung durch Einschlussnachweise. Wenn Sie beispielsweise die Einbeziehung einer Transaktion oder den Status eines Vertrags überprüfen möchten, muss nicht die gesamte Ethereum-Blockchain durchsucht werden, sondern nur der Pfad innerhalb des relevanten Merkle-Baums.

Der Aufbewahrungsnachweis im Sinne von Herodot ist eine Kombination aus:

1. Eindämmungsnachweise: Diese Beweise bestätigen die Existenz bestimmter Daten in einer kryptografischen Datenstruktur (z. B. einem Merkle-Baum oder Merkle-Patricia-Baum) und stellen sicher, dass die betreffenden Daten tatsächlich im Datensatz vorhanden sind.
2. Computergestützter Beweis: Überprüfen Sie die Ausführung eines mehrstufigen Workflows und beweisen Sie die Gültigkeit eines oder mehrerer Elemente in einem umfassenden Datensatz, beispielsweise der gesamten Ethereum-Blockchain oder einem Aggregat. Sie zeigen nicht nur das Vorhandensein von Daten an, sondern überprüfen auch die auf diese Daten angewendeten Transformationen oder Vorgänge.
3. Wissensfreie Beweise: Vereinfachen Sie die Datenmenge, mit der Smart Contracts interagieren müssen. Mithilfe wissensfreier Beweise können intelligente Verträge die Gültigkeit eines Anspruchs bestätigen, ohne alle zugrunde liegenden Daten verarbeiten zu müssen.

Arbeitsablauf

1.Erhalten Sie den Block-Hash

Alle Daten auf der Blockchain gehören zu einem bestimmten Block. Der Block-Hash dient als eindeutige Kennung des Blocks und fasst seinen gesamten Inhalt über den Block-Header zusammen. Im Proof-of-Storage-Workflow müssen wir zunächst den Block-Hash des Blocks ermitteln und überprüfen, der die Daten enthält, an denen wir interessiert sind. Dies ist der erste Schritt im gesamten Prozess.

2.Erhalten Sie den Block-Header

Sobald der relevante Block-Hash erhalten wurde, besteht der nächste Schritt darin, auf den Block-Header zuzugreifen. Dazu muss der Blockheader, der mit dem im vorherigen Schritt erhaltenen Block-Hash verknüpft ist, gehasht werden. Der Hash des bereitgestellten Blockheaders wird dann mit dem resultierenden Block-Hash verglichen:

Es gibt zwei Möglichkeiten, den Hash zu erhalten:

1. Verwenden Sie zum Abrufen den BLOCKHASH-Opcode
2. Fragen Sie den Hash von Blöcken ab, die im Verlauf überprüft wurden, vom Block Hash Accumulator

Dieser Schritt stellt sicher, dass der verarbeitete Blockheader authentisch ist. Sobald dieser Schritt abgeschlossen ist, kann der Smart Contract auf jeden Wert im Blockheader zugreifen.

3. Bestimmen Sie die erforderlichen Wurzeln (optional)

Mit dem Blockheader in der Hand können wir uns mit seinem Inhalt befassen, insbesondere mit:

stateRoot: Eine kryptografische Zusammenfassung des gesamten Blockchain-Status zum Zeitpunkt des Auftretens der Blockchain.

ReceiptsRoot: Verschlüsselter Digest aller Transaktionsergebnisse (Quittungen) im Block.

TransactionsRoot: Ein kryptografischer Auszug aller Transaktionen, die im Block stattgefunden haben.

kann entschlüsselt werden, sodass überprüft werden kann, ob ein bestimmtes Konto, eine bestimmte Quittung oder eine bestimmte Transaktion im Block enthalten ist.

4. Daten anhand des ausgewählten Stamms validieren (optional)

Mit der von uns ausgewählten Wurzel und unter Berücksichtigung der Tatsache, dass Ethereum eine Merkle-Patricia-Trie-Struktur verwendet, können wir den Merkle-Einschlussnachweis verwenden, um zu überprüfen, ob die Daten im Baum vorhanden sind. Die Überprüfungsschritte variieren je nach Daten und Datentiefe innerhalb des Blocks.

Derzeit unterstützte Netzwerke:

1. Von Ethereum bis Starknet
2. Von Ethereum Goerli zu Starknet Goerli
3. Vom Ethereum Goerli zum zkSync Era Goerli

Axiom

Axiom bietet Entwicklern eine Möglichkeit, Blockheader, Konto- oder Speicherwerte aus dem gesamten Verlauf von Ethereum abzufragen. AXIOM führt eine neue Methode zur Verknüpfung ein, die auf Kryptographie basiert. Alle von Axiom zurückgegebenen Ergebnisse werden in der Kette durch wissensfreie Beweise überprüft, was bedeutet, dass intelligente Verträge sie ohne zusätzliche Vertrauensannahmen verwenden können.

Axiom hat kürzlich Halo2-repl veröffentlicht, eine browserbasierte Halo2-REPL, die in Javascript geschrieben ist. Dadurch können Entwickler ZK-Schaltkreise nur mit Standard-Javascript schreiben, ohne eine neue Sprache wie Rust lernen, Proof-Bibliotheken installieren oder sich mit Abhängigkeiten befassen zu müssen.

Axiom besteht aus zwei Haupttechnologiekomponenten:

1. AxiomV1 – Ethereum-Blockchain-Cache, beginnend mit Genesis.
2. AxiomV1Query – Ein intelligenter Vertrag, der Abfragen gegen AxiomV1 ausführt.

Block-Hashes in AxiomV1 zwischenspeichern:

AxiomV1-Smart-Verträge speichern Ethereum-Block-Hashes seit dem Genesis-Block in zwei Formen:

Zunächst wird die Keccak-Merkle-Wurzel von 1024 aufeinanderfolgenden Block-Hashes zwischengespeichert. Diese Merkle-Wurzeln werden über ZK-Proofs aktualisiert und verifizieren, dass der Block-Header-Hash eine Commitment-Kette bildet, die mit einem der neuesten 256 Blöcke endet, auf die die EVM direkt zugreifen kann, oder einem Block-Hash, der bereits im AxiomV1-Cache vorhanden ist.

Zweitens speichert Axiom die Merkle-Bergkette dieser Merkle-Wurzeln ab dem Genesis-Block. Das Merkle-Gebirge wird in der Kette aufgebaut, indem der erste Teil des Caches, die Keccak-Merkle-Wurzel, aktualisiert wird.

Führen Sie die Abfrage in AxiomV1Query aus:

Der AxiomV1Query-Smart-Vertrag wird für Batch-Abfragen verwendet, um einen vertrauenswürdigen Zugriff auf historische Ethereum-Blockheader, Konten und beliebige in den Konten gespeicherte Daten zu ermöglichen. Abfragen können in der Kette durchgeführt werden und werden in der Kette über ZK-Proofs gegen zwischengespeicherte Block-Hashes von AxiomV1 abgeschlossen.

Diese ZK-Proofs überprüfen, ob sich die relevanten On-Chain-Daten direkt im Block-Header oder im Konto oder Speicherversuch des Blocks befinden, indem sie den Inklusions- (oder Nicht-Inklusions-)Beweis des Merkle-Patricia-Tries überprüfen.

Nexus

Nexus versucht, mithilfe wissensfreier Beweise eine universelle Plattform für überprüfbares Cloud Computing aufzubauen. Derzeit ist es unabhängig von der Maschinenarchitektur und unterstützt Risiko 5/WebAssembly/EVM. Nexus nutzt das Beweissystem von Supernova. Das Team hat getestet, dass der für die Erstellung des Nachweises erforderliche Speicher 6 GB beträgt. Zukünftig soll es auf dieser Basis so optimiert werden, dass normale Client-Geräte-Computer Beweise erstellen können.

Genauer gesagt ist die Architektur in zwei Teile gegliedert:

1. Nexus Zero: Ein dezentrales, überprüfbares Cloud-Computing-Netzwerk, das auf wissensfreien Beweisen und universellem zkVM basiert.
2. Nexus: Ein dezentrales, überprüfbares Cloud-Computing-Netzwerk, das auf Mehrparteienberechnung, Zustandsmaschinenreplikation und einer universellen virtuellen WASM-Maschine basiert.

Nexus- und Nexus Zero-Anwendungen können in traditionellen Programmiersprachen geschrieben werden, die derzeit Rust unterstützen, weitere Sprachen werden folgen.

Nexus-Anwendungen laufen in einem dezentralen Cloud-Computing-Netzwerk, bei dem es sich im Wesentlichen um eine universelle „serverlose Blockchain“ handelt, die direkt mit Ethereum verbunden ist. Daher erben Nexus-Anwendungen nicht die Sicherheit von Ethereum, erhalten aber im Gegenzug aufgrund der reduzierten Größe ihres Netzwerks Zugriff auf höhere Rechenleistung (z. B. Rechenleistung, Speicherung und ereignisgesteuerte E/A). Nexus-Anwendungen werden in einer dedizierten Cloud ausgeführt, die einen internen Konsens erzielt und durch überprüfbare netzwerkweite Schwellenwertsignaturen innerhalb von Ethereum überprüfbare „Beweise“ der Berechnung (anstelle von echten Beweisen) liefert.

Nexus Zero-Anwendungen erben die Sicherheit von Ethereum, da es sich um universelle Programme mit wissensfreien Beweisen handelt, die in der Kette auf der elliptischen BN-254-Kurve verifiziert werden können.

Da Nexus jede deterministische WASM-Binärdatei in einer replizierten Umgebung ausführen kann, wird erwartet, dass es als Quelle für den Nachweis der Gültigkeit/Dispersion/Fehlertoleranz für generierte Anwendungen verwendet wird, einschließlich ZK-Rollup-Sequenzern, optimistischen Rollup-Sequenzern und anderen Beweisservern. wie zkVM selbst von Nexus Zero.

Haftungsausschluss:

1. Dieser Artikel wurde von [panewslab] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [ABCDE]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen 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, Verbreiten oder Plagiieren der übersetzten Artikel verboten.