Was ist Byzantine Fault Tolerance (BFT)?

Byzantine Fault Tolerance (BFT) ist kurz gesagt die Fähigkeit eines Computernetzwerks, weiterhin korrekt zu funktionieren, wenn ein Teil der Teilnehmer ausfällt, Fehler macht oder bewusst falsche Informationen verbreitet.

Das ist vor allem für Blockchains wichtig. Eine Blockchain hat keinen zentralen Administrator, der festlegt, welche Transaktionen und Blöcke gültig sind. Stattdessen müssen verteilte Computer, oft auch Nodes oder Validatoren genannt, gemeinsam Einigkeit über eine Version der Blockchain erreichen.

Ein Validator kann auf verschiedene Arten einen Fehler haben, nämlich einen normalen Fehler oder einen Byzantine Fault. Bei einem normalen Fehler ist für das Netzwerk klar, dass der Validator nicht richtig funktioniert. Der Validator fällt zum Beispiel aus, verliert die Internetverbindung oder sendet eine Nachricht nicht rechtzeitig. Er liefert dann keine brauchbaren Informationen. Damit kann die Blockchain meist relativ einfach umgehen. Die anderen Validatoren warten nicht unbegrenzt, sondern machen nach einer gewissen Zeit ohne den ausgefallenen Validator weiter. Solange noch genug andere Validatoren aktiv sind, verarbeitet das Netzwerk weiter neue Blöcke.

Bei einem Byzantine Fault verhält sich ein Validator nicht nur defekt, sondern unvorhersehbar. Er kann weiterhin Nachrichten senden, dabei aber falsche oder widersprüchliche Informationen liefern. So kann er einem Validator sagen, dass Block A gültig ist, und einem anderen Validator, dass Block B gültig ist.

Der Unterschied ist also:

• Bei einem normalen Fehler fehlen die Informationen eines Validators.
• Bei einem Byzantine Fault gibt es zwar Informationen, aber es ist unklar, ob sie stimmen.

Ein Byzantine Fault ist deshalb schwieriger zu lösen. Das Netzwerk muss nicht nur ohne einen ausgefallenen Validator weitermachen können, sondern auch verhindern, dass falsche oder widersprüchliche Nachrichten zu einer falschen Entscheidung führen.

Byzantine Fault Tolerance beschreibt, wie ein Netzwerk trotz solcher Probleme trotzdem eine gemeinsame Entscheidung treffen kann. Das Protokoll nutzt dafür unter anderem Prüfungen, digitale Signaturen, mehrere Abstimmungsrunden und eine hohe Abstimmungsschwelle.

Viele BFT-Protokolle verlangen, dass mehr als zwei Drittel des gesamten Stimmgewichts denselben Vorschlag unterstützen, bevor ein Block final wird. Dadurch kann eine kleine Gruppe defekter oder böswilliger Validatoren nicht eigenständig bestimmen, welche Version der Blockchain gültig ist.

BFT ist kein eigenständiger Konsensmechanismus. Es ist eine Eigenschaft eines Netzwerks oder Konsensprotokolls. Protokolle wie PBFT, Tendermint und HotStuff nutzen jeweils eigene Regeln, um Byzantine Faults zu tolerieren.

Wichtigste Erkenntnisse

• Byzantine Fault Tolerance hilft einer Blockchain, mit defekten oder nicht vertrauenswürdigen Validatoren umzugehen.
• Ein Byzantine Fault kann durch eine technische Störung, einen Softwarefehler oder einen gezielten Angriff entstehen.
• Validatoren prüfen Vorschläge und stimmen über neue Blöcke ab.
• Viele BFT-Protokolle verlangen Unterstützung von mehr als zwei Dritteln des gesamten Stimmgewichts.
• BFT hilft zu verhindern, dass verschiedene Versionen der Blockchain gleichzeitig final werden.
• PBFT, Tendermint und HotStuff sind Beispiele für BFT-Protokolle.

