Blockchain sichern: Die Rolle der byzantinischen Fehlertoleranz

Jedes Mal, wenn Sie eine Kryptowährungstransaktion senden, eine Zahlung erhalten oder mit einem Smart Contract interagieren, muss ein Netzwerk von Computern, die einander nicht kennen oder vertrauen, bestätigen, dass Ihre Transaktion gültig ist und dauerhaft gespeichert werden soll. Einige dieser Computer sind möglicherweise offline. Andere könnten von Angreifern kontrolliert werden, die absichtlich falsche Informationen senden. Dennoch muss die Blockchain auf jedem ehrlichen Knoten zum gleichen korrekten Ergebnis gelangen.

Der Mechanismus, der dies ermöglicht, ist die byzantinische Fehlertoleranz (BFT). Sie ist eines der wichtigsten und am wenigsten verstandenen Konzepte in verteilten Systemen und bildet die Sicherheitsgrundlage für Blockchain-Technologie , dezentrale Finanzen, Unternehmensbuchhaltung und das Internet der Dinge.

Dieser Leitfaden behandelt die byzantinische Fehlertoleranz von den Grundlagen bis hin zu ihren modernsten Implementierungen. Er beschreibt unter anderem, wie sie sich mit Proof of Work und Proof of Stake vergleichen lässt, gegen welche spezifischen Angriffsvektoren sie abwehrt, welche Protokolle heute darauf aufbauen und an welchen Herausforderungen die Forscher noch arbeiten.

Das Problem der byzantinischen Generäle: Wo alles begann

Um byzantinische Fehlertoleranz zu verstehen, muss man das Problem verstehen, für dessen Lösung sie entwickelt wurde. Das Problem der byzantinischen Generäle wurde 1982 von den Informatikern Leslie Lamport, Robert Shostak und Marshall Pease in einem Artikel mit dem Titel „The Byzantine Generals Problem“ in den ACM Transactions on Programming Languages ​​and Systems erstmals formal beschrieben.

Das Problem wird anhand einer militärischen Analogie verdeutlicht. Stellen Sie sich mehrere Divisionen einer byzantinischen Armee vor, die eine feindliche Stadt umzingeln. Jede Division wird von einem General befehligt, und die Kommunikation zwischen den Divisionen ist ausschließlich über Boten möglich. Sie müssen sich auf einen gemeinsamen Plan einigen: entweder angreifen oder zurückziehen. Greifen alle gemeinsam an, siegen sie. Ziehen sie sich alle gemeinsam zurück, überleben sie. Greifen jedoch einige an, während andere sich zurückziehen, werden sie vernichtet.

Die Schwierigkeit besteht darin, dass einige der Generäle Verräter sein könnten. Ein Verräter könnte verschiedenen Generälen unterschiedliche Anweisungen geben, einigen zum Angriff und anderen zum Rückzug befehlen, um bewusst eine Einigung zu verhindern. Die loyalen Generäle können verdächtige Nachrichten nicht einfach ignorieren, da sie die Verräter nicht sofort erkennen können.

Die Frage lautet: Welchen Algorithmus können die loyalen Generäle verwenden, um zu garantieren, dass sie alle zur gleichen Entscheidung gelangen, selbst wenn ein Teil der Generäle Verräter sind, die aktiv versuchen, Uneinigkeit zu stiften?

Lamport, Shostak und Pease bewiesen, dass eine Lösung genau dann möglich ist, wenn mehr als zwei Drittel der Generäle loyal sind. Anders ausgedrückt: Ein System mit n Knoten kann höchstens f fehlerhafte oder böswillige Knoten tolerieren, solange n mindestens 3f + 1 beträgt. Bei weniger als zwei Dritteln ehrlichen Teilnehmern kann kein Algorithmus eine Einigung garantieren.

Dieses mathematische Ergebnis bildete die theoretische Grundlage für jeden nachfolgenden BFT-Konsensalgorithmus.

Lesen Sie auch: Wie Hashing die Blockchain-Technologie schützt

Was ist byzantinische Fehlertoleranz?

Byzantinische Fehlertoleranz bezeichnet die Eigenschaft eines verteilten Systems, weiterhin korrekt zu funktionieren und einen Konsens zu erreichen, selbst wenn einige seiner Knoten auf beliebige Weise ausfallen, beispielsweise durch das Senden widersprüchlicher oder falscher Nachrichten, durch inkonsistente Reaktionen auf verschiedene Teilnehmer oder durch böswilliges Verhalten, um das Netzwerk zu stören.

Der Begriff „byzantinisch“ bezeichnet die schwerwiegendste Fehlerklasse: willkürliches, feindseliges und inkonsistentes Verhalten. Dies ist wesentlich schwieriger zu beheben als ein einfacher Systemabsturz (bei dem ein Knoten vollständig ausfällt), da ein byzantinischer Knoten zwar manchmal korrekt zu funktionieren scheint, aber in anderen Momenten den Konsens aktiv untergräbt.

Im Kontext der Blockchain-Technologie bedeutet byzantinische Fehlertoleranz, dass das Blockchain-Netzwerk seine Integrität bewahren und Transaktionen weiterhin korrekt validieren kann, selbst wenn einige Validatoren oder Knoten kompromittiert, offline oder absichtlich bösartig sind.

Die in der Lamport-Studie aufgestellte Regel gilt uneingeschränkt: Solange mindestens zwei Drittel der Knoten im Netzwerk ehrlich sind und korrekt funktionieren, erreicht ein BFT-System den richtigen Konsens. Sobald ein einzelner Angreifer mehr als ein Drittel der Knoten kontrolliert, beginnen die Sicherheitsgarantien klassischer BFT-Protokolle zu versagen.

Nicht-byzantinische vs. byzantinische Fehlertoleranz: Eine entscheidende Unterscheidung

Fehlertoleranz ist nicht gleich Fehlertoleranz. Das Verständnis des Unterschieds zwischen nicht-byzantinischer und byzantinischer Fehlertoleranz verdeutlicht, warum letztere schwieriger zu realisieren ist und warum sie für die Blockchain so wichtig ist.

