Schritt 19: Auswählen einer Transaktionshistorie

Wenn Computer mit den Füßen abstimmen

In Schritt 18 wurde gezeigt, wie die Knoten der Blockchain Transaktionsdaten und neue Blöcke verarbeiten. Allerdings kann sich die Transaktionshistorie der einzelnen Knoten des Systems als Folge von Verzögerungen oder Fehlern in der Nachrichtenweitergabe dennoch unterscheiden. In diesem Schritt geht es deshalb darum, wie sich Konflikte zwischen den unterschiedlichen Versionen der Transaktionshistorie einzelner Knoten beheben lassen.

Die Metapher

Wann haben Sie zuletzt einen Spaziergang im Park unternommen? Vielleicht ist Ihnen ja ein Phänomen aufgefallen, das sich in nahezu allen Parks weltweit finden lässt: Es gibt befestigte Wege​, die den Plänen und Ideen der Landschaftsgestalter entsprechen, und außerdem von den Parkbesuchern hinterlassene Trampelpfade​. Häufig handelt es sich bei diesen Pfaden um die kürzeste Verbindung zwischen zwei Sehenswürdigkeiten, zwei Sitzbänken oder anderen beliebten Zielen. Trampelpfade entstehen dort, wo viele Menschen unabhängig voneinander die befestigten Wege verlassen, weil es ihnen vorteilhaft erscheint, einem anderen als dem vorgesehenen Weg zu folgen. So betrachtet ist ein ausgetretener Pfad im Park eine spezielle Grundform der Demokratie: Es gibt keine offiziellen Umfragen oder Wahlen, die entscheiden, wo ein solcher Pfad geschaffen wird, sondern jeder Besucher entscheidet spontan, wo er entlang läuft und seine Fußstapfen hinterlässt. Seltener genutzte Pfade verschwinden nach und nach, wenn die Natur sie zurückerobert. Andere bleiben bestehen, weil sie von vielen Menschen genutzt werden. In diesem Lernschritt wird ein Aspekt der Blockchain erläutert, der an das Erscheinen und Verschwinden von Trampelpfaden in einem Park erinnert.

Das Ziel

Das Ziel besteht darin, eine eindeutige Transaktionsdatenhistorie unter allen Knoten im Netz beizubehalten, damit beim Abklären des Eigentums ungeachtet des befragten oder kontaktierten Knotens dasselbe Ergebnis erreicht wird.

Die Herausforderung

Der in Schritt 18 beschriebene Blockchain-Algorithmus erlegt allen Knoten im System einen zweistufigen Arbeitstakt​ auf: Zu jedem beliebigen Zeitpunkt ist jeder Knoten im System entweder mit der Untersuchung eines neuen, von einem Peer erzeugten Blocks beschäftigt oder ringt darum, selbst der nächste Knoten zu sein, der einen neuen Block erzeugt, der wiederum von allen anderen Knoten untersucht wird. Allerdings gibt es keinen übergeordneten Taktgeber, der den Knoten vorschreibt, welche der beiden Arbeiten sie gerade erledigen sollen. Das Eintreffen neuer Blöcke in den Posteingängen der einzelnen Knoten löst den Arbeitstakt des Knotens aus – ebendieses Eintreffen hängt jedoch stark von den Fähigkeiten des Netzwerks zur Nachrichtenverbreitung ab: Nachrichten können verloren gehen, verzögert zugestellt werden oder in zufälliger Reihenfolge eintreffen. Somit liegen zu einem bestimmten Zeitpunkt keine identischen Informationen an allen Knoten vor. Außerdem erfolgt der Wechsel zwischen den beiden Arbeitstakten nicht an allen Knoten gleichzeitig. Stattdessen wechselt jeder Knoten abhängig vom Eintreffen der Nachrichten im Posteingang individuell zwischen den Arbeiten – und das führt zu Überlappungen der Arbeitstakte unter den Knoten. Beide Effekte stellen ein gewaltiges Hindernis für das Führen einer eindeutigen Transaktionsdatenhistorie bei allen Peers im Netz dar. Die Herausforderung besteht also darin, eine Möglichkeit zu finden, trotz aller Widrigkeiten bei der Nachrichtenzustellung und ohne Rückgriff auf eine zentralisierte Lösung eine eindeutige Transaktionsdatenhistorie auszuwählen.

Die Idee

Unser Beispiel mit den Trampelpfaden im Park zeigt, dass eine Gruppe von Menschen allein durch unabhängiges Abstimmen »mit den Füßen« eine Einigung oder einen Konsens​​ für kollektive Entscheidungsprobleme erzielen kann. Diese Art Abstimmungsverhalten​ wird häufig als verteilte Konsensentscheidung bezeichnet, da sie das Ergebnis unabhängig voneinander agierender Individuen ohne zentrale Kontrolle oder Koordinierung ist.