Was löst Byzantine Fault Tolerance?

Byzantine Fault Tolerance verhindert, dass eine kleine Gruppe defekter oder böswilliger Validatoren eigenständig bestimmen kann, welche Version der Blockchain gültig ist. Es hilft dem Netzwerk, eine gemeinsame Transaktionshistorie beizubehalten, auch wenn einige Teilnehmer ausfallen, nicht reagieren oder falsche Informationen verbreiten.

Ein unzuverlässiger Validator kann zum Beispiel unterschiedliche Blöcke an unterschiedliche Teilnehmer senden, für zwei miteinander in Konflikt stehende Blöcke stimmen oder versuchen, einen ungültigen Block durchzubringen. Ein Validator kann auch die Mitarbeit verweigern und so das Erreichen von Konsens verlangsamen.

Ohne gute Regeln könnten dadurch verschiedene Gruppen von Validatoren jeweils einer anderen Version der Blockchain folgen. Das Netzwerk könnte dann nicht mehr mit Sicherheit bestimmen, welche Transaktionen und Blöcke gültig sind.

BFT verhindert das, indem ein Block erst bestätigt wird, wenn genug Validatoren denselben Vorschlag geprüft und unterstützt haben. So kann eine begrenzte Gruppe unzuverlässiger Teilnehmer das Netzwerk nicht eigenständig täuschen.

Teilnehmer müssen sich dabei nicht persönlich vertrauen. Sie verlassen sich auf die festen Regeln des Konsensprotokolls, wie digitale Signaturen, Abstimmungsrunden und eine hohe Abstimmungsschwelle.

BFT macht es so möglich, ohne zentrale Verwaltung eine gemeinsame und konsistente Version der Blockchain zu führen.

Wie funktioniert Byzantine Fault Tolerance?

Um Byzantine Fault Tolerance gut zu verstehen, ist es wichtig, zuerst den Unterschied zu einem Konsensmechanismus zu kennen.

Ein Konsensmechanismus ist die Gesamtheit an Regeln, mit denen Teilnehmer einer Blockchain Einigkeit über neue Blöcke und die gültige Historie des Netzwerks erreichen. Er bestimmt zum Beispiel, wer einen Block vorschlagen darf, wie Validatoren darüber abstimmen und wann ein Block bestätigt oder final wird.

Byzantine Fault Tolerance ist die Eigenschaft, die dafür sorgt, dass dieser Prozess auch dann weiter funktioniert, wenn einige Validatoren ausfallen, Fehler machen oder falsche Informationen senden.

BFT ist also meist kein separates System neben dem Konsensmechanismus. Es besteht aus den Regeln innerhalb des Konsensprozesses, die verhindern, dass unzuverlässige Validatoren die Blockchain täuschen können. Denk zum Beispiel an eine hohe Abstimmungsschwelle, digitale Signaturen, mehrere Abstimmungsrunden und das Ersetzen eines Validators, der keinen gültigen Block vorschlägt.

Die genaue Funktionsweise unterscheidet sich je nach Blockchain, aber bei vielen BFT-Protokollen läuft der Prozess ungefähr gleich ab.

Ein Validator wird vorübergehend ausgewählt, um einen neuen Block vorzuschlagen. Dieser Validator wird oft Proposer oder Leader genannt. Im Block stehen neue Transaktionen und ein Verweis auf den vorherigen Block. Der Proposer signiert den Vorschlag digital, damit andere Validatoren prüfen können, von wem er stammt.

Die anderen Validatoren prüfen dann, ob der Block gültig ist. Sie schauen zum Beispiel, ob die Transaktionen den Regeln entsprechen, ob Nutzer genug Guthaben haben und ob dieselben Token nicht doppelt ausgegeben werden. Außerdem prüfen sie, ob der Block an die richtige Version der Blockchain anknüpft.