Nicht-byzantinische (Absturz-)Fehlertoleranz behandelt den einfacheren Fall, in dem Knoten durch Stillstand ausfallen können: Sie stürzen ab, gehen offline oder sind nicht mehr erreichbar. Das System muss trotz des Ausfalls einiger Knoten weiterlaufen. Dies ist einfacher zu handhaben, da ein abgestürzter Knoten keine Meldungen sendet und keine Störungen verursacht. Systeme wie Apache ZooKeeper und ältere verteilte Datenbanken wurden mit Blick auf Absturztoleranz entwickelt.

Byzantinische Fehlertoleranz behandelt den schwierigeren Fall, in dem ausgefallene Knoten sich willkürlich verhalten und falsche, widersprüchliche oder strategisch irreführende Nachrichten an verschiedene Teile des Netzwerks senden können. Ein byzantinischer Knoten verstummt nicht einfach; er beteiligt sich aktiv, um Verwirrung zu stiften oder eine Einigung zu verhindern. Blockchain-Netzwerke sind diesem Problem ausgesetzt, da sie in offenen, erlaubnisfreien Umgebungen operieren, in denen jeder, einschließlich Angreifer, einen Knoten betreiben kann.

Im Bereich der Blockchain zählen zu den byzantinischen Fehlern insbesondere: ein Miner, der betrügerische Transaktionen in einen vorgeschlagenen Block aufnimmt; ein Validator, der widersprüchliche Blöcke signiert, um eine Abspaltung zu versuchen; ein Knoten, der unterschiedliche Transaktionsreihenfolgeinformationen an verschiedene Peers sendet; und Knoten, die Doppelausgabenangriffe durchführen, indem sie widersprüchliche Transaktionen gleichzeitig an verschiedene Teile des Netzwerks senden.

Ein System, das zwar ausfalltolerant, aber nicht byzantinisch fehlertolerant ist, wäre für eine öffentliche Blockchain ungeeignet, in der die Knoten von unbekannten, potenziell feindseligen Parteien betrieben werden.

Wie BFT erreicht wird: Die Kernmechanismen

Die byzantinische Fehlertoleranz wird durch die Kombination dreier primärer Mechanismen erreicht, die zusammenwirken, um ehrlichen Knoten trotz gegnerischer Teilnehmer eine Einigung zu ermöglichen.

Redundanz

Anstatt sich auf einen einzelnen Knoten zur Aufzeichnung oder Validierung einer Transaktion zu verlassen, verwenden BFT-Systeme mehrere redundante Knoten. Solange mehr als zwei Drittel dieser redundanten Knoten fehlerfrei arbeiten, kann das System die wenigen falschen oder widersprüchlichen Nachrichten erkennen und verwerfen. Redundanz ist die strukturelle Grundlage von BFT: Ohne mehr Knoten als unbedingt notwendig zur Transaktionsverarbeitung ist byzantinische Fehlertoleranz nicht zu erreichen.

Kryptografische Signaturen

BFT-Protokolle verwenden Public-Key-Kryptografie zur Authentifizierung von Nachrichten zwischen Knoten. Wenn ein Knoten eine Nachricht sendet (z. B. eine Abstimmung über die Gültigkeit eines vorgeschlagenen Blocks), signiert er diese mit seinem privaten Schlüssel. Andere Knoten können die Signatur mithilfe des öffentlichen Schlüssels des Absenders überprüfen und so bestätigen, dass die Nachricht tatsächlich vom angegebenen Absender stammt und während der Übertragung nicht verändert wurde. Dies verhindert einen der gefährlichsten byzantinischen Angriffe: die Fälschung von Nachrichten durch einen bösartigen Knoten, der sich als ein anderer Knoten ausgibt.

Strukturierte Konsensprotokolle

BFT-Konsensprotokolle definieren präzise Regeln dafür, wie Knoten neue Daten vorschlagen, darüber abstimmen und sie finalisieren. Diese Protokolle sind so konzipiert, dass selbst bei widersprüchlichen Stimmen einzelner Knoten die ehrliche Mehrheit zum selben Ergebnis gelangt. Die Protokollstruktur beseitigt Mehrdeutigkeiten: Es gibt einen festgelegten Prozess für den Fall, dass Stimmen widersprüchlich sind, ein Leader ausfällt oder Knoten sich über den aktuellen Zustand uneinig sind.

Die drei Eigenschaften, die den BFT-Konsens definieren

Jedes BFT-Konsensprotokoll muss, unabhängig von seiner spezifischen Ausgestaltung, drei grundlegende Eigenschaften erfüllen:

Sicherheit bedeutet, dass keine zwei korrekten (ehrlichen) Knoten jemals unterschiedliche Werte festlegen. Wenn ein ehrlicher Knoten eine Transaktion als gültig bestätigt, wird kein anderer ehrlicher Knoten sie als ungültig bestätigen. Sicherheit gewährleistet, dass die Blockchain keine widersprüchlichen Historien zwischen ehrlichen Teilnehmern erzeugt.

Lebendigkeit bedeutet, dass das System letztendlich Fortschritte erzielt. Wenn genügend korrekte Knoten eine Transaktion einreichen, wird diese schließlich ausgeführt. Das Netzwerk bleibt nicht dauerhaft stehen. Lebendigkeit stellt sicher, dass ehrliche Teilnehmer nicht auf unbestimmte Zeit von der Verarbeitung ihrer Transaktionen ausgeschlossen werden.

Eine Vereinbarung bedeutet, dass, wenn ein korrekter Knoten eine Transaktion ausliefert, jeder korrekte Knoten dieselbe Transaktion ausliefert. Alle ehrlichen Knoten sehen dieselben Daten in derselben Reihenfolge.

Sicherheit und Lebendigkeit können im Widerspruch zueinander stehen. Das bekannte CAP-Theorem in verteilten Systemen zeigt, dass kein verteiltes System gleichzeitig Konsistenz, Verfügbarkeit und Partitionstoleranz garantieren kann. BFT-Protokolle treffen bewusste Kompromisse. Die meisten priorisieren Sicherheit gegenüber Lebendigkeit: Sie stoppen, anstatt ein potenziell falsches Ergebnis zu erzwingen, wenn zu viele Knoten fehlerhaft arbeiten.

Lesen Sie auch: Was ist Konsens in der Blockchain?

Arten von byzantinischen Fehlertoleranzalgorithmen

Die BFT hat sich seit der Veröffentlichung von 1982 erheblich weiterentwickelt. Das Gebiet umfasst heute mehrere unterschiedliche Protokollfamilien, die sich jeweils durch unterschiedliche Leistungsmerkmale, Vertrauensannahmen und Implementierungskontexte auszeichnen.

