0. Einleitung

Web3 hat den Wert von Daten verändert, aber die verteilte Struktur der Blockchain ist ein geschlossenes deterministisches System, und Smart Contracts implementieren nicht die Funktion externer API-Aufrufe. Daher wurde der Oracle-Mechanismus geboren, um Smart Contracts beim Abrufen externer Daten zu unterstützen .

Es ist nicht schwierig, Daten außerhalb der Kette in die Kette hochzuladen. Schwierig ist es, durch Technologie und Mechanismen Vertrauen zu schaffen und zu erzeugen. Das Oracle-Problem erfordert die Lösung des Vertrauensproblems von der Datenquelle über die Verarbeitung bis hin zur Preiseingabe.

Eine Grundvoraussetzung dafür, ein öffentlich anerkanntes Orakel zu werden, ist die Dezentralisierung, das heißt, ob Single Points of Failure und Datenüberprüfung zulässig sind. Eine gängige Lösung für die Kettendezentralisierung besteht darin, mehrere Datenknoten zu verwenden, um ein dezentrales Orakelnetzwerk zu bilden. Jeder Knoten sammelt Daten und gibt sie nach Erreichen eines Konsenses in einen Smart Contract auf der Blockchain ein.

 

Chainlink-Architektur

Der derzeitige Hauptzweck von Orakeln besteht darin, Preis-Feeds für DeFi bereitzustellen und den Preis der zugrunde liegenden Vermögenswerte sicher, zeitnah und genau zu aktualisieren. Laut DefiLlama-Daten ist Chainlink eine der größten Oracle-Lösungen auf dem Markt, mit einem garantierten Gesamtwert von etwa 11 Milliarden US-Dollar zum Zeitpunkt des Schreibens, was 46 % des Gesamtmarktes ausmacht.

 

Oracle-Marktdaten

Mit der Entwicklung der Blockchain wird die Nachfrage nach Off-Chain-Daten immer stärker. Die bloße Bereitstellung von Preisen für DeFi kann den Bedürfnissen der Entwickler nicht mehr gerecht werden. Die überwiegende Mehrheit der Daten in der realen Welt und im Web2 ist nicht öffentlich zugänglich, es ist jedoch notwendig, innovative Web3-Anwendungsszenarien zu erstellen (Kreditvergabe, soziale Netzwerke, DID, KYC/AML usw.). Eine neue Generation von Orakeln muss es daher ermöglichen, dass intelligente Verträge komplexe Anwendungsfälle mit sensiblen Daten auf datenschutzfreundliche Weise unterstützen.

DECO ist die Lösung von Chainlink in dieser Richtung und nutzt Zero-Knowledge-Proof-Technologie, um Benutzern die Generierung privater Off-Chain-Datennachweise für Smart Contracts zu ermöglichen, ohne die Daten der Öffentlichkeit oder dem Oracle-Knoten selbst preiszugeben. DECO kann in bestehende APIs eingebunden werden und erfordert keine Änderungen durch den API-Datenanbieter, selbst wenn eine Endbenutzerauthentifizierung erforderlich ist (z. B. erfordert das Abrufen eines Bankkontostands eine Anmeldung). Es hat nun das Alpha-Stadium erreicht und testet den Proof-of-Concept mit mehreren Partnern.

1. Hintergrund

Hier werden die notwendigen Hintergrundinformationen zu TLS und ZKP bereitgestellt, und DECO basiert auf diesen Protokollen.

1.1 TLS

TLS (Transport Layer Security) ist ein leistungsstarkes, weit verbreitetes Sicherheitsprotokoll, früher SSL, das den Datenschutz und die Datensicherheit der Internetkommunikation fördern soll und sich auf der Anwendungsprotokollebene und der TCP/IP-Ebene befindet. Der Hauptanwendungsfall ist unter anderem Verschlüsseln Sie die Kommunikation zwischen Webanwendungen und Servern.

