TL;DR

Web 2.0-Anwendungen werden häufig als Walled Gardens mit eingeschränkter Dateninteroperabilität betrieben, was zu Benutzerbindung und fragmentierten Identitäten führt. Auf Blockchains aufbauende dezentrale Web3-Anwendungen (dApps) haben das Potenzial, diese Probleme zu überwinden. Allerdings fehlt Smart Contracts, die den Kern von dApps bilden, derzeit eine vertrauensfreie Möglichkeit, auf die riesigen Datenmengen zuzugreifen und diese zu nutzen, die im gesamten Verlauf mehrerer Blockchains gespeichert sind. Um diese Einschränkung zu beheben, stellen wir Ihnen Brevis vor, eine Zero-Knowledge (ZK)-Omnichain-Datenbescheinigungsplattform, die es dApps ermöglicht, auf völlig vertrauensfreie Weise auf beliebige Daten über mehrere Blockchains hinweg zuzugreifen, diese zu berechnen und zu nutzen.

Die Architektur von Brevis besteht aus drei Komponenten: zkFabric, zkQueryNet und zkAggregatorRollup. zkFabric sammelt Blockheader von allen verbundenen Blockchains und generiert Konsensnachweise, die die Gültigkeit dieser Blockheader über ZK Light-Client-Schaltkreise bestätigen. Dies ist wichtig, damit dApps auf vertrauensfreie Weise auf die Blockheader und alle Zustände aller unterstützten Blockchains zugreifen können. zkQueryNet ist ein offener Marktplatz für ZK-Abfrage-Engines, der Datenabfragen von On-Chain-Smart Contracts direkt annehmen und die Abfrageergebnisse und entsprechenden ZK-Abfragenachweise über die ZK-Abfrage-Engine-Schaltkreise generieren kann. Diese Engines reichen von hochspezialisierten, wie z. B. der Berechnung des Handelsvolumens eines DEX während eines bestimmten Zeitraums, bis hin zu hochverallgemeinerten Engines mit Datenindexierungsabstraktionen und hochrangigen Abfragesprachen, die eine Vielzahl von Anwendungsanforderungen erfüllen. zkAggregatorRollup ist ein spezialisiertes ZK-Rollup, das als Aggregations- und Speicherschicht für zkFabric und zkQueryNet fungiert. Es überprüft die Beweise dieser beiden Komponenten, speichert die bestätigten Daten und überträgt seine zk-bestätigten Statuswurzeln an alle verbundenen Blockchains, sodass dApps direkt in der Geschäftslogik ihrer On-Chain-Smart Contracts auf die bestätigten Abfrageergebnisse zugreifen können.

Mit dieser modularisierten Architektur ermöglicht Brevis völlig vertrauensfreien, flexiblen und hocheffizienten Datenzugriff und Rechenfunktionen über alle unterstützten Ketten hinweg für On-Chain-Smart-Contracts. Dies ermöglicht völlig neue Paradigmen für die dApp-Entwicklung. Brevis bietet eine breite Palette von Anwendungsfällen wie datengesteuertes DeFi, zkBridges, On-Chain-Benutzerakquise, zkDIDs, Abstraktion sozialer Konten und vieles mehr.