Wenn ein Validator den Block für gültig hält, gibt er eine digitale Stimme ab. Durch diese Signatur kann das Netzwerk sehen, wer abgestimmt hat, für welchen Block die Stimme gedacht war und ob ein Validator auch für einen konfliktierenden Block gestimmt hat.

Hier kommt Byzantine Fault Tolerance ins Spiel. Das Netzwerk verlässt sich nicht auf die Entscheidung eines einzelnen Validators. Bei vielen BFT-Protokollen müssen mehr als zwei Drittel des gesamten Stimmgewichts denselben Block unterstützen, bevor er final werden kann.

Diese hohe Abstimmungsschwelle sorgt dafür, dass eine kleine Gruppe defekter oder böswilliger Validatoren nicht eigenständig bestimmen kann, welcher Block gültig ist. Wenn einige Validatoren falsche Informationen senden oder nicht reagieren, können die übrigen Validatoren trotzdem gemeinsam zu einer Entscheidung kommen.

Beispiel: Ethereum nutzt Proof of Stake und BFT-ähnliche Regeln, um Blöcke final zu machen. Validatoren staken ETH und stimmen anschließend über Checkpoints in der Blockchain ab. Mindestens zwei Drittel der insgesamt gestakten ETH müssen denselben Checkpoint unterstützen, damit er final wird. Wenn ein kleiner Teil der Validatoren ausfällt oder falsch abstimmt, kann Ethereum weiterhin Finalität erreichen. Wenn etwa ein Drittel des gesamten Stimmgewichts nicht korrekt teilnimmt, kann die Finalität vorübergehend stoppen. Ethereum hat dafür einen Inactivity Leak: Validatoren, die über längere Zeit nicht teilnehmen, verlieren schrittweise einen Teil ihres Stakes. Dadurch können die aktiven Validatoren am Ende wieder genug Stimmgewicht vertreten, um Finalität zu erreichen.

Bei Proof-of-Stake-Netzwerken geht es deshalb meist nicht nur um die Anzahl der Validatoren, sondern vor allem um ihr Stimmgewicht. Dieses Stimmgewicht hängt von der Menge an Token ab, die sie gestakt haben.

Manche Konsensprotokolle nutzen mehrere Abstimmungsrunden. Ein bekanntes Beispiel ist Tendermint, heute als CometBFT weiterentwickelt und von vielen Blockchains im Cosmos-Ökosystem genutzt, darunter Cosmos Hub. Validatoren stimmen dabei zuerst über den vorgeschlagenen Block ab und bestätigen dann in einer nächsten Runde, dass genug andere Validatoren denselben Vorschlag unterstützen. So prüft das Netzwerk nicht nur, ob der Block gültig ist, sondern auch, ob es breite Zustimmung dazu gibt.

Es kann auch passieren, dass nicht genug Unterstützung zustande kommt. Der Proposer kann zum Beispiel offline sein, einen ungültigen Block vorschlagen oder widersprüchliche Vorschläge verbreiten. Der Konsensmechanismus startet dann nach einer bestimmten Wartezeit eine neue Runde mit einem anderen Proposer.

Auch das ist Teil der Fehlertoleranz. Ein einzelner defekter oder böswilliger Validator kann das Netzwerk dadurch nicht unbegrenzt aufhalten.

Der Konsensmechanismus legt also fest, wie die Blockchain gemeinsam Entscheidungen trifft. Byzantine Fault Tolerance sorgt dafür, dass diese Entscheidungsfindung zuverlässig bleibt, wenn nicht jeder Teilnehmer korrekt handelt.

Kurz zusammengefasst: Wie funktioniert Byzantine Fault Tolerance?

