Wie jede neue Technologie, bringt auch die Blockchain ihr eigenes Vokabular mit sich. Einer der besonders häufig verwendeten Begriffe ist der Consensus. Er suggeriert eine Einigung - aber nur die wenigsten wissen überhaupt, wer sich mit wem worüber einigt und warum dieses Verfahren so komplex und dennoch essenziell für die Manipulationssicherheit der Blockchain ist.

Consensus: Chancengleichheit für Knoten

Wenn die Macht über das System auf alle Beteiligten verteilt ist, besteht keine Möglichkeit des einseitigen Missbrauchs. So lautet das Kredo von dezentralisierten Systemen. Unter dem Eintrag "decentralization" findet man im Merriam-Webster-Wörterbuch folgende Definition: "the dispersion or distribution of functions and powers". Frei übersetzt bedeutet das so viel wie "Streuung oder Verteilung von Zuständigkeiten und Machtbefugnissen". Übertragen auf den Blockchain-Kontext, beschreibt die Definition treffend den Aufbau des Netzwerks. Die Knoten darin sollen von möglichst vielen und voneinander unabhängigen Instanzen betrieben werden, die jeweils für sich genommen wenig Einfluss besitzen.

Da sie alle gleichberechtigt sind, kann es unter ihnen auch keinen geben, der koordinative Aufgaben aus einer Hand erledigt. Etwa, zu entscheiden, in welcher Reihenfolge Transaktionen ans Netzwerk herangetragen wurden. Erschwert wird diese Entscheidung dadurch, dass alle Knoten simultan Transaktionen entgegennehmen, die sie anschließend an die anderen Knoten weiterleiten. Dadurch kommen sie auf den verschiedenen Knoten in unterschiedlicher Reihenfolge an.

Die Frage der Reihenfolge wird jedoch dann relevant, wenn es sich um zwei Transaktionen handelt, die sich widersprechen. Die Auswirkungen von solchen Transaktionen werden durch das Double-Spend-Problem veranschaulicht: Ein Sender könnte sein Guthaben an zwei verschiedene Empfänger überweisen und dadurch Falschgeld erschaffen. In diesem Fall darf nur die erste der beiden Transaktionen als gültig akzeptiert werden und die zweite muss abgelehnt werden.

Wie aber soll die Reihenfolge festgelegt werden, wenn es niemanden gibt, der sie vorgibt? Hier kommt der Consensus ins Spiel: Knoten können eine Reihenfolge vorschlagen, während die anderen Knoten entscheiden, welchen Vorschlag sie akzeptieren. Damit keiner von ihnen zu viel Einfluss gewinnt, muss der Consensus für Chancengleichheit sorgen: Alle involvierten Knoten sollen im Schnitt gleich viele Vorschläge machen können und dadurch gleich oft die Gelegenheit haben, dass ihr Vorschlag akzeptiert wird.

Eine weitere, oft zitierte Eigenschaft von Blockchain Netzwerken lautet "trustless", was laut lexikalischer Definition mit "distrustful", also "misstrauisch" übersetzt werden kann. Im Blockchain-Kontext ist damit gemeint, dass die Teilnehmer gegenseitig nicht nur weisungsfrei sind, sondern sich nur auf Basis von kryptografisch verifizierbaren Beweisen vertrauen. Diese Prämissen sind notwendig, damit das Netzwerk nicht nur den Ausfall (Crash Fault Tolerance) einzelner Knoten übersteht, sondern auch eine koordinierte Verschwörung mehrerer Knoten (Byzantine Fault Tolerance) abwehren kann.

Dabei gibt es zwei Eigenschaften, die in einem Blockchain- Netzwerk gewährleistet werden müssen und die durch einen Angriff durch böswillige Knoten gefährdet sein könnten:

• Safety verlangt, dass die Entscheidungen der Knoten bzgl. der Reihenfolge von Transaktionen nicht auseinandergehen.

• Liveness erfordert, dass das Netzwerk irgendwann neue Transaktionen verarbeiten kann.

Kombiniert man diese beiden Eigenschaften, bedeutet das, dass die Knoten weder in eine dauerhafte Inkonsistenz noch in eine Pattsituation geraten dürfen.

Blockchain: Das Problem der Byzantinischen Generäle

Das zu Grunde liegende Problem wurde erstmals 1982 von Leslie Lamport und seinen Kollegen in Form einer fiktiven Geschichte über die Byzantinischen Generäle beschrieben: Darin umstellt eine Armee, angeführt von mehreren gleichberechtigten Generälen, eine Stadt. Um diese einzunehmen, müssen die Generäle dem Vorschlag von einem unter ihnen folgen und gleichzeitig aus verschiedenen Richtungen angreifen. Die Generäle haben keine Möglichkeit sich zu treffen, sondern können nur über Boten miteinander kommunizieren, ohne sich darauf verlassen zu können, dass die Boten ihre Nachrichten pünktlich überbringen. Gleichzeitig intrigieren einige Generäle, indem sie falsche Botschaften verschicken und dadurch einen unkoordinierten Angriff provozieren, der zur Vernichtung aller ehrlichen Generäle führen würde.

Bezieht man diese Analogie auf die Blockchain, sind die Generäle die Knoten. Die Frage, die sie immer wieder entscheiden müssen, ist, ob sie einen Block, den einer von ihnen vorgeschlagen hat, akzeptieren oder auf den nächsten Vorschlag warten. Da die Blöcke sequenziell nummeriert sind und eine eindeutig sortierte Liste von Transaktionen enthalten, bedeutet eine Einigung bzgl. der Blöcke gleichzeitig eine Lösung bzgl. der Reihenfolge der Transaktionen.

