DSGVO und Blockchain — Wie passt das zusammen?

Die DSGVO garantiert das Recht auf Löschung personenbezogener Daten. Blockchain-Technologie basiert auf Unveränderlichkeit. Diese beiden Grundsätze stehen in einem scheinbar unauflösbaren Widerspruch. Für DAO-Projekte, die in Europa operieren oder europäische Nutzer haben, ist dieser Widerspruch kein theoretisches Problem, sondern eine konkrete Compliance-Herausforderung.

Bei Just Tech Solutions beraten wir regelmäßig Projekte, die genau vor dieser Frage stehen. In diesem Artikel beschreibe ich, wie wir die Spannung in der Praxis auflösen, welche Strategien sich bewährt haben und wie Sie einen Entscheidungsrahmen für Ihr eigenes Projekt aufbauen können.

Den Widerspruch verstehen

Artikel 17 der DSGVO, das „Recht auf Vergessenwerden“, gibt Betroffenen das Recht, die Löschung ihrer personenbezogenen Daten zu verlangen. Der Verantwortliche muss dieser Aufforderung „unverzüglich“ nachkommen, sofern keine Ausnahmen greifen.

Auf einer Blockchain sind Daten, einmal geschrieben, nicht mehr löschbar. Das ist kein technischer Mangel, sondern das zentrale Designprinzip. Die Unveränderlichkeit der Blockchain ist die Grundlage für Vertrauen, Transparenz und Manipulationssicherheit. Ohne sie wäre eine Blockchain nur eine langsame Datenbank.

Aber: Nicht alles, was auf einer Blockchain gespeichert wird, sind personenbezogene Daten im Sinne der DSGVO. Und nicht alle Daten eines Blockchain-Projekts müssen auf der Blockchain liegen. Hier beginnt die Lösung.

Was sind personenbezogene Daten auf einer Blockchain?

Die DSGVO definiert personenbezogene Daten als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Im Blockchain-Kontext ist die Schlüsselfrage: Ist eine Wallet-Adresse ein personenbezogenes Datum?

Die Antwort europäischer Datenschutzbehörden ist differenziert, tendiert aber zum Ja. Eine Ethereum-Adresse ist pseudonym, nicht anonym. Wenn sie mit einer realen Person verknüpft werden kann, etwa durch KYC-Daten auf einer Börse, durch öffentliche Zuordnung auf ENS oder durch Transaktionsmuster, die eine Identifizierung ermöglichen, dann ist sie ein personenbezogenes Datum.

Das bedeutet: Transaktionsdaten, die eine Wallet-Adresse enthalten, sind potenziell personenbezogen. Governance-Stimmen, die einer Adresse zugeordnet sind, sind potenziell personenbezogen. On-Chain-Nachrichten, die von einer identifizierbaren Adresse gesendet werden, sind potenziell personenbezogen.

Die praktische Konsequenz: Minimieren Sie die Menge personenbezogener Daten, die on-chain landen. Alles, was nicht zwingend on-chain sein muss, gehört in Off-Chain-Systeme.

Strategie 1: Strikte On-Chain/Off-Chain-Trennung

Das effektivste Muster ist eine klare architektonische Trennung: On-Chain werden nur Daten gespeichert, die keine personenbezogenen Informationen enthalten oder die durch Aggregation anonymisiert sind. Personenbezogene Daten werden ausschließlich off-chain verwaltet.

Konkret bedeutet das:

• On-Chain: Abstimmungsergebnisse (aggregiert, nicht pro Adresse), Smart-Contract-Logik, Token-Transfers, kryptographische Hashes als Integritätsnachweis.
• Off-Chain: Benutzerprofile, Kommunikation, Mitgliederlisten, persönliche Einstellungen, alles, was eine natürliche Person identifizieren könnte.

Die Verbindung zwischen on-chain und off-chain wird über kryptographische Verweise hergestellt. Ein Hash eines Dokuments kann on-chain gespeichert werden, um seine Existenz und Integrität zu einem bestimmten Zeitpunkt zu beweisen, ohne den Inhalt des Dokuments offenzulegen. Wird das Off-Chain-Dokument gelöscht, bleibt der Hash on-chain bedeutungslos.

Strategie 2: Hashes statt Klardaten

Wenn Sie nachweisen müssen, dass ein bestimmtes Ereignis stattgefunden hat, ohne die Details offenzulegen, sind kryptographische Hashes das Mittel der Wahl. Beispiel: Eine DAO will nachweisen, dass ein bestimmtes Mitglied zu einem bestimmten Zeitpunkt abgestimmt hat, ohne die Stimmabgabe dauerhaft mit der Identität des Mitglieds zu verknüpfen.

Der Ablauf: Die Stimmabgabe wird off-chain gespeichert, zusammen mit allen personenbezogenen Details. Ein Hash der Stimmabgabe wird on-chain geschrieben. Solange die Off-Chain-Daten existieren, kann jeder die Integrität prüfen, indem er den Hash nachberechnet. Wird das Mitglied gelöscht und die Off-Chain-Daten entfernt, bleibt der Hash on-chain, ist aber nicht mehr einer Person zuordenbar.

Wichtig: Der Hash muss so berechnet werden, dass ein Rückschluss auf die Eingabedaten praktisch unmöglich ist. Bei kleinen Eingaberäumen, etwa wenn nur wenige Personen zur Wahl standen, kann ein Angreifer alle möglichen Eingaben durchprobieren. In solchen Fällen muss ein Salt verwendet werden, der zusammen mit den Off-Chain-Daten gelöscht wird.

Strategie 3: Privacy Layer und Zero-Knowledge-Proofs

