Schon bei oberflächlicher Betrachtung erscheint die Blockchain-Technik verhältnismäßig komplex. Im Normalfall führt die Blockchain kryptographische Methoden (Hash-Werte, digitale Signaturen) mit Konsens-Verfahren und einer über das Netz verteilten Speicherung zusammen. Wenig davon gehört zum Alltag in der IT, so dass die Blockchain mit allen Anlaufschwierigkeiten einer neuen Technik zu kämpfen hat.
Außerdem bringt die Blockchain einige Eigenheiten mit, die ihren Einsatz nicht vereinfachen. Dazu gehört das stetige Wachstum der Kette, die mit einem Ewigkeitsanspruch daher kommt. Aktuell umfasst die Bitcoin-Blockchain 180 Gigabyte, während die Ethereum-Blockchain, die mit Smart Contracts noch wesentlich mehr Daten speichert, auf 665 Gigabyte kommt. Dem ursprünglichen Gedanken eines dezentralen Netzwerks, bei dem jeder Knoten die komplette Kette speichert oder zumindest speichern könnte, steht die Datenmenge entgegen, die nicht mehr für alle Teilnehmer handhabbar ist.
Ein Ende des Wachstums ist nicht abzusehen. Momentan begrenzt die Bitcoin-Blockchain die Erweiterung der Kette, indem nur alle zehn Minuten ein Block in der Größe von einem Megabyte hinzu gefügt werden kann. Das sorgt für ein maximales Wachstum um etwas mehr als 50 Gigabyte im Jahr. Doch damit wird auch die Zahl der Transaktionen eingeschränkt, was bei einer Währung, die ja genau dafür zur Verfügung stehen soll, eher wie ein Design-Fehler wirkt (man stelle sich vor: "Diesen Euro können Sie erst in zehn Minuten ausgeben, wenn ihre Zahlung nicht zugunsten anderer Transaktionen zurückgestellt wird."). Um mehr Transaktionen zu ermöglichen, müsste die zulässige Blockgröße erhöht werden, was sich wiederum direkt im Wachstum der Kette niederschlägt.
Smart Contracts kratzen dagegen an etwas Grundsätzlichem, denn sie unterliegen einem Zwang zur Fehlerlosigkeit. Da Daten, die einmal in der Kette gespeichert sind, nicht verändert werden können, ist auch die in der Kette integrierte Software nicht veränderbar. Smart Contracts werden häufig in der Sprache Solidity programmiert. Die lehnt sich stark an Javascript an und erlaubt beliebig komplexe Programme. Doch Software enthält eben häufig auch mehr oder minder kritische Fehler. Und so sorgen fehlerhafte Smart Contracts, die es erlauben, ungestraft größere Summen abzuzweigen, immer wieder für Schlagzeilen.
Da es keinen Beweis für Fehlerlosigkeit gibt, lautet die Empfehlung für Smart Contracts in der Regel, die Software vorher prüfen zu lassen. Doch in der Praxis bleiben auch gravierende Programmfehler über Jahre unentdeckt - so wie die Heartbleed-Lücke in SSL. Sie blieb der Allgemeinheit unbekannt, obwohl der Programm-Code offen liegt und die ensprechenden Programme weltweit millionenfach im Einsatz sind.
Es gibt Lösungen für diese Probleme. Man könnte ein Geschäft daraus machen, den aktuellen Stand von Blockchains auf Festplatten oder Speicherkarten zu verkaufen, Smart Contracts könnten auch mit einem Verfallsdatum versehen werden oder ein Unternehmen könnte den Einsatz einer intern verwendeten Blockchain insgesamt zeitlich begrenzen.
Die Schwierigkeiten der Implementierung von Blockchain-Technik mögen zum Lästern Anlass geben, aber sie sind wohl auch eine Reaktion auf die überspannten Erwartungen, bzw. den Hype. Letztlich scheinen die Beschränkungen genauso überzeichnet zu werden wie die Potenziale. Sinnvoll kann dieses Hin und Her trotzdem sein: Wenn beides, Möglichkeiten und Grenzen bekannt sind, kann man anfangen, die Technik für die eigenen Zwecke anzupassen.
