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.