Autor: @Web3_Mario

Zusammenfassung: In letzter Zeit wurde nach neuen Projektrichtungen gesucht, und bei der Produktentwicklung stieß ich auf einen technischen Stack, mit dem ich vorher nicht in Kontakt gekommen war, also habe ich etwas Forschung betrieben und meine Lerninhalte organisiert, um sie mit Ihnen zu teilen. Insgesamt ist zkTLS eine neue Technologie, die Zero-Knowledge-Proofs (ZKP) und TLS (Transport Layer Security Protocol) kombiniert und in der Web3-Umgebung hauptsächlich dazu verwendet wird, die Authentizität der bereitgestellten Off-Chain-HTTPS-Daten ohne Vertrauen in Dritte zu überprüfen. Diese Authentizität umfasst drei Aspekte: Die Datenquelle stammt tatsächlich von einer bestimmten HTTPS-Ressource, die zurückgegebenen Daten wurden nicht manipuliert, und die Aktualität der Daten kann gewährleistet werden. Durch diesen kryptografischen Mechanismus erhalten On-Chain-Smart Contracts die Fähigkeit, vertrauenswürdigen Zugriff auf Off-Chain-Web2-HTTPS-Ressourcen zu erhalten und Dateninseln zu durchbrechen.

Was ist das TLS-Protokoll?

Um den Wert der zkTLS-Technologie besser zu verstehen, ist es sinnvoll, das TLS-Protokoll kurz zu überblicken. Zunächst bietet TLS (Transport Layer Security Protocol) in der Netzwerkkommunikation Verschlüsselung, Authentifizierung und Datenintegrität, um die sichere Übertragung von Daten zwischen dem Client (z. B. Browser) und dem Server (z. B. Webseite) zu gewährleisten. Für diejenigen, die nicht im Bereich der Web-Entwicklung tätig sind, kann auffallen, dass einige Domains mit https und andere mit http beginnen. Bei Zugriff auf Letzteres warnen die gängigsten Browser vor Unsicherheit. Ersteres kann zu Meldungen wie "Ihr Link ist kein privater Link" oder HTTPS-Zertifikatfehler führen. Der Grund für diese Warnungen liegt in der Verfügbarkeit des TLS-Protokolls.

Konkret gesagt, ist das HTTPS-Protokoll eine Erweiterung des HTTP-Protokolls, das auf der Grundlage des TLS-Protokolls die Vertraulichkeit und Integrität der Informationsübertragung gewährleistet und die Authentizität des Servers überprüfbar macht. Wir wissen, dass das HTTP-Protokoll ein unverschlüsseltes Netzwerkprotokoll ist und dieses Protokoll die Authentizität des Servers nicht überprüfen kann, was zu mehreren Sicherheitsproblemen führt:

1. Die Informationen, die Sie an den Server übermitteln, könnten von Dritten abgehört werden, was zu Datenschutzverletzungen führen könnte;

2. Sie können die Authentizität des Servers nicht überprüfen, d. h. ob Ihre Anfrage von anderen böswilligen Knoten abgefangen wurde und böswillige Informationen zurückgegeben wurden;

3. Sie können die Integrität der zurückgegebenen Informationen nicht überprüfen, d. h. ob aufgrund von Netzwerkproblemen Daten verloren gegangen sind;

Das TLS-Protokoll wurde genau zu diesem Zweck entwickelt, um diese Probleme zu lösen. An dieser Stelle sei erklärt, dass einige von Ihnen möglicherweise das SSL-Protokoll kennen. Tatsächlich wurde das TLS-Protokoll auf der Grundlage der SSL-Version 3.1 entwickelt. Aufgrund einiger geschäftlicher Probleme wurde der Name geändert, aber es ist im Grunde dasselbe. Daher sind manchmal in bestimmten Kontexten die beiden Begriffe austauschbar.

Das Hauptkonzept des TLS-Protokolls zur Lösung der oben genannten Probleme ist:

1. Verschlüsselte Kommunikation: Verwendung von symmetrischer Verschlüsselung (AES, ChaCha20), um Daten zu schützen und Abhörversuche zu verhindern.

