Ist die Blockchain mit der DSGVO vereinbar?

[jobo]

Ich bleibe dabei, dass ich nicht viel von Blockchain weiß, aber zu 3. würde ich sagen:
- references
- loose coupling
- usw.

Damit beschreibe ich nicht den Status Quo, sondern nur eine Idee. Wer das patentiert, kann mich ja netterweise erwähnen :
Wenn es darum geht, veränderbare (oder geschützte oder beides) Daten einzubeziehen, könnte man mit mehreren Blockchains arbeiten und mit Referenzen (RDBMS lässt grüßen)
Statt alles in eine Blockchain zu stopfen, wäre es denkbar Nutzdaten und Identity zu trennen.
Also eine Bestellung mit Ihrem Status, Bezahlung, Lieferstatus, etc enthielte dann eine Referenz auf eine Identiy blockchain mit dem Besteller. Diese Referenz zeigt auf eine bestimmte Stelle der Chain, die zum Zeitpunkt gerade gültig ist. Wenn der Besteller später heiratet (Namensänderung) oder Künstler wird, wird die Identity Blockchain geändert, ohne am Bestellzeitpunkt die Information zu verlieren. Eine Namenskorrektur (weil zum Bestellzeitpunkt falsch in der Chain) kann natürlich nachgetragen werden (Referenz Nachtrag in der Bestellblockchain auf die korrigierte Stelle der Identity).
Die Referenzen können nach Bedarf durch Verwendung, Weitergabe, Enthaltung von Schlüsseln verborgen oder publik gemacht werden oder durch Einbeziehung von Role Block Chains (auch wieder Identity am Ende) bestimmten Gruppen/Transaktionsteilnehmer transparent sein.
Das lässt zwar gewisse Probleme offen, wäre aber zumindest ein Beitrag zum Datenschutz.

Bedeutet am Ende, dass es Zweck oder Rollen gebundene Chains gibt, die vielfältig vernetzt sein können. Jeder schaut durch seine Brille (auf seine Chain) und sieht nicht mehr, als er für sein business/Nutzen braucht. Die einzelnen Blockchains mit den spezifischen Aufgaben müssen natürlich (per Trust chain) eine Vertrauensstellung haben.

Bestimmt gibt es das schon.

[Rollo62]

Diese Auseinanderlaufen gibt es schon per Design, wenn zufällig 2 gleiche Schlässel errechnet werden in Rio und in Basel.
So können kurzzeitug zwei verschiedene Stränge in einer Blockchain entstehen, von denen im Nachhinein eine bereinigt werden muss.
Also löschen is IMHO vorgesehen, aber auch die lückenlose Historie.

Weil jede ID personenbezogen sein kann wenn diese mit einer Person verknüpft werden kann wäre auch DSGVO relevant.
Womöglich dann nicht wenn es nur eine GUUID wäre die sonst keine Relevanz in der wirklichen Welt hat.

Aber wie weise ich nach das der Eintrag mir 'gehört' ?

Bitcoin soll ja angeblich anonym sein, aber die aktuelle Chain soll auch 200TB gross sein.
Das hat man nicht mal eben auf dem usb stick.

Wenn dann verteilt gerechnet werden muss auch in China und Nordkorea ist DSVGO u.U. remevant.

Ich denke nicht nur Blockchain sondern auch DSVGO hat ein Designproblem ..

[Codehunter]

Zitat von Rollo62:

Ich denke nicht nur Blockchain sondern auch DSVGO hat ein Designproblem ..

So würde ich das nicht sagen. Sie kommt nur 20 Jahre zu spät. Du kannst das Rad nicht zurückdrehen. Die Menschen sind Bequemlichkeit gewohnt und erwarten sie sogar. Wird ein Teil davon qua Gesetz unterbunden, nimmt man das nicht etwa klaglos hin. Vielmehr wandert er ab zu Anbietern aus liberaleren Jurisdiktionen. Datenschutz ist wichtig, nur die Leute verstehen es nicht und handeln gegen die eigenen Interessen.

[Phoenix]

Zitat von Rollo62:

Ich denke nicht nur Blockchain sondern auch DSVGO hat ein Designproblem ..

Blockchain-Technologien an sich haben kein Designproblem.

Im Prinzip ist eine Blockchain ein Event store, der kryptographisch gesichert ist, und als Sahnehäubchen oben drauf selber entscheiden kann, was als nächstes gespeichert werden darf oder was nicht (Smart Contracts, vergleichbar mit Stored Procedures in einer relationalen DB), und von wem es in die chain gelegt werden darf.

