Nachteile der Blockchain

Die Blockchain-Technologie bringt auch ganz spezifische Nachteile mit, die sich ebenso wie ihre Vorzüge aus ihrer Architektur ergeben – und dazu führen, dass Blockchain eben nicht für jeden Einsatzzweck das geeignete Mittel ist.

Das sind:

Kein optimaler Einsatz von Speicherplatz und Rechenleistung

Je redundanter Ihre Daten gespeichert sind, desto besser? Nicht unbedingt – es gilt, zwischen Redundanz und Leistung abzuwägen. Wenn man all seine Zeit und Rechenpower darauf verwendet, Sicherheitskopien (Backups) von seinen Daten anzulegen, dann wird die Produktivität steil abfallen. Und dieselben Daten immer und immer wieder in Kopie abzulegen ist auch keine besonders effiziente Verwendung von Speicherplatz.

Blockchain: Ineffiziente Nutzung von Speicherplatz und RechenleistungIm Falle der Blockchain führt die Redundanz zu zwei Komplikationen:

  1. Wenn man Daten aus der realen Welt in der Blockchain speichert, wird die Blockchain sehr schnell sehr groß werden. Bitcoin, die älteste Blockchain der Welt, hat im Dezember 2016 eine Größe von 100 GB erreicht – das heißt, jeder vollwertige Teilnehmer (sogenannter Full Node) an der Bitcoin-Blockchain muss zunächst einmal 100 GB historische Daten herunterladen. Und im Falle von Bitcoin enthält jede Transaktion nicht besonders viel an Daten. Wenn wir stattdessen Patientendaten in der Blockchain speichern würden, dann würde diese unhandliche Größe schon viel früher erreicht werden. Wenn man diese Größe mit der Anzahl der Blockchain-Benutzer multipliziert, die je nach Anwendungsfall mehrere Hunderttausend oder auch Millionen betragen kann – dann kommt man auf eine enorme Verschwendung von Speicherplatz.
  2. Wenn man mit Smart Contracts arbeitet – und die meisten Konzepte für Blockchains im Gesundheitswesen tun das, weil sie auf Ethereum basieren – dann wird der Programmcode für jeden Smart Contract auf jedem Server des Blockchain-Netzwerks ausgeführt. Somit wird also nicht nur Speicherplatz verschwendet, sondern auch Rechenleistung, also Energie. Damit nicht genug: Wenn der Smart Contract auf eine externe Datenbank zugreift, dann wird jeder Server im Blockchain-Netzwerk auf diese Datenbank zugreifen. Ein Beispiel wäre ein Smart Contract zur Medikationsplanung, der auf eine externe Datenbank mit Arzneimittelinteraktionen zugreift. Wenn jeder Server bei dieser externen Datenbank anfragt, dann entsteht damit nicht nur viel Traffic im Netzwerk, sondern es ist auch nicht gesichert, dass jeder Server auf seine Anfrage die gleiche Antwort erhält – vielleicht wird zwischen den gleichartigen Anfragen der Datenbankeintrag für ein Medikament aktualisiert. Dies zerstört den Konsens in der Datenbank und stellt somit den Konsensmechanismus in Frage.

Es gibt mehrere Ansätze, um das erstgenannte Problem des Speicherplatzes zu lösen: Man kann beispielsweise dazu übergehen, nicht vollständige Daten auf der Blockchain zu speichern, sondern nur Referenzen auf diese Daten. Die Daten selbst liegen dann in externen Datenbanken. Für eine Blockchain im medizinischen Bereich könnte man beispielsweise eine externe Datenbank für Arztberichte einrichten, eine für radiologische Bilder, eine für genetische Daten und so weiter. Für jeden Datensatz in einer dieser externen Datenbanken wird dann ein Hash berechnet und in der Blockchain gespeichert. Ein Hash ist eine Art Prüfsumme, die sich stets ändert, wenn sich der Inhalt des Datensatzes ändert (aber natürlich viel weniger Speicherplatz wegnimmt als der ursprüngliche Datensatz). Ein unveränderter Hash beweist also, dass sich der Datensatz nicht verändert hat, und bei einem auf der Blockchain gespeicherten Hash kann man beweisen, dass er nicht im Nachhinein manipuliert wurde.