Praktische byzantinische Fehlertoleranz (PBFT)

Die praktische byzantinische Fehlertoleranz wurde 1999 von Barbara Liskov und Miguel Castro am MIT eingeführt. Sie war der erste BFT-Algorithmus, der praktisch genug für den realen Einsatz in verteilten Systemen war und das Problem in asynchronen Netzwerken mit geringem Overhead im Vergleich zu früheren akademischen BFT-Arbeiten löste.

PBFT arbeitet mit drei Kommunikationsphasen zwischen den Knoten:

Vorbereitungsphase: Der primäre (Leader-)Knoten empfängt eine Client-Anfrage, weist ihr eine Sequenznummer zu und sendet eine Vorbereitungsnachricht an alle anderen Knoten (Replikate). Diese Nachricht enthält die Anfrage, die Sequenznummer und die aktuelle Ansichtsnummer.

Vorbereitungsphase: Jede Replik, die die Vorvorbereitungsnachricht akzeptiert, sendet eine Vorbereitungsnachricht an alle anderen Repliken. Eine Replik geht erst dann in die nächste Phase über, wenn sie von mindestens 2f Knoten übereinstimmende Vorbereitungsnachrichten erhalten hat (wobei f die maximale Anzahl fehlerhafter Knoten ist, die das System toleriert). Diese Quorumsanforderung verhindert, dass ein fehlerhafter Leader verschiedene Repliken dazu bringt, unterschiedliche Sequenznummern zu akzeptieren.

Commit-Phase: Sobald ein Knoten genügend passende Vorbereitungsnachrichten gesammelt hat, sendet er eine Commit-Nachricht. Eine Replik führt die Anfrage aus und antwortet dem Client erst, wenn sie Commit-Nachrichten von mindestens 2f + 1 Knoten erhalten hat. Dieses finale Quorum stellt sicher, dass selbst bei Ausfall einiger Knoten, die später Commit-Nachrichten gesendet haben, genügend Knoten mit Commit vorhanden sind, um die dauerhafte Gültigkeit des Ergebnisses zu gewährleisten.

Ein Client akzeptiert ein Ergebnis, wenn er f + 1 übereinstimmende Antworten erhält, wodurch sichergestellt wird, dass mindestens ein ehrlicher Knoten das Ergebnis bestätigt hat.

Die Kommunikationskomplexität von PBFT beträgt O(n²), d. h. die Anzahl der Nachrichten wächst quadratisch mit der Anzahl der Knoten. Dies ist für einige Dutzend oder wenige Hundert Knoten handhabbar, wird aber bei großen Netzwerken unpraktikabel. PBFT basiert zudem auf einer festen, bekannten Menge von Validatoren und eignet sich daher am besten für Blockchain-Umgebungen mit Zugriffsbeschränkungen oder Konsortien.

PBFT toleriert einen Anteil byzantinischer Knoten von bis zu einem Drittel (33 %). Dieser Schwellenwert ist mathematisch als theoretisches Maximum für klassische BFT-Protokolle erwiesen.

Die Nutzung des PBFT-basierten Konsensmechanismus durch Hyperledger Fabric ist das prominenteste Beispiel für Unternehmensanwendungen. Fabric verwendet einen Ordering-Service (früher PBFT-basiert, jetzt Raft-basiert mit einem BFT-Upgrade-Pfad über SmartBFT), der hohen Durchsatz und geringe Latenz für Unternehmensanwendungen bietet. Walmart setzte Hyperledger Fabric ein, um Lebensmittel vom Erzeuger bis zum Supermarktregal zurückzuverfolgen und demonstrierte so den praktischen Einsatz von BFT in einer realen Lieferkette.

Föderiertes Byzantinisches Abkommen (FBA)

Federated Byzantine Agreement (FBA) verfolgt einen grundlegend anderen Ansatz zur Lösung des Vertrauensproblems. Anstatt von allen Validatoren zu verlangen, dass sie die vollständige Menge der vertrauenswürdigen Validatoren kennen und sich darauf einigen, erlaubt FBA jedem Knoten, sein eigenes „Quorum-Slice“ zu definieren – die Teilmenge der anderen Knoten, denen er persönlich vertraut.

Das System erreicht einen globalen Konsens, wenn sich die einzelnen Vertrauensbereiche überschneiden. Wenn Knoten A den Knoten B und C vertraut und Knoten B den Knoten A und D, entsteht durch diese Überschneidung ein implizites globales Quorum, obwohl keine zentrale Instanz ein solches definiert hat.

FBA ist der Konsensmechanismus, der dem Stellar-Netzwerk und, in modifizierter Form, dem Ripple-Netzwerk zugrunde liegt. Die FBA-Implementierung von Stellar erreicht Transaktionsabschluss in drei bis fünf Sekunden und unterstützt Tausende von Transaktionen pro Sekunde, wodurch sie sich ideal für grenzüberschreitende Zahlungen eignet. MoneyGram und andere Zahlungsdienstleister nutzen Stellar insbesondere, weil dessen FBA-Konsensmechanismus die schnelle und zuverlässige Transaktionsabwicklung gewährleistet, die Zahlungsanwendungen benötigen.

Der FBA-Ansatz geht einen anderen Kompromiss ein als PBFT: Er ermöglicht eine dezentralere Vertrauensstruktur, erfordert aber eine sorgfältige Gestaltung der Quorum-Slices, um die globale Übereinstimmung zu gewährleisten. Bei unzureichender Definition der Quorum-Slices können sich in Teilen des Netzwerks voneinander unabhängige Konsensgruppen bilden, die unterschiedliche Zustände vereinbaren.

Heißes Zeug

HotStuff ist ein BFT-Konsensprotokoll, das 2019 von den Forschern Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta und Ittai Abraham eingeführt wurde. Es erlangte großen Einfluss als Grundlage für Facebooks LibraBFT-Protokoll (das im Diem-Blockchain-Projekt verwendet wird) und hat die Gestaltung zahlreicher moderner Blockchain-Konsenssysteme beeinflusst.

Die wichtigste Innovation von HotStuff besteht darin, eine lineare Kommunikationskomplexität von O(n) anstelle der quadratischen Komplexität von PBFT (O(n²)) zu erreichen. Dies wird durch ein Leader-basiertes Design realisiert, bei dem der Leader Stimmen in Form von Schwellenwertsignaturen sammelt und n Einzelstimmen zu einem einzigen kompakten Beweis zusammenfasst. Dadurch steigt der Kommunikationsaufwand nicht exponentiell mit der Anzahl der Validatoren.