1. Der Konsensmechanismus bestimmt, welcher Validator einen Block vorschlagen darf und wie andere Validatoren darüber abstimmen.
2. Die anderen Validatoren prüfen, ob der vorgeschlagene Block gültig ist.
3. BFT sorgt dafür, dass das Netzwerk nicht einem einzelnen Validator vertraut, sondern erst entscheidet, wenn eine große Mehrheit denselben Block unterstützt.
4. Digitale Signaturen machen sichtbar, wer wofür gestimmt hat und ob ein Validator widersprüchliche Stimmen abgegeben hat.
5. Bei vielen BFT-Protokollen sind mehr als zwei Drittel des gesamten Stimmgewichts nötig, um einen Block final zu machen.
6. Wenn ein Proposer ausfällt, lügt oder keine gültige Mehrheit bekommt, startet das Protokoll eine neue Abstimmungsrunde mit einem anderen Proposer.
7. Die Rolle von BFT ist also, den Konsens zuverlässig zu halten, wenn einige Validatoren ausfallen, Fehler machen oder bewusst falsche Informationen verbreiten.

Was sollen Safety und Liveness schützen?

Byzantine Fault Tolerance soll dafür sorgen, dass eine Blockchain zuverlässig bleibt, wenn einige Validatoren ausfallen, Fehler machen oder falsche Informationen verbreiten. Dabei muss das Netzwerk zwei Probleme vermeiden.

Erstens dürfen Validatoren nicht bei zwei unterschiedlichen finalen Versionen der Blockchain landen. Zweitens muss das Netzwerk, solange es möglich ist, weiter neue Blöcke und Transaktionen verarbeiten.

Diese beiden Ziele heißen im BFT-Kontext Safety und Liveness.

Safety: keine zwei unterschiedlichen Versionen

Safety bedeutet, dass das Netzwerk nicht zwei konfliktierende Blöcke als final akzeptiert.

Stell dir vor, zwei Gruppen von Validatoren bekommen jeweils einen anderen Block. Ohne klare Regeln könnten beide Gruppen glauben, dass ihre eigene Version gültig ist. Die Blockchain könnte dann zwei unterschiedliche Transaktionshistorien bekommen.

BFT-Protokolle versuchen das mit einer hohen Abstimmungsschwelle, mehreren Abstimmungsrunden und digital signierten Stimmen zu verhindern. Außerdem kann es Regeln geben, die verhindern, dass Validatoren einfach für einen anderen Block stimmen, nachdem sie zuvor schon einen Vorschlag unterstützt haben.

Safety sorgt also dafür, dass ehrliche Teilnehmer derselben finalen Version der Blockchain folgen, auch wenn einige Validatoren widersprüchliche Informationen verbreiten.

Liveness: das Netzwerk läuft weiter

Liveness bedeutet, dass das Netzwerk weiterhin neue Entscheidungen treffen kann.

Das heißt: Neue Blöcke werden produziert, Transaktionen verarbeitet und ein defekter oder böswilliger Proposer kann ersetzt werden, wenn er den Prozess blockiert.

BFT-Protokolle nutzen dafür zum Beispiel Wartezeiten und neue Abstimmungsrunden. Wenn ein Proposer keinen gültigen Block vorschlägt oder nicht reagiert, ist nach einiger Zeit ein anderer Validator an der Reihe.

Safety und Liveness können manchmal miteinander kollidieren. Wenn zu viele Validatoren offline sind oder unterschiedliche Informationen verbreiten, kann das Netzwerk möglicherweise nicht genug verlässliche Stimmen sammeln.

Das Protokoll kann sich dann entscheiden, vorübergehend keine Blöcke final zu machen. Die Blockchain macht dann kurz keinen Fortschritt, verhindert aber, dass zwei unterschiedliche Versionen bestätigt werden.

BFT-Protokolle geben bei starker Unsicherheit deshalb meist Safety den Vorrang. Das Netzwerk steht lieber vorübergehend still, als eine möglicherweise falsche oder konfliktierende Version der Blockchain final zu machen.

Was ist der Unterschied zwischen Byzantine Fault Tolerance und dem Byzantine Generals Problem?

Das Byzantine Generals Problem und Byzantine Fault Tolerance gehören zusammen, bedeuten aber nicht dasselbe.