2. Identitätsprüfung: Überprüfung der Identität des Servers durch digitale Zertifikate (z. B. X.509-Zertifikate), die von Dritten ausgestellt werden, um Man-in-the-Middle-Angriffe (MITM) zu verhindern.

3. Datenintegrität: Verwendung von HMAC (Hash-basierter Nachrichtenauthentifizierungscode) oder AEAD (authentifizierte Verschlüsselung), um sicherzustellen, dass die Daten nicht manipuliert wurden.

Lassen Sie uns einfach die technischen Einzelheiten des HTTPS-Protokolls basierend auf dem TLS-Protokoll im Dateninteraktionsprozess erklären. Der gesamte Prozess ist in zwei Phasen unterteilt: Zunächst die Handshake-Phase, in der der Client und der Server Sicherheitsparameter aushandeln und eine verschlüsselte Sitzung aufbauen. Dann die Datenübertragungsphase, in der der Sitzungsschlüssel für die verschlüsselte Kommunikation verwendet wird. Der genaue Ablauf gliedert sich in vier Schritte:

1. Der Client sendet ClientHello:

Der Client (z. B. der Browser) sendet eine ClientHello-Nachricht an den Server, die Folgendes enthält:

• Unterstützte TLS-Versionen (z. B. TLS 1.3)

• Unterstützte Verschlüsselungsalgorithmen (Cipher Suites, wie AES-GCM, ChaCha20)

• Zufallszahl (Client Random) (für die Schlüsselgenerierung)

• Schlüsselteilungsparameter (z. B. ECDHE-Öffentlichkeitsschlüssel)

• SNI (Server Name Indication) (optional, zur Unterstützung von Multi-Domain-HTTPS)
  

Ziel ist es, dem Server die Verschlüsselungsfähigkeiten des Clients mitzuteilen und die Sicherheitsparameter vorzubereiten.

2. Der Server sendet ServerHello:

Der Server antwortet mit einer ServerHello-Nachricht, die Folgendes enthält:

• Ausgewählte Verschlüsselungsalgorithmen

• Server-Zufallszahl (Server Random)

• Zertifikat des Servers (X.509-Zertifikat)

• Schlüsselteilungsparameter des Servers (z. B. ECDHE-Öffentlichkeitsschlüssel)

• Fertig Nachrichten (um den Abschluss des Handshakes zu bestätigen)
  

Ziel ist es, dass der Client die Identität des Servers kennt und die Sicherheitsparameter bestätigt.

3. Der Client überprüft den Server:

Der Client führt die folgenden Aktionen durch:

• Überprüfung des Serverzertifikats: Sicherstellen, dass das Zertifikat von einer vertrauenswürdigen CA (Zertifizierungsstelle) ausgestellt wurde und überprüfen, ob das Zertifikat abgelaufen oder widerrufen wurde;

• Berechnung des gemeinsamen Schlüssels: Verwendung des eigenen und des Server-ECDHE-Öffentlichkeitsschlüssels zur Berechnung des Sitzungsschlüssels, der für die symmetrische Verschlüsselung der nachfolgenden Kommunikation (z. B. AES-GCM) verwendet wird.

• Senden Sie die Finished-Nachricht: Bestätigung der Integrität der Handshake-Daten zur Verhinderung von Man-in-the-Middle-Angriffen (MITM).
  

Ziel ist es, sicherzustellen, dass der Server vertrauenswürdig ist und den Sitzungsschlüssel zu generieren.

4. Beginn der verschlüsselten Kommunikation:

Der Client und der Server verwenden nun den ausgehandelten Sitzungsschlüssel für die verschlüsselte Kommunikation.

• Verwendung von symmetrischer Verschlüsselung (z. B. AES-GCM, ChaCha20) zum Schutz der Daten, um Geschwindigkeit und Sicherheit zu erhöhen.

• Schutz der Datenintegrität: Verwendung von AEAD (z. B. AES-GCM) zur Verhinderung von Manipulationen.

  
  

