Blockchain – Demystifizierung eines Hypes

Angenommen Hans, Peter und Hugo wollen für ihr Monopoly-Spiel eine Währung erfinden. Sie einigen sich auf einen Betrag, der insgesamt zur Verfügung steht und führen ein Journal, wer welche Beträge von wem bekommen hat, also: Bank an Hugo 4000€ wegen LOS, etc.

Nun könnte jeder der Beteiligten, wenn die anderen gerade nicht hinschauen, eine Transaktion zu seinen Gunsten ins Journal eintragen und – schwups: Schon hat er mehr Geld. Wir können als Erkenntnis aus diesem Beispiel mitnehmen, dass es eine Rolle spielt, wer neue Einträge ins Journal vornehmen darf und wer diese Einträge überprüft.

Wenn das Spiel über mehrere Tage geht, könnte jeder eine Kopie des Journals anlegen und mit nach Hause nehmen. Wenn sie das nächste Mal zusammentreffen, können sie vergleichen, welche Einträge im Journal stehen.

Da sie nur zu dritt sind, könnte man sich sehr gut eine Kooperation von zwei Mitspielern zu Ungunsten des dritten vorstellen. Das wäre schwieriger, aber nicht ganz unmöglich, wenn es, statt nur drei, sehr viele Spieler wären. Eine Möglichkeit wäre nun, die Eltern zu bitten, das Journal zu führen oder wenigstens zu überprüfen. Das hätte ein wenig mehr Aussicht auf eine neutrale Überprüfung.

Im wirklichen Leben werden Währungen normalerweise von Zentralbanken überprüft, mit allen positiven und negativen Begleiterscheinungen. Es gab aber Kreise, die stark daran interessiert waren, eine Währung zu gründen, die außerhalb der Kontrolle der Staaten liegt, die sich praktisch selbst überprüfen kann.

Da gab es ein paar Fragen zu klären, die den Fragen von Hans, Peter und Hugo sehr ähnlich sind, mit dem Unterschied, dass sich die Beteiligten an Transaktionen nicht kennen und daher auch noch jeder Rest an Vertrauen dahinschwindet.

Eine digitale Währung

Die Lösung, mit der die Entwickler von Bitcoin um die Ecke kamen, war eine Währung, die rein digital funktioniert, in der alle Teilnehmer anonym sind und in der man scheinbar eine Lösung für das Journal-Problem gefunden hatte, ohne eine zentrale Instanz bemühen zu müssen, der alle Beteiligten vertrauen müssen.

Im Zentrum stand ein elektronisches Journal, dessen einzelne Einträge von den Beteiligten signiert wurden. Das ist mit Public Key-Verschlüsselungsverfahren sehr leicht möglich. Jeder Beteiligte hat ein Schlüsselpaar und kann mit dem privaten Schlüssel eine Transaktion unterschreiben. Mit dem öffentlichen Schlüssel, der allen Beteiligten vorliegt, lässt sich die Unterschrift verifizieren. Die öffentlichen Schlüssel sind sozusagen die Pseudonyme der Beteiligten.

Das sind die wesentlichen Bestandteile einer Blockchain:

• Alle Teilnehmer sind anonym
• Es gibt ein öffentliches Journal mit verifizierbaren Signaturen
• Es gibt keine zentrale Instanz, die das Journal überprüft

Der letzte Punkt ist jetzt ein wenig kniffelig. Das Hauptargument, das man immer hört, ist, dass ein Angriff auf die zentrale Instanz das ganze System kompromittieren könnte. Ein weiteres Argument ist natürlich auch, dass zwielichtige Gestalten ihre finanziellen Transaktionen lieber anonym halten möchten. Wenn eine zentrale Instanz das kontrolliert, ist es zur Deanonymisierung nicht mehr weit. Welches Argument auch mehr zählt, das Problem der Überprüfung muss gelöst werden.

Wie kann man das Journal überprüfen?