Hinweis

Konsens ist laut Duden die Übereinstimmung der Meinungen mehrerer Parteien. Eine verteilte Konsensentscheidung ist die Übereinstimmung der Mitglieder in einem rein verteilten Peer-to-Peer-System.

Fälle, in denen eine Gruppe oder ein Schwarm unabhängig voneinander agierender Individuen ein kollektives Problem löst, zeichnen sich durch die folgenden Bedingungen​ aus:[1]

  1. Eine Gruppe von unabhängigen Individuen agiert in einer identischen Umgebung.

  2. Es liegt ein kollektives Entscheidungsproblem vor.

  3. Die Individuen versuchen unabhängig voneinander dasselbe Ziel zu erreichen.

  4. Die individuellen Handlungen des Einzelnen zum Erreichen des Ziels hinterlassen sichtbare Spuren in der Umgebung, die beim Lösen des kollektiven Entscheidungsproblems helfen.

  5. Die Individuen nutzen ein identisches Kriterium zum Bewerten des Entscheidungsproblems auf der Grundlage von Veränderungen ihrer Umgebung.

Die Idee der Blockchain besteht darin, alle Knoten unabhängig voneinander »mit den Füßen« abstimmen zu lassen und somit zu einer kollektiven Übereinstimmung dahingehend zu gelangen, welche Version der Transaktionshistorie gelten soll. Die uns an dieser Stelle unseres Lernpfades bekannte Blockchain erfüllt die ersten vier Bedingungen der kollektiven Entscheidungsfindung:

  1. Alle Knoten arbeiten in der identischen Umgebung, nämlich dem Netzwerk mit seinen Knoten, die jeweils ein eigenes Exemplar der Blockchain-Datenstruktur führen, und unter dem Einfluss des Blockchain-Algorithmus, der das Verhalten der Knoten regelt.

  2. Das Entscheidungsproblem besteht darin, kollektiv eine Transaktionshistorie auszuwählen.

  3. Alle Knoten sind bestrebt, ihr jeweiliges Einkommen zu maximieren – hierbei handelt es sich um die Belohnungen für das Eintragen neuer, gültiger Blöcke in die Blockchain-Datenstruktur.

  4. Um das jeweilige Ziel zu erreichen, verbreiten sämtliche Knoten ihre neuen Blöcke zur Untersuchung und Annahme an alle Peers. Dadurch hinterlässt jeder Knoten seinen individuellen Fußabdruck in der Umgebung, also der kollektiv verwalteten Blockchain-Datenstruktur.

Allerdings fehlt hier noch der fünfte Punkt: ein Kriterium, das sämtliche Knoten verwenden, um eine Entscheidung bezüglich der Veränderungen in ihrer Umgebung zu treffen. Die Idee für das Auswahlverfahren einer Transaktionsdatenhistorie beruht darauf, wie neue Blöcke in die Blockchain-Datenstruktur eingetragen und wie die Daten gegen Manipulationen geschützt werden. Durch den Arbeitsnachweis ist das Eintragen eines neuen Blocks mit viel Rechenaufwand verbunden – noch rechenintensiver ist allerdings das Manipulieren der Transaktionshistorie. Der insgesamt eingesetzte Rechenaufwand für das Erstellen einer Transaktionshistorie erscheint daher als natürliches Kriterium für die Auswahl einer Transaktionsdatenhistorie, falls es mehrere konkurrierende Versionen derselben gibt. Sofern sämtliche Knoten des Systems dasselbe Kriterium für die Wahl einer Transaktionshistorie verwenden, werden sie sich schließlich alle für dieselbe Version der Historie entscheiden. Die kollektiv ausgewählte Version der Transaktionshistorie wird häufig als maßgebliche Kette, maßgebliche Blockchain​ oder ​maßgebliche Transaktionshistorie bezeichnet.

Funktionsweise

Das Auswählen einer Transaktionshistorie anhand des in sie geflossenen Rechenaufwands hat zu zwei Kriterien geführt:

Kriterium der längsten Kette