Nach diesen vier Schritten können die Probleme des HTTP-Protokolls effektiv gelöst werden. Diese grundlegende Technologie, die im Web2-Netzwerk weit verbreitet ist, hat jedoch die Entwicklung von Web3-Anwendungen behindert, insbesondere wenn On-Chain-Smart Contracts auf bestimmte Off-Chain-Daten zugreifen möchten. Aufgrund von Verfügbarkeitsproblemen wird die On-Chain-VM keine externen Datenabrufmöglichkeiten öffnen, um die Rückverfolgbarkeit aller Daten sicherzustellen und somit die Sicherheit des Konsensmechanismus zu gewährleisten.

Nach einer Reihe von Iterationen stellten Entwickler jedoch fest, dass DApps weiterhin Bedarf an Off-Chain-Daten haben, was zur Entstehung einer Reihe von Oracle-Projekten wie Chainlink und Pyth führte. Sie fungieren als Brücke zwischen On-Chain-Daten und Off-Chain-Daten, um das Phänomen der Dateninseln zu durchbrechen. Um die Verfügbarkeit der übermittelten Daten zu gewährleisten, setzen diese Oracles in der Regel auf den PoS-Konsensmechanismus, um sicherzustellen, dass die Kosten für böswilliges Verhalten der Relaisknoten höher sind als der Nutzen, sodass sie aus wirtschaftlicher Sicht keine falschen Informationen an die Chain weitergeben. Wenn wir beispielsweise im Smart Contract den gewichteten Preis von BTC an zentralen Börsen wie Binance oder Coinbase abrufen möchten, sind wir auf diese Oracles angewiesen, um die Daten Off-Chain zu aggregieren und sie dann in den On-Chain-Smart Contract zu übertragen, damit wir sie verwenden können.

Was löst zkTLS?

Es wurde jedoch festgestellt, dass dieses auf Oracle basierende Datenbeschaffungsmodell zwei Probleme aufweist:

1. Zu hohe Kosten: Wir wissen, dass um sicherzustellen, dass die von Oracle an die Chain übermittelten Daten echte, nicht manipulierte Daten sind, das PoS-Konsensmechanismus erforderlich ist. Die Sicherheit des PoS-Konsensmechanismus basiert jedoch auf der Menge der gestakten Mittel, was zu Kosten für die Wartung führt. Außerdem gibt es in der Regel im PoS-Konsensmechanismus viel Redundanz bei der Datenübertragung, da Datensätze im Netzwerk häufig wiederholt übertragen, berechnet und zusammengefasst werden müssen, um durch Konsens zu gelangen, was die Kosten für die Datennutzung ebenfalls erhöht. Daher neigen Oracle-Projekte in der Regel dazu, um Kunden zu gewinnen, nur die gängigsten Daten kostenlos zu warten, wie z. B. BTC-Preise, während für spezielle Anforderungen Gebühren gezahlt werden müssen. Dies behindert die Innovationsfähigkeit in der Anwendung, insbesondere für einige langfristige, maßgeschneiderte Anforderungen.

2. Zu geringe Effizienz: In der Regel benötigt der Konsensmechanismus von PoS eine gewisse Zeit, was zu einer Verzögerung der On-Chain-Daten führt, was für einige hochfrequente Nutzungsszenarien nachteilig ist, da die On-Chain-Daten erhebliche Verzögerungen im Vergleich zu den tatsächlichen Off-Chain-Daten aufweisen.

Um die oben genannten Probleme zu lösen, wurde die zkTLS-Technologie geboren. Ihr Hauptansatz besteht darin, durch die Einführung des ZKP-Zero-Knowledge-Proof-Algorithmus zu ermöglichen, dass On-Chain-Smart Contracts als Dritte direkt die von einem Knoten bereitgestellten Daten überprüfen können, dass diese Daten tatsächlich von einer bestimmten HTTPS-Ressource stammen und nicht manipuliert wurden. Dadurch können die hohen Nutzungskosten traditioneller Oracles, die durch Konsensalgorithmen entstehen, vermieden werden.