Das Byzantine Generals Problem ist ein Gedankenexperiment, das zeigt, warum Einigkeit in einem Netzwerk ohne zentrale Entscheidungsinstanz schwierig ist. In der Geschichte müssen mehrere Generäle gemeinsam entscheiden, ob sie angreifen oder sich zurückziehen. Sie kommunizieren nur über Nachrichten, während einige Generäle möglicherweise lügen oder widersprüchliche Informationen verbreiten.

Bei einer Blockchain spielt im Grunde dasselbe Problem. Validatoren müssen gemeinsam entscheiden, welche Transaktionen und Blöcke gültig sind, während sie nicht sicher wissen, ob jeder Teilnehmer ehrlich und zuverlässig ist.

Byzantine Fault Tolerance beschreibt dann, wie ein Netzwerk mit diesem Problem umgeht. Es sorgt dafür, dass Validatoren trotzdem zu einer gemeinsamen Entscheidung kommen können, auch wenn ein Teil der Teilnehmer ausfällt, Fehler macht oder falsche Informationen sendet.

Das Byzantine Generals Problem beschreibt also das Problem. Byzantine Fault Tolerance ist die Fähigkeit eines Netzwerks, dieses Problem zu lösen. Die konkreten Regeln, mit denen das passiert, wie Abstimmungsrunden, digitale Signaturen und eine hohe Abstimmungsschwelle, bilden zusammen das BFT-Protokoll.

Wie setzen Blockchains Byzantine Fault Tolerance um?

Blockchains können Byzantine Fault Tolerance auf verschiedene Arten umsetzen. Nicht jedes Netzwerk nutzt dasselbe Protokoll, aber das Ziel ist immer ähnlich: Validatoren sollen gemeinsam eine gültige Version der Blockchain auswählen, auch wenn ein Teil ausfällt oder falsche Informationen verbreitet.

Die Unterschiede liegen vor allem darin, wie ein Validator ausgewählt wird, um einen Block vorzuschlagen, wie viele Abstimmungsrunden nötig sind und wann ein Block final wird. Außerdem unterscheidet sich je nach Protokoll, was passiert, wenn Validatoren nicht reagieren oder widersprüchliche Stimmen abgeben.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance, meist abgekürzt als PBFT, ist eines der bekanntesten BFT-Protokolle. Es wurde von Miguel Castro und Barbara Liskov entwickelt, um Byzantine Fault Tolerance in echten Computersystemen praktikabel zu machen.

PBFT arbeitet mit einem temporären Leader, der einen Vorschlag an die anderen Teilnehmer schickt. Sie prüfen den Vorschlag und teilen danach miteinander, ob sie ihn für gültig halten. Anschließend bestätigen sie, dass genug Teilnehmer denselben Vorschlag unterstützen.

Durch diese unterschiedlichen Kommunikationsrunden kann das Netzwerk prüfen, ob wirklich breite Einigkeit besteht. PBFT funktioniert besonders gut mit einer relativ kleinen Gruppe bekannter Teilnehmer. Wenn die Gruppe größer wird, müssen immer mehr Nachrichten ausgetauscht werden. Dadurch wird das Protokoll weniger effizient für Blockchains mit sehr vielen Validatoren.

Tendermint BFT

Tendermint BFT wird von vielen Blockchains im Cosmos-Ökosystem genutzt. Bei Tendermint schlägt zuerst ein Validator einen Block vor. Danach folgen zwei Abstimmungsrunden, in denen Validatoren angeben, ob sie den Block unterstützen.

Ein Block wird erst final, wenn mehr als zwei Drittel des Stimmgewichts zustimmen. Tendermint nutzt außerdem einen Locking-Mechanismus. Wenn ein Validator sieht, dass ein Block genug Unterstützung hat, wird er sozusagen auf diesen Block festgesetzt.

Der Validator darf danach nicht einfach für einen konfliktierenden Block stimmen. Das hilft zu verhindern, dass in verschiedenen Runden zwei widersprüchliche Blöcke bestätigt werden.