Um sich zu einigen, ob ein Block akzeptiert werden soll oder nicht, braucht es ein gemeinsames Regelwerk, an das sich alle ehrlichen Knoten halten können. Dieses Regelwerk wird als Consensus bezeichnet und hilft den Knoten dabei, eigenständig und automatisiert zu entscheiden, wann sie einen Block als gültig ansehen.

Lesetipp: Geistiges Eigentum - Wie Sie Ihre Algorithmen schützen

Über die Jahrzehnte wurden immer effizientere Consensus-Algorithmen entworfen. Zu den ersten und bekanntesten Algorithmen, aus der Zeit lange vor der Blockchain, gehören Paxos und Raft. Sie können nur mit "Generälen" umgehen, die auf keine Nachricht antworten, aber nicht mit "Intriganten", die den anderen bewusst irreführende Nachrichten senden.

Der aus dem Jahr 1999 stammende Practical Byzantine Fault Tolerance (PBFT) setzte schließlich neue Maßstäbe und diente zahlreichen Nachfolgern als Vorbild. Seine zahlreichen Weiterentwicklungen wie zum Beispiel Tendermint, Instanbul (IBFT) oder BFT-SMaRT werden heute in verschiedenen Blockchain-Technologien eingesetzt. Sie alle eint die Eigenschaft, dass sie Safety vor Liveness bevorzugen. Mit anderen Worten: Bis die entscheidende Mehrheit der Knoten sicher ist, dass sie einig sind, wird kein weiterer Block akzeptiert.

Als Alternative dazu sind sogenannte Proof of Authority (PoA) -Algorithmen wie Aura oder Clique entstanden. Diese bevorzugen Liveness vor Safety. Das heißt, sie akzeptieren in regelmäßigen Abständen neue, mitunter auch konkurrierende, Blöcke und entscheiden mit der Zeit darüber, welche von ihnen sie endgültig behalten. Was alle bisher genannten Algorithmen verbindet, ist die Annahme, dass sich die Knoten kennen und verlässlich identifizieren können. Dies ist jedoch nur in Permissioned-Netzwerken der Fall. Permissioned bedeutet in diesem Zusammenhang, dass alle Knoten, die über die Blöcke abstimmen, geprüft und zugelassen wurden und ihr Public Key allen Teilnehmern bekannt ist.

Consensus-Algorithmen: Entscheidung ohne Generäle

In Permissionless-Netzwerken kann jeder Knoten ohne vorherige Bekanntgabe seines Public Keys und Erlaubnis der anderen an der Wahl der Blöcke teilnehmen. In diesem Fall kann jedoch nicht ausgeschlossen werden, dass jemand mehrere Identitäten vortäuscht, um die Abstimmung zu beeinflussen. Ohne die wahre Anzahl der Generäle zu kennen, kann man auch nicht feststellen, ob die notwendige Mehrheit für einen Block gestimmt hat. Anstelle ihrer Identität wird eine andere Methode benötigt, um das Stimmrecht der einzelnen Knoten einzuschränken. Es kann beispielsweise proportional zu einer wertvollen und knappen Ressource, die jedem nur begrenzt zur Verfügung steht, verteilt werden. Während sich jeder mühe- und kostenlos beliebig viele Private Keys zulegen kann, muss er Ressourcen wie Rechen- oder Speicherkapazität erstmal teuer erwerben. Damit sind diese Ressourcen grundsätzlich geeignet, um das Stimmrecht daran zu knüpfen.

Da sich die Knoten untereinander aber nicht vertrauen, müssen sie beweisen, dass sie die Ressourcen tatsächlich besitzen, um ihr Stimmrecht ausüben zu können. Doch wie können sie beweisen, dass sie über eine bestimmte Rechenkapazität verfügen? Etwa indem sie eine Aufgabe berechnen, an der man die eingesetzte Rechenkapazität messen kann. Die Rechenaufgabe besteht darin, eine Zahl zu finden, die - eingebettet in den vorgeschlagenen Block - dessen Hashwert kleiner ist als die vorgegebene Obergrenze. Diese Rechenaufgabe ist nur durch ein Trial-and-Error-Verfahren zu lösen. Die Chance, sie vor allen anderen zu lösen und einen gültigen Block vorzuschlagen, ist umso höher, je mehr Rechenkapazität zur Verfügung steht und entsprechend mehr Zufallszahlen durchgetestet werden können. Ein solches Verfahren ist das gemeinsame Grundprinzip von Proof of Work (PoW) -basierten Consensus-Algorithmen wie zum Beispiel Hashcash (Bitcoin) oder Ethash (Ethereum).

Die Suche nach energieeffizienten Alternativen zu PoW, die weder auf die Sicherheit noch auf die Dezentralisierung des Netzwerks verzichten, gehört zu den spannendsten Forschungsfragen rund um Blockchain und Distributed-Ledger-Technologien. Neben Proof of Stake (PoS), bei dem das Stimmrecht durch die Menge an Kryptowährung im Besitzt des Knoten begrenzt wird, sind auch Consensus-Mechanismen wie jene von IOTA oder Hashgraph entstanden, die anstelle von Blöcken gerichtete, azyklische Graphen nutzen, um die Reihenfolge der Transaktionen zu bestimmen.

Nach heutigem Stand der Dinge kann keine dezentralisierte Blockchain oder Distributed-Ledger-Technologie ohne Consensus existieren. In einer einfacheren Variante - Crash Fault Tolerance - ist der Consensus auch Bestandteil von anderen verteilten Systemen wie etwa Datenbanken. Bei Blockchains wird eine Variante von Consensus - Byzantine Fault Tolerance - gesucht, die auch einer koordinierten Sabotage durch einige Knoten standhält. Je nach Art des Netzwerks sind verschiedene Algorithmen im Einsatz - weitere werden noch erforscht. (bw)