Konsensfindungsverfahren bei der Blockchain - Prof. Dr. Norbert Pohlmann

Was ist eine Konsensfindungsverfahren bei der Blockchain?

Damit ein neuer Block in die Blockchain aufgenommen werden kann, muss dieser zuerst validiert werden. Es muss sichergestellt werden, dass sämtliche darin enthaltenen Transaktionen echt und nicht manipuliert worden sind.
Da beim Blockchain-Konzept keine zentrale Instanz existiert, die einen neuen Block validieren kann, werden verteilte Konsensfindungs- und Validierungsverfahren benötigt, die helfen, diese Aufgabe sicher und vertrauenswürdig umsetzen zu können.
Das Konsensfindungsverfahren ist dazu da, dass ein Konsens gefunden wird und sich untereinander auf einen „korrekten“ Zustand geeinigt wird. Das Konsensfindungsverfahren hat dabei die Aufgabe, aus dem Peer-to-Peer-Blockchain-Netzwerk eine Node auszuwählen, die als nächstes aus den gesammelten Transaktionen diejenigen heraussuchen darf, aus denen ein neuer Block zusammengestellt, validiert und der Blockchain hinzufügt werden soll.

Jede Transaktion wird vom Blockchain-Teilnehmer signiert, der für die Daten verantwortlich ist und über die Nodes per Peer-to-Peer-Blockchain-Netzwerk verteilt.
Das heißt, im Prinzip hat jede Node alle Transaktionen und kann einen neuen Block erstellen.
Ein Konsensfindungsverfahren bestimmt, welche Node konkret als nächstes einen neuen Block erstellen, validieren und verteilen darf. Dabei entscheidet dann die ausgewählte Node anhand von Kriterien, wie Länge, Transaktionsgebühren usw., welche Transaktionen aus dem Transaktionsspeicher in einem neuen Block aufgenommen werden.

Verteilte Validierung und Hinzufügen eines neuen Blocks
Die ausgewählte Node nimmt nur die Transaktionen in einen neuen Block auf, die von Semantik und Syntax her richtig sind und die digitalen Signaturen der Blockchain-Teilnehmer der Transaktionen, die mit der Blockchain-Adresse übereinstimmen.

Wenn alle Transaktionen in Ordnung sind, wird mit diesen ein neuer Block mit HashPrev, Merkle Hash usw. generiert und an alle anderen Nodes des entsprechenden Peer-to-Peer-Blockchain-Netzwerkes verteilt. Jede Node hat dadurch jederzeit eine vollständige Version der aktuell gültigen Blockchain. Alle Nodes des Peer-to-Peer-Blockchain-Netzwerkes überprüfen die empfangenden neuen Blöcke der ausgewählten Nodes, ehe sie diese der eigenen Blockchain-Version hinzufügen. Dafür kontrollieren sie sämtliche im Block enthaltenen Transaktionen. Außerdem kontrollieren sie den Block selbst darauf, ob zum Beispiel der Proof-of-Work erbracht ist und ob die Hashwerte korrekt sind. Sobald ein Block oder auch nur eine einzige in dem Block enthaltene Transaktion eine der Regeln verletzt, wird der Block abgelehnt und nicht in die Blockchain der eigenen Version aufgenommen. Das geschieht selbst dann, wenn jede andere Node der Blockchain den Block für zulässig hält. Es ist essentiell für die Sicherheit und Vertrauenswürdigkeit der Blockchain, dass sich alle Nodes ihr Urteil selbst bilden.
Dieses Prinzip des Distributed Consensus macht die Konsistenzprüfung der Transaktionen vollkommen unabhängig von einer einzelnen vertrauenswürdigen Instanz. Für die Herstellung des Konsenses gibt es verschiedene Verfahren zwischen den Nodes, die festlegen, wer für den Abschluss neuer Transaktionen und das Hinzufügen eines bestimmten Blocks an die Blockchain verantwortlich ist.

Proof-of-Work Konsensfindungsverfahren