HotStuff

HotStuff ist ein moderneres BFT-Protokoll, das dieselbe Grundidee effizienter umsetzen will. Auch hier schlägt ein temporärer Leader Blöcke vor, und genug Validatoren müssen diese unterstützen.

HotStuff kann die Unterstützung der Validatoren in einem Quorum Certificate zusammenfassen. Das ist ein kryptografischer Nachweis, dass genug Validatoren denselben Vorschlag unterstützt haben. Validatoren müssen ihre Stimmen weiterhin senden, aber das Quorum Certificate macht es möglich, den Beleg für diese breite Unterstützung kompakt weiterzugeben. HotStuff ist außerdem darauf ausgelegt, die Kommunikation und den Leader-Wechsel effizienter zu machen.

Dadurch müssen nicht ständig alle einzelnen Stimmen separat verarbeitet werden. Das Protokoll ist zudem so entworfen, dass es schneller den Leader wechselt, wenn der aktuelle Leader nicht richtig funktioniert.

Verschiedene moderne Blockchainprotokolle sind ganz oder teilweise von HotStuff inspiriert.

Ethereum

Ethereum nutzt keine klassische Form von PBFT, Tendermint oder HotStuff. Das Netzwerk nutzt Proof of Stake, wobei Validatoren mit der ETH abstimmen, die sie gestakt haben. Trotzdem sind BFT-Prinzipien klar darin erkennbar, wie Ethereum Finalität erreicht.

Validatoren stimmen über Checkpoints in der Blockchain ab. Ein Checkpoint wird erst final, wenn mindestens zwei Drittel der insgesamt gestakten ETH ihn unterstützen.

Wenn mehr als ein Drittel des Stimmgewichts nicht mitmacht, kann die Finalität vorübergehend stoppen. Das Netzwerk entscheidet sich dann, auf genügend verlässliche Stimmen zu warten, statt zwei unterschiedliche Versionen final zu machen.

Validatoren, die nachweislich für widersprüchliche Versionen stimmen, können bestraft werden. Das nennt man Slashing. Die ökonomische Strafe unterstützt hier die BFT-Regeln: Validatoren können falsche Informationen verbreiten, aber dieses Verhalten ist sichtbar und kann Folgen haben.

Bitcoin

Bitcoin geht dasselbe Grundproblem anders an. Das Netzwerk muss ebenfalls Konsens erreichen, während Teilnehmer einander nicht vollständig vertrauen, nutzt dafür aber kein klassisches, abstimmungsbasiertes BFT-Protokoll.

Bitcoin nutzt Proof of Work. Miner verwenden Rechenleistung, um neue Blöcke zu produzieren, danach prüfen Nodes, ob diese Blöcke gültig sind. Miner bauen auf der gültigen Chain weiter, in die das meiste kumulative Rechenwerk investiert wurde.

Ein Block ist dabei nicht sofort final. Die Wahrscheinlichkeit, dass er rückgängig gemacht wird, wird immer kleiner, je mehr Blöcke oben drauf gebaut werden. Das nennt man probabilistische Finalität.

Bitcoin versucht also, dasselbe allgemeine Problem zu lösen wie BFT-Protokolle: Wie hält ein Netzwerk eine verlässliche Historie, wenn nicht jeder Teilnehmer vertrauenswürdig ist? Der Unterschied ist, dass Bitcoin dafür Rechenleistung und wirtschaftliche Kosten nutzt, während klassische BFT-Protokolle vor allem mit expliziten Abstimmungsrunden und einer hohen Abstimmungsschwelle arbeiten.

Was passiert, wenn Validatoren nicht mitmachen?

Was passiert, wenn Validatoren ausfallen oder falsch handeln, hängt davon ab, wie viel Stimmgewicht sie zusammen vertreten.

Wenn nur eine kleine Gruppe von Validatoren nicht mitmacht, können die übrigen Validatoren meist noch genug Unterstützung sammeln, um neue Blöcke zu bestätigen. Das Netzwerk funktioniert dann ganz normal weiter, auch wenn nicht jeder Validator aktiv oder zuverlässig ist.

