---
title: "Byzantinische Fehlertoleranz: Sicherheit, Lebendigkeit und Quoren"
description: "Byzantinische Fehlertoleranz beschreibt, wann ein verteiltes Protokoll trotz beliebiger Fehler sicher und lebendig bleibt. Protokoll, Netzmodell, Fehlergrenze, Quorumregel, Gewichte, Finalität und Wiederherstellung sind gemeinsam zu prüfen."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Byzantinische Fehlertoleranz: Sicherheit, Lebendigkeit und Quoren
> Nur zur Aufklärung über Protokolle. Eine BFT-Bezeichnung oder Quorumsschwelle allein belegt weder Sicherheit und Lebendigkeit noch korrekte Ausführung, Dezentralisierung, Finalität oder Vermögensschutz.
## Direkte Antwort
Byzantinische Fehlertoleranz (BFT) ist eine Eigenschaft eines bestimmten verteilten Protokolls unter einem bestimmten Fehler- und Netzmodell: Es erfüllt seine angegebenen Garantien weiter, auch wenn Teilnehmer ausfallen, Nachrichten zurückhalten, verschiedenen Gegenstellen widersprüchliche Nachrichten senden oder sich anderweitig beliebig verhalten. BFT ist kein einzelner Algorithmus und bedeutet nicht, dass bei jeder Netzpartition alle Dienste verfügbar bleiben.
Die Garantien sind zu trennen. `safety` (Sicherheit) bedeutet, dass ehrliche Teilnehmer keine widersprüchlichen Werte entscheiden; `liveness` (Lebendigkeit) bedeutet, dass zulässige Eingaben letztlich zu einer Entscheidung führen können; `validity` (Gültigkeit) beschränkt die entscheidbaren Werte. Bei unzureichender Kommunikation oder ehrlicher Stimmkraft kann ein Protokoll anhalten, um Sicherheit zu erhalten. Korrekter Konsens belegt auch nicht die Korrektheit von Anwendungscode, Gültigkeitsregeln, Bridges, Schlüsseln oder Governance.
In einer verbreiteten Klasse authentifizierter, partiell synchroner BFT-Protokolle tolerieren `n=3f+1` Replikate höchstens `f` byzantinische Replikate, und ein Commit-Zertifikat verwendet `q=2f+1` Stimmen. Die bekannten Aussagen „weniger als ein Drittel fehlerhaft“ und „mehr als zwei Drittel Quorum“ stammen aus diesem Modell. Synchrone, randomisierte asynchrone und Crash-Fehler-Protokolle, Proof-of-Work-Ketten und andere BFT-Konstruktionen können andere Annahmen und Grenzen haben.
In stakegewichteten Systemen beziehen sich Schwellen auf die vom Protokoll definierte Stimmkraft, nicht zwingend auf Validator-, Adress-, Personen- oder unabhängige Betreiberzahlen. Vor Anwendung eines Anteils sind genaue Protokollversion, Gewichtssnapshot, Entscheidungstyp, Netzannahme, Quorumsvergleich (`>` oder `>=`) und Fehlerverhalten zu nennen.
## Funktionsweise
1. **Entscheidung definieren.** Feststellen, ob Knoten Transaktionen ordnen, einen Block committen, einen Checkpoint finalisieren, einen Leiter wählen, einen Zustandsübergang akzeptieren oder einen Fork auswählen. Diese Entscheidungen sind nicht austauschbar.
2. **System- und Angreifermodell angeben.** Mitgliedschaft, Authentifizierung, Berechtigungsänderungen, Stimmgewichte, adaptive Korruption, Schlüsselkompromittierung, Äquivokation, Abstürze, Nachrichtenverlust, Zensur, Dienstverweigerung und mögliche Fehlerkorrelation erfassen.
3. **Netzmodell angeben.** Synchronität, partielle Synchronität und Asynchronität unterscheiden. Bei partieller Synchronität klären, was erst nach einer unbekannten globalen Stabilisierungszeit garantiert ist und wie Zeitüberschreitungen angepasst werden.
4. **Quorumsregel herleiten.** Exakte Schwelle und Sperr- oder Abstimmungsregeln verwenden. Im klassischen Fall `n=3f+1` schneiden sich zwei `2f+1`-Quoren in mindestens `f+1` Replikaten; bei höchstens `f` byzantinischen enthält der Schnitt ein ehrliches Replikat.
5. **Jede Phase und jedes Zertifikat verfolgen.** Vorschlag, Stimme, Sperre, View- oder Rundenwechsel, Commit, Forkwahl und Wiederherstellung prüfen. Eine signierte Supermehrheit zählt nur, wenn Höhe, Runde, Wert, Vorgänger, Domäne, Mitgliedschaftsepoche und vorheriges Zertifikat geprüft werden.
6. **Nachweise für Sicherheit und Lebendigkeit trennen.** Zuerst beweisen, welche Konfliktentscheidungen jederzeit ausgeschlossen sind; dann testen, ob Fortschritt wiederkehrt, sobald Kommunikations- und Ehrlichkeitsannahmen gelten. Ein Timeout ist ein Planungsmittel, kein Beweis für Böswilligkeit.
7. **Implementierung und Betrieb prüfen.** Clientvielfalt, Schlüsselverwahrung, Signierer-Failover, Replay-Schutz, Zustandssynchronisierung, Beweisbehandlung, Mitgliedschaftswechsel, Überwachung, Bestätigungsregeln und Wiederherstellung mit dem bewiesenen Modell abgleichen.
Das FLP-Ergebnis besagt, dass ein deterministisches Konsensprotokoll in einem vollständig asynchronen Modell selbst bei nur einem möglichen Prozessabsturz keine Terminierung garantieren kann. Es besagt weder, dass Sicherheit unmöglich ist, noch dass verteilter Konsens nie funktioniert. Partielle Synchronität, Randomisierung, Fehlerdetektoren, ökonomische Annahmen oder schwächere Garantien ändern auf unterschiedliche Weise die konkreten Unmöglichkeitsbedingungen.
## Durchgerechnete Beispiele
### 1. Vier gleich gewichtete Replikate
Es gelte `n=4`, `f=1` und `q=3`. Zwei Mengen mit je drei Stimmen schneiden sich in mindestens `3+3-4=2` Replikaten. Bei höchstens einem byzantinischen ist mindestens eines im Schnitt ehrlich. Verbieten die Regeln ehrlichen Knoten, im maßgeblichen Höhen- und Rundenverlauf für Konfliktwerte zu stimmen, können nicht zwei widersprüchliche Commit-Zertifikate entstehen.
Sind zwei Replikate offline, bleiben nur `2` Stimmen und kein `q=3`-Zertifikat entsteht. Das ist ein Lebendigkeits-, nicht automatisch ein Sicherheitsfehler: Ein sicher entworfenes Protokoll wartet, statt die Schwelle lokal zu senken.
### 2. Sieben gleich gewichtete Replikate
Es gelte `n=7`, `f=2` und `q=5`. Zwei Quoren schneiden sich in mindestens `5+5-7=3=f+1` Replikaten. Da höchstens `2` byzantinisch sind, enthält der Schnitt ein ehrliches. Zwei byzantinische können allein kein Fünf-Stimmen-Zertifikat bilden; drei abwesende oder zurückhaltende lassen jedoch nur `4` Stimmen und können den Fortschritt stoppen.
Die Schwellenrechnung ist notwendig, aber nicht hinreichend. Akzeptieren ehrliche Implementierungen Stimmen falscher Höhe, verwenden eine Mitgliedschaft erneut, verletzen eine Sperre oder signieren mit kompromittierten Schlüsseln, entsprechen die Beweisannahmen nicht mehr dem eingesetzten System.
### 3. Gewichtete Stimmkraft
Validatoren hätten Gewichte `40`, `30`, `20` und `10`, insgesamt `100`; ein Zertifikat verlangt strikt mehr als `2/3`, hier mindestens `67`. Die Koalition `40+30=70` kann zertifizieren; `30+20+10=60` kann es trotz drei von vier Validatoren nicht. Fällt der Validator mit Gewicht `40` aus, bleiben `60` und die Finalität stoppt.
Zwei Mengen mit mindestens `67` schneiden sich in mindestens `67+67-100=34`. Widersprüchliche Zertifikate bedeuten daher, dass mindestens `34` Gewicht an beiden beteiligt war oder eine andere Annahme scheiterte. In manchen Protokollen kann wenig mehr als ein Drittel Äquivokation Sicherheit brechen; „zwei Drittel für einen Angriff“ ist kein universelles Minimum.
### 4. Partielle Synchronität und Timeouts
Vier Replikate nutzten Runden-Timeouts von `1 s`, `2 s`, `4 s` und `8 s`. Vor der unbekannten Stabilisierung können Nachrichten nach jedem aktuellen Timeout eintreffen, sodass Runden ohne Entscheidung wechseln. Liegt die Verzögerung danach unter `3 s`, kann eine Runde mit `4 s` oder mehr einem ehrlichen Vorschlagenden und Quorum genug Zeit geben, sofern die übrigen Annahmen gelten.
Die Zahlen illustrieren späteren Fortschritt, keine allgemeine Timeout-Formel. Kurze Zeiten verursachen unnötige Viewwechsel, lange verlängern die Erholung. Sicherheit darf nicht davon abhängen, die Verzögerungsgrenze vor der Stabilisierung zu erraten.
## Risiken und Prüffehler
### Modell und Beweis
- „BFT“ sagen, ohne Protokoll, Version, Entscheidung, Fehler- und Netzmodell, Mitgliedschaft und Schwelle zu nennen.
- `n=3f+1` oder ein Drittel auf jedes verteilte Register anwenden, auch wenn dessen Beweis andere Annahmen nutzt.
- Sicherheit, Lebendigkeit, Gültigkeit, Verfügbarkeit, Konsistenz, Finalität, Forkwahl und Transaktionskorrektheit gleichsetzen.
- Behaupten, FLP mache Konsens unmöglich, ohne Determinismus, vollständige Asynchronität und garantierte Terminierung beizubehalten.
- Knoten oder Adressen zählen, obwohl das Protokoll Stake, Delegation, Komitees, Epochen oder andere Ressourcen zählt.
- „Zwei Drittel“ mehrdeutig runden oder `>`, `>=`, Ganzzahlgewichte und Nenner-Snapshot ignorieren.
- Nur Quorumsgröße, nicht Schnitt, Sperren, Zertifikate, Viewwechsel, Rekonfiguration und Zustandstransfer prüfen.
- Ohne Beleg annehmen, der Beweis decke adaptive Korruption, Schlüsseldiebstahl, korrelierte Fehler, Dienstverweigerung oder Langstreckenhistorien ab.
### Implementierung und Betrieb
- Signaturen akzeptieren, die nicht an Kette, Domäne, Höhe, Runde, Wert, Vorgänger, Mitgliedschaftsepoche und Nachrichtentyp gebunden sind.
- Alte Stimmen oder Zertifikate über Runden, Höhen, Forks, Netze, Upgrades oder Validatorwechsel hinweg wiedergeben.
- Doppelsignatur, Sperrrückschritt, unsicheres Signierer-Failover oder zwei aktive Replikate mit einer Validatoridentität zulassen.
- Timeout als Böswilligkeitsbeweis behandeln und sicherheitskritisch nur nach lokalen Uhren entscheiden.
- Korrelierte Fehler durch gemeinsamen Client, Cloud, Region, Netz, Hardware, Schlüsselverwaltung oder Betreiber ignorieren.
- Annehmen, Slashing verhindere Fehler, stelle Lebendigkeit her, mache finalisierte Anwendungsaktionen rückgängig oder entschädige alle.
- Nur Normalbetrieb testen statt Partitionen, Verzögerung und Umordnung, Äquivokation, Vorschlagendenfehler, Neustarts und Mitgliederwechsel.
### Anwendung und Governance
- Einen im Konsens committeten Wert ohne deterministische Ausführung und Zustandsübergangsprüfung als gültigen Zustand behandeln.
- Einzahlungen gutschreiben, Bridge-Assets prägen oder Geschäfte abwickeln, bevor die genaue erforderliche Finalität erreicht ist.
- Protokollfinalität mit sozialer Unumkehrbarkeit nach Schlüsselkompromittierung, Softwarefehler oder Governance-Eingriff gleichsetzen.
- Zensur und Aufnahmeverzögerung ignorieren, weil Blöcke für andere Nutzer weiter finalisiert werden.
- Aus BFT-Bezeichnung oder beworbener Validatorzahl Dezentralisierung, Vermögensschutz, Tokenwert oder Rechtsdurchsetzbarkeit ableiten.
## Häufige Irrtümer
- **BFT bedeutet, dass das Netz nie stoppt.** Viele BFT-Protokolle opfern bei zu vielen Fehlern oder Partitionen bewusst Lebendigkeit, um Sicherheit zu wahren.
- **Mehr als 51 % ehrliche Teilnehmer reichen immer.** Die Schwelle hängt vom Protokoll ab; klassisches partiell synchrones BFT braucht für Fortschritt häufig mehr als zwei Drittel der maßgeblichen Stimmkraft.
- **Ein Angreifer braucht immer zwei Drittel, um Sicherheit zu brechen.** Zwei Drittel können allein zertifizieren; zwei Konfliktzertifikate können aber schon knapp über ein Drittel Äquivokation offenlegen.
- **Mehr Validatoradressen verbessern automatisch die Toleranz.** Gemeinsames Eigentum, Delegation, Clients, Infrastruktur, Schlüssel und Fehlerdomänen bestimmen die Unabhängigkeit.
- **Slashing ist der BFT-Beweis.** Es ist eine ökonomische Reaktion mancher PoS-Systeme; Sicherheit folgt aus Regeln und Annahmen, und Strafen beseitigen externe Folgen nicht.
## Verwandte Themen
- [Problem der byzantinischen Generäle](/de/crypto/byzantine-generals-problem/)
- [Konsensmechanismus](/de/crypto/consensus-mechanism/)
- [Finalität](/de/crypto/finality/)
- [Proof of Stake](/de/crypto/proof-of-stake/)
- [Validator](/de/crypto/validator/)
## Quellen
- [The Byzantine Generals Problem](https://lamport.azurewebsites.net/pubs/byz.pdf) - ACM Transactions on Programming Languages and Systems (abgerufen: 2026-08-18)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (abgerufen: 2026-08-18)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (abgerufen: 2026-08-18)
- [Practical Byzantine Fault Tolerance](https://pmg.csail.mit.edu/papers/osdi99.pdf) - USENIX OSDI (abgerufen: 2026-08-18)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (abgerufen: 2026-08-18)
- [HotStuff: BFT Consensus with Linearity and Responsiveness](https://arxiv.org/abs/1803.05069) - arXiv (abgerufen: 2026-08-18)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (abgerufen: 2026-08-18)
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (abgerufen: 2026-08-18)
Source: https://wiki.fcontext.com/de/crypto/byzantine-fault-tolerance/index.mdx