Proof-of-Work (PoW) war die erste und ist die aktuell gebräuchlichste Methode zur Konsensfindung und wird zum Beispiel aktuell von der Bitcoin-Blockchain genutzt. Hier konkurrieren die einzelnen Nodes als sogenannte „Miner“ untereinander, indem sie jeweils ein mathematisches Problem – dessen Schwierigkeit sich dynamisch ändern lässt – lösen müssen. Jeder Miner einer Node muss einen Hashwert für einen Block finden, der einem bestimmten vorgegebenen Muster entspricht. Dieses Muster wird vom Blockchain-Netzwerk eigenständig festgelegt, wobei sich die Schwierigkeit mit der Anzahl der vorgegebenen Stellen des Musters erhöht. Zum Beispiel soll ein Hashwert fünf führende Nullen als Muster besitzen, siehe Difficulty-Feld im Block-Header.

Die einzige Möglichkeit für die Nodes, diesen speziellen Hashwert zu erzeugen, ist die Veränderung des NONCE-Wertes im Block-Header. Somit wird die Konsensfindung eines Blockes zu einem Glückspiel für die Miner in einer Node, da diese nun einen NONCE-Wert für diesen Block-Header finden müssen, der die Eigenschaften des zu suchenden Hashwertes ergibt. Der Miner, der dieses Problem als erstes gelöst hat, darf den nächsten Block an die Blockchain anhängen. Die Komplexität des Problems wird in der Praxis bei der Bitcoin-Blockchain so gewählt, dass die Aufgabe im Schnitt 10 min dauern soll. Das bedeutet, dass die Transaktionen nur alle 10 min in einem Block der Blockchain hinzugefügt werden und gültig sind.

Ablauf des Minings

1. Alle Miner generieren eine Nonce (Zufallszahl).

2. Diese Zufallszahl mit allen weiteren Daten im Block-Header wird als Input von Hashfunktionen berechnet.

3. Es wird dann überprüft, ob der berechnete Hashwert den Kriterien vom Feld Difficult (bestimmte Anzahl von führenden Nullen) im Block-Header entspricht.

Wenn ja, hat der entsprechende Miner gewonnen. Wenn nein, wird eine neue Zufallszahl generiert und ein neuer Versuch gestartet.

Bewertung Proof-of-Work (PoW)

Es kann passieren, dass zwei Miner zur gleichen Zeit den notwendigen Hashwert berechnen. Wenn die Nonce 32 Bit lang ist, gibt es 2³² verschiedene Kombinationen (42.949.667.296).

Die Berechnung des mathematischen Problems beim Proof-of-Work-Konsensfindungsverfahren kostet sehr viel Energie. Laut dem sogenannte “Cambridge Bitcoin Electricity Consumption Index” lag der Energieverbrauch 2020 durch die Bitcoin-Technologie bei 115 Terrawattstunden (TWh). Das ist der jährliche Stromverbrauch von Pakistan.

Practical Byzantine Fault Tolerance (PBFT) Konsensfindungsverfahren

Practical Byzantine Fault Tolerance (PBFT) ist ein Verfahren, welches böswillige Nodes toleriert. Hier gibt es eine ausgewählte Gruppe an „Validating Peers“, die alle Transaktionen erhalten. Sie wählen untereinander einen „Leader“ aus; dieser gibt eine genaue Reihenfolge der Transaktionen vor, in der diese in den Block eingefügt werden. Diese wird von ihm wiederum an alle „Validating Peers“ gebroadcasted. Anschließend führt jeder „Validating Peer“ sämtliche Transaktionen in dem Block in der vorgegebenen Reihenfolge aus und berechnet den Hashwert. Dieses Ergebnis wird wiederum an die anderen „Validating Peers“ gebroadcasted und mit deren Ergebnissen verglichen. Wenn mehr als 2/3 der anderen Peers dasselbe Ergebnis haben, wird der Block endgültig zur lokalen Kopie der Blockchain verstetigt.

Mechanismus: Byzantine Fault Tolerance (Kompensation von fehlerhaften Komponenten)

Ein zuverlässiges System muss dazu in der Lage sein, den Ausfall einer oder mehrerer Komponenten zu kompensieren. Eine fehlerhafte Komponente kann ein Verhalten zeigen, das häufig übersehen wird, nämlich das Senden von widersprüchlichen Informationen an verschiedene Teile des Systems. Mit dieser Art von Fehler in einem System umzugehen, wird abstrakt im „Byzantine Generals Problem“ ausgedrückt. Die Byzantine Fault Tolerance (byzantinische Fehlertoleranz) befasst sich mit diesem Problem und bietet eine Lösung, mit der zuverlässig Systeme implementiert werden können, auch wenn fehlerhafte Komponenten vorhanden sind.