Einige von Ihnen fragen sich vielleicht, warum nicht einfach die Fähigkeit zur direkten Web2-API-Aufruf im On-Chain-VM-Umfeld integriert wurde. Die Antwort ist, dass dies nicht möglich ist, da die Notwendigkeit, eine geschlossene Datenumgebung aufrechtzuerhalten, um die Rückverfolgbarkeit aller Daten zu gewährleisten, darin besteht, dass alle Knoten während des Konsensprozesses eine einheitliche Bewertungslogik für bestimmte Daten oder Ergebnisse haben, oder man könnte sagen, eine objektive Validierungslogik. Dies stellt sicher, dass in einer völlig dezentralisierten Umgebung die meisten wohlmeinenden Knoten auf ihre redundanten Daten verlassen können, um die Wahrheit des Ergebnisses zu bestimmen. Da jedoch Web2-Daten, aufgrund von Netzwerkverzögerungen, die unterschiedliche Ergebnisse bei verschiedenen Knoten zu erhalten, schwer eine solche einheitliche Bewertungslogik aufzubauen ist, erschwert dies den Konsens, insbesondere in einigen hochfrequenten Datenbereichen. Darüber hinaus gibt es ein weiteres entscheidendes Problem: Die Sicherheit des TLS-Protokolls, auf dem HTTPS basiert, hängt von der vom Client generierten Zufallszahl (Client Random) (für die Schlüsselgenerierung) und den Schlüsselteilungsparametern ab, um die Verhandlungen über den Verschlüsselungsschlüssel mit dem Server zu ermöglichen. Wir wissen jedoch, dass die On-Chain-Umgebung transparent ist; wenn Smart Contracts die Zufallszahl und die Schlüsselteilungsparameter verwalten, werden kritische Daten offengelegt, was die Datenprivatsphäre gefährdet.

Das zkTLS hingegen nutzt einen anderen Ansatz. Die Idee besteht darin, durch kryptografischen Schutz die hohen Kosten der Verfügbarkeit von Daten zu ersetzen, die durch traditionelle Oracles auf Basis von Konsensmechanismen entstehen. Dies ähnelt der Optimierung von ZK-Rollup über OP-Rollup in L2. Konkret gesagt, wird durch die Einführung von ZKP-Zero-Knowledge-Proofs und die Berechnung von Proofs durch die Anforderung bestimmter HTTPS-Ressourcen, relevanter CA-Zertifikatsvalidierungsinformationen, Zeitstempel und Datenintegritätsnachweise, die auf HMAC oder AEAD basieren, die notwendigen Validierungsinformationen und -algorithmen auf der Chain aufrechterhalten, sodass Smart Contracts die Authentizität, Aktualität und Zuverlässigkeit der Datenquelle validieren können, ohne kritische Informationen offenzulegen. Die genauen Details der Algorithmen werden hier nicht diskutiert; interessierte Leute können selbst tiefergehende Studien durchführen.

Der größte Vorteil dieser technischen Lösung besteht darin, die Kosten für die Verfügbarkeit von Web2-HTTPS-Ressourcen zu senken. Dies hat viele neue Anforderungen geweckt, insbesondere in Bezug auf die Senkung der On-Chain-Preiserfassung für Long-Tail-Assets, die Nutzung von autoritativen Websites aus der Web2-Welt für On-Chain-KYC, was die technische Architektur von DID und Web3-Spielen optimiert. Natürlich lässt sich erkennen, dass zkTLS auch Auswirkungen auf bestehende Web3-Unternehmen hat, insbesondere auf die derzeit führenden Oracle-Projekte. Um diesen Herausforderungen zu begegnen, verfolgen Branchengrößen wie Chainlink und Pyth aktiv Forschungen in verwandten Richtungen, um im technischen Evolutionsprozess weiterhin eine führende Rolle zu spielen und gleichzeitig neue Geschäftsmodelle zu schaffen, wie z. B. den Übergang von zeitbasierten Gebühren zu nutzungsbasierten Gebühren oder Compute as a service. Natürlich besteht hier, wie bei den meisten ZK-Projekten, die Herausforderung darin, die Rechenkosten zu senken, um kommerziellen Wert zu schaffen.

Zusammenfassend lässt sich sagen, dass Sie bei der Produktgestaltung auch die Entwicklungen von zkTLS im Auge behalten und diese Technologie in geeigneten Bereichen integrieren können. Möglicherweise finden Sie neue Ansätze für Geschäftsinovationen und technische Architekturen.