Das Kriterium der längsten Kette​​​ beruht auf der Vorstellung, dass zur Erstellung derjenigen Blockchain-Datenstruktur, die aus den meisten Blöcken besteht, der insgesamt größte Rechenaufwand betrieben wurde. Stellen Sie sich dazu eine Ausgangssituation vor, in der sämtliche Knoten eines verteilten Systems eine identische Version der Blockchain-Datenstruktur​​ führen. Diese Blockchain-Datenstruktur ist in Abbildung 19.1 schematisch dargestellt. (Aus Gründen der Einfachheit sind darin viele Details weggelassen.) Jeder Kasten steht für einen Block, der über einen verkürzten Hashwert identifiziert wird. Der Pfeil, der von einem auf den anderen Kasten verweist, steht für die Hashreferenz, die von einem Block-Header auf seinen Vorgänger verweist. In dieser Ausgangssituation haben alle Knoten einer Transaktionsdatenhistorie zugestimmt und bemühen sich darum, die vorhandene Kette um einen weiteren Block zu ergänzen, der auf Block A397 als seinen Vorgänger verweist.

Abb. 19.1: Anfängliche Blockchain-Datenstruktur in einem verteilten System

Das Erstellen eines neuen Blocks gestaltet sich als Wettlauf zwischen allen Knoten, denn dazu muss ein für diesen Block eindeutiges Hashpuzzle gelöst werden. Abbildung 19.2 zeigt die Blockchain-Datenstruktur, die bei den meisten Knoten vorliegt, nachdem ein Knoten das Hashpuzzle für einen neuen Block gelöst und diesen an seine Peers übermittelt hat. Diese Knoten führen nun also die Blockchain-Datenstruktur gemäß Abbildung 19.2 und arbeiten daran, sie um einen neuen Block zu erweitern, der auf Block AB12 als seinen Vorgänger verweist. Aus Sicht der Mehrheit gibt es nur eine Version der Blockchain-Datenstruktur, die drei Blöcke enthält, allerdings dauert das Übertragen eines neuen Blocks im Netzwerk eine gewisse Zeit und kann durch diverse Probleme verzögert werden. Aufgrund einer Verzögerung bei der Nachrichtenübermittlung hat eine Minderheit der Knoten den Block AB12 noch nicht erhalten. Diese Knoten versuchen nach wie vor, die in Abbildung 19.1 dargestellte Kette zu erweitern. Schließlich löst einer davon erfolgreich das Hashpuzzle für einen neuen Block mit dem Hashwert DD01 und übermittelt diesen an seine Peers. Irgendwann liegen der Mehrheit der Knoten sowohl der Block AB12 als auch der Block DD01 vor. Die Mehrheit der Knoten führt nun die in Abbildung 19.3 dargestellte Blockchain-Datenstruktur, die zwei Äste an einem gemeinsamen Stamm aufweist. In diesem Fall hilft das Kriterium der längsten Kette​​​ nicht weiter, da kein eindeutiges Ergebnis vorliegt: Beide Ketten (AB12 A397 33FF und DD01 A397 33FF) weisen dieselbe Länge auf.

Abb. 19.2: Ergebnis nach dem Anfügen eines neuen Blocks an die bestehende Blockchain-Datenstruktur

Wenn der in Abbildung 19.3 dargestellte Fall eintritt, können die Knoten frei entscheiden, welcher Ast zum Anfügen eines neuen Blocks verwendet wird.

Abb. 19.3: Die Blockchain-Datenstruktur nach der verzögerter Zustellung eines neuen Blocks

Einige Knoten versuchen möglicherweise, einen neuen Block zu erstellen, der auf Block AB12 als Vorgänger verweist, andere dagegen arbeiten an einem Block, der auf Block DD01 als Vorgänger verweist. Plötzlich empfängt die Mehrheit der Knoten zwei neue Blöcke, nämlich BB11 und CCC1, die beide auf Block AB12 als Vorgänger verweisen. Das kann geschehen, wenn zwei Knoten nahezu zeitgleich den Arbeitsnachweis (das Hashpuzzle) für ihre Blöcke fertigstellen. Sobald diese beiden neuen Blöcke in die Blockchain-Datenstruktur eingetragen sind, ergibt sich eine Datenstruktur, die drei Ketten enthält (vgl. Abbildung 19.4). Eine der Ketten enthält lediglich drei, die anderen beiden Ketten dagegen vier Blöcke.

Das Kriterium der längsten Kette schließt die kürzeste Kette eindeutig aus, also die Kette mit der Blockreihenfolge DD01 A397 33FF. Allerdings liegt bei Anwendung des Kriteriums der längsten Kette trotzdem kein eindeutiges Ergebnis vor, denn es existieren noch immer zwei Ketten mit identischer Länge. Es kann also weiterhin vorkommen, dass einige Knoten einen Block erstellen wollen, der auf Block BB11 als Vorgänger verweist, während andere Knoten hingegen an einem neuen Block arbeiten, der auf Block CCC1 als Vorgänger verweist.