Die Lage ändert sich, wenn mehr als ein Drittel des gesamten Stimmgewichts nicht teilnimmt. Bei vielen BFT-Protokollen kann das Netzwerk dann die erforderliche Unterstützung von mehr als zwei Dritteln nicht mehr sammeln. Neue Blöcke können dadurch vorübergehend nicht final gemacht werden. Diese Gruppe kann den Fortschritt also blockieren, aber meist nicht eigenständig eine konfliktierende Version der Blockchain bestätigen.

Wenn eine Gruppe mehr als zwei Drittel des Stimmgewichts kontrolliert und zusammenarbeitet, kann sie eigenständig genug Unterstützung bilden, um Blöcke zu bestätigen. So eine Gruppe kann damit bestimmen, welche gültigen Blöcke Finalität erreichen, und kann Transaktionen zensieren, indem sie diese nicht aufnimmt. Um zwei konfliktierende Versionen final zu machen, müssten Validatoren allerdings nachweislich gegen die Konsensregeln verstoßen, was bei vielen Proof-of-Stake-Netzwerken zu Slashing führen kann.

Deshalb ist nicht nur die Anzahl der Validatoren wichtig, sondern vor allem die Verteilung des Stimmgewichts. Eine Blockchain kann Tausende Validatoren haben und trotzdem relativ konzentriert sein, wenn eine kleine Zahl von Parteien einen großen Teil der gestakten Token kontrolliert.

Wie werden böswillige Validatoren bestraft?

Proof-of-Stake-Blockchains können Validatoren bestrafen, wenn sie nachweislich gegen die Konsensregeln verstoßen. Das nennt man Slashing.

Ein Validator kann zum Beispiel bestraft werden, wenn er für zwei konfliktierende Blöcke stimmt oder versucht, zwei unterschiedliche Versionen der Blockchain zu unterstützen. Weil jede Stimme digital signiert ist, kann das Netzwerk prüfen, welcher Validator den Verstoß begangen hat.

Die Strafe unterscheidet sich je nach Blockchain. Ein Validator kann Staking-Rewards verlieren, einen Teil seiner gestakten Token verlieren oder vorübergehend aus der Validator-Set entfernt werden. Bei schweren Verstößen kann der Ausschluss länger dauern oder dauerhaft sein.

Slashing macht Betrug nicht unmöglich, erhöht aber die finanziellen Folgen. Ein Validator, der die Konsensregeln verletzt, riskiert dadurch, einen Teil seines eigenen eingesetzten Werts zu verlieren.

Was sind die Vorteile von Byzantine Fault Tolerance?

Byzantine Fault Tolerance hat mehrere Vorteile:

1. Das Netzwerk kann bei Fehlern weiterlaufen: Nicht jeder Validator muss jederzeit online oder fehlerfrei sein. Solange genug Validatoren korrekt arbeiten, kann das Netzwerk weiter neue Blöcke verarbeiten.
2. Die Blockchain behält eine gemeinsame Historie: BFT hilft zu verhindern, dass unterschiedliche Gruppen von Validatoren konfliktierende Blöcke final machen. Dadurch folgen ehrliche Teilnehmer derselben Version der Blockchain.
3. Blöcke können schnell final werden: Viele BFT-Protokolle machen einen Block final, sobald genug Validatoren ihn unterstützen. Nutzer müssen dadurch oft nicht auf viele zusätzliche Blöcke warten.
4. Validator-Verhalten ist überprüfbar: Stimmen sind digital signiert. So kann das Netzwerk sehen, welcher Validator für welchen Block gestimmt hat und ob jemand widersprüchliche Stimmen abgegeben hat.
5. Keine zentrale Entscheidungsinstanz nötig: Validatoren können gemeinsam bestimmen, welche Blöcke gültig sind, ohne dass eine zentrale Partei alle Entscheidungen trifft.