Um das zweite Problem zu lösen, das Problem der Smart Contracts, haben Blockchain-Entwickler die Einrichtung sogenannter Orakel vorgeschlagen. Dies sind externe Dienste, die die für die Smart Contracts notwendigen Informationen von außen in die Blockchain schicken („push“), so dass die Smart Contracts keine externen Datenbanken abfragen müssen („pull“). Diese Speicherung von externen Daten in der Blockchain sollte aber auf das Notwendigste beschränkt bleiben – denn sonst gibt es wieder ein Problem mit dem Speicherplatz.

Transaktionen sind innerhalb des Netzwerks nicht vertraulich

Die Geschichte von Blockchain und Anonymität ist eine Geschichte voller Missverständnisse, könnte man sagen. Blockchain-Laien denken bei Bitcoin und anderen Kryptowährungen gern an eine „anonyme Währung“, mit der Drogen- und Waffenhändler im Darknet ihre dunklen Geschäfte abwickeln.

Blockchain: Mangelnde VertraulichkeitTatsächlich aber sind Bitcoin und anderen Blockchains von Grund auf transparent. Das müssen sie sein, denn jeder Knoten muss in der Lage sein, die Validität aller Transaktionen zu prüfen – und dazu muss er Zugriff auf alle Transaktionen haben. Die Blockchain ist aber in ihren meisten Implementationen, wenn schon nicht anonym, dann jedoch zumindest pseudonym: Personenbezogene Daten werden in der Regel nicht direkt auf der Blockchain gespeichert. Stattdessen wird beispielsweise in Bitcoin der öffentliche Schlüssel einer Person auf der Blockchain gespeichert. Jeder Teilnehmer kann sehen, welche öffentlichen Schlüssel an einer Transaktion beteiligt waren. Jeder öffentliche Schlüssel gehört zu einer Person und stellt daher eine Art Pseudonym dar.

Das bedeutet: Wenn man das Netzwerk lange genug beobachtet, kann man Schlüsse darüber ziehen, welche öffentlichen Schlüssel zu welcher Person gehören könnten. Das funktioniert ähnlich, als könnten Sie die Transaktionen auf einem Girokonto beobachten: Wenn Sie lange genug zuschauen, dann können Sie relativ gute Vermutungen darüber anstellen, wem das Konto gehört, auch wenn Sie den Namen der Person nicht kennen.

Diejenigen Nutzer, die Bitcoin zu illegalen Zwecken verwenden, wissen, dass diese Transparenz vom Arm des Gesetzes genutzt werden kann, um ihren Identitäten auf die Schliche zu kommen. Aus diesem Grund stellen sie die gewünschte Anonymität anders her: Sie wechseln regelmäßig ihre Schlüsselpaare, so dass jeder öffentliche Schlüssel – jedes Pseudonym – nur für eine einzelne Transaktion verwendet und dann entsorgt wird.

Auch im Kontext des Gesundheitswesens können Informationen darüber, wer mit wem Transaktionen durchführt, sensibel und vertraulich sein. So möchte möglicherweise ein Patient nicht, dass sein Hausarzt sieht, dass er in eine Transaktion mit einem Spezialisten für Geschlechtskrankheiten involviert war – auch wenn der Hausarzt den Inhalt der Transaktion nicht sehen kann. Oder der Patient möchte nicht, dass sein Kardiologe sieht, dass er eine Transaktion mit einem anderen Kardiologen hatte – etwa, um eine Zweitmeinung darüber einzuholen, ob die empfohlene (teure) Koronarangiographie tatsächlich notwendig ist.

Um innerhalb der Blockchain Vertraulichkeit zu ermöglichen, kann man den gleichen Ansatz wählen wie die illegalen Händler im Darknet: Öffentliche Schlüssel häufig wechseln. Ein anderer Ansatz befindet sich gerade in Entwicklung – er ermöglicht tatsächliche Anonymität auf der Blockchain und basiert auf einem nicht ganz einfachen mathematischen Prinzip, den sogenannten Zero-Knowledge-Beweisen. Eine derartige anonyme Blockchain ist bereits in der Kryptowährung ZCash in Gebrauch – und wird sicher auch bei medizinischen Blockchains wichtig werden.