Abb. 19.4: Eine Blockchain-Datenstruktur, nachdem zwei Knoten nahezu zeitgleich den Arbeitsnachweis ihres neuen Blocks fertiggestellt haben

Schließlich trifft ein neuer Block ein, der auf Block BB11 als Vorgänger verweist, sodass die in Abbildung 19.5 dargestellte Datenstruktur entsteht. Diese enthält viele konkurrierende Versionen der Transaktionshistorie​, doch mit dem Kriterium der längsten Kette​​​ lässt sich ein eindeutiger »Gewinner« feststellen, nämlich die Kette mit den Blöcken 0101 BB11 AB12 A397 33FF. Die Mehrheit der Knoten und irgendwann auch sämtliche Knoten im System verwenden dann diese Kette zum Abklären von Eigentum. Außerdem versucht die Mehrheit der Knoten – und irgendwann auch ihre Gesamtheit –, diesen Ast zu erweitern und einen neuen Block zu erstellen, der auf Block 0101 als Vorgänger verweist.

Abb. 19.5: Schematische Darstellung einer Blockchain-Datenstruktur, die nach dem Eintreffen eines weiteren Blocks eine längste Kette enthält

Eine wichtige Erkenntnis ist, dass die Blockchain-Datenstruktur tatsächlich keine geradlinige Kette im klassischen Sinn darstellt, sondern eher einem Baum oder Säulenkaktus ähnelt. Es handelt sich also eigentlich nicht um eine Blockkette, sondern um einen »Blockkaktus«, dessen Äste konkurrierende Versionen der Transaktionshistorie repräsentieren. Unter Anwendung des Kriteriums der längsten Kette erkennen irgendwann sämtliche Knoten einstimmig dieselbe Version der Transaktionshistorie an.

Hinweis

Aufgrund ihrer Form wird die Blockchain-Datenstruktur häufig als Baumdatenstruktur​ bezeichnet. Der allererste und somit älteste Block​ in der Blockchain-Datenstruktur besitzt keinen Vorgänger und wird daher auch als Wurzel der baumförmigen Struktur bezeichnet. Ein Block ohne Nachfolger wird Blatt genannt. Eine gerade Abfolge von Blöcken von der Wurzel zu einem Blatt ist ein Pfad.

Kriterium der schwersten Kette

In Schritt 16 haben Sie gelernt, dass in Blockchain-Anwendungen selten ein gleichbleibender Schwierigkeitsgrad für das Hashpuzzle verwendet wird,​ das beim Eintragen eines neuen Blocks in die Blockchain-Datenstruktur gelöst werden muss. Stattdessen wird der Schwierigkeitsgrad normalerweise dynamisch bestimmt, sodass sich die Blöcke im Hinblick auf den Rechenaufwand, der zum Eintragen in die Blockchain-Datenstruktur erforderlich war, unterscheiden. Andererseits beruht das Kriterium der längsten Kette​​​ auf der Vorstellung, dass der Pfad, der aus den meisten Blöcken besteht, den insgesamt größten Rechenaufwand repräsentiert. Im Falle eines heterogenen Schwierigkeitsgrades ist der längste Pfad jedoch nicht zwingend der, für den der größte Rechenaufwand aufgebracht wurde.

Der für einen Pfad erforderliche Rechenaufwand kann jeweils ermittelt werden, indem man die Schwierigkeitsgrade sämtlicher Blöcke in dem betreffenden Pfad addiert. Dieser Wert lässt sich jederzeit berechnen, da jeder Block-Header den Schwierigkeitsgrad seines zugehörigen Hashpuzzles enthält. Die Summe der Schwierigkeitsgrade eines Pfades wird auch als dessen Gewicht bezeichnet. Abbildung 19.6 zeigt die aus Abbildung 19.5 bekannte Blockchain-Datenstruktur, allerdings ist hier zusätzlich für jeden einzelnen Block der Schwierigkeitsgrad angegeben. Die längste Kette (der Pfad von der Wurzel 33FF zum Blatt 0101) hat ein Gewicht von 5, die zweitlängste Kette (der Pfad von der Wurzel 33FF zum Blatt CCC1) ein Gewicht von 6. Wird für die Blockchain-Datenstruktur aus Abbildung 19.6 das Kriterium der längsten Kette zugrunde gelegt, wählen die Knoten eine Kette aus, die nicht den größten Rechenaufwand repräsentiert.

