Byzantinische Fehlertoleranz in der Blockchain

In den letzten Jahrzehnten ist die Kryptowährungsindustrie stark gewachsen. Ständig tauchen neue Projekte auf, die Entwickler dazu zwingen, neue Wege zu finden, um bestehende Probleme in der Branche zu lösen. Ein ziemlich gebräuchlicher Begriff ist der BFT-Konsensmechanismus. BFT steht für Byzantine Fault Tolerance und gilt als solche Theoretisches Problem von Computersystemen, mit der sich die Macher schon lange vor dem Erscheinen von Bitcoin auseinandersetzen mussten.

Viele Entwickler blockkettenbasierter Protokolle haben jedoch mit Problemen mit byzantinischer Fehlertoleranz zu tun, also schauen wir uns die Art des Problems und die Auswirkungen an, denen wir gegenüberstehen, wenn dieses Problem auftritt.

Das Problem der byzantinischen Fehlertoleranz

Ausgabe Byzantinische Fehlertoleranz ist eine der am häufigsten betrachteten theoretischen Situationen bei der Diskussion der Nuancen des Konsenses. Dieses Problem wurde erstmals in der 1982 erschienenen Studie „Major Problems of Byzantine Failure“ von Leslie Lappport, Robert Szostak und Marshall Pease erkannt.

Die Studie ergab:

Ein zuverlässiges Computersystem muss den Ausfall einer oder mehrerer Komponenten verkraften. Eine ausgefallene Komponente kann sich auf eine Weise verhalten, die oft übersehen wird, nämlich das Senden widersprüchlicher Informationen an verschiedene Teile des Systems. Das Problem, diese Art von Fehlern zu lösen, wird abstrakt als "Allgemeines Problem der byzantinischen Fehlertoleranz" bezeichnet.

Der Name stammt von der in der Studie vorgestellten Analogie.

Genauer beschreiben die Autoren eine theoretische Situation, in der Mehrere Einheiten der byzantinischen Armee waren außerhalb der feindlichen Stadt stationiert. Jede Abteilung hatte ihren Kommandanten und jede Abteilung befand sich in einem separaten Lager. Die Kommandeure mussten einen Plan für gemeinsame Aktionen (Vormarsch oder Rückzug) ausarbeiten, konnten sich aber nur über Boten verständigen. Andererseits könnte es unter den Generälen Verräter geben, die loyale Generäle daran hindern könnten, auf einen gemeinsamen Nenner (Konsens) zu kommen.

Daher mussten die Generäle einen Weg finden, um sicherzustellen, dass:

• Alle loyalen Generäle folgen dem gleichen Aktionsplan,
• Eine kleine Handvoll Verräter wird die Generäle nicht daran hindern können, den richtigen Plan zu verfolgen.

Wir sprechen also von einem System, das das oben beschriebene Problem lösen kann und es heißt Byzantinische Fehlertoleranzlösung (BFS). Hier kommt der BFT-Konsensalgorithmus her. Insgesamt verhindert die Byzantine Fault Tolerance-Lösung Systemabstürze durch unzuverlässige (ungültige) Teilnehmer.

Lösung des Problems der byzantinischen Generäle

Um das Problem der byzantinischen Generäle zu lösen und eine byzantinische Fehlertoleranzlösung (FTS) zu erstellen, müssen die meisten Generäle dieselbe Strategie anwenden. Dies wird je nach Art des Systems und seinem Zweck auf unterschiedliche Weise erreicht. In der Blockchain können auch zwei Mechanismen, Proof-of-Stake und Proof-of-Work, durch unterschiedliche Ansätze einen Konsens über eine byzantinische Notfalllösung erzielen.

Die meisten Proof-of-Stake-Blockchains können funktionieren, wenn ein Drittel der vorhandenen Knoten wird ausfallen, wodurch der "3f+1"-Regel freien Lauf gelassen wird, wobei sich F i auf die Anzahl der nicht arbeitenden Knoten bezieht. Die Formel selbst berechnet die Anzahl der Knoten, die im System vorhanden sein müssen, damit es ordnungsgemäß funktioniert.

