Midnight Hackathon Projekte demonstrieren private Webdaten und Prüfung von Berechtigungsnachweisen

Entwickler vom Midnight Hackathon in Buenos Aires präsentierten zwei funktionierende Datenschutz Prototypen, die auf externen Daten und digitalen Berechtigungsnachweisen aufbauen.

Das erste kombiniert ZK Fetch und Reclaim Attestierungen mit Midnight Compact, um die Herkunft von Webdaten festzustellen. KEEP wählt mit Ward einen anderen Ansatz, einer mobilen Anwendung, die dafür ausgelegt ist, Berechtigungsnachweise auszustellen und zu validieren, ohne den vollständigen personenbezogenen Datensatz des Inhabers zu übertragen.

ZK Fetch bringt nachgewiesene Webdaten in Compact

Das erste Projekt befasst sich mit einem häufigen Problem, wenn Smart Contracts sich auf Informationen stützen, die von externen APIs abgerufen werden.

HTTPS sichert die Kommunikation zwischen Client und Server, doch der Vertrag, der diese Information erhält, war nicht Teil der ursprünglichen Verbindung. Die Entwickler nutzten daher ZK Fetch und Reclaim Protocol, um kryptografische Nachweise zu erzeugen, dass die HTTPS Interaktion mit der behaupteten Quelle stattgefunden hat.

Das Nachweissystem von Reclaim und Midnight Compact waren nicht direkt kompatibel, daher fügte das Team eine Notar Ebene dazwischen ein. Notare prüfen den Nachweis und signieren ihn, während eine Schnorr Signatur Implementierung in Compact eine Bestätigung von mindestens zwei Notaren verlangt, bevor die Information als Eingabe für den Vertrag akzeptiert werden kann.

Die Architektur wurde mit Strava Daten demonstriert. Zwei Konten reichten Laufergebnisse von etwa 3,5 Kilometern und 15 Kilometern ein, wodurch die Anwendung einen Sieger bestimmen konnte, ohne den größeren Datensatz öffentlich zu machen.

Das Team gab an, der externe Nachweisprozess habe etwa drei bis vier Sekunden gedauert, gefolgt von der normalen Zeit, die für eine Midnight Transaktion erforderlich ist. Die Compact Implementierung ist weiterhin ein MVP und für weitere Refactorings vorgesehen.

KEEP speichert Berechtigungsnachweise auf dem Gerät des Inhabers

KEEP wendet Datenschutz auf Berechtigungsnachweise an, die von Institutionen wie Universitäten, Schulen oder öffentlichen Stellen ausgestellt werden.

Die mobile Anwendung Ward unterstützt sowohl die Rolle des Inhabers als auch die des Prüfers. Anstatt personenbezogene Datensätze über mehrere Systeme zu verteilen, bleibt der Berechtigungsnachweis auf dem Telefon des Nutzers, und der Inhaber kann nur die Informationen offenlegen, die für eine bestimmte Prüfung erforderlich sind.

Das System verwendet einen Merkle Baum für selektive Offenlegung, wodurch ein Element eines Berechtigungsnachweises offenbart werden kann, während die kryptografische Integrität gewahrt bleibt. Die Entwickler integrierten außerdem Schnorr Signaturen und Capacity Exchange für gesponserte Transaktionen, um die für Endnutzer sichtbare Blockchain Komplexität zu verringern.

In der Demo fungierte ein Telefon als Prüfer und zeigte eine QR Herausforderung an, während ein zweites Telefon den Berechtigungsnachweis hielt. Nachdem der Inhaber die Herausforderung gescannt hatte, lief der Prozess über Midnight und lieferte eine Bestätigung, dass der Berechtigungsnachweis gültig ist.

Das Team berichtete von einer Bearbeitungszeit von etwa 20 Sekunden. Der Prüfer erhielt das Ergebnis, ohne den vollständigen Datensatz des Berechtigungsnachweises des Inhabers zu erhalten.

Zwei Datenschutz Prototypen adressieren unterschiedliche Datenprobleme

Die beiden Projekte richten sich an unterschiedliche Informationsquellen.

Die ZK Fetch Implementierung konzentriert sich auf Daten aus bestehenden Webdiensten und gibt Compact Verträgen eine Methode an die Hand, festzustellen, dass eine externe Behauptung von der erwarteten HTTPS Quelle stammt.

KEEP konzentriert sich auf Berechtigungsnachweise, die direkt an Einzelpersonen ausgestellt werden, sodass der Inhaber den Datensatz lokal behält und nur das offenlegt, was ein Prüfer benötigt.

Beide sind weiterhin Implementierungen auf Hackathon Niveau. Das KEEP Team sagte, sein 24 Stunden Build könne nicht vollständig dezentralisiert werden und verwendet derzeit einen Capacity Exchange Knoten, der in gewissem Maß zentralisiert ist. Nach Angaben der Entwickler besitzt dieser Knoten nicht den Inhaber Schlüssel, der zum Signieren der Midnight Transaktion des Nutzers erforderlich ist.

Die Demonstrationen hinterlassen Midnight mit zwei unterschiedlichen funktionierenden Prototypen, einer kann nachgewiesene HTTPS Informationen in einen Compact Vertrag einspeisen, während der andere einen Berechtigungsnachweis an ein mobiles Gerät ausgeben und eine Behauptung bestätigen kann, ohne dem Prüfer den vollständigen personenbezogenen Datensatz zu übergeben.