Daher kommt das Kriterium der längsten Kette in Blockchains, die einen dynamischen Schwierigkeitsgrad verwenden, nicht zum Einsatz. Stattdessen nutzen diese das Kriterium der schwersten Kette​​​: Gewählt wird die Transaktionsdatenhistorie, die die schwerste Kette darstellt. Ist der Schwierigkeitsgrad sämtlicher Blöcke identisch, ist der längste Pfad auch der schwerste Pfad, sodass die Kriterien der längsten Kette und der schwersten Kette zum selben Ergebnis gelangen.

Abb. 19.6: Schematische Darstellung einer Blockchain-Datenstruktur und der Schwierigkeitsgrade

Folgen der Entscheidung für eine Kette

Wird unter mehreren widersprüchlichen bzw. konkurrierenden Versionen eine bestimmte Kette ausgewählt und als maßgebliche Kette bestimmt, hat das folgende Konsequenzen:

Verwaiste Blöcke

Die kollektiv gepflegte Blockchain-Datenstruktur ähnelt einem Baum, dessen Äste für die unterschiedlichen Versionen der Transaktionshistorie stehen. Wendet man ein Auswahlkriterium darauf an, wird ein Pfad des Baums ausgewählt und als maßgebliche Version der Transaktionsdatenhistorie bestimmt. Alle Blöcke der baumförmigen Datenstruktur, die nicht Teil des maßgeblichen Pfades sind, werden von den Knoten aufgegeben und als verwaiste Blöcke​​​ bezeichnet.[5] Wird zum Beispiel das Kriterium der längsten Kette auf die Situation in Abbildung 19.4 angewendet, wird der Block DD01 zum verwaisten Block. In Abbildung 19.5 sind die Blöcke DD01 und CCC1 kein Teil der maßgeblichen Kette und werden somit aufgegeben. Wird das Kriterium der schwersten Kette für die Situation in Abbildung 19.6 zugrunde gelegt, zeigt sich, dass die Blöcke 0101, BB11 und DD01 kein Teil der maßgeblichen Blockchain sind, sodass diese aufgegeben werden.

Zurückgeforderte Belohnung

Verwaiste Blöcke taugen nicht dazu, Eigentum abzuklären, denn sie tragen nicht zur maßgeblichen Kette bei. Daher wird die Belohnung​​, die einem Knoten für ihre Erzeugung und Einreichung gutgeschrieben wurde, zurückgefordert. Das folgt aus den Regeln 11 und 13 des Blockchain-Algorithmus, die wir in Schritt 18 behandelt haben, welche besagen, dass ein bereits in die Blockchain-Datenstruktur eingetragener Block, der nachträglich als ungültig oder nutzlos identifiziert wird, samt aller darauf folgenden Blöcke logisch aus der Blockchain-Datenstruktur entfernt und den für deren Erstellung verantwortlichen Knoten die dafür gutgeschriebene Belohnung entzogen wird.

Abklären des Eigentums

Nur solche Transaktionen, die Teil der maßgeblichen Kette sind, gelten als abgewickelt und werden zum Abklären von Eigentum genutzt. Verwaiste Blöcke sind kein Teil der kollektiv ausgewählten maßgeblichen Kette und somit sind auch ihre Transaktionsdaten kein Teil der maßgeblichen Transaktionsdatenhistorie. Stattdessen werden sie so behandelt, als hätten sie nie stattgefunden. Wenn es um das Abklären von Eigentum​ geht, gelten sie als nicht existent.

Neuverarbeitung von Transaktionen

Transaktionsdaten, die Teil von verwaisten Blöcken sind, wurden ursprünglich eingereicht, um sie in die Transaktionshistorie einzutragen. Natürlich war zu diesem Zeitpunkt nicht geplant, dass sie irgendwann in einem verwaisten Block enden und als nie durchgeführt behandelt werden würden – vielmehr ist dies das Ergebnis der zufälligen Natur des Hashpuzzles und seiner Rolle in der wachsenden Blockchain-Datenstruktur. Aber die Transaktionsdaten in verwaisten Blöcken erhalten eine zweite Chance, zu einem Teil der ausgewählten Transaktionshistorie zu werden, denn sie werden abermals in den Posteingang der Knoten gelegt, sodass sie später erneut verarbeitet und in die Blockchain-Datenstruktur eingetragen werden können. Das folgt aus Regel 11 des Blockchain-Algorithmus, die Sie in Schritt 18 nachschlagen können. Es kann also vorkommen, dass Transaktionen, die zuvor Bestandteil der maßgeblichen Kette waren, für eine Weile verschwinden, sofern die Mehrheit der Knoten den Block, der sie enthält, aufgibt. Allerdings sind sie nach der erneuten Verarbeitung wieder sichtbar, weil sie dadurch wieder Teil der maßgeblichen Kette werden.

