Programmierbarer Datenschutz: Wie er Compliance-freundlicher sein könnte zur Web3-Welt

Bei Ola stimmen wir der Aussage von a16z in ihrem Artikel voll und ganz zu. Erreichen des Krypto-Datenschutzes und der Einhaltung gesetzlicher Vorschriften " über web3:

„Die Entwicklung und Regulierung von web3 – eine durch Krypto betriebene Weiterentwicklung des Internets – muss zwei Ziele erreichen, die oft im Spannungsfeld stehen. Ziel 1: Wahrung der Privatsphäre der Verbraucher, trotz der standardmäßig transparenten Natur von Blockchains . Ziel 2: Das Risiko illegaler Finanzierung im Interesse der nationalen Sicherheit verringern.“

Diese Vision stimmt mit dem überein, was Ola im Artikel „ Ola – Gestalten Sie Ihre eigene Web3-Reise „Darüber hinaus ist die Betonung des hohen Durchsatzes eine Funktion, an deren Implementierung Ola derzeit intensiv arbeitet.

Unabhängig davon, ob es sich um private oder nicht private Szenarien handelt, ist die Programmierbarkeit ein äußerst wichtiges Merkmal. Im Bereich der programmierbaren Privatsphäre arbeiten neben Ola auch Aztec und Miden auf das gleiche Ziel hin.

Olas Artikel: „ Sin7y Tech Review (35): Hybrid Rollup – Die Infrastruktur der nächsten Generation – HackMD ,“ beschreibt die Unterschiede zwischen diesen drei Lösungen.

In diesem Artikel konzentrieren wir uns mehr darauf, das Design von Ola im Hinblick auf Compliance-Freundlichkeit zu erläutern. Wie im a16z-Artikel beschrieben, muss der Datenschutz zwei Attribute gleichzeitig umfassen:

1. Erzielen Sie einen nativen Datenschutz, um Benutzerinformationen zu schützen.

   
   

2. Stellen Sie die Einhaltung gesetzlicher Vorschriften sicher, um illegale Aktivitäten zu verfolgen.

Der erste Punkt ist relativ einfach zu erreichen. Was den zweiten Punkt betrifft, so hat jedes Projekt seine eigenen Überlegungen und Kompromisse. Wir werden uns hauptsächlich mit Olas Denkprozess und Design in Bezug auf die Einhaltung gesetzlicher Vorschriften befassen.

Betrachten wir dies aus der Perspektive der Lösung realer Probleme und untersuchen wir zunächst die Herausforderungen, denen sich verschiedene Datenschutzprojekte im Hinblick auf die Einhaltung gesetzlicher Vorschriften gegenübersehen. Wie im Kapitel „Unfreiwillige selektive De-Anonymisierung“ aus dem Artikel „ Datenschutzrechtliche Regulierungslösungen mit Zero-Knowledge-Proofs: Vollständiger Artikel – a16z crypto „Die entscheidende Frage lautet: „ Wer verwaltet den privaten Schlüssel, um die Rückverfolgbarkeit zu ermöglichen?“ "

Warum brauchen wir einen privaten Schlüssel, um die Rückverfolgbarkeit freizuschalten?

Die Notwendigkeit eines privaten Schlüssels zur Erreichung der Rückverfolgbarkeit hängt mit aktuellen Datenschutzdesigns zusammen.

Da sich fast alle Datenschutzlösungen, die derzeit auf der ZK-Technologie (Zero-Knowledge) basieren, an Zcash orientiert haben, werden wir direkt auf das Design von Zcash eingehen, wie unten dargestellt:

Im Artikel " Sin7y Tech Review (33): Grundsätze privater Transaktionen und Fragen der Einhaltung gesetzlicher Vorschriften – HackMD ", finden Sie die Designprinzipien hinter privaten Transaktionen. Wir erklären kurz, wie die Privatsphäre bei diesem Design gewahrt bleibt und wie es regulatorische Bedenken berücksichtigt:

1. Verbergen des Transaktionsinitiators oder des Absenders : Dies wird durch eine einmalige Signatur erreicht, wie in Abschnitt 4.1.7.1 des beschrieben Zcash-Sapling-Protokoll .

   
   

2. Ausblenden des Transaktionsempfängers bzw. des Empfängers : Dies ist in zwei Szenarien unterteilt:

   
   

ⅰ. Die Geheimhaltung vor Dritten wird durch die Verschlüsselung der Transaktionsinformationen mithilfe der öffentlichen Adresse des Empfängers erreicht. Siehe Abschnitt 4.19.1 des Zcash-Sapling-Protokoll . Der Empfänger durchsucht dann die Transaktionen mithilfe eines privaten Schlüssels (bekannt als eingehender Ansichtsschlüssel), um an ihn gesendete Transaktionen zu entschlüsseln und herauszufiltern, wie in Abschnitt 4.19.2 des beschrieben Zcash-Sapling-Protokoll . Der Transaktionsinhalt selbst enthält keine Informationen über den Empfänger.

ⅱ. Das Verbergen vor demselben Absender erfolgt über eine einmalige öffentliche Adresse.

3. Zur Verschleierung von Transaktionsinformationen : Der Ansatz beinhaltet die Verwendung von Zero-Knowledge-Beweisen und Shared-Secret-Systemen. Siehe Abschnitte 4.17 und 4.19 der Zcash-Sapling-Protokoll .

   
   

4. Für die Implementierung von Non-Traceable : Der Ansatz basiert auf dem Design des Commitment-Baums (im Folgenden als „CM“ bezeichnet) und des Nullifier-Baums (im Folgenden als „NF“ bezeichnet). Dieses Design dient folgenden Zwecken:

   
   

ⅰ. Jeder UTXO (Unspent Transaction Output) entspricht einem CM und einem NF, es besteht jedoch keine direkte Verbindung zwischen den beiden.

ⅱ. Sowohl der CM-Baum als auch der NF-Baum sind reine Append-Bäume.

ⅲ. Der CM-Baum wird verwendet, um die Gültigkeit des UTXO zu beweisen, während der NF-Baum eine doppelte Ausgabe des UTXO verhindert.

Basierend auf dem oben genannten Datenschutzdesign können Benutzer von den folgenden Datenschutzfunktionen profitieren:

1. Jede Transaktion bleibt für Außenstehende unsichtbar.

   
   

2. Die Verbindungen zwischen Transaktionen sind nicht nachvollziehbar.

   
   

Es scheint ein makelloses Design zum Schutz der Privatsphäre der Benutzer zu sein. Wenn man sich jedoch an der Realität orientiert, handelt nicht jeder Benutzer mit echten und rechtmäßigen Absichten. Es müssen Mechanismen vorhanden sein, um Teile oder alle privaten Transaktionsdetails offenzulegen, um bei Bedarf eine Rückverfolgbarkeit zu gewährleisten.

Dies unterstützt Regulierungsbehörden dabei, gegen böswillige Benutzer vorzugehen. Andernfalls könnte diese Form der Privatsphäre zu einem Werkzeug für böswillige Akteure werden, um normalen Benutzern Schaden zuzufügen.

Erlaubt das oben genannte Datenschutzdesign den Regulierungsbehörden, Transaktionen bequem zu verfolgen und Vorschriften durchzusetzen? Die Antwort ist nein. Wie im bereitgestellten Diagramm dargestellt (auf das verwiesen, aber nicht gezeigt wird), erfordert das aktuelle Datenschutzdesign einen Ansichtsschlüssel, um die Rückverfolgbarkeit von Transaktionen freizuschalten.

Dieser Ansichtsschlüssel befindet sich jedoch im Besitz des Benutzers und ist daher für die Aufsichtsbehörden nicht direkt zugänglich. Dies hängt mit den in den Abschnitten 13/14 mit den Titeln „Freiwillige selektive De-Anonymisierung“ und „Unfreiwillige selektive De-Anonymisierung“ beschriebenen Problemen des Artikels zusammen. Datenschutzrechtliche Regulierungslösungen mit Zero-Knowledge-Proofs: Vollständiger Artikel – a16z crypto. "