Die Kommunikation über HTTP erfolgt im Klartext und ist anfällig für Abhören, Manipulation und Identitätsdiebstahl. Mit TLS werden die HTTP-Daten, die Benutzer an die Website senden (klicken, ein Formular ausfüllen usw.) und die HTTP-Daten, die die Website an den Benutzer sendet, verschlüsselt, und der Empfänger muss einen Schlüssel verwenden, um die verschlüsselten Daten zu entschlüsseln. HTTPS implementiert die TLS-Verschlüsselung auf Basis des HTTP-Protokolls und ist eine Standardpraxis für Websites. Websites müssen ein TLS-Zertifikat auf ihrem Quellserver installieren und Browser markieren alle Nicht-HTTPS-Websites als unsicher.

 

Nicht-HTTPS-Website

Die Grundidee von TLS besteht darin, eine Verschlüsselung mit öffentlichem Schlüssel zu verwenden. Das von der Website öffentlich geteilte TLS/SSL-Zertifikat enthält den öffentlichen Schlüssel, und der private Schlüssel ist auf dem Quellserver installiert und gehört der Website. Der Client fragt zunächst den Server nach dem öffentlichen Schlüssel des digitalen Zertifikats und verwendet dann den öffentlichen Schlüssel zum Verschlüsseln der Informationen. Nachdem der Server den Chiffretext empfangen hat, verwendet er seinen eigenen privaten Schlüssel, um ihn zu entschlüsseln.

Hier liegt ein Problem vor, das zu viele Berechnungen erfordert. Um die von der Sitzung benötigte Zeit zu reduzieren, generieren Client und Server für jede Sitzung einen „Sitzungsschlüssel“ und verwenden ihn zum Verschlüsseln von Informationen. Da der „Sitzungsschlüssel“ symmetrisch verschlüsselt ist, ist die Vorgangsgeschwindigkeit sehr hoch und der öffentliche Schlüssel des Servers wird nur zum Verschlüsseln des „Sitzungsschlüssels“ selbst verwendet, wodurch der Zeitaufwand für den Verschlüsselungsvorgang reduziert wird.

Daher kann das TLS-Protokoll hauptsächlich in zwei Schichten unterteilt werden:

  1. Handshake-Protokoll für die Aushandlung des Authentifizierungsschlüssels: Klartextkommunikation, gegenseitige Bestätigung durch asymmetrische Verschlüsselung, gegenseitige Verifizierung, Festlegung des zu verwendenden Verschlüsselungsalgorithmus und Generierung eines konsistenten Sitzungsschlüssels zur Aufzeichnung der symmetrischen Verschlüsselung der Vereinbarung

  2. Aufzeichnungsprotokoll für symmetrisch verschlüsselte Übertragung: Der Hauptteil des Protokolls, der die Vertraulichkeit und Integrität der Datenübertragung schützt.

 

TLS-Protokollstapel

Die TLS-Verschlüsselungssuite (CipherSuite) ist eine Kombination aus 4 Algorithmen:

  1. Authentifizierung: Bestimmen Sie die Authentizität der Identität. Die gängigsten sind RSA/DSA/ECDSA

  2. Schlüsselaustausch: Die kommunizierenden Parteien handeln den für die Verschlüsselung verwendeten Schlüssel aus. Der gängige Schlüssel ist ECDHE.

  3. Verschlüsselung: Symmetrische Verschlüsselung für die Kommunikation, der Trend geht zur Verwendung von GCM

  4. MAC (Message Authentication Code, Message Authentication Code): Wird verwendet, um die Datenintegrität zu überprüfen und festzustellen, ob die Daten manipuliert wurden. Zu den gängigen Codes gehören SHA256/SHA384/SHA1 usw.