HotStuff verwendet eine dreiphasige Struktur (Vorbereiten, Vorab-Commit, Commit), die konzeptionell den Phasen von PBFT entspricht, aber durch Pipelining effizienter arbeitet: Während ein Block committet wird, wird bereits der nächste Block vorgeschlagen, was den Durchsatz drastisch verbessert.

HotStuff nimmt eine etwas höhere Latenz (drei Roundtrips gegenüber zwei bei PBFT) in Kauf, bietet dafür aber eine deutlich bessere Skalierbarkeit. Für große Validator-Sets mit Hunderten oder Tausenden von Knoten ist dieser Kompromiss äußerst vorteilhaft. Das CometBFT-Verfahren (ehemals Tendermint Core) des Cosmos-Ökosystems sowie der in Aptos und Sui verwendete Konsensmechanismus basieren beide auf Designs der HotStuff-Familie.

Tendermint und CometBFT

Tendermint ist ein BFT-Konsensalgorithmus, der speziell für die Blockchain-Nutzung entwickelt wurde und 2014 von Jae Kwon eingeführt wurde. Er trennt die Konsensschicht von der Anwendungsschicht durch die Application BlockChain Interface (ABCI), sodass jede Anwendung den Tendermint-Konsens nutzen kann, ohne eine eigene Netzwerk- und Konsensinfrastruktur aufbauen zu müssen.

Tendermint erzielt Konsens in Runden. In jeder Runde sendet ein Proposer einen Block. Die Validatoren stimmen in zwei Phasen ab (Vorabstimmung und Vorbestätigung). Ein Block wird bestätigt, sobald mindestens zwei Drittel der Validatoren übereinstimmende Vorabstimmungsstimmen abgegeben haben. Schlägt die Runde fehl (weil der Proposer fehlerhaft ist oder das Netzwerk zu langsam ist), beginnt eine neue Runde mit einem neuen Proposer.

Tendermint gewährleistet sofortige Endgültigkeit: Sobald ein Block bestätigt wurde, kann er nicht mehr rückgängig gemacht werden, ohne die Annahme der ehrlichen Zwei-Drittel-Mehrheit zu verletzen. Dies ist ein wesentlicher Vorteil gegenüber probabilistischen Endgültigkeitssystemen wie Proof-of-Work, bei denen eine Transaktion erst nach dem Hinzufügen mehrerer aufeinanderfolgender Blöcke als endgültig gilt.

Tendermint verarbeitet Tausende von Transaktionen pro Sekunde mit einer Latenz von etwa einer Sekunde. 2023 wurde es in CometBFT umbenannt, um ein breiteres Community-Governance-Modell widerzuspiegeln. Der Cosmos Hub und alle auf dem Cosmos SDK basierenden Chains (bis 2025 über 100 aktive Chains) nutzen CometBFT als Konsensmechanismus. Ein bemerkenswertes Beispiel aus der Praxis war der Ausfall der Cosmos Hub v17.1-Chain. Dieser war nicht auf einen Fehler im Sicherheitsnachweis von CometBFT zurückzuführen, sondern auf einen Softwarefehler im Code für das Validator-Set-Update im Bereich EndBlock. Dies verdeutlicht, dass die BFT-Garantien in einer vollständigen Implementierung verankert sind und nicht isoliert in der Theorie existieren.

BFT im Proof-of-Stake-Format: Casper und Ethereum

Der Übergang von Ethereum zu Proof-of-Stake durch den Merge im September 2022 führte zur Einführung von Casper FFG (Friendly Finality Gadget) in Kombination mit der LMD-GHOST-Fork-Wahl. Zusammen bilden sie das Gasper-Konsensprotokoll. Casper bietet BFT-ähnliche Finalität zusätzlich zu einem Proof-of-Stake-Validator-Set.

Casper fungiert als Finalisierungsmechanismus, der auf der Blockproduktion aufsetzt. Validatoren stimmen alle 32 Zeitschlitze (ca. 6.4 Minuten) über Prüfpunkte ab. Sobald zwei Drittel des gesamten gestakten ETH für einen Prüfpunkt gestimmt haben, gilt dieser als „gerechtfertigt“. Werden zwei aufeinanderfolgende Prüfpunkte als gerechtfertigt angesehen, wird der frühere als „finalisiert“ bezeichnet. Finalisierte Blöcke können nicht rückgängig gemacht werden, ohne dass der Angreifer mindestens ein Drittel des gesamten gestakten ETH verbrennt. Dies stellt eine starke ökonomische Garantie für Block-Finalisierungs-Transaktionen dar.

Dieser ökonomische Slashing-Mechanismus ist Ethereums Adaption der klassischen Blockfunktionstheorie (BFT): Anstelle rein mathematischer Garantien wird die Finalität durch die wirtschaftlichen Kosten von Fehlverhalten sichergestellt. Signiert ein Validator widersprüchliche Blöcke, verliert er seinen gesamten Einsatz (wird „geslasht“). Die Gefahr, erhebliches Kapital zu verlieren, bringt ehrliches Verhalten mit wirtschaftlichem Eigeninteresse in Einklang.

Byzantinische Fehlertoleranz im Proof of Work

Bitcoins Proof-of-Work (PoW) erreicht eine probabilistische Form der byzantinischen Fehlertoleranz durch einen anderen Mechanismus als klassische BFT-Protokolle. Satoshi Nakamotos Bitcoin-Whitepaper von 2008 führte PoW als Lösung für das Problem der byzantinischen Generäle in einer erlaubnisfreien Umgebung ein, in der die Teilnehmer unbekannt sind und nicht vorab identifiziert werden können.

Im Proof-of-Work-Verfahren von Bitcoin bedeutet byzantinische Fehlertoleranz, dass ein Angreifer, der weniger als 50 % der Hash-Leistung des Netzwerks kontrolliert, die bestätigte Transaktionshistorie nicht verändern kann, solange ehrliche Miner mehr als 50 % der gesamten Hash-Leistung kontrollieren. Die Kosten eines 51-%-Angriffs steigen mit der Hash-Rate von Bitcoin und der Schwierigkeit der Mining-Aufgaben.