Lassen Sie uns tiefer eintauchen. Warum ist der Ansichtsschlüssel so sensibel, dass Benutzer zögern, ihn den Aufsichtsbehörden zur Verfügung zu stellen?

1. Zunächst muss unbedingt klargestellt werden, dass der Ansichtsschlüssel nicht der private Schlüssel ist, der für Transaktionssignaturen verwendet wird. Es kann nicht zum direkten Signieren von Transaktionen und daher nicht zum Diebstahl von Benutzerressourcen verwendet werden.

   
   

2. Sobald der Ansichtsschlüssel offengelegt wird, können Regulierungsbehörden alle von einem Benutzer initiierten privaten Transaktionen im Klartext sehen. Benutzer müssen den Aufsichtsbehörden vertrauen, dass: (1) der Ansichtsschlüssel nicht preisgegeben wird; und (2) Transaktionsdetails werden nicht offengelegt.

   
   

3. Benutzer mit bösartigen Absichten werden natürlich nicht bereit sein, ihren Ansichtsschlüssel preiszugeben, sodass die Regulierungsbehörden machtlos sind.

   
   

Basierend auf der obigen Analyse sollte die ideale Datenschutzlösung :

1. Verbergen Sie weiterhin den Inhalt jeder Transaktion, um sicherzustellen, dass die Privatsphäre der Benutzer gewahrt bleibt.

   
   

2. Erzielen Sie eine erlaubnisfreie Rückverfolgbarkeit zwischen Transaktionen, was bedeutet, dass die Rückverfolgbarkeit ohne die obligatorische Bereitstellung zusätzlicher Informationen realisiert werden kann .

Dies ist die Vision, die Ola erreichen möchte: programmierbarer Datenschutz, der von Haus aus Rückverfolgbarkeit beinhaltet!

Wie führt Ola die native Rückverfolgbarkeit in den programmierbaren Datenschutz ein?

Um die regulatorischen Herausforderungen anzugehen, denen die oben genannten Datenschutzlösungen gegenüberstehen, hat Ola mutig einen Versuch gewagt und ein spezifisches Design skizziert. Die technologischen Kernpunkte lassen sich wie folgt zusammenfassen:

1. Der Nullifier-Baum wird nicht mehr eingeführt, um die Unauffindbarkeit von Transaktionen zu erreichen. Im Design von Ola sind Transaktionen nachvollziehbar, dies geschieht jedoch unter Verschlüsselung, ohne die Datenschutzeigenschaften der Transaktionen selbst zu beeinträchtigen.

   
   

2. Der verbleibende Commitment-Baum wird vom ursprünglichen Nur-Anhängen-Modus in einen aktualisierbaren Modus überführt, indem zusätzliche Beweisanweisungen eingeführt werden, um Angriffe mit doppelten Ausgaben auf dasselbe Commitment zu verhindern. Dies ist in Abbildung 2 dargestellt:

   
   

3. Integrieren Sie einen aktualisierbaren Ansichtsschlüsselmechanismus. Das heißt, wenn ein Ansichtsschlüssel offengelegt wird, können Benutzer den Ansichtsschlüssel aktualisieren, um sicherzustellen, dass nachfolgende private Transaktionen, die nach der Schlüsselaktualisierung erstellt wurden, nicht entschlüsselt werden können. Wie in Abbildung 3 dargestellt:

   
   

zkDID/zkKYC bringt Datenschutz und Regulierung effektiv in Einklang

Zero-Knowledge Decentralized Identifiers (zkDIDs) spielen eine entscheidende Rolle in Datenschutzplattformen. Sie haben die Möglichkeit, die rechtliche Identität eines Benutzers (Legal ID) in eine zkDID umzuwandeln. Zum Beispiel im PSE-Projekt Anon Aadhaar Personen mit einer Aadhaar-Karte können eine zkDID generieren.

Für andere ist eine zkDID anonym und gibt nicht die tatsächlichen Identitätsinformationen des Benutzers preis. Diese doppelte Eigenschaft stellt ein leistungsstarkes Instrument zum Schutz der Privatsphäre dar.

