Die Hype-Energie beim Thema Blockchain ist gewaltig, und es ist auf jeden Fall zu empfehlen, sich vor dem Einsatz dieses Technologieansatzes sehr genau zu überlegen, ob man eine Lösung auf der Suche nach einem Problem vor sich hat oder andersherum. Dabei können eine Reihe von Kriterien helfen, zu beurteilen, ob ein „Distributed Ledger“ für einen vorliegenden Anwendungsfall tatsächlich angemessen ist. Eines der wichtigsten dieser Kriterien ist der Aspekt der Verteilung auf eine Vielzahl (oder zumindest eine Zahl >1) von Rechnern (Knoten) und die Notwendigkeit, dass diese Knoten sich auf eine einzige, konsistente Wahrheit einigen.
Klassische Konsensus-Verfahren
Dieses Problem ist nicht neu. Ein einziges Bit, das an mehr als einer Stelle gespeichert wird, kann bereits gewaltige Kopfschmerzen verursachen, wenn man sich sicher sein will, dass alle Beteiligten sich zu jedem Zeitpunkt darüber einig sind, ob es aktuell den Wert 1 oder 0 hat. Für eine redundante Speicherung von Daten gibt es eine Vielzahl von Gründen wie z.B. Ausfallsicherheit, Performance-Optimierung oder Offline-Szenarien. Daher haben sich in der Informatik sowohl die Forschungsbereiche „Verteilte Systeme“ wie auch „Datenbanken“ bereits seit vielen Jahrzehnten mit der Thematik auseinandergesetzt und Verfahren etabliert wie Two-Phase-Commit (das von den relationalen Datenbanken mehr oder weniger gut unterstützt wird) oder Paxos (das zu erklären der eine oder die andere im Informatikstudium sicher als Aufgabe kennt). All diese Verfahren sorgen mit mehr oder weniger hoher Sicherheit dafür, dass sich die Beteiligten auf eine Wahrheit einigen. In den letzten Jahren haben vor allem NoSQL-Datenbanken am CP-Ende des CAP-Theorems und Werkzeuge zum Management verteilter Systeme das Thema Konsensus wieder in das Bewusstsein von Architekten und Entwicklern gerückt. Dabei zeigen sich vor allem die Systeme als erfolgreich und zuverlässig, die eine gemeinsame Weltsicht auf Basis wohlverstandener Algorithmen wie Raft (etcd), Zab (Zookeeper) oder eben Paxos mit seinen Varianten herstellen.
Eine Blockchain bzw. ein Distributed Ledger ist jedoch mehr als eine Datenbank (bzw. sollte es sein, ansonsten sollten Sie sich fragen, ob sie wirklich einen passenden Anwendungsfall haben). Der entscheidende Unterschied ist, dass man aus Sicht des Gesamtsystems den beteiligten Partnern – den Knoten oder „Nodes“ – nicht vertrauen kann. Man muss davon ausgehen, dass jeder einzelne im Zweifelsfall das System so zu manipulieren versucht, dass er selbst einen Vorteil erhält. Eine solche Problemstellung bezeichnet man als „byzantinisch“, nach einem wissenschaftlichen Artikel, der sie anhand eines fiktiven Beispiels eines gemeinsames Feldzugs byzantinischer Generäle erläutert, die sich weder darauf verlassen können, dass keiner den anderen verrät, noch den Nachrichten, die sie erhalten, vertrauen können, weil diese mit bösartiger Absicht auf dem Weg von Feinden verfälscht worden sein könnten.
Eine solche Situation ist sehr unangenehm und nicht trivial lösbar. Die lange Zeit bekannteste Lösung für das Problem ist der sogenannte „PBFT (Practical Byzantine Fault Tolerance)“-Algorithmus, der bereits 1999 veröffentlich wurde. Ein auf dieser Basis implementiertes System toleriert bis zu 1/3 bösartiger (oder fehlerhafter) Akteure – eine durchaus respektable Leistung. Allerdings leidet er unter zwei Problemen: Zum einen setzt er voraus, dass die Gruppe der Knoten initial bekannt ist und konstant bleibt. Zum anderen hat er eine Komplexität von O(n²), d.h. die Laufzeit steigt quadratisch mit der Anzahl der Beteiligten. Damit ist er für praktische Anwendungen in einem Kontext mit vielen Hunderten oder Tausenden Beteiligten, die das System dynamisch erweitern oder wieder verlassen, ungeeignet.
Proof-of-Work/Nakamoto-Konsensus
Und damit sind wir nun endlich bei dem Blockchain-Verfahren angekommen, wie es als Teil von Bitcoin vor knapp zehn Jahren vorgestellt wurde. Es erreicht Konsens auf Basis eines probalistischen Verfahrens: Es ist nie zu 100% garantiert, dass man die „Wahrheit“ kennt, aber man kann sich im Laufe der Zeit immer sicherer sein. Am Beispiel von Bitcoin: Die Daten, um die es geht, sind Transaktionen, mit denen sich (vereinfacht gesagt) die Bitcoin-Sender und -Empfänger Geld zusenden. Transaktionen werden zum einen selbst validiert, indem sichergestellt wird, dass in ihnen nur virtuelles Geld ausgegeben wird, das demjenigen, der es ausgibt, auch gehört. Dies geschieht auf Basis eines Public/Private-Key-Verfahrens. Zum anderen werden Transaktionen als Ganzes validiert, indem sie Teil eines Blockes werden, der seinerseits wiederum abgesichert wird – im Falle von Bitcoin durch das „PoW-(Proof-of-work)“-Verfahren.
Da dieses Verfahren nicht nur bei Bitcoin, sondern auch bei vielen anderen öffentlichen Blockchains (wie z.B. Ethereum) zum Einsatz kommt und häufig in der Kritik steht, nehmen wir uns die Zeit, es genauer zu erläutern. Das Verfahren ist mit Absicht sehr rechenintensiv und wird von den sogenannten „Miner“-Knoten durchgeführt. Die Grundidee dabei ist, dass ein Algorithmus mit Eingabedaten gefüttert wird, die sich aus den Transaktionen, einem Verweis auf den vorhergehenden Block, ein paar weiteren Metadaten und zusätzlich einem frei wählbaren Wert zusammensetzen. Da es sich um einen Hashing-Algorithmus handelt, ist das Ergebnis aus den Eingabedaten nicht vorherzusehen, es sei denn, man führt den Algorithmus aus (das genau ist das Wesen eines Hash-Verfahrens). Das wiederum bedeutet, das der einzige Weg, ein gewünschtes Ergebnis zu erzielen, die „Brute Force“-Methode ist – sprich: aggressives Ausprobieren. Legt man nun nicht einen bestimmten Wert, sondern eine Menge von Werten fest, die als gültiges Ergebnis gelten, kann man bestimmen, wie schwierig die zu lösende Aufgabe ist. Bei Bitcoin ist dieser als „Difficulty Target“ bezeichnete Parameter eine Anzahl von Nullen, mit denen das Ergebnis beginnen muss. Mit anderen Worten: Die Miner probieren solange andere Werte für das eine frei wählbare Feld im Block aus, bis sie ein Ergebnis bekommen, das mit n führenden Nullen beginnt. Dabei liefern sie sich ein Wettrennen mit allen anderen Miner-Knoten, die das im gleichen Zeitraum ebenfalls versuchen – bis einer von ihnen einen Block gefunden hat und diesem im Peer-to-Peer-Netzwerk verbreitet.
Ein Miner, der einen solchen Block empfängt, prüft, ob dieser den gleichen Block als Vorgänger hat wie der Blockkandidat, für den er selbst gerade nach einer Lösung sucht. Ist dies der Fall, stellt er die Arbeit daran ein und bildet einen neuen Kandidaten mit dem neuen Block als Vorgänger (und ohne die darin enthaltenen Transaktionen) – sprich: Er gibt auf. Warum? Könnte er nicht genau so gut den Block verwerfen, den er empfangen hat, und stattdessen einfach hoffen, schnell genug selbst einen Block zu finden, um diesen zum Teil der offiziellen Blockchain werden zu lassen? Ja – und in der Praxis geschieht das sogar häufig, wenn auch meistens nicht mit Absicht, sondern weil schlicht nicht auszuschließen ist, dass ein bereits gefundener Block einen Miner, der ebenfalls einen gültigen Block findet, noch nicht erreicht hat. In solchen Fällen spricht man von einer Gabelung („Fork“) in der Blockchain. Allerdings konvergiert der so entstandene Baum binnen kurzer Zeit wieder zu einer Kette, weil sich einer der Zweige gegenüber den anderen durchsetzt. Ein Block, der bereits zwei oder drei Schritte „voraus“ ist, signalisiert einem Miner, dass er eventuell auf einem Zweig arbeitet, der kaum eine Chance hat, sich noch durchzusetzen, denn alle arbeiten nach demselben Prinzip: Die längste Kette gewinnt. Die Äste, die sich vom Stamm (der Kette, Entschuldigung für den Analogiebruch) abgegabelt haben, sterben ab.
Warum nun das aufwändige Rätselraten? Man könnte schließlich argumentieren, dass dadurch massiv Ressourcen verschwendet werden, weil all diejenigen Miner, die das Rennen nicht gewinnen, ihre Rechenleistung (und die dafür benötigte Energie und Hardwarekapazität) umsonst eingesetzt haben. Insbesondere Bitcoin steht genau dafür massiv in der Kritik, weil sich der Energiebedarf der Bitcoin-Blockchain durch das PoW-Verfahren mittlerweile dem Gesamtenergiebedarf der Niederlande nähert. (Das war kein Scherz, sondern ist zumindest von der Größenordnung her belegbar.) Der Grund dafür ist, dass das Produzieren eines Blocks unbedingt aufwändig sein muss, damit diese Sorte Blockchain funktioniert – und zwar wegen des byzantinischen Problems, also wegen des mangelnden Vertrauens gegenüber den Beteiligten. Würde ein Miner versuchen, eine alternative Version der Realität zu erzeugen, z.B. durch Entfernen einer Transaktion aus der Historie, um Geld ein zweites Mal ausgeben zu können, müsste er eine alternative Version der Blockchain erzeugen. Weil die Blöcke aber verkettet sind, wird dieses Fälschen um so schwieriger, je mehr Blöcke nach der bereits im System gespeicherten Transaktion, die man löschen oder verändern möchte, bereits entstanden sind. Bei Bitcoin dauert das Finden eines Blocks ca. zehn Minuten; nach sechs Blöcken, also nach ca. einer Stunde, kann man eine Transaktion als genügend abgesichert betrachten, dass sie nicht mehr gefälscht werden kann. Wenn jemand z.B. per Bitcoin online ein Auto bezahlt, könnte man nach einer Stunde davon ausgehen, dass man das Fahrzeug samt Brief und Schlüssel problemlos ausliefern kann. Eine Stunde mag dabei lang klingen, aber das ist ein Irrglaube: Im Gegensatz zu einer Kreditkarten- oder SEPA-Transaktion gibt es keine Möglichkeit, Widerspruch einzulegen; als Empfänger des Geldes kann man sich also sehr, sehr sicher sein, dass der Transfer erfolgreich war.
Der entscheidende Punkt beim PoW-Verfahren ist, dass die Verschwendung – oder positiv formuliert: Investition – in die Rechenleistung und die damit verbundene Energie es schwierig, und noch wichtiger, nicht lohnenswert macht, die Inhalte der Blockchain zu fälschen. Man müsste enorme Rechenleistung erbringen, um mit der gefälschten Historie gegen die Miner-Knoten, die sich an die Regeln halten, gewinnen zu können. Und das wiederum lohnt sich nicht, denn die Miner arbeiten natürlich nicht umsonst, sondern für den sogenannten Block-Reward, eine Belohnung, die derjenige erhält, der den offiziell akzeptierten Block findet. Jeder Miner darf nämlich eine Transaktion in den Block aufnehmen, die quasi aus dem Nichts einen Betrag von 12,5 Bitcoin (zum Zeitpunkt des Schreibens dieses Artikels immerhin ungefähr 72.000€) an ihn selbst transferiert.
Das Konsensusverfahren der Bitcoin-Blockchain, nach dem Erfinder Nakamoto-Konsensus genannt, basiert also zum einen auf dem Proof-of-work-Verfahren, durch das belegt wird, dass jemand die Energie und Rechenleistung investiert hat, um die Blöcke zu bestimmen, sowie zu anderen auf dem Netzwerk, in dem die beteiligten Knoten die jeweils längste Kette durch die Propagation der entsprechenden Blöcke unterstützen bzw. (im Falle von Mining-Knoten) durch ihr Mining darauf aufsetzen. Das Besondere daran ist, dass es vollständig dezentral, also ohne Koordinator auskommt, keinerlei Kenntnis der Identität der Knoten voraussetzt und grundsätzlich davon ausgeht, dass niemand vertrauenswürdig ist. Für dieses besondere Szenario, das - wen wundert’s – perfekt auf eine Währung passt, die ohne eine zentrale Stelle auskommt, ist das Bitcoin-Blockchain-PoW-Verfahren aktuell die einzige etablierte, erprobte und ausgereifte Lösung. Viele der bestehenden Währungen (neben Bitcoin z.B. auch Dash, Zcash und – noch – Ether) basieren darauf (wenn auch in der Regel mit anderen Algorithmen als dem oben beschriebenen Hashing-Verfahren).
PoW-Alternativen
Allerdings ist das PoW-Verfahren, wie weiter oben bereits erwähnt, heftig umstritten. Zum einen liegt das am erheblichen Energiebedarf, der – je nach Fraktion – als „Versündigung an folgenden Generationen“ oder als „erheblich sinnvoller als das bestehende Finanzsystem und das für weniger Energie als die jährliche Weihnachtsbeleuchtung“ betrachtet wird. Die Lösungen lassen sich in unterschiedliche Kategorien einsortieren.
Zunächst gibt es dabei die Kategorie, die das Problem adressiert, indem sie einige der Grundanforderungen in Frage stellt: Vor allem die Dezentralisierung, die Offenheit gegenüber beliebigen Teilnehmern (Knoten) und den Grad des Vertrauens, das man ihnen entgegenbringt. Lässt man die Anforderung nach Dezentralisierung komplett weg, kann man sich auf einen einzigen zentralen Leistungserbringer beschränken und ist damit bei einer klassischen Lösung, die mit Blockchain oder Distributed Ledger-Ansätzen gar nichts zu tun haben braucht. Auch wenn man die Teilnehmer auf wenige bekannte Knoten beschränken kann, denen man vollständig vertraut, ist die Lösung gradlinig – es handelt sich dann schlicht um eine verteilte Datenbank. Auch in diesem Fall ist der Begriff „Blockchain“ bestenfalls als Marketing-Gimmick zu verstehen.
Interessanter sind Szenarien, bei denen die Menge der Teilnehmer beschränkt ist, aber keiner von ihnen Vertrauen genießt. Solche Umgebungen können mit Protokollen wie dem altbekannten PBFT oder optimierten Verfahren unterstützt werden, die oft eine bessere Skalierbarkeit bzw. eine geringere Komplexität versprechen. Ein prominentes Beispiele dafür ist Ripple, das den Konsensus in die Verantwortung besonders privilegierter Knoten legt, die nicht einfach jeder betreiben kann, sondern die bewusst ausgewählt werden. Diejenigen, die dazu berechtigt sind, beweisen dies durch ein geeignetes Verfahren wie z.B. ein Zertifikat. In diesem Fall spricht man von einem „PoA-(Proof-of-Authority)“-Ansatz. Ein Hinweis allerdings: Bei solchen Systemen ist die Dezentralisierung, also die Verteilung der Verantwortung auf eine Menge wirklich unabhängiger Instanzen, oft erst für die Zukunft geplant; wird das auf dezentralen Betrieb ausgerichtete System jedoch zentral betrieben, kann man die berechtigte Frage stellen, ob nicht auch eine zentrale Lösung ausgereicht hätte.
Um den Rahmen dieses Artikels nicht zu sprengen, fokussieren wir uns im Folgenden auf Algorithmen, die den gleichen Problembereich wie Nakamoto-Konsensus/PoW adressieren, aber dafür andere Wege gehen: Proof-of-Stake, Proof-of-Service sowie hybride Varianten.
Dem PoS-(Proof-of-Stake)-Verfahren liegt die Annahme zugrunde, dass niemand Interesse daran hat, ein System zu destabilisieren, auf dessen korrekter Funktion er selbst angewiesen ist. Während beim PoW-Verfahren ein Miner „beweist“, dass er bereit war, eine Menge Energie zu investieren, würde in einem Währungssystem, das auf PoS aufsetzt, stattdessen ein bestimmter Betrag der Währung im System selbst eingesetzt. Das kann direkt oder indirekt geschehen: Bei der direkten Variante „setzen“ ein oder mehrere Partner einen Betrag ein (engl.: „put at stake“), indem sie ihn während der Validierung sperren und nicht anderweitig ausgeben können. Bei der indirekten Variante werden der oder die Partner, die über valide Blöcke entscheiden, mit einer Wahrscheinlichkeit ausgewählt, die im Verhältnis zu der Größe ihres Anteils (ihres Besitzes) steht.
Der große Vorteil des PoS-Verfahrens gegenüber PoW ist, dass es zwar für den gleichen Anwendungsfall geeignet ist – öffentliche, für jeden zugängliche Blockchains –, aber ohne den massiven Energiebedarf auskommt. Aus diesem Grund hat sich z.B. Ethereum schon sehr früh darauf festgelegt, das PoW- durch ein PoS-Verfahren abzulösen (ein Prozess, der aktuell mit einer hybriden Lösung vorbereitet wird). Der Nachteil ist zum einen, dass diejenigen, die innerhalb des Systems über viel „Reichtum“ verfügen, nicht außerhalb, sondern nur innerhalb des Systems motiviert sind, sich an die Regeln zu halten, zum anderen die schlichte Tatsache, dass ein solches System bislang noch in keiner öffentlichen Blockchain-Implementierung verwendet wird und die Reife daher bezweifelt werden muss.
Proof-of-Service
Eine interessante Variante ist das Proof-of-Service-Verfahren. In diesem wird nicht die Leistung belohnt, ein kryptographisches Puzzle gelöst zu haben, sondern die Erbringung einer anderen, für das System sinnvollen Leistung. Ein gutes Beispiel dafür ist die Kryptowährung Dash. Sie ist ursprünglich als Fork von Bitcoin entstanden, ergänzt dieses aber um zwei Features: Das (mehr oder weniger) sofortige Durchführen von Transaktionen und das Anonymisieren. Für beides sind sogenannte „Masternodes“ verantwortlich, die anders als die Miner-Knoten bei Bitcoin nicht Blöcke validieren, sondern ein verteiltes System für diese Zusatzfeatures bilden. Um ein Masternode zu werden, muss ein Knoten nachweisen, mindestens 1000 Dash (ungefähr 200.000€) zu besitzen. Das genügt anstelle eines Identitätsnachweises, um Masternode zu werden. Die Masternodes wiederum werden für ihre (sinnvolle) Arbeit belohnt, sodass genügend Beteiligte incentiviert sind, einen Masternode zu betreiben.
Dash ist auch ein gutes Beispiel für ein hybrides Modell: Obwohl es den PoS-Ansatz für die Masternodes verwendet, hat es trotzdem das PoW-Modell, das es von Bitcoin geerbt hat, nicht aufgegeben. Die eigentliche finale Validierung der Blöcke erfolgt genau wie bei Bitcoin durch die Miner. Allerdings kommt die Belohnung (der „Block Reward“) nicht nur dem Miner zugute, sondern nur zu 45%. Weitere 45% werden an die Masternodes verteilt, 10% wandern in eine Art F&E-Budget, aus dem Weiterentwicklungen an Dash selbst finanziert werden. Gleichzeitig werden in den Blöcken die Transaktionen, die von den Masternodes durchgeführt wurden, endgültig in die Blockchain aufgenommen. Bevor dies geschieht, sind sie daher „nur“ durch das Netzwerk von Masternodes abgesichert – ein typischer Kompromiss zwischen Vertrauen/Sicherheit auf der einen und Durchsatz auf der anderen Seite.