Das Problem kann folgendermaßen beschrieben werden:

• Das klassische Problem kann auch anhand eines militärischen Beispiels gezeigt werden, dem Problem der byzantinischen Generäle.
• Bei diesem Problem lagert eine rote Armee im Tal und die blauen Generäle halten ihre Armeen auf den nahe gelegenen Bergen bereit. Die Aufgabe der blauen Generäle ist, festzustellen, wieviel Soldaten sie zusammen haben.
• Die Kommunikation erfolgt paarweise und ist unmittelbar und perfekt, aber m der Generäle sind Verräter (fehlerhaft) und verhindern aktiv, dass die loyalen Generäle eine Einigung erzielen, indem sie ihnen fehlerhafte und widersprüchliche Informationen bereitstellen.
• Die Frage ist, wie loyalen Generäle zu einer Einigung kommen können?
• Wir gehen davon aus, dass jeder General weiß, wie viele Leute er hat.
• Das Ziel ist, dass die Generäle ihre Truppenstärke austauschen, sodass nach Abschluss des Algorithmus jeder General einen Vektor der Länge n besitzt, der der Gesamtstärke aller Armeen entspricht.
• Ist General i loyal, enthält Element i seine Truppenstärke, andernfalls ist es undefiniert.
• In diesem Beispiel wird der Algorithmus für den Fall von n=4 und m=1 dargestellt
• Für diese Parameter führt der Algorithmus vier Schritte aus.

• Im ersten Schritt sendet jeder General eine Nachricht an jeden anderen General, indem er seine Truppenstärke mitteilt.
• Loyale Generäle sagen die Wahrheit; Verräter können jedem anderen General eine andere Lüge auftischen.
• In dem Beispiel sehen wir, dass General 1 1K Mann meldet, General 2 meldet 2K, General 3 lügt jeden an, gibt x, y und z an und General 4 meldet 4K
• Im zweiten Schritt werden die Ergebnisse der Ankündigungen aus dem ersten Schritt in Form von Vektoren gesammelt.

      General 1 ( 1, 2, x, 4 )

      General 2 ( 1, 2, y, 4 )

      General 3 ( 1, 2, 3, 4 )

      General 4 ( 1, 2, z, 4 )

• Im dritten Schritt übergibt jeder General seinen Vektor an jeden anderen General. Jeder General erhält 3 Vektoren, jeweils von einem der anderen Generäle.

General 1                          General 2                           General 4
( 1, 2, y, 4 )                       ( 1, 2, x, 4 )                         ( 1, 2, x, 4 )

( a, b, c, d )                       ( e, f, g, h )                         ( 1, 2, y, 4 )

( 1, 2, z, 4 )                       ( 1, 2, z, 4 )                         ( i, j, k, l )

• Auch hier lügt General 3 und erfindet 12 neue Werte, a bis l.
• Im vierten Schritt wertet jeder General das i-te Element jedes neu empfangenen Vektors aus.
• Hat ein Wert eine Mehrheit, wird er in den Ergebnisvektor übernommen.
• Hat kein Wert eine Mehrheit, wird das entsprechende Element des Ergebnisvektors als UNKNOWN markiert.
• In diesem Beispiel sehen wir, dass die Generäle 1, 2 und 4 eine Einigung mit
  
                                    ( 1,  2, UNKNOWN, 4 )
  
  gefunden haben, was das korrekte Ergebnis darstellt.
• Der Verräter kann die Informationen für die loyalen Generäle nicht verfälschen; er konnte ihre Arbeit nicht unterminieren.
• In einem System mit m fehlerhaften Prozessen kann nur dann eine Einigung erzielt werden, wenn es 2m+1 (mehr als 2/3) korrekt funktionierende Prozesse gibt, also insgesamt 3m+1 Prozesse.

Bewertung Practical Byzantine Fault Tolerance (PBFT)

Mit Konsensverfahren auf der Basis von Byzantine Fault Tolerance kann der Konsens auch beim Ausfall von bis zu 1/3 der Nodes zuverlässig arbeiten.

Alternative Konsensfindungsverfahren einer Blockchain Technologie