Anders als bei klassischen BFT-Protokollen, die nach einer einzigen Abstimmungsrunde absolute Endgültigkeit gewährleisten, ist die Endgültigkeit bei Bitcoin probabilistisch: Die Wahrscheinlichkeit, dass eine Transaktion rückgängig gemacht wird, sinkt exponentiell mit jedem weiteren hinzugefügten Block. Aus diesem Grund werden für große Bitcoin-Transaktionen traditionell Bestätigungen alle sechs Blöcke (etwa eine Stunde) verwendet.

Der Kompromiss ist beträchtlich: PoW bietet BFT in einer erlaubnisfreien Umgebung, allerdings auf Kosten eines enormen Energieverbrauchs, einer langsamen Finalität (10-60 Minuten) und der 51%-Angriffsanfälligkeit, der klassische BFT-Protokolle unterhalb ihrer Schwelle nie ausgesetzt sind.

Vergleich von BFT-Protokollen: Ein direkter Überblick

Protokoll	Fehlerschwelle	Endgültigkeit	Nachrichtenkomplexität	Am besten geeignet für
PBFT (Castro-Liskov)	1/3 Byzantinisch	Augenblick	O(n²)	Kleine, erlaubnisbasierte Netzwerke
Heißes Zeug	1/3 Byzantinisch	Augenblick	O(n) linear	Große Validierungssätze
Tendermint / CometBFT	1/3 Byzantinisch	Sofort (~1s)	O (n)	Cosmos Chains, öffentliche Blockchains
Föderiertes byzantinisches Abkommen	Überlappende Quorum-Slices	3-5 Sekunden	Variable	Zahlungsnetzwerke (Stellar, Ripple)
Casper FFG (Ethereum PoS)	1/3 der gestakten ETH	Alle 6.4min	O(n) mit BLS-Aggregation	Öffentliche PoS-Blockchains
Bitcoin PoW	50 % Hash-Leistung	Probabilistisch (6+ Blöcke)	O(1)-Sendung	Erlaubnisfreie, vertrauenslose Netzwerke
Algorand BA	1/3 Byzantinisch	~4.5 Sekunden	Sublinear mit VRF	Erlaubnisfrei mit schneller Endgültigkeit

Reale Implementierungen von BFT im Jahr 2025

Hyperledger Fabric und Enterprise Blockchain

Hyperledger Fabric ist das am weitesten verbreitete Blockchain-Framework für Unternehmen in der Produktion. Es bildet die Grundlage für das Lebensmittelrückverfolgbarkeitssystem von Walmart, die Supply-Chain-Lösungen von IBM und Hunderte von Finanz- und Logistikanwendungen. Der Bestellservice von Fabric hat eine bedeutende Weiterentwicklung erfahren: Nach dem Wechsel von PBFT zu Raft (einem ausfallsicheren Konsensmechanismus für einfachere Implementierungen) führte Fabric SmartBFT als byzantinisch fehlertoleranten Bestellservice für Umgebungen ein, die vollständige BFT-Garantien erfordern. SmartBFT folgt dem bekannten dreiphasigen Broadcast-Muster von PBFT und bietet einen hohen Durchsatz bei geringer Latenz, ideal für Anwendungen im Unternehmensbereich.

Stellars föderiertes byzantinisches Abkommen im globalen Zahlungsverkehr

Die FBA-Implementierung von Stellar verarbeitet täglich Millionen von Transaktionen. MoneyGram, Wirex und andere Finanzinstitute nutzen sie für grenzüberschreitende Zahlungen. Der Stellar-Konsens ermöglicht die endgültige Abwicklung in drei bis fünf Sekunden – um ein Vielfaches schneller als traditionelle Korrespondenzbanken (ein bis fünf Tage) und die meisten Blockchain-Alternativen. Das FBA-Modell erlaubt es jedem Knoten, seine eigenen Vertrauensbeziehungen zu definieren und dennoch globale Übereinstimmung zu erzielen. Dadurch eignet sich das Stellar-Konsensmodell besonders für ein Zahlungsnetzwerk, in dem nicht alle Teilnehmer einander vollständig vertrauen, aber alle eine zuverlässige Abwicklung wünschen.

Algorands Byzantine Agreement Protocol

Algorand verwendet einen einzigartigen BFT-Ansatz namens Pure Proof of Stake in Kombination mit kryptografischer Sortierung. In jeder Konsensrunde wird mithilfe einer verifizierbaren Zufallsfunktion (VRF) ein zufälliges Komitee von Validatoren ausgewählt. Nur die ausgewählten Komiteemitglieder wissen, dass sie gewählt wurden (und können dies anderen beweisen). Dadurch sind gezielte Angriffe auf Komiteemitglieder praktisch unmöglich, da der Angreifer nicht im Voraus weiß, wen er angreifen soll.

Das BA-Protokoll von Algorand erreicht Finalität in etwa 4.5 Sekunden bei einem Durchsatz von über 1,000 Transaktionen pro Sekunde im Produktivbetrieb. Sein Design ermöglicht BFT in einer erlaubnisfreien Umgebung ohne den Energieaufwand des Proof-of-Work-Verfahrens – eine Kombination, die es sowohl von Bitcoin als auch von klassischen erlaubnisbasierten BFT-Systemen unterscheidet.

Cosmos Ecosystem und CometBFT

Das Cosmos-Ökosystem umfasst im Jahr 2025 über 100 souveräne Blockchains, die alle CometBFT als Konsensmechanismus nutzen. Das Inter-Blockchain-Kommunikationsprotokoll (IBC) basiert auf der sofortigen Finalitätsgarantie von CometBFT: IBC-Beweise sind nur gültig, wenn der Cosmos Hub und die beteiligten Blockchains die tatsächliche und nicht nur wahrscheinliche Finalisierung einer Transaktion bestätigen können. Ohne die starken Finalitätsgarantien des BFT-Konsens wäre die Sicherung einer solchen kettenübergreifenden Kommunikation deutlich schwieriger. Das Ökosystem verarbeitet täglich Milliarden von Dollar an kettenübergreifenden Werttransfers, die alle durch den byzantinischen fehlertoleranten Konsens von CometBFT abgesichert sind.

Klaytns Istanbul BFT