Das Problem wird so gelöst, wie Hans, Peter und Hugo es auch versucht haben: Jeder hat seine Kopie des Journals. Fragt sich nur, wer nun schreiben und überprüfen soll. Überprüfen sollen möglichst alle. Wer schreiben darf, wird mit einer Art Zufallsprinzip bestimmt. Und zwar geht das so: Man stellt ein Rätsel, das rechnerisch zu lösen ist. Wer sich beim Lösen des Rätsels besonders hervortut, darf schreiben. Bei Crypto-Währungen ist die Lösung des Rätsels gleichzeitig ein weiterer notwendiger Prozess: das sogenannte Mining, also die Erzeugung neuen "Geldes".

Man stelle sich mal vor, dass jeder, der das gemeinsame Journal betrippsen möchte, das Rätsel ganz schnell löst und dann ein paar Einträge machen darf. Dem wird jetzt vorgebaut, indem das Rätsel im Lauf der Zeit immer schwieriger zu lösen ist. BTW kann man neben dem Mining auch gleich noch die Aufgabe der Überprüfung übernehmen, aber das soll uns jetzt nicht weiter interessieren. Es kommen also weitere Eigenschaften der Blockchain dazu:

• Es braucht einen teuren Prozess des Minings, um das Schreibrecht zu ermitteln
• Man braucht viele Teilnehmer, damit sich nicht ein paar Teilnehmer absprechen
• Der Abgleich der Blockchains kostet Zeit, man kann den neuen Stand alle paar Sekunden bis hin zu alle paar Minuten erhalten. Bei Bitcoin haben wir eine Transaktionsrate von maximal 10-20 Transaktionen pro Sekunde weltweit.

Kurz: Das Verfahren ist langsam, umständlich und verbrät haufenweise Energie beim Mining.

Brauchen Sie solche Blockchains in Ihrem Unternehmen? Wenn Sie nicht gerade Schneeballsysteme für naive Spekulanten entwickeln wollen, oder einer der hier genannten Anwendungsfälle für Sie in Frage kommt, ist das höchstwahrscheinlich nichts für Sie.

Auftritt: Private Blockchain

Aufgrund der offenkundigen Probleme der Blockchains kamen findige Personen aus den Löchern mit der Erfindung des 21. Jahrhunderts: Die private Blockchain. (Das vorhin genannte Konzept nennen wir jetzt einfach öffentliche Blockchain.) Ihre Eigenschaften:

• Die Teilnehmer müssen nicht anonym sein
• Eine Public Key-Infrastruktur mit zentralen Instanzen ist möglich
• Die Rechtevergabe ist dadurch simpel
• Es braucht daher kein Mining
• Das System unterstützt wesentlich höhere Transaktionszahlen

Die private Blockchain hat aber zwei entscheidende Nachteile:

1. Es gibt wieder zentrale Instanzen – wir erinnern uns: das Fehlen von zentralen Instanzen war das Hauptargument für die Nutzung der Blockchain.
2. Sie ist ein alter Hut.

Public Key Verfahren

Das möchte ich etwas näher erläutern. Die Public Key-Verfahren zur Verschlüsselung und Signierung gibt es bereits seit 45 Jahren. 1976 wurde RSA als Public Key-Verfahren beschrieben, 1983 als Patent angemeldet. Weitere Verfahren folgten in den Jahren danach. Damit ist folgendes möglich:

• Man hat ein Paar an Schlüsseln, den privaten und den öffentlichen.
• Man kann mit dem privaten Schlüssel Information signieren, die Signatur kann mit dem öffentlichen Schlüssel überprüft werden.
• Man kann mit dem öffentlichen Schlüssel einer anderen Person Inhalte verschlüsseln, diese können dann nur von der Person mit ihrem privaten Schlüssel gelesen werden.

