Im vorangehenden Blog-Artikel zu Blockchain Basics  haben wir die Technik hinter der Bitcoin-Blockchain erläutert und dargelegt, warum diese Variante der Blockchain für kommerzielle Anwendungen nicht ökonomisch sinnvoll ist. In diesem Blog-Artikel wollen wir uns nun damit beschäftigen, wann Blockchain-Technologie überhaupt eingesetzt werden sollte und welche Technologien und Produkte dafür herangezogen werden können. Ein Schlüsselkonzept ist dabei das eingesetzte Consensus-Protokoll, aber es gibt auch andere Aspekte, die zu berücksichtigen sind.

Fragen, die man sich nun stellen muss

Aus dem vorangegangenen Blog-Artikel übernehmen wir unsere Eingangsfragen:

      • Die Blockchain à la BitCoin (mit dem Proof-of-Work-Consensus-Protokoll) ist – soweit man das derzeit einschätzen kann – fälschungssicher. Aber würde eine kommerzielle Anwendung der Blockchain den ökologischen und folglich auch ökonomischen Preis, der damit einhergeht, bezahlen wollen?
      • Welche Einschränkungen sind zu erwarten, wenn man ein anderes Consensus-Protokoll verwendet?
      • Wenn andere Consensus-Protokolle weniger Fälschungssicherheit bieten, welche Voraussetzungen müssen bei der Replikation (z.B. Anzahl und Art von Replikationsteilnehmern) gegeben sein, damit Blockchain-Technologie Sinn macht?
      • Wie kann eine andere Blockchain-Technologie dann noch gegen andere Verfahren der verteilten  und revisionsfähigen Speicherung (distributed ledger) konkurrieren?
Kriterien für den Einsatz einer Blockchain