Klaytn, eingesetzt vom südkoreanischen Unternehmen Kakao, nutzt Istanbul BFT (IBFT) mit über 4,000 Transaktionen pro Sekunde und einer Blockzeit von einer Sekunde. IBFT ist eine EVM-kompatible BFT-Variante, die es Klaytn ermöglicht, die Kompatibilität mit den Ethereum-Tools beizubehalten und gleichzeitig eine deutlich höhere Leistung als die Basisschicht von Ethereum zu erzielen. Die hybride Public-Private-Architektur erlaubt es Unternehmen, erlaubnisbasierte Sidechains zu betreiben, während die öffentliche Mainchain die dezentralen BFT-Garantien aufrechterhält.

Angriffsvektoren, gegen die BFT abwehrt

Wenn man versteht, wovor BFT schützt, werden sein Wert und seine Grenzen deutlich.

Double-Spend-Angriffe

Bei einem Double-Spend-Angriff versucht ein Angreifer, dieselben Gelder zweimal auszugeben, indem er zwei widersprüchliche Transaktionen gleichzeitig sendet. Der BFT-Konsens verhindert dies, indem er die Zustimmung von zwei Dritteln der Validatoren zu einer einzigen Transaktionsreihenfolge erfordert, bevor eine Transaktion abgeschlossen wird. Sobald eine Transaktion in einem BFT-System bestätigt wurde, kann keine konkurrierende Transaktion für dieselben Gelder mehr bestätigt werden, ohne die Zwei-Drittel-Hürde zu überschreiten.

Eclipse-Angriffe

Bei einem Eclipse-Angriff isoliert ein Angreifer einen bestimmten Knoten, indem er ihn mit bösartigen Peers umgibt und so die Kontrolle über alle Informationen erlangt, die dieser Knoten empfängt. Einem erfolgreich eclipsierten Knoten können falsche Informationen über den Blockchain-Zustand zugeführt werden. BFT-Protokolle schützen davor, indem sie die Zustimmung einer qualifizierten Mehrheit aller Validatoren erfordern, nicht nur die der direkten Nachbarn eines Knotens. Selbst wenn ein Knoten eclipsiert wird, lehnt die größere ehrliche Mehrheit Transaktionen ab, die dem tatsächlichen Zustand der Blockchain widersprechen.

Sybil-Angriffe

Bei einem Sybil-Angriff erstellt ein Angreifer mehrere gefälschte Knotenidentitäten, um übermäßigen Einfluss auf ein Netzwerk zu erlangen. In Permissioned-BFT-Systemen werden Sybil-Angriffe durch die formale Registrierung und Authentifizierung der Validatoren verhindert. In Proof-of-Stake-BFT-Systemen wie Ethereum beruht die Sybil-Resistenz auf den Kosten des Stakings: Die Erstellung mehrerer Validatoren erfordert für jeden einzelnen den Einsatz realen Werts, wodurch Sybil-Angriffe in großem Umfang kostspielig werden.

Die 33%-Angriffsschwelle

Klassische BFT-Protokolle bieten nur dann Sicherheitsgarantien, wenn weniger als ein Drittel der Knoten byzantinisch sind. Kontrolliert ein Angreifer mehr als ein Drittel der Validatoren (oder mehr als ein Drittel des eingesetzten Kapitals in PoS-BFT-Systemen), bricht die Sicherheitsgarantie des Protokolls zusammen. Dies ist die grundlegende Einschränkung des BFT-Konsensmechanismus. Das bedeutet nicht, dass ein Angreifer mit 33 % Kontrolle beliebige Gelder stehlen kann, sondern dass er potenziell die Finalität verhindern oder im schlimmsten Fall ehrliche Knoten dazu bringen kann, widersprüchliche Zustände anzunehmen.

Aus diesem Grund ist die 33%-Schwelle ein entscheidender Faktor für das Sicherheitsmodell jedes BFT-basierten Systems. Protokolle wie Casper von Ethereum ergänzen die BFT-Schwelle um eine wirtschaftliche Strafe: Selbst wenn ein Angreifer ein Drittel der gestakten ETH erreicht, müsste sein gesamter Einsatz vernichtet werden, um die Finalität erfolgreich anzugreifen. Dies macht den Angriff wirtschaftlich verheerend für den Angreifer.

Nachrichtenmanipulation und Replay-Angriffe

Ohne kryptografische Signaturen könnte ein byzantinischer Knoten Nachrichten zwischen ehrlichen Knoten abfangen und verändern oder alte, gültige Nachrichten erneut senden, um den Konsensprozess zu stören. BFT-Protokolle schützen vor Nachrichtenmanipulation, indem sie vorschreiben, dass jede Konsensnachricht mit dem privaten Schlüssel des Absenders signiert werden muss. Sequenznummern und Rundenkennungen in den Nachrichten verhindern, dass gültige Nachrichten einer Runde in einer späteren Runde erneut gesendet werden und so Verwirrung stiften.

Vorteile der byzantinischen Fehlertoleranz in der Blockchain

Deterministische, sofortige Transaktionsfinalität

Der wohl wichtigste praktische Vorteil des BFT-Konsens gegenüber Proof-of-Work-Systemen ist die sofortige Finalität. Bei Bitcoin ist eine Transaktion mathematisch nie endgültig; ihre Rückgängigmachung wird lediglich mit zunehmender Anzahl hinzugefügter Blöcke immer schwieriger. In einem BFT-System hingegen wird die Transaktion, sobald in der Commit-Phase die Zwei-Drittel-Schwelle erreicht ist, gemäß den Protokollannahmen mit Sicherheit abgeschlossen. Es müssen keine weiteren Bestätigungen abgewartet werden.

Dies ist für Finanzanwendungen von enormer Bedeutung. Zahlungsnetzwerke können nicht effizient arbeiten, wenn jede Transaktion Stunden später rückgängig gemacht werden kann. Dezentrale Finanzanwendungen benötigen zuverlässige Endgültigkeit für Liquidationen, Kredite und die Abwicklung von Derivaten. Die kettenübergreifende Kommunikation über Protokolle wie IBC erfordert, dass eine Kette der anderen nachweist, dass eine bestimmte Transaktion tatsächlich endgültig ist.

Energieeffizienz