Eventsourcing ist eine Technologie die so alt ist wie Rechner bei Banken (Dein Konto ist mit an Sicherheit grenzender Wahrscheinlichkeit in einem Event store gespeichert. Es gibt eigentlich keine Bank die ihre "Quelle aller Wahrheit" in einer relationalen DB ablegt. Es mag eine Kopie der Daten in einer normalen DB geben (für schneller Suche etc.), aber Dein aktueller Kontostand ist immer die Summe aller vorangegangen Kontobewegungen (inkl. Stornos / Rückbuchungen). Eine Kontobewegung die mal passiert ist, wird auch nicht gelöscht. Natürlich wäre es ineffizient, Deinen Kontostand jedes mal aus der Summe der Einzelbewegungen neu zu berechnen, wenn Du im Onlinebanking drauf guckst, aber dafür gibt es eben separate read stores bzw. caches.

Git ist z.B. auch ein Event store. Die Events sind die Commits. Sie sind auch kryptographisch gesichert, und die Datenhaltung ist auch verteilt möglich. Git ist sozusagen die Vorstufe einer Blockchain.

Wenn man nun noch Smart Contracts einführt, kommen wir schon in die Nähe.

Für vieles, wegen dem stand heute Blockchains gehyped werden, sind sie eigentlich gar nicht notwendig. Ein nachvollziehbares Audit-Trail kann man genauso gut heute auch mit einem klassischen Event store bauen, und die Verifizierbarkeit mit aufeinander aufbauenden Hashes ist in null Komma nichts selber dazu gebaut. Dazu braucht es keine Blockchain.

Blockchains werden dann interessant, wenn mehrere Parteien, die sich potentiell nicht gegenseitig vertrauen, untereinander nachvollziehbar und transparent Geschäfte abwickeln wollen. Unser Paradebeispiel sind Telekommunikationsunternehmen und die RegTp, und der Use-Case der Rufnummernportierung. Dies könnte eine private Blockchain sein, die zwischen allen Telcos und der Regulierungsbehörde verteilt ist. Es würde z.B. darin stehen, welcher der Telcos z.B. welche Nummer gerade betreibt. Um das DSGVO-Thema zu berücksichtigen, wollen wir aber keine Kundendaten da drin haben. Wenn ich jetzt meine Rufnummer von der Telekom z.B. zu Unitymedia umziehen will, fülle ich den Wisch aus, und sende ihn an Unitymedia. Die scannen mein Dokument ein, und stellen einen Portierungsantrag (implementiert als Smart contract) in die Chain ein, zusammen mit einem Hash des Scans. Wenn die Telekom jetzt anzweifelt, ob der Antrag korrekt ist, kann sie das Dokument von Unitymedia anfordern, und verifizieren dass er der Antrag zu dem Smart contract ist. Und die Portierung wird dann in einem der folgenden Blöcke stattgegeben. Damit weiss jeder der anderen Telkos jetzt, dass die Nummer bei Unitymedia liegt, und von wem die ggf. zukünftig portiert werden soll. Die Smart contracts in der Chain können dann Beispielsweise so implementiert sein, dass immer der aktuelle Besitzer der Nummer zustimmen muss, oder aber die RegTp überstimmen kann. Das ganze ist dann auch kryptographisch über Zertifikate abgesichert.

Und was das Thema der Energieeffizienz angeht: Das ist ein Bitcoin- und Ethereum-Problem. Und Ether ist grad auf dem Weg, davon los zu kommen. Im Prinzip wird damit aktuell bestimmt, wer den nächsten Block signieren darf, und wer dafür dann - im Falle von Kryptowährungen - die Mining-Gebühr erhält. Bei Bitcoin und aktuell noch Ether ist es so, dass es derjenige ist, der zuerst ein komplexes Kryptographisches Rätsel löst. Und die Schwierigkeit des Rätsels wird durch Smart contracts in Bitcoin so ausgelegt, dass es immer ungefähr gleich lang dauern wird. Also je mehr Rechenpower drin steht, desto kürzer wird gerechnet, desto schwieriger wird das Rätsel, desto mehr CPU/GPU werden gebraucht. Doofer Teufelskreis.

Das interessante ist, dass der derjenige, der den nächsten Block signieren darf, die Quelle der zukünftigen Wahrheit darstellt. Schmuggele ich bei Bitcoin eine Transaktion ein, die alle Bitcoins die es gibt auf mein Konto überweist, dann ist das für die Zukunft so. Dadurch, das bei öffentlichen Chains aber jeder die Transaktionen sehen kann, und nachrechnen kann, würde das auffallen, und der Block würde vom Netzwerk nicht akzeptiert werden. Meine Rechenenergie wäre also verschwendet.

Ethereum will in Zukunft auf Proof of Stake umstellen. Damit muss jemand eine bestimmte Anzahl von Ether hinterlegen, die eingefroren werden. Sollte jemand nun versuchen, die Chain zu manipulieren, so würde er seinen Einsatz verlieren.

In privaten Blockchains würden sich die beteiligten Parteien entweder auf ein solches System, oder auf einen anderen Algorithmus (Round robin, der Reihe nach, jeweils ein Quorum etc.) einigen, der bestimmt wer den nächsten Block signieren darf.

Das Hashen ist dann nicht mehr Rechenaufwändig als den Hash eines Git-Commits zu berechnen. Also mehr als vernachlässigbar.

Kurzum:
Es gibt einige Fälle, in denen Blockchain in der Tat eine sinnvolle Technologie ist, aber man sollte dem Hype nicht verfallen und mit Blockchain auf alles einschlagen, was nach verifizierbarer Historie aussieht (siehe Eventstore, ggf. reicht es ja auch aus, Logs stündlich in ein Git repo zu committen, und das dann woanders hin zu pushen - ist in ein paar Minuten gescripted...).
Und vor allem sollte man Blockchain nicht mit Bitcoin im speziellen oder Kryptowährungen im allgemeinen gleichsetzen. Andere Use-cases sind deutlich interessanter und spannender.

[Rollo62]

Dankesehr.
Endlich mal ein use-case der mich überzeugen kann.
In den meisten anderen Fällen denke ich dass das Ziel oft mit weniger Aufwand anders erreicht werden kann.

Also ich verstehe das mal so: wenn mehrseitiges Vertrauen im Spiel ist könnte es sinnvoll sein.

[freimatz]

@Phoenix: Danke

[Codehunter]

Kleiner später Nachtrag: Die Süddeutsche hat am Samstag einen Artikel veröffentlicht, der meine ursprüngliche Aussage unterstreicht.

[Codehunter]

Auf Heise Developer ist heute ein guter Artikel zu dem Thema veröffentlicht worden, welcher das Ganze mal aus technisch-rechtlicher Perspektive beleuchtet.