Mit diesem Verfahren können wir folgendes machen. Ich behaupte: „Ich bin Mirko Matytschak“. Sie glauben mir das nicht? Ich lasse meine Aussage von Maximilian Vollendorf unterschreiben. Das Problem: Sie vertrauen auch nicht darauf, dass das wirklich Maximilian Vollendorf unterschrieben hat. Also lässt auch er sich seine Identität beglaubigen.

Das lässt sich in einer Kette fortsetzen, aber am Ende müssen wir bei einer Instanz ankommen, der jeder vertrauen kann. Diese Instanz nennt sich Root Authority. Das Verfahren der Vertrauenskette, das ich hier beschrieben habe, basiert auf kleinen Informationsblöcken, die eine standardisierte Struktur haben und mit Hilfe eines Public Key-Verfahrens signiert werden. Diese Informationsblöcke nennen sich Zertifikate. Der Standard für Zertifikate heißt X509 und wurde 1988 veröffentlicht – das ist auch schon ein Weilchen her. Das sieht dann so aus:

Das ist genau das gleiche Verfahren, das als Kern der Blockchain beschrieben wird, nur dass der Informationsblock bei der Blockchain andere Informationen enthalten kann, als die im X509-Standard definierten. Unterschrieben werden die Blöcke mit dem privaten Schlüssel des Ausstellers und das kann jederzeit mit dem öffentlichen Schlüssel des Ausstellers überprüft werden.

Die ursprüngliche Hauptanwendung der Zertifikate war das SSL-Protokoll, mit dem Browser sicherstellen, dass eine Website auch wirklich von einem bestimmten Herausgeber ist. Gleichzeitig können Requests der Anwender an den Betreiber der Website, zum Beispiel Formularinhalte, verschlüsselt werden. Die zentrale Instanz bei SSL (heute: TLS) heißt Root CA, und es gibt gleich mehrere davon, deren Zertifikate zusammen mit dem Browser ausgeliefert werden.

Daher ist es auch wichtig, regelmäßig Browser-Updates vorzunehmen, damit Sie nur gültige Root CAs zur Überprüfung der Zertifikate verwenden. Letztlich sind wir alle darauf angewiesen, dass die Browser-Hersteller den richtigen Root CAs vertrauen. Die Browser-Hersteller kennen durchaus ihre Verantwortung. Da kann es schon einmal vorkommen, dass einer Root CA das Vertrauen entzogen wird. Sie sehen: Die Instanz, der Sie letztlich vertrauen, ist der Hersteller Ihres Browsers.

Innerhalb von Unternehmen können natürlich auch eigene Certificate Authorities aufgebaut werden, die als Basis einer Public Key-Infrastruktur (PKI) für das Unternehmen dienen können. Hat man erst einmal eine Public Key-Infrastruktur, lassen sich die schönsten Anwendungen damit erstellen.

Das ist die gute Nachricht: Die sogenannte Private Blockchain ist zwar ein alter Hut, die verwendeten Verfahren sind schon lange bekannt und bewährt, aber das macht sie nicht schlechter. Im Gegenteil: Wir sprechen ja von Anwendungen, die eine gewisse Sicherheit erfordern. Da ist es kein Schaden, wenn wir auf bewährte Methoden zurückgreifen.

Kurz: Jedes Unternehmen, das mit Public Key-Infrastrukturen umgehen kann, ist in der Lage, Anwendungen zu entwickeln, die als Anwendungsfälle für die Blockchain beschrieben werden. Die FORMFAKTEN GmbH gehört dazu.

Mit diesen Aussagen werde ich Widerspruch ernten, mit der Behauptung, dass an Blockchains mehr dran ist, als die verlinkte Liste an signierten Contents. Daher möchte ich folgendes Fazit zu dem Thema ziehen:

Die Innovation an den Blockchains ist das Verfahren der Journal-Überprüfung ohne eine zentrale Instanz. Genau das werden Sie nicht brauchen. Die realen Anwendungsfälle beziehen sich auf die private Blockchain und damit auf den "alten Hut" der signierten Listen.