Was die Implementierungsebenen von zkDID betrifft, so kann dies je nach Design und Anforderungen der Plattform auf verschiedenen Ebenen erfolgen:

1. Implementierung auf Plattformebene : Wenn eine Plattform die Identität aller Benutzer verwalten und überprüfen muss, um Sicherheit und Compliance zu gewährleisten, ist die Implementierung von zkDID auf Plattformebene möglicherweise die geeignetere Wahl. Auf diese Weise kann die Plattform zkDID direkt als Teil ihres Identitätsmanagementsystems integrieren und so die Überprüfung und Autorisierung der Benutzeridentität ermöglichen.

   
   

   Dieser Ansatz ermöglicht einen konsistenten Identitätsschutz und Datenschutzkontrolle auf der gesamten Plattform.

   
   

2. Implementierung auf Anwendungsebene : Wenn eine Plattform Benutzerkontrolle und Flexibilität priorisiert, ist die Implementierung von zkDID in einer Anwendung der oberen Schicht auf der Plattform möglicherweise vorzuziehen. Mit dieser Methode können Benutzer entscheiden, ob sie zkDID verwenden möchten, und ihre Identität nach Bedarf verwalten.

   
   

   Benutzer können entscheiden, wann sie zkDID verwenden, um Privatsphäre und Komfort in Einklang zu bringen. Dieser Ansatz eignet sich möglicherweise besser für Benutzer, die eine aktivere Kontrolle über ihre Identität wünschen. (Nicht-Muttersprachler).

Angesichts des oben genannten Designs bietet die Datenschutzlösung von Ola die folgenden Vorteile:

1. Rückverfolgbarkeit : Basierend auf den CM-Informationen innerhalb einer Transaktion kann jeder Dritte den Flusspfad des CM verfolgen, wie in Abbildung 2 dargestellt.

   
   

2. Datenschutz : Die Privatsphäre jeder Transaktion bleibt erhalten; Informationen über den Absender, den Empfänger und andere Aspekte bleiben vertraulich.

   
   

3. Effizienz : Durch die Erhaltung weniger Bäume wird der Overhead des zk-proof-Systems reduziert.

   
   

4. Aktualisierbarer Ansichtsschlüssel : Unterstützt Aktualisierungen des Ansichtsschlüssels und stellt sicher, dass der Transaktionsschutz nicht gefährdet wird, wenn der Ansichtsschlüssel offengelegt wird.

   
   

5. Compliance-freundlich : Ohne die Notwendigkeit nicht durchsetzbarer Informationen können Regulierungsbehörden beispielsweise die Abstammung des Ziels und die CM-Sammlungen nachverfolgen. Auch wenn es den Regulierungsbehörden vorübergehend an Wissen über die Eigentümer dieser CMs mangelt, haben sie zwei Möglichkeiten:

   
   

6. A. Warten Sie, bis der CM verbraucht und an eine öffentliche Adresse übertragen wird. Dies ist machbar, da im Entwurf von Ola alle privaten Zustände in öffentliche Zustände übergehen müssen, bevor sie das Ökosystem verlassen.

   
   B. Erhalten Sie Ansichtsschlüsselinformationen für die Entschlüsselung, eine traditionelle Methode zur Rückverfolgbarkeit in Datenschutzlösungen, wie sie in Systemen wie Zcash, Aleo, Aztec, Miden und anderen zum Einsatz kommt.

Über diese technischen Vorteile hinaus kann Ola immer noch in Papiere wie „ Erreichen des Krypto-Datenschutzes und der Einhaltung gesetzlicher Vorschriften – a16z crypto " Und " Blockchain-Datenschutz und Einhaltung gesetzlicher Vorschriften: Auf dem Weg zu einem praktischen Gleichgewicht „Um Blacklist-Mechanismen und andere Einschränkungen im Frühstadium zu integrieren und das Design des gesamten programmierbaren Datenschutzsystems zu verfeinern.

Auch hier veröffentlicht