Im ersten Proof of Concept für Brevis haben wir einige der schnellsten ZK-Light-Client-Schaltkreise als Teile von zkFabric mit Gnark für Ethereum PoS, Cosmos und BNB Chain gebaut, um allen EVM- und Nicht-EVM-Ketten den Zugriff auf die Zustände dieser drei Ketten auf völlig vertrauensfreie Weise zu ermöglichen. Einige der wichtigsten Benchmark-Zahlen zur Schaltkreisleistung sind in Tabelle 1 zusammengefasst (unter Verwendung eines Linux-Servers mit 20 Kernen@2,3 GHz und 384 GB Speicher ohne GPU-Beschleunigung). Unter Verwendung dieser ZK-Light-Client-Schaltkreise haben wir eine benutzerorientierte Asset-zkBridge zwischen Ethereum Goeril und BNB Chain Testnet implementiert, die Benutzer ausprobieren können. [https://zkbridge.brevis.network/]

Für eine ausführlichere Beschreibung von Brevis lesen Sie diesen Blog weiter oder schauen Sie in unser Brevis-Whitepaper, wo Sie umfassendere und technische Details finden. [https://get.celer.app/brevis/BrevisWhitePaper_03211833.pdf]

Web3-dApps verpassen den Wert der Nutzung von Omnichain-Daten

Web 2.0-Anwendungen haben die Benutzerinteraktion und die Inhaltserstellung im Internet revolutioniert. Allerdings werden diese Anwendungen häufig als „Walled Gardens“ betrieben, d. h. Benutzerdaten werden in zentralen Datenbanken gespeichert, die von Plattformanbietern kontrolliert werden. Dies führt zu Herausforderungen wie eingeschränkter Dateninteroperabilität, fragmentierten Identitäten, Abhängigkeit von finanziellen und sozialen Daten und daraus resultierenden Problemen wie Innovationsbehinderung, Abhängigkeit von Anbietern, Datenschutzproblemen und fragmentiertem Benutzererlebnis.

Dezentrale Web3-Anwendungen (dApps) haben das Potenzial, diese Informationssilos aufzubrechen, indem sie auf Blockchains aufgebaut werden, die über einen nur anfügbaren und öffentlich zugänglichen Datenspeicher verfügen. Mit der zunehmenden Multi-Blockchain-Erweiterung und Akzeptanz von dApps haben L1-Blockchains und L2-Rollups eine Fülle von Rohdaten angesammelt, wie z. B. Vermögensübertragungen, Vertragsfunktionsaufrufe, In-Contract-Ereignisse und Blockchain-Statuswurzeln. All diese Daten ermöglichen die Extraktion wertvoller Informationen wie Eigentumsverhältnisse an Vermögenswerten, Benutzeraktivitätsprofile, soziale Diagramme, Finanzverbindungen, Marktpreistrends, Handelsvolumina und vieles mehr.

Viele Off-Chain-Produkte und -Projekte nutzen bereits diese einzigartige Eigenschaft der öffentlich zugänglichen Datenspeicherung. Produkte wie Dune Analytics und Graph bieten Off-Chain-Datenindizierung oder Datenanalyse für Blockchain-Anwendungen im Zeitverlauf. Sie können auch verwendet werden, um Statusdaten bereitzustellen, wie z. B. den Transaktionsverlauf des Benutzers für die Frontend-Benutzeroberflächen von dApps. Diese Anwendungen greifen Off-Chain-basiert auf Blockchain-Daten zu und zeichnen Daten über die RPC-Endpunkte der Blockchain-Knoten auf, indizieren sie und berechnen sie.

Intuitiv sollten On-Chain-Blockchain-Anwendungen oder Smart Contracts problemlos auf diese Omnichain-Dateneinblicke zugreifen und sie in ihrer Geschäftslogik auf völlig vertrauensfreie Weise nutzen können, da alle diese dApps die „nativen Bewohner“ innerhalb der Blockchains sind.

Dies ist jedoch nicht der Fall.

In Wirklichkeit haben Web3-dApps einfach keine Möglichkeit, auf den Großteil der in Blockchains gespeicherten Daten vertrauensfrei zuzugreifen. Das liegt daran, dass Smart Contracts, die auf einer einzigen Blockchain bereitgestellt werden, im Kontext von virtuellen Blockchain-Maschinen existieren und nur auf Daten zugreifen können:

• (1) über explizit definierte Schnittstellen anderer Smart Contracts;

• (2) Das sich auf derselben Blockchain befindet;

• (3) Nur im aktuellsten Stand der Blockchain statt mit einer kompletten historischen Ansicht.

Man könnte argumentieren, dass Lösungen wie das Parsen und Berechnen der Semantik von Datenabfragen direkt in Smart Contracts oder das Validieren von Konsensalgorithmen mit reinen, auf Smart Contracts basierenden, vertrauensfreien Light Clients theoretisch möglich sind. Diese Ansätze sind jedoch aufgrund der hohen On-Chain-Berechnungskosten nicht umsetzbar. Off-Chain-Oracle-Lösungen können verwendet werden, erfordern jedoch zusätzliches Vertrauen in die externe Oracle-Sicherheit für die Datengültigkeit.

Wie können wir also Smart Contracts den Zugriff auf und die Verarbeitung von Daten aus jeder Blockchain über einen beliebigen Zeitraum hinweg ermöglichen?

Zero-Knowledge Succinct Proofs: Die Magie der Computermigration

Die Zero-Knowledge Succinct Proof-Technologie (ZKP) ist ein aufstrebendes Feld in der Kryptographie mit dem Potenzial, unsere digitalen Interaktionen zu verändern. Sie ermöglicht es einer Partei, einer anderen Partei die Gültigkeit einer Berechnung zu beweisen, ohne Informationen über den Eingabewert preiszugeben. Die verifizierende Partei muss lediglich ein rechnerisch kostengünstiges Programm, einen sogenannten Verifier, ausführen, um die Genauigkeit der Berechnung zu bestätigen.

ZKP bietet nicht nur Vorteile für den Datenschutz, sondern ermöglicht auch die Migration von Berechnungen von Standorten mit hohen Kosten pro Einheit zu Standorten mit niedrigen Kosten pro Einheit. Der Beweiser führt eine rechenintensive Operation durch, um die Berechnung abzuschließen und einen kryptografischen Beweis zu generieren, während der Prüfer eine kostengünstigere Operation ausführt, um den Beweis zu validieren. Dieser Prozess verschiebt den Berechnungsort vom Prüfer zum Beweiser, was einen lohnenden Kompromiss darstellt, wenn die Rechenkosten des Beweisers pro Einheit wesentlich niedriger sind als die des Prüfers. Diese Rechenmigrationseigenschaft ist die treibende Kraft hinter vielen ZK-Rollups. Wir werden diese Eigenschaft auch nutzen, um Brevis zu entwickeln.

Übersicht zum Brevis-System 

Wie in Abbildung 1 dargestellt, besteht die Architektur von Brevis aus drei Hauptkomponenten: zkFabric, zkQueryNet und zkAggregatorRollup. zkFabric sammelt Blockheader von allen verbundenen Blockchains und generiert ZK-Konsensnachweise, die die Gültigkeit dieser Blockheader bestätigen. Diese Blockheader werden zusätzlich von zk verifiziert und in zkAggregatorRollup gespeichert. zkQueryNet akzeptiert Datenabfragen von dApps und generiert ZK-Abfragenachweise basierend auf den bestätigten Blockheadern, die in zkAggregatorRollup gespeichert sind. Diese Abfrageergebnisse werden ebenfalls von zk verifiziert und in zkAggregatorRollup gespeichert. Im Wesentlichen ist zkAggregatorRollup ein ZK-Rollup, das als Aggregations- und Speicherschicht für zkFabric und zkQueryNet fungiert. Indem zkAggregatorRollup seine von zk bestätigten Statuswurzeln in alle mit Brevis verbundenen Blockchains einträgt, ermöglicht es dApps, auf bestätigte Abfrageergebnisse zuzugreifen und diese direkt und völlig vertrauensfrei in ihrer On-Chain-Smart-Contract-Logik zu nutzen.

Lassen Sie uns mit diesem umfassenden Überblick im Hinterkopf die einzelnen Komponenten durchgehen.

Erstens müssen dApps, um beliebige Daten über mehrere Blockchains hinweg nutzen zu können, über eine vertrauensfreie Möglichkeit verfügen, auf die Blockheader anderer Blockchains als ihrer nativen Kette zuzugreifen. Dies liegt daran, dass Blockheader Zustandswurzeln enthalten, die zum Zugriff auf die Daten und Zustände der Blockchains verwendet werden können. Um diesen Bedarf zu decken, wird zkFabric eingeführt, um ZK-Konsensnachweise für Blockheader aller unterstützten Ketten zu generieren. Ein Konsensnachweis wird von einem Light-Client-Schaltkreis generiert, der beweist, dass der betreffende Blockheader gemäß der Konsensregel der entsprechenden Blockchain generiert wird. zkFabric selbst ist ein dezentrales System, das aus einem Netzwerk von Blockheader-Relayern und -Provern besteht.

Um tatsächlich wertvolle Informationen aus den zk-bestätigten Blockheadern zu extrahieren, ist zkQueryNet als offener Marktplatz für ZK-Abfrage-Engines aufgebaut, die direkt mit dApp-Entwicklern und Smart Contracts interagieren. Ein dApp-Entwickler kann eine ZK-Abfrage-Engine auswählen, die seinen Anforderungen entspricht, und dann Abfragen über High-Level-APIs in Smart Contracts schreiben.

Zur Laufzeit kann ein Smart Contract den Agent Smart Contract von zkQueryNet aufrufen, der auf eine bestimmte ZK Query Engine abzielt. Diese Abfrage wird von den Prüfern dieser ZK Query Engine übernommen. Mithilfe der bereits von zkFabric bereitgestellten, zk-bestätigten Blockheader kann die ZK Query Engine dann die Abfrageergebnisse berechnen und einen ZK Query Proof generieren, der bestätigt, dass die Berechnung korrekt durchgeführt wurde.

Verschiedene ZK-Abfrage-Engines können sehr unterschiedliche APIs haben, die von verallgemeinerten Abfragesprachen bis zu hochspezifischen Funktionsaufrufen mit einer festen Anzahl von Parametern reichen. Auf der einen Seite des Spektrums kann eine bestimmte ZK-Abfrage-Engine beispielsweise nur eine Funktion bereitstellen, die zwei Blocknummern und zwei Ketten-IDs akzeptiert und den zeitgewichteten Durchschnittspreis für das Paar ETH/USDC während eines bestimmten Zeitraums auf Uniswap für die angegebenen zwei Blockchains zurückgibt. Auf der anderen Seite kann eine verallgemeinerte ZK-Abfrage-Engine Entwicklern eine Blockchain-Indizierungsabstraktion mithilfe von Datenbankabfragen auf hoher Ebene wie SQL oder GraphQL bieten, was sehr ähnlich zu dem ist, was sie in Off-Chain-Datenlösungen wie Dune Analytics und Graph tun können.

Brevis wird eine Reihe von ZK-Abfrage-Engines bereitstellen, die viele unmittelbare Anwendungsfälle mit angemessener Flexibilität und hoher Leistung abdecken. Da zkQueryNet ein offener Marktplatz ist, erwarten wir, dass dApp-Entwickler und andere Dritte andere ZK-Abfrage-Engines bereitstellen, um ein vielfältiges Ökosystem von Anwendungen besser zu bedienen.

Schließlich ist zkAggregatorRollup eine ZK-Rollup-Blockchain, die von einer leichten ZK-VM betrieben wird, die verschiedene Proofs und deren Eingaben von zkQueryNet und zkFabric aggregiert. Insbesondere verfügt die zkAggregatorRollup-VM-Laufzeit über die folgenden Funktionen:

• (1) Überprüfen Sie rekursiv die von zkQueryNet und zkFabric generierten Beweise.

• (2) Speichern Sie die von zk verifizierten Blockheader von zkFabric;

• (3) Speichern Sie Abfragen und die von zk verifizierten Ergebnisse.

Wenn Sie eine ZK Query Engine einbinden oder einen neuen Konsenstyp hinzufügen, wird zkAggregatorRollup erweitert, um die Überprüfung der entsprechenden ZK-Beweise zu unterstützen. Darüber hinaus werden die State-Root-Beweise von zkAggregatorRollup im Gegensatz zu vielen ZK-Rollup-Ketten, bei denen die Beweise für die State-Root-Progression nur einer einzigen Blockchain zugewiesen werden, an alle von Brevis unterstützten Blockchains zugewiesen.

Da die State Roots von zkAggregatorRollup in allen verbundenen Ketten verfügbar sind, können Smart Contracts über Dateneinschlussnachweise auf die Abfrageergebnisse und Blockheader zugreifen. Der Hauptvorteil der Verwendung von zkAggregatorRollup als Aggregationspunkt besteht darin, den Kommunikations- oder Verifizierungsaufwand für Blockheader von O(N^2) auf O(N) zu reduzieren (wobei N die Anzahl der von Brevis unterstützten Blockchains ist) und Abfrageergebnisse bei Bedarf und effizient über alle verbundenen Blockchains hinweg zu teilen.

Zusammenfassend bietet Brevis die folgenden wesentlichen Vorteile:

• Vertrauensfrei: Brevis verlässt sich nicht auf eine externe Partei, die die Integrität von Daten und Berechnungen bestätigt. Stattdessen verlässt es sich ausschließlich auf prägnante ZK-Beweise. Daher müssen Anwendungen, die Brevis verwenden, keine weiteren Vertrauensannahmen akzeptieren als die der zugrunde liegenden Blockchains und kryptografischen Protokolle.

• Omnichain: Brevis lässt sich in mehrere Blockchains integrieren, die auf unterschiedlichen Konsensen laufen, und ermöglicht daher Omnichain-Datenzugriff und -Berechnung.

• Modularisiert: Brevis verwendet in seinem zkQueryNet ein hochmodulares Design und kann daher durch verschiedene Varianten und Implementierungen von ZK Query Engines ein breites Spektrum an Anwendungsanforderungen erfüllen.

• Niedrige Kosten: Brevis‘ zkAggregatorRollup fungiert im Wesentlichen als Batching- und Aggregationsschicht für Blockheader und Abfrageergebnisse. Daher reduziert zkAggregatorRollup die On-Chain-Kosten um Größenordnungen, indem es den sonst N-zu-N-Kommunikationsaufwand beseitigt und die gemeinsame Nutzung von Abfrageergebnissen zwischen Ketten und Anwendungen ermöglicht.

Es ist wichtig zu beachten, dass der Hauptunterschied zwischen Brevis und Off-Chain-Datenindizierungslösungen wie Dune Analytics und Graph darin besteht, dass Brevis zk-bestätigte Abfrageergebnisse generieren kann, die von der Geschäftslogik von On-Chain-Smart Contracts direkt und vertrauensfrei genutzt werden können. Im Vergleich zu Off-Chain-Lösungen, deren Datenergebnisse nur im web2-basierten Datenanalysekontext verwendet werden können.

Eine Beispiel-Komplettlösung

Bevor wir eine breite Palette von Anwendungsfällen besprechen, präsentieren wir ein konkretes Anwendungsbeispiel, um einen Überblick über Brevis zu geben. Beachten Sie, dass dieser Überblick einige wichtige Details abstrahiert. Für weitere Einzelheiten verweisen wir die Leser auf das vollständige Whitepaper.

Dezentrale Börsen (DEXes) mit mehreren Blockchains wie PancakeSwap müssen die Farming-Belohnungen für Anreizpools häufig dynamisch anpassen. Dies erfolgt auf Grundlage von Qualitätsbewertungen der Handelspaare wie durchschnittlichem Tagesvolumen, 14-Tage-Volumen, Preisvolatilität, Anzahl aktiver Händler und Liquiditätsanbietern über alle unterstützten Blockchains hinweg.

Derzeit müssen solche Anpassungen über Governance-Vorschläge vorgenommen werden, die einen erheblichen Personalaufwand erfordern und nur dann durchgeführt werden können, wenn die Rahmenbedingungen stark vom Optimalen abweichen. Dies führt dazu, dass die Dinge hinter den Markttrends zurückbleiben und führt häufig zu einem Rückgang des Benutzerengagements, Umsatzeinbußen und einer Verschwendung von Treasury-Mitteln aufgrund suboptimaler Belohnungskonfigurationen.

Brevis kann diese Herausforderungen bewältigen, indem es DEXes ermöglicht, den Zeitplan für die Liquiditätsbewirtschaftung programmgesteuert und auf vertrauensfreie Weise basierend auf Omnichain-Markttrends anzupassen. Der Einfachheit halber nehmen wir an, dass uns nur das Volumen interessiert. Nehmen wir außerdem an, dass es in zkQueryNet eine ZK Query Engine 𝑄 gibt, die eine Reihe hochoptimierter Schaltkreise für DEX-Volumendaten mit einer API bereitstellt, die wie folgt aussieht:

uint_64 get_trading_volume(uint_64 Ketten-ID,

                            uint_64 Startblock,

                            uint_64 Blockende,

                            Adresspaar)

Abbildung 2 zeigt den schrittweisen Ablauf dieses Anwendungsfalls. Um diese Datenberechnungs-API zu verwenden, muss der DEX-Smart Contract zunächst einen Funktionsaufruf an den Agent Smart Contract (bezeichnet als 𝐴) von zkQueryNet mit den oben angegebenen Abfrageparametern durchführen. Beachten Sie, dass diese Funktion asynchron ist und nur unmittelbar eine 𝑞𝑢𝑒𝑟𝑦_𝑖𝑑 zurückgibt, sodass sich der Smart Contract des DEX diese ID merken muss und über einen Handler verfügt, um den Rückgabewert später zu verarbeiten.

Dieser Funktionsaufruf wird dann vom Beweiser von 𝑄 abgerufen, gekennzeichnet mit 𝑃_𝑞. Unter Verwendung der Blockheader für 𝑐ℎ𝑎𝑖𝑛_𝑖𝑑 (die bereits überprüft und in zkAggregatorRollup gespeichert wurden) generiert 𝑃_𝑞 einen ZK-Beweis 𝜋, der beweist, dass am 𝑐ℎ𝑎𝑖𝑛_𝑖𝑑 im Zeitraum von 𝑠𝑡𝑎𝑟𝑡_𝑏𝑙𝑜𝑐𝑘 bis 𝑒𝑛𝑑_𝑏𝑙𝑜𝑐𝑘 die 𝑡𝑟𝑎𝑑𝑖𝑛𝑔_𝑝𝑎𝑖𝑟 tatsächlich 𝑣𝑜𝑙𝑢𝑚𝑒.

Der Proof-Verifier von 𝑄 in zkAggregatorRollup überprüft 𝜋, dann werden das Ergebnis 𝑣𝑜𝑙𝑢𝑚𝑒 sowie die entsprechenden Abfrageparameter in zkAggregatorRollup gespeichert. Dieser Status wird später in eine Statuswurzel 𝑆 von zkAggregatorRollup aufgenommen und an die Kette übermittelt, in der der DEX bereitgestellt wird.

Jetzt kann 𝐴 das Abfrageergebnis abrufen und überprüfen, indem es einen Statuseinschlussnachweis gegen 𝑆 verwendet. Dieses abgerufene Abfrageergebnis wird dann an die Handlerfunktion des Smart Contracts des DEX zurückgegeben. Die Handlerfunktion kann die gespeicherten 𝑞𝑢𝑒𝑟𝑦_𝑖𝑑 mit dem zurückgegebenen Abfrageergebnis abgleichen und den Zeitplan für die Liquiditätsfarm basierend auf den Volumendaten anpassen.

zkFabric PoC: Ethereum PoS, Cosmos Tendermint, BNB Chain Light Client ZK Circuits und ZK Bridge

Obwohl On-Chain-Light-Client-Lösungen theoretisch das Vertrauen minimieren, sind sie in der Praxis unerschwinglich teuer umzusetzen. Brevis begegnet dieser Herausforderung durch die Kombination von Light-Client-Protokoll und ZKP, wobei zkFabric einen ZK-Konsensnachweis für alle verbundenen Blockchains generiert und die entsprechenden Blockheader in zkAggregatorRollup speichert. Im ersten Proof of Concept von zkFabric implementieren wir Light-Client-Protokolle in den ZK-Schaltkreisen für Ethereum PoS, Cosmos Tendermint und BNB Chain.

• Light-Client für Ethereum PoS. Der Schaltkreis für den Ethereum PoS Light-Client besteht hauptsächlich aus zwei Unterschaltkreisen. Einer ist der SSZ Sync Committee Commitment-Schaltkreis, der das SSZ-Commitment für die 512 aktuellen Validierer im Sync Committee aktualisiert, das alle 27 Stunden rotiert. Der andere ist die aggregierte BLS12-381-Signaturüberprüfung für die 512 Validierer, die hauptsächlich Hash-zu-Kurve-Berechnungen und BLS12-381-Paarungen über das Skalarfeld von BN254 durchführt, damit sie in Ethereum-Smart-Contracts effizient überprüft werden kann. Hier erfordert die nicht-native Paarung ein massives nicht-natives Arithmetikfeld. Indem wir verschiedene Tricks für BLS-Paarungsimplementierungen befolgen und die effizienten Bereichsprüfungsgeräte verwenden, die von Gnark bereitgestellt werden, können wir die beschleunigte BLS12-381-Signaturüberprüfung über das BN254-Skalarfeld im Vergleich zu vorhandenen Implementierungen erreichen. Für die SSZ Sync Committee Commitment-Schaltung arbeiten wir an der Optimierung mithilfe von Nachschlagetabellen und werden bald eine optimierte Schaltung veröffentlichen.

• Light-Client für Cosmos Tendermint und BNB Chain. Die BNB-Kette verwendet eine zweischichtige Architektur, bestehend aus der Basisschicht, die als BNB Beacon Chain (BBC) bezeichnet wird, und der Ausführungsschicht, die als BNB Smart Chain (BSC) bezeichnet wird. Die BBC verwendet den Tendermint-Konsens, während die BSC einen Proof-of-Authority-Konsens (PoA) namens Parli verwendet. Jeder BSC-Block wird von einem der Validierer im Set signiert. Als spezialisierte Tendermint-Anwendung verwaltet die BBC die Wahl und Aktualisierung des BSC-Validierersets. Alle 24 Stunden wird ein neuer Satz BSC-Validierer gewählt und über einen IBC-ähnlichen Cross-Chain-Mechanismus, der der offiziellen IBC-Spezifikation vorausgeht, mit der BSC synchronisiert. Für die BBC (im Wesentlichen Tendermint) umfasst der Light-Client hauptsächlich die Überprüfung einer Reihe von Ed25519-Signaturen, deren direkte Überprüfung in der Kette teuer ist. Wir implementieren die nicht-nativen Ed25519-Signaturüberprüfungen über das BN254-Skalarfeld in Gnark. Mithilfe der Bereichsprüfungsgeräte in Gnark erreichen wir eine hochmoderne Leistung für die nicht-native Ed25519-Signaturüberprüfung. Für BSC umfasst der PoA-Konsens secp256k1-Signaturüberprüfungen, die aufgrund der Existenz von Vorkompilierungen direkt im Smart Contract überprüft werden.

Die oben genannten Schaltkreise sind in Gnark und Open Source implementiert [https://github.com/celer-network/brevis-circuits]. Ihre Benchmark-Leistung ist in Tabelle 1 am Anfang dieses Blogs dargestellt. Beachten Sie, dass wir den Schaltkreis kontinuierlich optimieren und in naher Zukunft auch Hardwarebeschleunigung und Parallelisierung nutzen werden.

Darüber hinaus fallen fast alle bestehenden Interoperabilitätslösungen in das „externe Validierungsmodell“, das Vertrauen in eine vermittelnde Instanz erfordert. Als ersten Schritt haben wir eine Proof-of-Concept-Demo für eine ZK-Brücke zwischen dem Goerli-Testnetz und dem BNB-Chain-Testnetz erstellt, die die Fähigkeiten von Brevis demonstriert. Aufbauend auf den Light Clients haben wir eine bidirektionale Asset-ZK-Brücke zwischen dem Goerli-Testnetz und dem BNB-Chain-Testnetz erstellt. Es ist zu beachten, dass für die Richtung Goerli-zu-BNB die erwartete Brückenverzögerung etwa 25 Minuten beträgt, da der Blockheader, der die Quellketten-TX enthält, erst nach 2-3 Epochen (64-96 Blöcke) als abgeschlossen und weitergeleitet gilt.

Zahlreiche spannende Anwendungsfälle durch Brevis

Abgesehen vom obigen Beispiel einer ZK Bridge ermöglicht Brevis Entwicklern, dApps zu erstellen, die auf Omnichain-Daten über beliebige Zeithorizonte hinweg auf eine Weise zugreifen können, die bisher nicht möglich war. Diese Innovation wird zweifellos ein neues Paradigma etablieren und die Art und Weise verändern, wie dApps in allen Sektoren entwickelt werden. In diesem Abschnitt werden wir einige unmittelbare Anwendungen vorstellen, wir gehen jedoch davon aus, dass die Community noch viele weitere Anwendungsfälle entdecken wird.

Datengesteuertes DeFi

Zusätzlich zu dem zuvor besprochenen Beispiel der automatischen Anpassung der Belohnungen für Liquidity Farming glauben wir, dass datengesteuertes DeFi dank der Skalierbarkeit und Privatsphäre, die es ermöglicht, zu einer breiten Klasse von Anwendungen werden wird, die Brevis nutzen.

Durch vertrauensfreien Zugriff auf umfassende historische und Omnichain-Handelsflüsse können Derivate wie Optionen nun neuartige Ausübungsbedingungen wie den exponentiell zeitgewichteten Preis oder den zeit-volumengewichteten Preis integrieren. Durch verschiedene Implementierungen von ZQEs werden auch alternative Derivate möglich sein, die das Benutzerverhalten, Preistrends, Protokoll- oder Blockchain-TVL-Änderungen, Volatilität, Preiskorrelationen und mehr verfolgen.

On-Chain-Lösungen für aktives Fondsmanagement können ZK-Beweise generieren, die belegen, dass Positionsanpassungen ausschließlich auf spezifischen algorithmischen Modellen basieren, die aus Marktdaten abgeleitet werden, ohne dass unbefugtes menschliches Eingreifen erforderlich ist. Darüber hinaus können aufgrund der datenschutzfreundlichen Eigenschaft von Brevis die genauen Modellparameter verborgen bleiben, um einen Wettbewerbsvorteil auf dem Markt zu erhalten.

Benutzerakquise mit vertrauensfreier Umsatzbeteiligung

Im Web 2.0 endet der Prozess der Benutzerakquise, wenn ein Benutzer herunterlädt oder sich registriert. Die Werbetreibenden zahlen dabei einen Festpreis für alle Benutzer, unabhängig von ihrem Lifetime Value. Diese Regelung ist weder für die Werbetreibenden noch für die Werbekanäle ideal, da erstere den Benutzerwert nicht differenzieren und letztere die langfristigen Einnahmen nicht teilen können. Dieses Problem entsteht, weil die Benutzerdaten nach der Akquise privat und für die Werbekanäle unzugänglich sind.

Web3 könnte dieses Modell möglicherweise ändern, da die meisten Daten zur Benutzeraktivität öffentlich sind. Aktuelle Plattformen folgen jedoch immer noch dem Paradigma von Web 2.0. Brevis revolutioniert dies, indem es Werbekanälen ermöglicht, vertrauensfreie Umsatznachweise für gewonnene Benutzer zu erstellen. Dies wird zu einer grundlegenden Veränderung der Benutzergewinnung im Web 3.0 führen, bei der Werbetreibende nur für hochwertige Benutzer zahlen und Werbekanäle Anreize erhalten, Benutzer optimal mit Werbetreibenden zusammenzubringen.

zkDID

Brevis ist ein unverzichtbares Tool zum Erstellen vertrauensfreier zkDID-Lösungen, das Sybil-Angriffe verhindert und das Benutzerlebenszyklusmanagement in verschiedenen Anwendungsfällen erleichtert. Durch die Generierung von ZK-Beweisen auf der Grundlage schwer zu fälschender On-Chain-Verhaltensweisen ermöglicht Brevis dApp-Entwicklern, völlig vertrauensfrei zu arbeiten und gleichzeitig Sybil-Angriffe in Kampagnen oder Rollouts zu verhindern.

Durch die Nutzung von Abfrageergebnissen und Daten aggregierter Benutzerverhalten kann ein vertrauensfreier Benutzerlebenszyklus-Managementprozess aufgebaut werden, der Treuesysteme, VIP-Händlerprogramme und LiveOps-Kampagnen im Blockchain-Gaming ermöglicht. Brevis bietet gegenüber der In-App-Buchhaltung mehrere Vorteile, wie geringere Kosten, Zukunftssicherheit und Portabilität. Über Brevis generierte zkDIDs werden in zkAggregatorRollup gespeichert und sind somit für verschiedene Anwendungen zugänglich.

Kontoabstraktion

Brevis bietet einen überzeugenden Anwendungsfall in der Kontoabstraktion (AA), indem es die Sicherheit und Benutzerfreundlichkeit in Blockchain-Anwendungen verbessert. Ein wichtiger Vorteil ist die soziale Wiederherstellung, die hilft, den Wallet-Zugriff wiederzuerlangen, selbst wenn der Hauptkontrollschlüssel verloren gegangen ist. Brevis ermöglicht es Smart Wallets, die soziale Wiederherstellung basierend auf aktuellen Transaktionsverbindungen statt auf einem festen Satz externer Wallets zu implementieren. Dieser Ansatz reduziert den Wartungsaufwand und senkt die Eintrittsbarriere für neue Benutzer im Blockchain-Ökosystem.

Brevis hat auch potenzielle Anwendungen in vielen anderen Bereichen wie Social- und NFT-Gaming. Wir ermutigen Entwickler, weitere spannende Anwendungsfälle für Brevis zu erkunden und zu entdecken.