TLS ist sehr leistungsfähig, weist jedoch eine Einschränkung auf: Es ermöglicht dem Benutzer nicht, gegenüber Dritten nachzuweisen, dass die Daten, auf die er zugreift, tatsächlich von einer bestimmten Website stammen gleiche Fähigkeit, die Daten zu signieren. Ein intuitives Beispiel ist, dass Alices Identitätsinformationen auf den Servern vieler Websites gespeichert sind. Es lässt sich leicht überprüfen, dass Alice über 18 Jahre alt ist, aber es ist für Alice schwierig, dies gegenüber Bob zu beweisen. Alice könnte einen Screenshot von der Website machen, aber Screenshots können leicht gefälscht werden, und selbst wenn sich der Screenshot als authentisch erweisen könnte, würde er Informationen preisgeben – Alices genaues Geburtsdatum, nicht nur die Tatsache, dass sie über 18 Jahre alt ist.

Die Oracle-Maschine muss dezentralisiert sein (und nicht auf einen einzigen Punkt wie einen Website-Server angewiesen sein), um die Herkunft privater Daten außerhalb der Kette nachzuweisen und von intelligenten Verträgen verwendet zu werden, ohne dass die Privatsphäre verloren geht. Wissensfreie Beweise können dabei helfen, diese Funktionen zu erreichen.

1,2 CPC

Zero Knowledge Proof (ZKP) hat in der Blockchain große Aufmerksamkeit erhalten, und seine Hauptanwendungen sind ZK-Rollup (im Algorithmusdesign wurden viele Kompromisse gemacht, um die Erweiterungseffizienz zu verbessern, ohne den Validity Proof von ZK) und Datenschutztechnologie (echt zk). Der wissensfreie Beweis ermöglicht es dem Prüfer, dem Prüfer zu beweisen, dass er über eine Lösung (Witness) verfügt, die ein bestimmtes Rechenproblem (Statement) lösen kann, ohne zusätzliche Informationen über die Lösung preiszugeben (Witness).

Ein typisches ZK-System kann in Front-End und Back-End unterteilt werden.

  1. Front-End: Compiler, der die zu verifizierende Anweisung in eine domänenspezifische Sprache (DSL) schreibt und sie dann in ein ZK-freundliches Format, z. B. arithmetische Schaltkreise, kompiliert;

  2. Backend: Beweissystem, interaktives Demonstrationssystem, das die Korrektheit der Schaltung überprüft, wie Marlin, Plonky2, Halo2;

 

ZK-System

Der Prozess der Erstellung interaktiver Fragen auf einem offenen System wie der Blockchain ist sehr kompliziert. Der Beweis muss jederzeit von jedem überprüft werden. Daher ist das ZK-System in der Regel nicht interaktiv Wird für die interaktive heuristische Konvertierung in nicht interaktiv verwendet.

2. Wie DECO funktioniert

DECO wurde auf Basis des HTTPS/TLS-Protokolls erweitert, so dass der Server ohne Modifikationen genutzt werden kann.

Die Kernidee von DECO besteht darin, ein neuartiges Drei-Parteien-Handshake-Protokoll zwischen Prover (Benutzer oder Dapp, auf dem DECO Prover ausgeführt wird), Verifier (Chainlink-Orakel, auf dem DECO Verifier ausgeführt wird) und Server (Datenanbieter) zu erstellen.

  • Herkunft: Wenn Prover Informationen vom Webserver abfragt, beobachtet Verifier den Interaktionsprozess und empfängt eine von Prover erstellte Verpflichtung zu den TLS-Sitzungsdaten, damit Verifier die wahre Quelle der Informationen überprüfen kann;

  • Datenschutz: Wenn für die Daten kein Datenschutz erforderlich ist, kann Prover den Schlüssel, der die Daten entschlüsseln kann, direkt an Verifier bereitstellen, damit Entwickler Daten zu Dapp hinzufügen können. Wenn Datenschutz erforderlich ist, verwendet Prover ZKP, um Beweise zu generieren, die keine Daten für Entwickler preisgeben zu Dapp hinzufügen.

 

DECO Beispiel

Konkret besteht das DECO-Protokoll aus drei Phasen:

  1. Drei-Parteien-Handshake: Prover, Verifier und Server erstellen einen Sitzungsschlüssel in einem speziellen Format, um sicherzustellen, dass die Daten nicht gefälscht werden können.

  2. Bei der Abfrageausführung verwendet Prover Query mit ihren privaten Parametern θs (z. B. Kontopasswort, API-Schlüssel), um Daten vom Server abzufragen.

  3. Bei der Beweiserstellung beweist Prover, dass die Antwort die erforderlichen Bedingungen erfüllt.

 