Neben den Grundmethoden gibt es noch weitere Methoden zur Konsensfindung, wie zum Beispiel:

Istanbul Byzantine Fault Tolerance (IBFT)
Der Istanbul BFT Algorithmus wurde durch den PBFT inspiriert. Der ursprüngliche PBFT wurde jedoch angepasst optimiert, um mit Blockchain noch besser zu funktionieren. Der IBFT ist für private Blockchains ein bewährter Algorithmus.

Yet Another Consensus
Bei Yet Another Consensus (YAC) handelt es sich um einen Algorithmus für delegierte byzantinische Fehlertoleranz. Es handelt sich um einen Konsensverfahren für private, also zugangsbeschränkte Blockchains.

Proof of Elapsed Time
Beim Proof of Elapsed Time (PoET) Algorithmus wird zufällig und fair entschieden, wer über einen neuen Block entscheiden darf. Diese Entscheidung basiert auf der Wartezeit der Knoten. Jeder Knoten im Netzwerk bekommt eine zufällige Wartezeit zugeordnet. Für diese zugeordnete Zeit lang muss der Knoten „schlafen gehen“. Der Knoten mit der kürzesten Wartezeit wird als erster wieder aktiv und gewinnt somit den Block.

Paxos
Paxos ist ein verhältnismäßig alter Konsensalgortihmus von 1989. Wenn ein Client einen Befehl auf einem bestimmten Knoten ausführt, ernennt sich der Knoten selbst zum Leader. Diese Ausführung wird mit der höchsten Nummer versehen, die dieser Knoten gesehen hat. Der Konsens zwischen den Knoten wird durch ein 2-Phasen-Commit-Protokoll erreicht.

Raft
Raft ist ein Konsensalgorithmus, der ein Ergebnis liefert, das dem von (multi-)Paxos entspricht und genauso effizient ist wie Paxos. Seine Struktur ist anders als die von Paxos, was Raft verständlicher als Paxos macht und auch eine bessere Grundlage für den Aufbau praktischer Systeme bietet.

Weitere Informationen zum Begriff “Konsensfindungsverfahren bei der Blockchain”:

„Eine vertrauenswürdige Zusammenarbeit mit Hilfe der Blockchain-Technologie“

„Blockchain-Technologie unter der Lupe“

„Blockchain-Technologie revolutioniert das digitale Business“

„Blockchain als Echtheitsgarant“

„Kryptografie wird Währung – Bitcoin: Geldverkehr ohne Banken“

„Validierung digitaler Nachweise mit der Blockchain“

„Lehrbuch Cyber-Sicherheit“

„Übungsaufgaben und Ergebnisse zum Lehrbuch Cyber-Sicherheit“

„Bücher im Bereich Cyber-Sicherheit und IT-Sicherheit zum kostenlosen Download“

„Vorlesungen zum Lehrbuch Cyber-Sicherheit“

„BlockChain-Sicherheit – Verfügbarkeit / Robustheit versus Vertrauensbildung und Effizienz?“

„BlockChain – Einführung und Einsatzmöglichkeiten“

„BlockChain-Technologie – Sicherheit und Anwendungen“

„Wissenschaftliche Perspektiven im Bereich Blockchain“

„Forschungsinstitut für Internet-Sicherheit (IT-Sicherheit, Cyber-Sicherheit)“

„Master-Studiengang Internet-Sicherheit (IT-Sicherheit, Cyber-Sicherheit)“

„Marktplatz IT-Sicherheit“

„Marktplatz IT-Sicherheit: IT-Notfall“

„Marktplatz IT-Sicherheit: IT-Sicherheitstools“

„Marktplatz IT-Sicherheit: Selbstlernangebot“

„Vertrauenswürdigkeits-Plattform“

Summary

Article Name

Konsensfindungsverfahren bei der Blockchain

Description

Das Konsensfindungsverfahren bei Blockchains ist dazu da, dass ein Konsens gefunden wird und sich untereinander auf einen „korrekten“ Zustand geeinigt wird. Ziel ist dabei, ein Node auszuwählen, die als Nächstes ein neuer Block zusammengestellt und der Blockchain hinzufügt darf.

Author

Prof. Norbert Pohlmann

Publisher Name

Institut für Internet-Sicherheit – if(is)

Publisher Logo