Wachsender gemeinsamer Stamm

Das Anwenden eines Auswahlkriteriums führt nicht immer zu einem eindeutigen Ergebnis. Die Beispiele in den Abbildungen 19.3 und 19.4 zeigen Fälle, in denen mehr als eine längste Kette vorliegt. In diesen Fällen enthält die Blockchain-Datenstruktur zwei Pfade identischer Länge, die aus einem gemeinsamen Stamm entspringen. In Abbildung 19.3 umfasst dieser gemeinsame Stamm lediglich zwei Blöcke, welche die kurze Kette A397 33FF bilden. In Abbildung 19.4 besteht der gemeinsame Stamm bereits aus drei Blöcken mit der Kette AB12 A397 33FF – der vorherige gemeinsame Stamm ist darin enthalten. Es zeigt sich also, dass auch bei mehrdeutigen Ergebnissen für ein Auswahlkriterium ein weniger mehrdeutiger gemeinsamer Stamm​​ die Basis der konkurrierenden Versionen der Transaktionshistorie bildet. Je weiter man in einem Pfad der Blockchain-Datenstruktur in Richtung der Wurzel geht, desto weniger mehrdeutig fällt die Entscheidung aus, ob ein Block Bestandteil der maßgeblichen Kette ist oder nicht.

Eventual Consistency

​Betrachten wir den Fall, der in Abbildung 19.4 dargestellt ist: Hier führt das Kriterium der längsten Kette nicht zu einem eindeutigen Ergebnis. Wie Sie Abbildung 19.5 entnehmen können, entscheidet der nächste in die Blockchain-Datenstruktur eingetragene Block darüber, ob Block BB11 oder Block CCC1 zum Teil der längsten Kette oder aber aufgegeben wird. Doch wer entscheidet, dass der nächste Block, der gemäß Abbildung 19.4 in die Blockchain-Datenstruktur eingetragen wird, auf Block BB11 als Vorgänger verweist und somit Block CCC1 aufgegeben wird? Die überraschende und vielleicht auch enttäuschende Antwort lautet, dass diese Entscheidung ganz und gar zufällig ist. Wenn der in Abbildung 19.4 dargestellte Fall eintritt, können die Knoten frei bestimmen, welcher Ast für das Anfügen eines neuen Blocks verwendet wird. Es kann also weiterhin vorkommen, dass einige Knoten einen neuen Block erstellen wollen, der auf Block BB11 als Vorgänger verweist, andere dagegen an einem Block arbeiten, der auf Block CCC1 als Vorgänger verweist. Welcher Knoten den neuen Block zuerst fertigstellt, ist abhängig von der Lösung des Hashpuzzles: Das Lösen dauert eine endliche, aber zufällige Zeitspanne. Und es ist genau der Knoten, der das Hashpuzzle für einen neuen Block zuerst löst, der entscheidet, an welchen der konkurrierenden Äste dieser Block angehängt wird und somit darüber entscheidet, welche Blöcke Teil der maßgeblichen Kette werden und welche Blöcke aufgegeben werden. Das Wachstum der baumförmigen Blockchain-Datenstruktur enthält eine Zufallskomponente, die eine Folge einerseits des Geschwindigkeitswettbewerbs um die Lösung des Hashpuzzles und andererseits der zufälligen Schwankungen in der Nachrichtenübermittlung im Netzwerk ist. Der nächste Block, dessen Erscheinungszeitpunkt von der zufälligen Lösungsdauer des Hashpuzzles abhängig ist, bestimmt darüber, welcher der Pfade verlängert und welcher Block aufgegeben wird.

Sie haben bereits gelernt, dass konkurrierende Äste der baumförmigen Blockchain-Datenstruktur auf einen gemeinsamen Stamm zurückgehen, der ungeachtet von aufgegebenen Blöcken oder Blättern konstant bleibt. Daher sind die Blöcke weit oben in der maßgeblichen Blockchain am stärksten von der zufälligen Natur des Eintreffens neuer Blöcke betroffen, Blöcke weiter unten in der Blockchain-Datenstruktur dagegen weniger stark. Wir können diesen Umstand in die folgenden Aussagen fassen: Je weiter unten (also näher an der Wurzel) in der maßgeblichen Blockchain sich ein Block befindet, ...

  • ... desto länger ist es her, dass er eingetragen wurde.

  • ... desto mehr Zeit ist vergangen, seit er zum Teil der Blockchain-Datenstruktur wurde.

  • ... desto mehr gemeinsame Anstrengungen wurden unternommen, um weitere Blöcke hinzuzufügen.

  • ... desto weniger stark wird er von der Zufallskomponente beim Anfügen von neuen Blöcken an die maßgebliche Kette beeinflusst.

  • ... desto unwahrscheinlicher ist es, dass er aufgegeben wird.

  • ... desto höher ist seine Akzeptanz unter den Knoten des Systems.

  • ... desto fester verankert ist er in der gemeinsamen Historie der Knoten.