Um beispielsweise die (3f+1)-Regel zu erfüllen, müssen in einem System mit 4 Knoten drei Knoten voll funktionsfähig sein.

Wie kann Blockchain dieses Problem lösen?

Blockchain-basierte Technologie hätte mehrere Möglichkeiten, das Problem der byzantinischen Generäle zu lösen. Der einzige Unterschied ist der benötigte Konsensalgorithmus und wie das BFTS angewendet wird. Sowohl auf der Proof-of-Work- als auch auf der Proof-of-Stake-Seite lassen sich unterschiedliche Lösungen finden.

Interessanterweise Satoshi Nakamoto erwähnte das „Problem der byzantinischen Generäle“ im ursprünglichen Bitcoin-Whitepaper nicht. Nach dem Start des Bitcoin-Netzwerks schlug der unbekannte Schöpfer der ersten Kryptowährung jedoch eine Lösung für das oben genannte Problem vor, indem er einen „Proof-of-Work“-Konsens verwendete. Satoshi hat eine Möglichkeit geschaffen, kryptografische Sicherheit und Verschlüsselung mit öffentlichen Schlüsseln in einem digitalen Netzwerk zu verwenden. Um jegliches Datenleck zu verhindern, verwendet die kryptografische Sicherheit Hashing, und die Identität des Netzwerkbenutzers wird mit einem öffentlichen Schlüssel verifiziert.

Transaktionen werden in Blöcken erfasst, die auf Kosten des Hashings mit dem Rest verknüpft und kryptografisch geschützt sind. Es sollte auch beachtet werden, dass die Blockchain einen Merkle-Baum verwendet, um Hashes zu verifizieren, die vom Hauptblock kommen. Alle der aus dem Genesis-Block kommende Block ist gültig. Diese Blöcke werden von Bergleuten verifiziert, die kryptografische Rätsel in einem Wettbewerb zur Erstellung von Konsensblöcken lösen.

Bitcoin hat ein klares und definitiv objektives Regelwerk aufgestellt, dem die Blockchain folgen muss, um das Problem der byzantinischen Generäle zu überwinden. Ein Netzwerkteilnehmer muss einen Arbeitsnachweis veröffentlichen, um Informationen zur Blockchain hinzuzufügen (daher Nachweis der Arbeit). Dies ist für den Teilnehmer kostspielig und hält ihn davon ab, falsche Informationen weiterzugeben, da diese von anderen Teilnehmern im Netzwerk widerlegt werden.

Alle Regeln sind klar und objektiv, was bedeutet, dass Informationen nicht geändert werden können.

Was ist mit Proof-of-Stake?

Netzwerke, die vom Proof-of-Stake-Konsensalgorithmus beherrscht werden, basieren nicht auf Mining, sondern auf Staking. Um ein Netzwerk-Validator zu werden, muss ein Benutzer zuerst Geld in das System einzahlen. Diejenigen, die einen größeren Anteil halten, können auch mehr Blöcke festschreiben und größere Belohnungen erhalten. Wer versucht, Informationen zu fälschen, riskiert, seinen Einsatz zu verlieren.

Verschiedene Systeme behandeln dieses Problem auf unterschiedliche Weise. Beispielsweise verwendet Ethereum 2.0 den Casper-Algorithmus. Das erfordert es Mindestens zwei Drittel der Mehrheit der Knoten haben einem bestimmten Block zugestimmtbevor es erstellt und dem Netzwerk hinzugefügt wird.

Je nach Bedarf des Systems und Herangehensweise des Teams gibt es unterschiedliche Lösungsansätze. Mit dem delegierten Teilnahmenachweis (dPoS) kommt man beispielsweise viel schneller zu einem Konsens. Andererseits verwenden einige Systeme in der Praxis byzantinische Fehlertoleranz.