Für Anwendungsfälle, in denen Daten on-chain verifizierbar sein müssen, aber nicht lesbar sein sollen, bieten Zero-Knowledge-Proofs (ZKPs) eine elegante Lösung. Ein ZKP kann beweisen, dass eine Aussage wahr ist, ohne die zugrundeliegenden Daten offenzulegen.

Im DSGVO-Kontext bedeutet das: Statt personenbezogene Daten on-chain zu speichern, wird nur ein ZKP gespeichert, der eine bestimmte Eigenschaft beweist. Zum Beispiel: „Diese Adresse gehört einem verifizierten EU-Bürger“ oder „Dieses Mitglied hat die erforderliche Reputation für diese Abstimmung.“

Die Herausforderung liegt in der technischen Komplexität. ZKP-Systeme wie zk-SNARKs oder zk-STARKs erfordern spezialisiertes Wissen und sind rechenintensiv. Für die meisten DAO-Projekte ist die Hash-basierte Strategie pragmatischer. Aber wenn die Anforderungen es erfordern, sind ZKPs die datenschutzfreundlichste Lösung.

Wer ist der Verantwortliche?

Eine der schwierigsten DSGVO-Fragen im Blockchain-Kontext ist die nach dem Verantwortlichen. Die DSGVO setzt voraus, dass es einen identifizierbaren Verantwortlichen gibt, eine natürliche oder juristische Person, die über Zweck und Mittel der Datenverarbeitung entscheidet.

Bei einer öffentlichen, permissionless Blockchain ist unklar, wer dieser Verantwortliche ist. Ist es der Entwickler des Smart Contracts? Der Node-Betreiber? Die DAO als Organisation? Jeder einzelne Nutzer, der eine Transaktion auslöst?

Die europäische Rechtsprechung hat hier noch keine abschließende Antwort gegeben. Aber für DAO-Projekte, die als erkennbare Organisation auftreten und Infrastruktur betreiben, empfehlen wir einen pragmatischen Ansatz:

• Die DAO oder ihr rechtlicher Wrapper (z.B. eine GmbH oder Foundation) übernimmt die Rolle des Verantwortlichen für die Off-Chain-Daten.
• Für On-Chain-Daten wird die Position vertreten, dass diese durch Minimierung und Anonymisierung nicht unter die DSGVO fallen.
• Ein Datenschutzkonzept dokumentiert die getroffenen Maßnahmen und die Abwägung transparent.

Entscheidungsrahmen: Was gehört on-chain?

Bevor Sie Daten on-chain schreiben, stellen Sie sich vier Fragen:

1. Enthält das Datum personenbezogene Informationen? Wenn ja, prüfen Sie, ob es anonymisiert oder pseudonymisiert werden kann, bevor es on-chain geht. Wenn eine Anonymisierung nicht möglich ist, gehört es nicht on-chain.

2. Ist die Unveränderlichkeit zwingend erforderlich? Nicht jedes Datum braucht die Garantien einer Blockchain. Fragen Sie sich ehrlich, ob eine signierte Datenbank den gleichen Zweck erfüllen würde. Wenn ja, wählen Sie die einfachere Lösung.

3. Kann das Datum mit einer natürlichen Person verknüpft werden? Auch scheinbar anonyme Daten können durch Korrelation identifizierbar werden. Transaktionsmuster, Zeitstempel und Beträge können in Kombination eine Person identifizieren, selbst wenn keine Adresse direkt zugeordnet ist.

4. Was passiert bei einem Löschantrag? Spielen Sie den Fall durch: Ein Nutzer stellt einen Löschantrag nach Art. 17 DSGVO. Können Sie dem nachkommen? Wenn die Antwort „nein“ ist, weil die Daten on-chain liegen, dann haben Sie ein Problem. Restrukturieren Sie die Architektur, bevor Sie in Produktion gehen.

Praktische Empfehlungen

Aus unserer Beratungspraxis heraus empfehlen wir DAO-Projekten folgende Maßnahmen:

• Privacy by Design: Datenschutz muss von Anfang an in die Architektur eingebaut werden, nicht nachträglich. Die Entscheidung, welche Daten on-chain und welche off-chain liegen, sollte die erste Architekturentscheidung sein.
• Datensparsamkeit: Speichern Sie on-chain nur das absolute Minimum. Jedes zusätzliche Byte an personenbezogenen Daten on-chain erhöht das Compliance-Risiko.
• Dokumentation: Erstellen Sie ein Verarbeitungsverzeichnis, das klar aufschlüsselt, welche Daten wo gespeichert werden, welche Rechtsgrundlage gilt und wie Betroffenenrechte gewährleistet werden.
• Technische Maßnahmen: Implementieren Sie die Hash-basierte Referenzierung konsequent. Nutzen Sie Verschlüsselung für alle Off-Chain-Daten. Erwägen Sie ZKPs für sensible Anwendungsfälle.
• Rechtliche Beratung: Dieser Artikel ersetzt keine Rechtsberatung. Die Schnittstelle zwischen DSGVO und Blockchain ist ein sich entwickelndes Rechtsgebiet. Holen Sie sich spezialisierten juristischen Rat.

Fazit

DSGVO und Blockchain sind kein unauflösbarer Widerspruch. Sie erfordern aber ein bewusstes architektonisches Design, das beide Anforderungen respektiert: die Unveränderlichkeit für Vertrauen und Transparenz, den Datenschutz für die Rechte der Betroffenen.

Die Lösung liegt nicht in der Wahl zwischen Blockchain und DSGVO, sondern in der intelligenten Kombination von On-Chain- und Off-Chain-Systemen. Wer von Anfang an auf Datensparsamkeit und Privacy by Design setzt, kann beides haben: die Vorteile dezentraler Systeme und die Einhaltung europäischen Datenschutzrechts.