Die Tatsache, dass die Gewissheit bezüglich der Aufnahme von Blöcken in die maßgebliche Blockchain​ im Laufe der Zeit und mit der Eintragung neuer Blöcke zunimmt, wird als ​Eventual Consistency bezeichnet.

Robustheit gegenüber Manipulationen

Der Pfad der baumförmigen Blockchain-Datenstruktur, der den größten Rechenaufwand darstellt, ist die maßgebliche Version der Transaktionshistorie. Um diesen maßgeblichen Pfad aufbauen und weiterführen zu können, muss lediglich die Mehrheit der Rechenleistung des Gesamtsystems kontrolliert werden. Um einen neuen maßgeblichen Pfad aufzubauen, der an einem der inneren Blöcke der Blockchain-Datenstruktur beginnt, muss der von der Mehrheit geführte Pfad eingeholt und überholt werden. Diese Tatsache bildet das stabile Fundament der Blockchain und ist somit der Grund für ihre Robustheit​.

Solange die ehrlichen Knoten die Mehrheit der Rechenleistung des Gesamtsystems stellen, wird der von ihnen geführte Pfad am schnellsten wachsen und so alle konkurrierenden Pfade hinter sich lassen. Um einen inneren Block zu manipulieren, müsste ein Angreifer den Arbeitsnachweis für diesen Block erneut führen und in der Folge natürlich auch die Hashpuzzles aller nachgelagerten Blöcke lösen – und zwar in einer Geschwindigkeit, die es ihm erlaubt, den von den ehrlichen Knoten geführten Pfad nicht nur einzuholen, sondern auch zu überholen. Allerdings ist der Aufbau eines neuen Pfades durch Ein- und Überholen des Mehrheitspfades unmöglich, wenn der Angreifer über weniger Rechenleistung verfügt als die Mehrheit. Somit wird jeder Versuch, einen neuen maßgeblichen Pfad mit gefälschten Transaktionen einzurichten, vom Fortschrittstempo des Pfades der ehrlichen Mehrheit überholt und folglich aufgegeben. Und dementsprechend ist die vom System geführte Transaktionshistorie nicht anfällig gegenüber Manipulationen durch eine unehrliche Minderheit.

Bedrohungen für das Abstimmverhalten

​Jede kollektive Entscheidungsfindung wird zum Ziel von Manipulationen, wenn die Beeinflussung des gesamten Verfahrens es wert zu sein scheint. Das gilt natürlich auch für die Blockchain und ihren Algorithmus für verteilte Konsensentscheidungen​. Eine Vielzahl von Manipulationsmöglichkeiten am Konsens-Algorithmus der Blockchain wird in der Forschungsliteratur diskutiert. Doch ungeachtet der auf den ersten Blick unterschiedlichen Manipulationsmöglichkeiten, ist deren Ziel doch stets dasselbe: Blöcke, die Teil der maßgeblichen Blockchain sind, in verwaiste Blöcke​​ zu verwandeln und eine neue maßgebliche Blockchain​ aufzubauen, die eine Transaktionsdatenhistorie und eine alternative Verteilung der Eigentumsrechte darstellt, die dem Angreifer zum Vorteil gereichen. Allerdings können derartige Manipulationen von verschiedenen Standpunkten aus betrachtet werden: Wirtschaftlich wird dabei versucht, die Eigentumsverhältnisse durch Veränderungen der kollektiven Transaktionsdatenhistorie umzuschreiben. Was die kollektive Entscheidungsfindung betrifft, wird bei diesen Manipulationen versucht, eine Mehrheit der Stimmrechte zu erlangen, um so das gewünschte Ergebnis zu erzwingen. Vom technischen Standpunkt aus gesehen, untergräbt jeder Versuch einer Manipulation der kollektiven Entscheidungsfindung die Systemintegrität​. Bezüglich der verteilten Natur des Systems wird bei solchen Manipulationen versucht, zumindest vorübergehend ein verborgenes Element der Zentralität​ einzuführen, das den Zustand des Systems verändert – daher werden solche Angriffe häufig als ​51-Prozent-Angriffe bezeichnet.