Folgende Kriterien sind zu prüfen, wenn man sich den Einsatz von Blockchain überlegt:

      1. Verteilte Datenbank: Die Blockchain ist eine Technologie für verteilte Datenbanken. Wenn die Datenbank nicht verteilt werden soll – d.h. es gibt nur eine Instanz, in der die Daten gehalten werden sollen – dann kann auch eine traditionelle Datenbank verwendet werden.
      2. Mehrere Akteure: An dem Transaktionsprozess, der in der Blockchain dokumentiert werden soll, sind mehrere Akteure beteiligt. Diese Akteure führen üblicherweise auch ihre eigene Kopie der verteilten Datenbank.
      3. Mangel an Vertrauen: Blockchain ist eine Datenbank-Technologie für mehrere, sich potentiell nicht vertrauende Akteure. Vertrauen ist hier in erster Linie rechtlich gemeint und bezieht sich auf Akteure die potentiell unterschiedliche Interessen verfolgen. Die Nachweisbarkeit von Sachverhalten schafft dieses Vertrauen (s.a. https://de.wikipedia.org/wiki/Vertrauen – Situationsbasiertes Vertrauen: „Eine mögliche Defektion muss beobachtbar sein und entdeckt werden können“). Das muss nicht notwendigerweise bedeuten, dass die Akteure sich gegenseitig absichtlich betrügen wollen.
      4. Abbau der Mittlerrolle: Wo mehrere sich nicht vertrauende Akteure kollaborieren wollen (z.B. Werte austauschen), wird in der Regel ein vertrauenswürdiger Mittler eingeschaltet, z.B. ein Notar, eine Bank, ein Rechtsanwalt, ein sicherer Datenspeicher. Blockchain-Technologie erlaubt den Speicherung von Informationen im Rahmen von Transaktionen, wobei über deren Inhalt, Herkunft und zeitliche Reihenfolge der Speicherung zwischen den teilnehmenden Akteuren ein Konsens hergestellt wird und auch eine mögliche spätere Manipulation (s. Punkt 3) erkennbar wird.
      5. Validierung bzw. Schlichtung: Die Erkennung von Manipulationen (oder auch Verweigerung der Beteiligung am Konsens) löst aber dann noch nicht das Problem der Schlichtung im Falle von erkannten Diskrepanzen: wenn die verteilte Blockchain zwischen zwei Akteuren unterschiedlich ist, welche ist dann die richtige? Dies kann nur durch eine vorher von den Akteuren definierte Form der Validierung der Transaktionen (= Schaffung von Vertrauen) gelöst werden, z.B. dadurch, dass eine Mehrheit der Blockchain-Instanzen als „Wahrheit“ herangezogen wird (was wiederum mehr als zwei Akteure und am besten eine ungerade Anzahl davon erfordert) oder doch ein Mittler – z.B. in der Rolle eines vertrauenswürdigen Zeugen/Notars – von vorneherein einbezogen wird (womit der Vorteil unter Punkt 4 aber wieder ad absurdum geführt würde).

Man sieht, dass das keine einfachen (Anfangs-)Überlegungen sind. Einen interessanter Blog-Artikel zu Thema „Die sinnlose Blockchain vermeiden“ findet man übrigens auf der Website der Firma Multichain.

Unterschied zwischen Smart Contract und Consensus

Die Art und Weise der Replikation zwischen Instanzen einer Blockchain stellt also eine Art (Grund-)Vertrag mit Regeln zwischen den Akteuren dar. An dieser Stelle – sagt mir meine Intuition – kommt vielleicht von einigen Lesern die Einlassung, es gäbe doch sog. „Smart Contracts“ in der Blockchain. Das ist jedoch etwas völlig anderes: Ein Smart Contract ist Chain Code, also eine Anwendung, die die Daten in der Blockchain auf eine bestimmte Weise interpretiert, nämlich indem sie in den Daten enthaltene Bedingungen prüft und damit verbundene Anweisungen ausführt. Das Consensus-Protokoll regelt die Einigung der Akteure über die Daten in der Blockchain und nicht deren Interpretation.

Ein Problem, so alt wie die Informatik

Das zuverlässige Schreiben von Daten in verteilte Datenbanken ist so alt wie die Informatik selbst. Das Problem wurde zum ersten Mal adressiert in den 1970er-Jahren mit dem two-phase commit-Protokoll (2PC). Das Problem hier war, Änderungen an verschiedenen Tabellen in einer Datenbank so koordinieren, dass die Änderungen als eine singuläre Transaktion durchgeführt werden konnten. Das Schreiben der Daten wurde deshalb in einer ersten Phase angekündigt und vorbereitet und in einer weiteren Phase dann durchgeführt (committed). Wie viele sich erinnern können, war das Problem dabei, dass eine andere parallel laufende Transaktion auf dem selben Datensatz zum „Hängen“ von Transaktionen führen konnte. Als Antwort darauf wurde in den 1980er-Jahren das three-phase commit-Protokoll (3PC) entwickelt, welches sich auch besser für replizierte Datenbanken eignet.

Nun sind klassische Datenbanken typischerweise in einem Intranet zu finden, was zu einen ein vertrauenswürdiges Umfeld schafft und zum anderen eine hohe Zuverlässigkeit und Konsistenz der Übertragungswege garantiert. Zudem kann man sich in einer solchen Umgebung leisten, dass die Nichterreichbarkeit einer Datenbank-Replika als Fehler wahrgenommen wird, der nach Beseitigung der Störung (Verlust der Verbindung oder Nachricht) wieder relativ einfach behoben werden kann. Dies ist bei verteilten Datenbanken, die über das Internet operieren sollen, so nicht der Fall, daher braucht es dafür andere Protokolle. Womit wir beim Byzantinischen-Generals-Problem wären.

Das Byzantinische-Generals-Problem (BGP)

Das BGP beschreibt eine Situation, in der eine Anzahl von Generälen einen Angriff von mehreren Seiten auf eine Stadt vereinbaren müssen, der aber nur gelingen kann, wenn die Mehrheit der Truppen den Angriff gleichzeitig unternimmt. Bei der Vereinbarung des Angriffs können sie sich aber nicht auf die Botennachrichten zur Verständigung verlassen, sie können verloren gehen oder gefälscht sein, weil Verräter unter den Generälen sein können. Unter diesen Umständen muss entschieden werden, ob ein Angriff gewagt werden kann.

Das ist eine ziemlich perfekte Analogie zur Situation bei einem verteilten System wie Bitcoin oder einem welches die Kriterien erfüllt, wie sie im Abschnitt über Kriterien für den Blockchain-Einsatz beschrieben sind. Es geht bei diesen verteilten Datenbanken also darum, ein Protokoll zu entwerfen, welches dieses Problem löst. Das Bitcoin-Proof-of-Work-Protokoll tut genau das, in dem es technische Hürden vorschreibt, die nur von der Mehrheit aller existierenden Rechner gelöst werden können, jedoch für einen hohen Preis.

Andere Lösungen und ihre Einschränkungen

(Vorausgeschickt sei hier, dass keine detaillierte Abhandlung von einzelnen Protokollen erfolgen soll, sondern lediglich eine Vorstellung der grundsätzlichen Konzepte. Wenn Interesse besteht, dann kann ich in einen späteren Block hier gerne tiefer gehen.)

Das grundsätzliche Problem das es zu lösen gilt, ist die Frage wo bei einer womöglich größeren Anzahl von divergierenden Vorschlägen zum Informationsstand die Mehrheit mit der „richtigen“ Information liegt und wer der Anführer der Mehrheit ist, d.h. der der die “Wahrheit“ vertritt, der alle anderen folgen können.

Protokolle für Umgebungen, in denen zumindest Vertrauen (trustful) in die Integrität der Akteure besteht, verwenden dafür z.B. ein Vorschlagsverfahren (Paxos, Raft) oder ein Verfahren mit einem roulierenden Anführer (Round-robin), damit gewährleistet ist, dass nicht nur ein Akteur die Status der Datenbank bestimmt.

In Umgebungen, in denen wenig oder kein Vertrauen vorhanden ist (trustless), kommen Protokolle nach dem Proof-of-Stake-Konzept zur Anwendung. Proof-of-Stake bedeutet, dass Akteure Werte einsetzen um ihre Version der Information zu „versichern“, d.h. sie würden diese Werte verlieren, wenn sie versuchen würden zu betrügen.

Man kann also Consensus-Protokolle in folgende Kategorien einteilen (mit Beispielen für die jeweiligen Consensus-Protokolle, nicht vollständig):

Trustless, proof-of-work (Investition um Belohnung zu bekommen): skalierbar, unstable peers

    • Bitcoin

Trustless, proof-of-stake (Kaution oder Spielgeld), mind. 2/3 Übereinstimmung, skalierbar,  unstable peers

      • Tendermint
      • EOS
      • Casper

Trustful, prepare-commit, stable peers

      • Paxos
      • Raft
Zusammenfassung

Wir stellen abschließend fest, dass wir uns mit der Diskussion von Blockchain-Einsatz nicht nur in einem technologisch-algorithmischen Umfeld bewegen, sondern dass sich die Informatik, feststellbar an der Bedeutung der Abbildung von „Vertrauen“, zunehmend im sozio-transaktionalen Umfeld bewegt. Das bedeutet, dass bei der Entscheidung über den Einsatz von Blockchain eben dieses beiden Aspekte auch berücksichtigt werden müssen. Bei der Umsetzung liegt die zentrale Rolle in der Auswahl des geeigneten Consensus-Protokolls, das oftmals mit der einzusetzenden Blockchain-Technologie gekoppelt ist.

Bitcoin ist eine ganz spezifische Anwendung der Blockchain, die aufgrund ihrer Anforderungen einen ganz besonders geeigneten Einsatzfall darstellt, aber die Welt besteht nicht nur aus Kryptowährungen. Blockchain ist insbesondere eine Lösung für verteilte, sich nicht vertrauende Umgebungen, die ohne Mittler auskommen wollen.

In einem nächsten Blogartikel zur Blockchain – dieser ist schon zu lang geworden – werden wir uns die auf dem Markt vorhandenen Produkte ansehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.