DECO Architektur

2.1 Drei-Parteien-Handshake

Hinweis: Die folgenden Anweisungen basieren auf dem AES-CBC-HMAC-Verschlüsselungsalgorithmus. TLS 1.3 behält nur den sichereren AEAD als Verschlüsselungsalgorithmus bei und verwendet einen Schlüssel für die Verschlüsselung und einen MAC. Es ist kein MAC-Schlüssel erforderlich. Aufgrund der Schlüsselunabhängigkeit von TLS 1.3 kann jedoch auch ein Drei-Parteien-Handshake-Protokoll mit ähnlicher Komplexität aufgebaut werden.

Nach Erhalt des MAC-Schlüssels kann Prover P keine Verpflichtung eingehen, da er sonst die Daten fälschen oder manipulieren kann. Daher besteht die Idee des Drei-Parteien-Handshakes darin, Prover P und Verifier V als TLS-Clients zu verwenden, um einen gemeinsamen MAC einzurichten Schlüssel mit TLS-Server S . Der MAC-Schlüssel k wird auf der Clientseite aufgeteilt, der Prover hält kp und der Verifier hält kv, k=kp+kv. Gleichzeitig enthält P auch den Verschlüsselungsschlüssel k^{Enc}, der für den symmetrischen Verschlüsselungsalgorithmus verwendet wird. Wenn der Verifizierer nichts Böses tut, kann das Drei-Parteien-Handshake-Protokoll sicherstellen, dass die Daten fälschungssicher sind.

2.2 Abfrageausführung

Da der MAC-Schlüssel nach dem Handshake heimlich geteilt wird, führen P und V ein interaktives Protokoll aus (sichere Zwei-Parteien-Berechnung) und verwenden die privaten Parameter θs, um eine verschlüsselte Abfrage-TLS-Nachricht Abfrage Q zu erstellen. Dann fungiert P als Standard-TLS-Client und sendet Q an S. In diesem Prozess kommuniziert nur P mit S, und von ihm gesendete Abfragen können nicht an V weitergegeben werden.

Nach Erhalt der Antwort R von S verpflichtet sich P zur Sitzung, indem es den Chiffretext Rˆ an V sendet und den kv von V empfängt, um die Authentizität der Antwort R zu überprüfen.

2.3 Nachweiserstellung

Als nächstes muss P beweisen, dass der Klartext R, der dem Chiffretext Rˆ entspricht, bestimmte Attribute erfüllt. Wenn keine Privatsphäre erforderlich ist, kann der Verschlüsselungsschlüssel k^{Enc} direkt offengelegt werden. Wenn Privatsphäre erforderlich ist, muss ein Zero-Knowledge-Beweis erfolgen gebraucht.

Wenn der Klartext aus mehreren Datenblöcken R=(B1,...,Bn) besteht, verwendet DECO Selective Opening, um einen wissensfreien Beweis zu generieren:

  • Zeigen Sie nur bestimmte Datenzeilen an: Beweisen Sie, dass der i-te Datenblock von R Bi ist, ohne andere Datenblöcke preiszugeben

  • Datenzeilen mit privaten Daten ausblenden: Beweisen Sie, dass R_{-i} und R gleich sind, außer dass Bi gelöscht wird

 

Allerdings muss Verifier oft überprüfen, ob die angezeigte Teilzeichenfolge im richtigen Kontext erscheint, und die oben genannten Methoden reichen nicht aus, um den Kontextintegritätsschutz zu gewährleisten. Um dies zu kompensieren, nutzt DECO eine Technologie namens Zero-Knowledge-Zwei-Stufen-Parsing: Prover analysiert seine Sitzungsdaten lokal, ermittelt den kleinsten Teilstring, der Verifier überzeugen kann, und sendet die Daten dann an Verifier. Privatsphäre wird somit gewährleistet.