Was sind die Nachteile von Byzantine Fault Tolerance?

Byzantine Fault Tolerance hat auch mehrere Nachteile:

1. Das Netzwerk kann vorübergehend stehen bleiben: Wenn zu wenige Validatoren teilnehmen, kann das erforderliche Quorum nicht gebildet werden. Das Netzwerk kann dann möglicherweise zwar weiter Blöcke vorschlagen, sie aber nicht final machen. Transaktionen bleiben dadurch länger unsicher, und Nutzer müssen warten, bis wieder genug Validatoren teilnehmen.
2. Validatoren müssen viele Informationen austauschen: Validatoren müssen während des Konsensprozesses Vorschläge, Stimmen und Bestätigungen miteinander teilen. Je mehr Validatoren es gibt, desto stärker steigt auch die Kommunikationsmenge. Das kann das Netzwerk verlangsamen und mehr Bandbreite und Rechenleistung erfordern.
3. BFT-Protokolle sind technisch komplex: Diese Protokolle arbeiten mit mehreren Abstimmungsrunden, Wartezeiten, temporären Leadern und Regeln, die festlegen, wann ein Validator seine Stimme ändern darf. Ein Fehler in diesen Regeln oder in der Software kann dazu führen, dass Validatoren hängen bleiben, unterschiedliche Informationen verarbeiten oder vorübergehend keinen Konsens erreichen.
4. Das Stimmgewicht kann sich konzentrieren: Eine Blockchain kann viele Validatoren haben, während einige große Staking-Provider oder Organisationen zusammen einen großen Teil des Stimmgewichts kontrollieren. Wenn diese Parteien mehr als ein Drittel des Stimmgewichts kontrollieren, können sie die Finalität möglicherweise blockieren. Mit mehr als zwei Dritteln können sie starken Einfluss darauf nehmen, welche Blöcke bestätigt werden.
5. BFT schützt nur die Konsensschicht: BFT hilft Validatoren, sich über die gültige Blockchain zu einigen, schützt aber nicht alle Teile des Netzwerks. Eine Transaktion kann zum Beispiel korrekt bestätigt werden, während das verwendete Smart Contract einen Fehler enthält. Außerdem verhindert BFT keine gehackten Wallets, anfälligen Bridges, falsche Preisinformationen von Oracles, Probleme bei Krypto-Exchanges oder Verluste durch Kursrückgänge.

Fazit

Byzantine Fault Tolerance sorgt dafür, dass eine Blockchain zuverlässig funktionieren kann, wenn einige Validatoren ausfallen, Fehler machen oder bewusst falsche Informationen verbreiten. Dabei vertraut das Netzwerk nicht einem einzelnen Teilnehmer, sondern nutzt unter anderem digitale Signaturen, Abstimmungsrunden und eine hohe Abstimmungsschwelle, um zu einer gemeinsamen Entscheidung zu kommen.

BFT ist kein eigenständiger Konsensmechanismus, sondern eine Eigenschaft des Konsensprozesses. Es hilft zu verhindern, dass unterschiedliche Versionen der Blockchain gleichzeitig final werden, und sorgt dafür, dass das Netzwerk, solange genug Validatoren teilnehmen, weiter neue Blöcke verarbeiten kann.

Blockchains setzen diese Prinzipien auf unterschiedliche Weise um. Tendermint nutzt mehrere Abstimmungsrunden und Locking-Regeln, Ethereum nutzt BFT-ähnliche Regeln für Finalität, und Bitcoin löst ein vergleichbares Problem mit Proof of Work und probabilistischer Finalität.

Byzantine Fault Tolerance macht eine Blockchain nicht vollständig gegen alle Fehler und Angriffe geschützt. Es ist aber eine wichtige Grundlage für Netzwerke, in denen Teilnehmer einander nicht vollständig vertrauen müssen und trotzdem gemeinsam eine gültige Transaktionshistorie führen können.