Der klassische BFT-Konsens benötigt nicht den enormen Rechenaufwand, den der Proof-of-Work-Mechanismus von Bitcoin erfordert. Validatoren stimmen mittels digitaler Signaturen ab, nicht durch das Lösen rechenintensiver Rätsel. Dadurch ist BFT deutlich energieeffizienter. Ethereums Übergang zu PoS-BFT reduzierte den Energieverbrauch um etwa 99.95 %. Diese Reduzierung wurde insbesondere dadurch ermöglicht, dass der Proof-of-Work-Mechanismus durch eine Validierungsabstimmung im BFT-Stil ersetzt wurde.

Widerstandsfähigkeit gegenüber Netzwerkausfällen und bösartigen Knoten

Ein korrekt implementiertes BFT-Protokoll funktioniert so lange einwandfrei, wie zwei Drittel der Knoten ehrlich und verbunden bleiben. Es bewältigt Systemausfälle, (vorübergehende) Netzwerkpartitionierungen, byzantinische Knoten und deren gleichzeitige Kombinationen. Diese Ausfallsicherheit ist genau das, was öffentliche Blockchain-Netzwerke benötigen: Da sie nicht im Voraus wissen können, welche Knoten ausfallen oder sich böswillig verhalten werden, muss das Konsensprotokoll beliebige Ausfälle elegant abfangen.

Hoher Durchsatz für Systeme mit Berechtigungen

BFT-Protokolle in geschützten Umgebungen wie Hyperledger Fabric ermöglichen einen sehr hohen Transaktionsdurchsatz. Da die Validatoren fest definiert und bekannt sind, ist der Kommunikationsaufwand vorhersehbar und optimierbar. Unternehmensimplementierungen erreichen routinemäßig Tausende von Transaktionen pro Sekunde mit einer Finalität im Subsekundenbereich – eine Leistung, die mit Proof-of-Work unmöglich und selbst für viele Proof-of-Stake-Systeme eine Herausforderung darstellt.

Schutz vor byzantinischen Fehlern und koordinierten Angriffen

BFT-Mechanismen bieten robusten Schutz vor koordinierten byzantinischen Angriffen. Eine Gruppe von kollaborierenden, bösartigen Knoten, die weniger als ein Drittel der Validatoren ausmacht, kann den Konsens nicht stören, egal wie strategisch sie vorgehen. Sie können ehrliche Knoten nicht daran hindern, eine Einigung zu erzielen, keine falschen Transaktionen in die vereinbarte Historie einfügen und ehrliche Knoten nicht dazu veranlassen, widersprüchliche Zustände anzunehmen. Diese starke Sicherheitsgarantie ist mathematisch bewiesen und nicht nur empirisch beobachtet.

Herausforderungen und Grenzen der byzantinischen Fehlertoleranz

Skalierbarkeitsbeschränkungen

Die grundlegende Herausforderung klassischer BFT-Algorithmen besteht darin, dass die Kommunikationskomplexität mit der Anzahl der Validatoren wächst. Die Nachrichtenkomplexität von PBFT (O(n²)) führt dazu, dass das Hinzufügen weiterer Validatoren schnell unpraktisch wird. Ein Netzwerk mit 100 PBFT-Validatoren benötigt bis zu 10,000 Nachrichten pro Konsensrunde. Bei 1,000 Validatoren steigt diese Zahl auf 1,000,000 Nachrichten.

HotStuff und seine Derivate begegneten diesem Problem mit einer drastischen Reduzierung der Komplexität auf lineare O(n) durch Schwellenwert-Signaturaggregation. Doch selbst lineare Komplexität stößt an praktische Grenzen. Die meisten aktuellen BFT-basierten öffentlichen Blockchains verwenden Validator-Sets im Bereich von Hunderten bis wenigen Tausend, anstatt der Zehntausende, die das Bitcoin-Mining-Netzwerk umfasst.

Diese Skalierbarkeitsgrenze ist der Grund, warum der BFT-Konsens in Permissioned Blockchains und Proof-of-Stake-Netzwerken mit begrenzten Validator-Sets weit verbreitet ist, während der Permissionless Proof-of-Work der Mechanismus für Netzwerke bleibt, die uneingeschränkte Teilnahme priorisieren.

Abhängigkeit von einem bekannten Validierungssatz

Die meisten BFT-Protokolle benötigen eine definierte, authentifizierte Gruppe von Validatoren. Dies funktioniert gut in geschlossenen Systemen und in Proof-of-Stake-Netzwerken, in denen Validatoren Kapital einsetzen, um sich ihren Platz zu verdienen. In vollständig offenen Systemen, in denen jeder ohne Registrierung teilnehmen kann, ist dies deutlich schwieriger. Bitcoins Proof-of-Work löste die offene Variante des Problems der byzantinischen Generäle, da PoW keine Kenntnis der Teilnehmer im Voraus erfordert.

Leistungs-Overhead

Die Realisierung byzantinischer Fehlertoleranz erfordert deutlich mehr Kommunikation zwischen den Knoten als nicht-byzantinische Fehlertoleranzsysteme. Die in PBFT-Protokollen notwendige mehrphasige Abstimmung, die Erfassung und Verifizierung einer großen Anzahl kryptografisch signierter Nachrichten sowie der Koordinierungsaufwand von View-Change-Protokollen (Umgang mit ausgefallenen Leadern) erhöhen Latenz und Rechenkosten. Für Anwendungen, die Tausende von Transaktionen pro Sekunde mit sehr geringer Latenz benötigen, ist eine sorgfältige Planung dieser Kosten unerlässlich.

Komplexität der korrekten Implementierung

Die mathematischen Beweise, die den BFT-Algorithmen zugrunde liegen, sind exakt: Das Protokoll ist sicher und funktionsfähig, wenn es präzise wie spezifiziert implementiert wird. Software entspricht jedoch selten exakt den Spezifikationen. Reale Implementierungen enthalten Fehler in der Parallelverarbeitung, Grenzfälle in der Netzwerkverarbeitung, Schwachstellen im Nachrichten-Timing und kryptografische Implementierungsfehler, die die Garantien des Protokolls in der Praxis verletzen können, selbst wenn der theoretische Entwurf korrekt ist. Der Ausfall der Cosmos Hub v17.1-Chain verdeutlicht dies: Die zentrale Sicherheitsgarantie von BFT wurde erfüllt, aber ein Softwarefehler im umgebenden Code führte zu einem Produktionsstopp. Eine korrekte BFT-Implementierung erfordert äußerste Sorgfalt im gesamten Implementierungs-Stack, nicht nur in der Konsenslogik.

Schwachstelle bei der 33%-Schwelle