Saubere, nicht interaktive (NIZK) Zero-Knowledge-Proofs verursachen auf der Beweiserseite in der Regel einen hohen Rechen- und Speicheraufwand. Da der von DECO durchgeführte ZKP-Verifizierer spezifiziert ist (Orakel von Chainlink), können effizientere interaktive Zero-Knowledge-Beweise verwendet werden, wie z. B. geringere Speichernutzung, Vermeidung vertrauenswürdiger Einstellungen, kostengünstige Berechnungen usw.

Im aktuellen Alpha-Test verwendet DECO weiterhin Dapp als Prover. In zukünftigen Iterationen ist geplant, dass Prover lokal von Endbenutzern (z. B. Mobiltelefonen) oder in einer Trusted Execution Environment (TEE) bereitgestellt werden kann.

3. Anwendung

DECO kann die Gültigkeit der Off-Chain-Identitätsinformationen der Benutzer überprüfen und gleichzeitig den Datenschutz gewährleisten, wodurch viele innovative Web3-Anwendungsszenarien erschlossen werden, von wirtschaftlich bis sozial.

  • Selbstgehosteter Social-Recovery-/Rechtsidentitätsnachweis (Wer sind Sie): Nutzen Sie mit DECO institutionelle Websites (Banken, soziale Medien), die bereits über ausgereifte Authentifizierungsmechanismen verfügen, um als einer der Hüter des Social-Recovery zu fungieren.

 

  • Kreditvergabe/Fondsnachweis (wie viel Geld Sie haben): Teller ist ein DeFi-Kreditvergabeprotokoll, das das DECO-Protokoll verwendet, um nachzuweisen, dass der Vermögenssaldo des Benutzers auf dem Off-Chain-Bankkonto den für Kredite erforderlichen dynamischen Mindestschwellenwert überschreitet.

 

  • Follower Proof/Interaction Proof (mit wem Sie interagiert haben): Clique ist ein soziales Orakel, das eine Lösung entwickelt, die Off-Chain-Benutzereinfluss, Loyalität über verschiedene Social-Media-Plattformen hinweg (z. B. mithilfe der Twitter-API) und eine detaillierte Analyse von Beiträgen bietet.

  • Digitaler Identitäts-/sozialer Identitätsnachweis (Sie haben ein Online-Konto): PhotoChromic ist eine digitale Identitätslösung, die Web3-Benutzer mithilfe von DECO an ihre sozialen Twitter- oder Discord-Konten bindet, ohne dabei die zugrunde liegenden personenbezogenen Daten offenzulegen. Anwendungen können dabei echte herausfiltern Benutzer.

  • DAOs Widerstand gegen Sybil-Angriffe, SBT, KYC/AML usw.

4. Andere Spieler

  • Axiom erstellt ein ZK-Orakel für Uniswap TWAP und nutzt dabei überprüfbare Datenquellen, die vollständig aus der Kette stammen und eher der Indexierung ähneln (z. B. Hyper Oracle). -Chain-Orakel sind eine Richtung; immer mehr Off-Chain-Daten müssen in die Kette hochgeladen werden, und Off-Chain-Datenschutzorakel sind ebenfalls eine Richtung.

  • Empiric Network verwendet ZK-Computing, um das gesamte Oracle in die Kette einzubinden. Es gibt keine Off-Chain-Infrastruktur, durch die Daten fließen müssen. Es erfolgt nicht in die gleiche Richtung wie bei DECO.

4. Fazit

Chainlink ist der absolute Marktführer bei aktuellen Orakeln. Unter der Prämisse des Datenschutzes werden umfangreiche Off-Chain-Privatdaten von On-Chain-Smart Contracts abgerufen, die viele Anwendungsszenarien von Finanzen über Identität bis hin zu sozialen Netzwerken erschließen können. Mögliche Risiken sind die Geschwindigkeit der Beweiserstellung durch Prover und die Zentralisierungsprobleme von Verifier.