Smart Contracts

Eins der Anwendungsgebiete, die heute für die Blockchains genannt werden, sind sogenannte Smart Contracts. Selten gibt es in der Branche so viel Übereinstimmung wie zu der Aussage, dass „Smart Contracts“ ein völlig falsch gewählter Begriff ist.

Die Idee ist etwa folgende: Wenn sich ein Verfahren formal beschreiben lässt, dann kann man das Verfahren als Programmcode formulieren und die Signatur des Codes in der Blockchain veröffentlichen. Damit haben alle Beteiligten die Sicherheit, dass das Verfahren nicht einfach geändert werden kann. Das funktioniert natürlich nur mit Verfahren, die tatsächlich als Code ausführbar sind.

Das hat also gar nichts damit zu tun, dass eine künstliche Intelligenz (KI) vielleicht in ein paar Jahren rechtssichere Verträge erstellen könnte (was bezweifelt werden darf). Ein solcher Vertrag wäre das glatte Gegenteil eines „Smart Contracts“, weil KI ja nicht deterministisch arbeitet, sprich: Es kommt nicht jedes Mal das Gleiche heraus, wenn man eine KI zwei Mal an ein und dasselbe Problem setzt. Es gäbe also gar nichts, was sich signieren und in seiner Integrität überprüfen ließe.

Smart Contracts können in Branchenlösungen für die Automatisierung von Prozessschritten verwendet werden, die immer auf die gleiche Weise funktionieren und Input verarbeiten können, der idealerweise ebenfalls digital entsteht. Sie dienen also der Zusammenarbeit von Unternehmen. Je größer aber die Komplexität solcher Prozessschritte wird, desto schwieriger lässt sich die formale Beschreibung, aka der Programmcode, analysieren.

Man weiß also nicht so recht, auf welche Implikationen man sich einlässt, wenn man einen komplexen Smart Contract absegnet. Das ist, wie wenn man etliche Seiten Geschäftsbedingungen durchlesen müsste, die in einer Programmiersprache erfasst sind. Damit komme ich zu folgendem Fazit:

Wenn Smart Contracts wirklich smart sind, sind sie als Contracts im rechtlichen Sinn ungeeignet. Sie müssen auf sehr einfache Verfahrensschritte begrenzt bleiben, die sich von Experten zweifelsfrei analysieren lassen. Und damit ist ihr Anwendungsgebiet stark begrenzt.

Mit dieser Einschränkung sei folgendes gesagt: Es gibt jede Menge hervorragender Scriptsprachen, mit denen sich kleine Funktionseinheiten darstellen lassen. Selbst die Entwicklung einer eigenen domänenspezifischen Sprache ist heute mit vertretbarem Aufwand leistbar und von Entwicklern der FORMFAKTEN GmbH schon vorgenommen worden. Solche Sprachen können Vorgänge in einem branchenspezifischen Vokabular beschreiben, was die Verständlichkeit erhöht. Die Beschreibungen lassen sich signieren und veröffentlichen. Dazu werden am Besten PKIs verwendet, denen alle Beteiligten vertrauen.

Die Entwickler der FORMFAKTEN GmbH können solche Lösungen für ihre Kunden bereitstellen.

Update 15.04.2021

Keine Blockchain für den digitalen Impfpass...

Auch die Bundesregierung hat eingesehen, dass sie gut auf die Blockchain verzichten kann. Wer nicht weiß, was es damit auf sich hat: Die Firma, die den digitalen Impfpass realisieren soll, hatte vorgeschlagen, die Informationen gleich in 5 Blockchains zu speichern. Das hat zu einer allgemeinen Erheiterung unter dem Hashtag #5blockchains geführt. Bei der Firma will man jetzt plötzlich nichts mehr davon wissen. Interessant ist, welche Lösung statt dessen gefunden wurde: Public Key Infrastructure (PKI) mit Zertifikaten.