Die Anforderung einer ehrlichen Mehrheit von 33 % ist sowohl die Stärke als auch die absolute Grenze von BFT. Solange diese Annahme erfüllt ist, ist das System sicher. Erlangt ein Angreifer jedoch die Kontrolle über ein Drittel oder mehr der Validatoren (oder ein Drittel des eingesetzten Kapitals in PoS-BFT-Systemen), brechen die Sicherheitsgarantien zusammen. In der Praxis erfordert dies enorme Ressourcen für etablierte Netzwerke, kleinere Netzwerke mit einem geringeren Gesamteinsatz sind jedoch anfälliger für diesen Angriff.

Die Zukunft der byzantinischen Fehlertoleranz in der Blockchain

Post-Quanten-BFT

Aktuelle BFT-Protokolle basieren auf kryptografischen Signaturverfahren, die anfällig für Quantencomputer sind. Ein ausreichend leistungsstarker Quantencomputer könnte die Public-Key-Kryptografie brechen, die BFT-Protokolle zur Authentifizierung von Validator-Stimmen verwenden. Die Post-Quanten-BFT-Forschung untersucht daher aktiv Signaturverfahren, die gegen Quantenangriffe resistent sind, darunter gitterbasierte und hashbasierte Kryptografie. Trezor Safe 7, eine Hardware-Wallet, implementiert bereits NIST-standardisierte Post-Quanten-Kryptografie zur Firmware-Verifizierung, was darauf hindeutet, dass sich das gesamte kryptografische Ökosystem in Richtung Quantenresistenz entwickelt. BFT-Protokolle müssen diesem Beispiel folgen, sobald die Quantencomputertechnologie Fortschritte macht.

Asynchrone BFT-Protokolle

Klassische PBFT und die meisten ihrer Ableitungen basieren auf der Annahme partieller Synchronität: Sie gehen davon aus, dass Nachrichtenverzögerungen letztendlich beschränkt sind, selbst wenn diese Beschränkung unbekannt ist. Unter vollständig asynchronen Bedingungen (bei denen Nachrichtenverzögerungen beliebig lang sein können) beweist der FLP-Unmöglichkeitssatz, dass deterministischer Konsens unmöglich ist. Randomisierte asynchrone BFT-Protokolle, die verifizierbare Zufallsfunktionen verwenden, können jedoch auch unter vollständiger Asynchronität probabilistischen Konsens erreichen. HoneyBadgerBFT und Dumbo sind Beispiele für asynchrone BFT-Protokolle, die so konzipiert sind, dass sie auch bei stark beeinträchtigten Netzwerkbedingungen zuverlässig funktionieren.

Skalierbarkeit durch Sharding und Layer 2

Ein vielversprechender Ansatz zur Überwindung der Skalierbarkeitsgrenzen von BFT ist der parallele Betrieb mehrerer BFT-Instanzen mittels Sharding. Dabei wird das Netzwerk in Teilmengen (Shards) unterteilt, die jeweils ihren eigenen BFT-Konsens für einen Teil der Transaktionen durchführen. Ethereums Roadmap sieht Sharding in Verbindung mit einer Finalität nach BFT-Art vor. Die App-Chain-Architektur von Cosmos ist eine weitere Form horizontaler Skalierung: Jede Anwendung betreibt ihre eigene CometBFT-Chain und verteilt so die Konsenslast. Layer-2-Lösungen wie Rollups erweitern die Skalierung um eine weitere Dimension, indem sie Transaktionen außerhalb der Blockchain bündeln und BFT-gesicherte Chains für die endgültige Abwicklung nutzen.

BFT im Internet der Dinge

IoT-Netzwerke bieten ein überzeugendes Anwendungsbeispiel für BFT-Konsens. Milliarden von IoT-Geräten müssen Daten sicher über verteilte Netzwerke koordinieren und austauschen, in denen einzelne Geräte physisch kompromittiert werden, einen Stromausfall erleiden oder absichtlich manipuliert werden können. Studien aus dem Jahr 2025 zeigen, dass BFT-basierte Algorithmen die für IoT-Anwendungen erforderliche geringe Latenz bieten. Ihr hoher Rechenaufwand und die Angriffswahrscheinlichkeit von 33 % erfordern jedoch für IoT-Implementierungen zugriffsbeschränkte Netzwerkarchitekturen. Das Internet der Dinge zählt zu den am schnellsten wachsenden Bereichen für die Forschung und Anwendung von BFT.

BFT in Decentralized Finance

Dezentrale Finanzanwendungen ( DeFi), deren Gesamtwert bis 2025 über 56.3 Milliarden US-Dollar betragen wird, sind für die Zuverlässigkeit ihrer Operationen grundlegend auf den BFT-Konsens angewiesen. Liquidationen, Oracle-Preisfeeds, Kreditpositionen und Derivateabwicklungen erfordern allesamt zuverlässige und schnelle Finalität. Alle wichtigen DeFi-Protokolle basieren auf Blockchains mit BFT-Konsens: Ethereum mit Casper, Cosmos Chains mit CometBFT und Stellar mit FBA. Mit zunehmender Komplexität der DeFi-Anwendungen und dem steigenden Volumen an verwalteten Vermögenswerten wird die Nachfrage nach BFT-Garantien immer wichtiger.

Interoperabilität zwischen BFT-Systemen

Die Zukunft der Blockchain ist zunehmend kettenübergreifend. Vermögenswerte und Nachrichten werden zwischen Ethereum, Cosmos, Stellar, Hyperledger und anderen Netzwerken transferiert. Kettenübergreifende Interoperabilität erfordert, dass jede Kette die Finalitätsnachweise von Transaktionen auf anderen Ketten verifiziert. Die sofortige Finalität von BFT vereinfacht dies erheblich: Ein finalisierter BFT-Nachweis ist kompakt und verifizierbar, im Gegensatz zur probabilistischen Finalität von Proof-of-Work , die das Warten auf zahlreiche Bestätigungen erfordert, bevor eine kettenübergreifende Operation sicher ist. Das IBC-Protokoll im Cosmos-Ökosystem und kettenübergreifende Brückenarchitekturen im breiteren Ökosystem sind beide auf die BFT-Finalität angewiesen, um sicher zu funktionieren. Die Interoperabilitätsforschung ist eines der aktivsten Forschungsgebiete im Bereich des BFT-Protokolldesigns.

Häufig gestellte Fragen