Hinweis

Als 51-Prozent-Angriff wird der Versuch bezeichnet, in einer kollektiven Entscheidungsfindung die Mehrheit aller Stimmrechte zu erlangen oder zu kontrollieren.

Die Rolle des Hashpuzzles

In Schritt 16 haben Sie erfahren, wie die Unveränderlichkeit​ der Blockchain-Datenstruktur​ erreicht wird. Vom rein technischen Standpunkt aus betrachtet, ist das Hashpuzzle lediglich ein Mittel zum Zweck, mit dem Ziel, die Blockchain-Datenstruktur unveränderlich zu machen. Betrachten wir jedoch die Nutzung der Blockchain-Datenstruktur, tritt ein weiterer Aspekt des Hashpuzzles zutage: Während eine kollektive Entscheidung über die gültige Transaktionshistorie erfolgt, haben die einzelnen Blöcke der Blockchain-Datenstruktur die Funktion eines Stimmzettels. Dabei repräsentiert das Hashpuzzle einen Preis, der für die Stimmabgabe zu entrichten ist – und aufgrund dieser Kosten scheuen unehrliche Personen die Beteiligung an der Wahl.

Jeder Versuch, die kollektive Entscheidungsfindung in der Blockchain zu manipulieren, zielt darauf ab, die absolute Mehrheit der Stimmrechte hinter sich zu versammeln. Da das Stimmrecht in der Blockchain über das Hashpuzzle fest mit dem Einsatz von Rechenleistung verwoben ist, führt der Weg zur absoluten Mehrheit der Stimmrechte einzig und allein über die Mehrheit der Rechenleistung des gesamten Peer-to-Peer-Systems. Die Zuverlässigkeit und Vertrauenswürdigkeit, mit der die Blockchain zu einem kollektiven Ergebnis kommt, gründet auf der Annahme, dass keine einzelne Person oder Organisation die Mehrheit der Gesamtrechenleistung des Peer-to-Peer-Systems erlangen kann.

Warum das funktioniert

Der kollektive Aufbau der Blockchain-Datenstruktur ähnelt ein wenig einer kontinuierlich durchgeführten Wahl. Jeder Einzelknoten verfügt in dieser Dauerwahl, bei der über die gültige Transaktionshistorie entschieden wird, nur über eine winzige Stimme. Erst all diese winzigen Stimmen zusammen sind mächtig genug, um sich konsistent auf eine Historie zu einigen. Das funktioniert, weil die Beteiligung an der fortlaufenden Wahl einerseits Kosten verursacht und andererseits lohnenswert ist. Um die Stimme abzugeben, muss eine Arbeitsleistung erbracht werden – nämlich die Lösung des Hashpuzzles. Und durch das Abgeben der Stimme (also das Einreichen eines neuen Blocks), erhält der Knoten die Chance auf eine Belohnung. Da alle Knoten unabhängig voneinander das identische Kriterium bezüglich der Auswahl einer Transaktionshistorie nutzen, kommen auch alle Knoten irgendwann zu einem Konsens.

Ausblick

Dieser Schritt hat gezeigt, wie sich die Knoten in einem rein verteilten Peer-to-Peer-System gemeinsam für eine kollektiv geführte Transaktionsdatenhistorie entscheiden. Außerdem haben Sie die Bedeutung des Hashpuzzles für den Konsens und den Erhalt der Integrität kennengelernt. Im nächsten Schritt wird die Wichtigkeit der Belohnung und des Zahlungsmittels behandelt, die als Kompensation für den Beitrag der Peers zur Systemintegrität dienen.

Zusammenfassung

[1] Hassanien, Aboul Ella, und Emary, Eid. Swarm intelligence: Principles, advances, and applications. Boca Raton, FL: CRC Press, 2016.

[2] Nakamoto, Satoshi. Bitcoin: A peer-to-peer electronic cash system. 2008. https://bitcoin.org/bitcoin.pdf.

[3] Wood, Gavin. Ethereum: A secure decentralized generalized transaction ledger. 2014. http://gavwood.com/paper.pdf; Okupski, Krzysztof. Bitcoin developer reference. Arbeitspapier. 2014.

[4] Eventual Consistency (zu Deutsch etwa »irgendwann eintretende Konsistenz«) beschreibt den Umstand, dass Konsistenz erst im Zeitverlauf erreicht wird, sofern allen Netzwerkknoten ausreichend Zeit für Erhalt und Verarbeitung von Informationen zur Verfügung stand.

[5] Okupski, Krzysztof. Bitcoin developer reference. Arbeitspapier. 2014.