Was ist das HotStuff-Konsensprotokoll und wie funktioniert es?

Was ist das HotStuff-Konsensprotokoll?

HotStuff ist ein BFT-Konsensprotokoll, mit dem eine feste Gruppe von Validatoren sich auf genau eine endgültige Reihenfolge von Transaktionen oder anderen Aufträgen einigen kann, selbst wenn ein Teil dieser Gruppe Fehler macht oder absichtlich irreführende Nachrichten verschickt.

BFT steht für Byzantine Fault Tolerance. Das bedeutet, dass das Protokoll gegen Validatoren robust ist, die ausfallen, nicht reagieren, lügen oder unterschiedlichen Teilnehmern unterschiedliche Nachrichten schicken. HotStuff sorgt dafür, dass die korrekt arbeitenden Validatoren trotzdem derselben Version der Blockchain oder eines gemeinsamen Registers folgen.

HotStuff arbeitet mit einer bekannten Validatorgruppe. Das Protokoll legt also nicht selbst fest, wer Validator werden darf, wie Staking gestaltet ist oder wie ein offenes Krypto-Netzwerk Teilnehmer auswählt. Solche Regeln liegen außerhalb von HotStuff. Das Protokoll konzentriert sich auf die Frage: Wie erreicht diese Validatorgruppe sicher eine Einigung?

Das ursprüngliche Modell geht von einer Validatorgruppe mit n = 3f + 1 Teilnehmern aus. Dabei ist n die Gesamtzahl der Validatoren und f die maximale Anzahl an Validatoren, die sich fehlerhaft oder böswillig verhalten dürfen. Einfach gesagt: Solange weniger als ein Drittel der Validatoren unzuverlässig ist, funktioniert das System weiterhin korrekt. Bei 4 Validatoren darf maximal 1 unzuverlässig sein. Die anderen 3 Validatoren können dann trotzdem gemeinsam eine sichere Entscheidung treffen. Bei 7 Validatoren dürfen maximal 2 Validatoren unzuverlässig sein. Für eine gültige Entscheidung müssen mindestens 5 Validatoren übereinstimmen. HotStuff nutzt dafür ein Quorum Certificate, oft als QC abgekürzt. Ein QC ist ein kompakter kryptografischer Nachweis, dass genügend Validatoren für denselben Vorschlag gestimmt haben. Ein Quorum ist die minimale Unterstützung, die nötig ist, um eine Entscheidung zu treffen. Im ursprünglichen Modell besteht dieses Quorum aus n − f, also 2f + 1, Stimmen.

Bei 4 Validatoren sind das 3 Stimmen. Bei 7 Validatoren sind das 5 Stimmen. Diese hohe Schwelle verhindert, dass eine kleine Gruppe unzuverlässiger Validatoren eigenständig einen widersprüchlichen Block genehmigen lassen kann.

HotStuff ist für ein partiell synchrones Netzwerk ausgelegt. Das bedeutet, dass Nachrichten zeitweise stark verzögert sein dürfen, das Netzwerk aber letztlich wieder stabil genug werden muss, um Nachrichten rechtzeitig zuzustellen. Die Sicherheit bleibt auch bei großen Verzögerungen erhalten. Fortschritt, wie das Finalisieren neuer Blöcke, ist erst garantiert, wenn das Netzwerk ausreichend stabil ist.

Wichtigste Erkenntnisse

• HotStuff ist ein BFT-Konsensprotokoll für eine feste Gruppe von Validatoren.
• Validatoren halten gemeinsam eine Reihenfolge von Transaktionen oder Aufträgen fest.
• Ein Quorum Certificate beweist kryptografisch, dass ausreichend Validatoren denselben Vorschlag unterstützen.
• Das ursprüngliche Modell toleriert weniger als ein Drittel byzantinischer Validatoren.
• HotStuff bleibt bei Netzwerkverzögerungen sicher, braucht aber ein stabiles Netzwerk für Fortschritt.

Wie funktioniert das HotStuff-Konsensprotokoll?

HotStuff läuft in aufeinanderfolgenden Runden, in denen ein temporärer Leader einen Vorschlag koordiniert und die Validatoren darüber abstimmen. So eine Runde heißt View. Der Leader ist kein dauerhafter Block Producer, sondern hat nur während dieser konkreten View eine koordinierende Rolle.

In der ursprünglichen Basic-HotStuff-Variante sind drei Abstimmungsphasen nötig, bevor eine Entscheidung endgültig wird: prepare, pre-commit und commit. Jede Phase gibt den Validatoren zusätzliche Sicherheit, dass kein widersprüchlicher Vorschlag abgeschlossen werden kann.

Eine spätere, praktischere Form, Chained HotStuff, lässt diese Phasen über aufeinanderfolgende Blöcke hinweg überlappen. Dadurch kann ein neuer Block gleichzeitig einen Nachweis für den Fortschritt früherer Blöcke liefern. Die Grundregeln zu Abstimmungen, Quorums und Sicherheit bleiben dabei gleich.

Welche Rolle spielen Validatoren und der Leader?

Validatoren prüfen, ob der Vorschlag des Leaders sicher ist, bevor sie abstimmen. Sie schauen unter anderem, ob der Vorschlag korrekt auf den richtigen früheren Blöcken aufbaut und in die Sicherheitsregeln des Protokolls passt. Wenn das der Fall ist, schicken sie eine digital signierte Stimme an den Leader.

Der Leader sammelt die Stimmen. Sobald der Leader genug Stimmen hat, bündelt er sie zu einem QC. Statt also immer alle einzelnen Stimmen weiterzuleiten, kann der Leader einen kompakten Nachweis verbreiten, der zeigt, dass ein Quorum zugestimmt hat.

Validatoren nutzen außerdem einen Lock, also eine Sperre. Ein Lock ist eine Regel, die verhindert, dass ein Validator später einfach so einen widersprüchlichen Zweig unterstützt. Ein Validator stimmt normalerweise nur für einen Vorschlag, der seinen gelockten Zweig erweitert. Eine Ausnahme ist möglich, wenn ein QC aus einer höheren View nach den Sicherheitsregeln zeigt, dass eine Fortsetzung sicher ist.

Wenn eine View keinen Fortschritt macht, zum Beispiel weil der Leader offline ist, wechseln Validatoren in eine neue View. Sie schicken dann eine New-View-Nachricht an den nächsten Leader. Darin steht ihr höchstes bekanntes prepareQC, also der stärkste Nachweis, den sie zu diesem Zeitpunkt kennen.

Der neue Leader wählt das höchste erhaltene QC als highQC. Das ist der Ausgangspunkt für einen sicheren neuen Vorschlag. Eine vorab bekannte Rotation kann festlegen, wer der nächste Leader ist. Ein Pacemaker, also ein Mechanismus mit Time-outs, sorgt dafür, dass Validatoren nicht unbegrenzt auf einen nicht funktionierenden Leader warten.

Wie läuft der Konsensprozess ab?

In Basic HotStuff läuft die Entscheidungsfindung Schritt für Schritt über drei Abstimmungsphasen. Die folgende Beschreibung zeigt, wie ein Vorschlag vom Start bis zur endgültigen Entscheidung durchläuft.

1. Der neue Leader sammelt Informationen. Bei einem View-Wechsel erhält der neue Leader New-View-Nachrichten von einem Quorum an Validatoren. Der Leader wählt das höchste QC, das darin enthalten ist. Das verhindert, dass der Leader einen Vorschlag macht, der mit einem zuvor sicher fortgeführten Block kollidiert.

2. Der Leader macht einen Vorschlag. Der Leader baut einen neuen Block auf dem Zweig auf, der durch die highQC gerechtfertigt ist, und sendet ihn an alle Validatoren. Der Vorschlag enthält also auch einen Nachweis, warum das der sichere Fortsetzungsweg ist.

3. Validatoren prüfen und stimmen in der Prepare-Phase. Jeder Validator prüft, ob der Block die Sicherheitsregeln erfüllt. Wenn der Vorschlag diese erfüllt, sendet der Validator eine Prepare-Stimme an den Leader zurück.

4. Der Leader bildet Nachweise für Prepare und Pre-Commit. Nach 2f + 1 Prepare-Stimmen erstellt der Leader ein prepareQC und verteilt es für die Pre-Commit-Phase. Danach sammeln die Validatoren erneut Stimmen. Mit wieder 2f + 1 Stimmen bildet der Leader ein precommitQC.

5. Validatoren locken und committen den Vorschlag. Validatoren setzen einen Lock auf Basis des precommitQC und stimmen in der Commit-Phase ab. Der Leader bündelt anschließend 2f + 1 Commit-Stimmen zu einem commitQC. Eine nachfolgende Decide-Nachricht macht den Vorschlag ausführbar und endgültig.

Beispiel: Stell dir vor, eine Gruppe besteht aus 4 Validatoren. Ein Leader schlägt einen Block vor. Mindestens 3 Validatoren müssen in jeder erforderlichen Phase abstimmen, bevor der Leader ein QC bilden kann. Ein defekter Validator kann den Prozess also nicht dazu zwingen, einen anderen Block endgültig zu machen.

Chained HotStuff macht diese Vorgehensweise effizienter, indem Phasen verschiedener Blöcke kombiniert werden. Nach der Three-Chain-Commit-Rule wird der älteste Block in einer Reihe endgültig, wenn drei aufeinanderfolgende Blöcke gemäß den Protokollregeln über gültige QCs miteinander verbunden sind. Diese Kette liefert den Commit-Nachweis für den ältesten relevanten Block.

Wie geht HotStuff mit byzantinischen Fehlern um?

HotStuff begrenzt den Schaden durch byzantinische Fehler, indem es eine hohe Abstimmungsschwelle, signierte Stimmen, Locks und klare Regeln für View-Wechsel kombiniert. Ein byzantinischer Validator ist ein Validator, der sich unvorhersehbar oder böswillig verhält, zum Beispiel indem er lügt, nicht reagiert oder verschiedene Vorschläge an verschiedene Validatoren schickt.

Die Fehlergrenze liegt bei weniger als einem Drittel der Validatoren in einer ungewichteten Gruppe. Bei n = 3f + 1 Teilnehmern dürfen maximal f Validatoren byzantinisch sein. Ein QC erfordert 2f + 1 Stimmen, was n − f entspricht.

Die wichtige Folge ist, dass sich zwei Quorums immer überlappen. Bei 7 Validatoren sind zum Beispiel 5 Stimmen für ein QC nötig. Zwei Gruppen mit je 5 Stimmen müssen mindestens 3 Validatoren gemeinsam haben. Da höchstens 2 Validatoren byzantinisch sein dürfen, gibt es in dieser Überlappung immer mindestens einen korrekten Validator.

Ein korrekter Validator stimmt nicht zweimal für widersprüchliche Vorschläge in derselben Phase und View. Dadurch können zwei widersprüchliche QCs für dieselbe Phase und View nicht entstehen. Die Locks und die SafeNode-Regel, also die Prüfung, ob ein neuer Vorschlag sicher auf bekannten Nachweisen aufbaut, sorgen außerdem dafür, dass Validatoren später nicht einfach so auf einen widersprüchlichen Zweig wechseln.

Das schützt die Safety. Safety bedeutet hier, dass zwei widersprüchliche Blöcke nicht beide von korrekt arbeitenden Validatoren endgültig gemacht werden können. Im Zweifel wartet das Netzwerk lieber, als zwei verschiedene Historien endgültig festzuschreiben.

Liveness steht für Fortschritt: die Fähigkeit, neue Blöcke endgültig zu machen. HotStuff verspricht diesen Fortschritt nicht während einer langen Netzwerkpartition oder bei dauerhaft großen Verzögerungen. Sobald das Netzwerk wieder ausreichend stabil ist und ein korrekter Leader lange genug dieselbe View führt, können Validatoren wieder Quorums bilden und weitermachen.

Bei Proof-of-Stake-Varianten wird diese Grenze oft in Stimmgewicht statt nur in der Anzahl der Validatoren ausgedrückt. Dann zählt nicht jeder Validator gleich stark. Die Sicherheits- und Fortschrittsgarantien gelten nur, solange weniger als ein Drittel des relevanten Stimmgewichts byzantinisch ist.

Wofür wird das HotStuff-Konsensprotokoll genutzt?

HotStuff wird genutzt, um eine Gruppe von Servern oder Validatoren eine endgültige Reihenfolge von Aufträgen festlegen zu lassen. Das heißt State Machine Replication: mehrere Computer führen dieselben Aufträge in derselben Reihenfolge aus, sodass sie dasselbe Ergebnis und dasselbe gemeinsame Register behalten.

In einer Blockchain kann diese Aufgabe darin bestehen, Blöcke mit Transaktionen zu ordnen und zu finalisieren. Nachdem die Validatoren die Reihenfolge festgelegt haben, können andere Teile des Netzwerks die Transaktionen ausführen und das Ledger aktualisieren. HotStuff selbst bestimmt also vor allem die Reihenfolge und Finalität von Entscheidungen.

DiemBFT war eine auf HotStuff basierende Konsensfamilie für die historische Diem-Blockchain. Diese Protokollfamilie ordnete und finalisierte Transaktionen innerhalb einer konfigurierbaren Validatorgruppe.

Aptos nutzt AptosBFT, ein auf Jolteon basierendes BFT-Konsensprotokoll. Das Protokoll arbeitet mit stake-gewichteter Stimmkraft und kann reputation-basierte Leaderauswahl einsetzen, wobei Verhalten und Leistung von Validatoren Einfluss auf die Auswahl der Leader haben. Dabei kann sich das Stimmgewicht der Validatoren je nach Stake unterscheiden.

Flow nutzt die HotStuff-Konsensfamilie und migrierte im Januar 2023 zu Jolteon. Jolteon ist eine optimierte Variante von HotStuff. Diese Systeme nutzen also nicht unbedingt exakt die ursprüngliche HotStuff-Spezifikation so, wie sie entworfen wurde; Details wie Leaderauswahl und Verarbeitung können abweichen.

Was sind die Vorteile von HotStuff?

Ein wichtiger Vorteil von HotStuff ist, dass es die Kommunikation zwischen Validatoren effizienter organisiert als Protokolle, bei denen jeder ständig mit allen anderen Validatoren kommunizieren muss.

• Kompakte Nachweise: Der Leader bündelt Validatorstimmen mit Threshold Signatures zu einem QC. Threshold Signatures sind zusammengeführte digitale Signaturen, die beweisen, dass genügend Validatoren abgestimmt haben. Dadurch muss ein Validator nicht jedes Mal alle einzelnen Stimmen erhalten, um das Quorum zu prüfen.

• Lineare Kommunikation bei einem korrekten Leader: Im ursprünglichen Modell wächst die Kommunikations- und Authentifizierungslast pro korrektem Leader ungefähr mit der Anzahl der Validatoren, statt deutlich schneller. Das sagt nicht automatisch, wie viele Transaktionen eine vollständige Blockchain verarbeiten kann, weil Ausführung, Speicherung, Hardware und Verbreitung von Transaktionen ebenfalls limitierend sein können.

• Effizientere Leaderwechsel: HotStuff ist so entworfen, dass auch bei einem Leader Failure weniger Kommunikation nötig ist als bei PBFT. Das ist wichtig, wenn ein Leader ausfällt oder keinen brauchbaren Vorschlag verbreitet.

• Pipelining in Chained HotStuff: Neue Vorschläge können dazu beitragen, frühere Blöcke zu finalisieren. Dadurch muss das Netzwerk nicht jede Phase komplett getrennt abschließen, bevor es mit dem nächsten Vorschlag beginnt.

• Deterministische Finalität: Ein gecommiteter Block ist innerhalb der Sicherheitsannahmen endgültig. Deterministische Finalität bedeutet, dass korrekt arbeitende Validatoren später nicht auch noch einen widersprüchlichen Block als endgültig akzeptieren können.

HotStuff hat außerdem optimistic responsiveness. Nachdem das Netzwerk stabil geworden ist, muss ein korrekter Leader nicht immer auf eine vorab gesetzte maximale Netzwerkverzögerung warten, wenn die nötigen Nachrichten schon früher angekommen sind. Das kann den Fortschritt unter günstigen Netzwerkbedingungen verbessern.

Was sind die Einschränkungen von HotStuff?

HotStuff bietet keinen unbegrenzten Schutz oder garantierten Fortschritt unter allen Bedingungen. Die Funktionsweise hängt von klaren Annahmen über Validatoren, Netzwerkommunikation und die gewählte Implementierung ab.

• Grenzen der Fehlertoleranz: Die formale Sicherheitsanalyse gilt, wenn weniger als ein Drittel der Validatoren oder des Stimmgewichts byzantinisch ist. Bei einem größeren unzuverlässigen Anteil liegen die Sicherheits- und Fortschrittsgarantien außerhalb des Modells.

• Kein Fortschritt bei einer dauerhaften Partition: Safety bleibt bei unbegrenzten Netzwerkverzögerungen erhalten, aber HotStuff macht nicht garantiert neue Blöcke endgültig, solange das Netzwerk langfristig geteilt oder instabil bleibt.

• Abhängigkeit vom Leader: Ein schlechter, abgestürzter oder unerreichbarer Leader kann eine View scheitern lassen. Pacemaker und Leaderrotation helfen dem Netzwerk letztlich, sich zu erholen, sobald die Synchronieannahme wieder gilt, verursachen aber zunächst zusätzliche Verzögerung.

• Feste Validatorgruppe als Ausgangspunkt: Das ursprüngliche Protokoll geht von einer bekannten, authentifizierten Validatorgruppe und Threshold Signatures aus. HotStuff legt nicht selbst fest, wie ein offenes Netzwerk Validatoren auswählt, Stake verteilt oder wirtschaftliches Fehlverhalten bestraft.

• Mehrere Phasen bis zur Finalität: Basic HotStuff benötigt drei Abstimmungsphasen, bevor ein Vorschlag endgültig ist. Chained HotStuff erhöht den Durchsatz durch Pipelining, aber die Zeit bis zur Finalität der ersten Blöcke und das Verhalten bei Leaderwechseln bleiben von Netzwerkverzögerungen, Time-outs und der Implementierung abhängig.

Der Leader reduziert also die Menge an gegenseitiger Kommunikation, wird aber auch zu einem wichtigen temporären Koordinationspunkt. Dieser Leader muss Quorumstimmen rechtzeitig einsammeln und neue Nachweise verteilen.

Wie steht HotStuff im Vergleich zu anderen Konsensprotokollen?

HotStuff gehört zur Familie leader-basierter BFT-Protokolle, unterscheidet sich aber darin, wie Abstimmungen, Quorums und Leaderwechsel organisiert werden. Eine direkte Rangfolge gibt es nicht: Protokolle treffen unterschiedliche Entscheidungen zu Validatorgruppen, Netzwerkbedingungen und Finalität.

Im Vergleich zu PBFT ist HotStuff dafür entworfen, die Kommunikation während normalem Fortschritt und bei einem View-Wechsel zu reduzieren. In der ursprünglichen Gegenüberstellung wächst die Authenticator-Komplexität von HotStuff bei einem korrekten Leader und bei einem Leader Failure linear mit der Anzahl der Validatoren. Bei PBFT wächst diese Last in derselben Gegenüberstellung schneller. Authenticator-Komplexität bezieht sich konkret auf die Menge an zu verarbeitender Authentifizierungsinformation innerhalb des Protokolls, nicht direkt auf Transaktionen pro Sekunde oder Nutzerlatenz.

Tendermint und Casper teilen mit HotStuff den BFT-Ansatz mit temporären Leadern, Quorums und Finalität. In der ursprünglichen Gegenüberstellung haben die damaligen Tendermint- und Casper-Varianten eine höhere Kommunikationslast. Technische Optimierungen, wie Threshold Signatures, können diese Kosten in konkreten Implementierungen verändern.

HotStuff unterscheidet sich klar von der Nakamoto-Konsensklasse, wie bei Bitcoin. HotStuff arbeitet mit einer bekannten Validatorgruppe und kann gecommitete Entscheidungen innerhalb der Fehlergrenze deterministisch finalisieren. Bitcoin nutzt ein permissionless Proof-of-Work-Modell, in dem Teilnehmer frei mitmachen können und Finalität probabilistisch ist. Das bedeutet, dass die Wahrscheinlichkeit einer Rückabwicklung kleiner wird, je mehr Blöcke folgen, statt dass ein Zeitpunkt absolute Finalität innerhalb der Protokollregeln liefert.

Im Vergleich zu vollständig asynchronen BFT-Protokollen setzt HotStuff auf partielle Synchronie. Das Protokoll kann dadurch nach Stabilisierung des Netzwerks responsiv Fortschritt machen, verspricht aber keine Liveness während einer dauerhaften Netzwerkpartition.

Spätere Varianten bauen auf den Ideen von HotStuff auf. DiemBFTv4 passt den Ansatz mit einem Two-Step Steady-State Commit an, während Flow Jolteon als optimierte HotStuff-Variante nutzt. Solche Ableitungen können andere Eigenschaften haben als das ursprüngliche Protokoll.

Fazit

HotStuff ist ein BFT-Konsensprotokoll, das einer festen Validatorgruppe hilft, sicher eine Reihenfolge von Transaktionen oder Aufträgen festzulegen. Der temporäre Leader sammelt Stimmen, während Quorum Certificates nachweisen, dass genügend Validatoren denselben Vorschlag geprüft und unterstützt haben.

Die Kombination aus hohen Abstimmungsschwellen, digitalen Signaturen, Locks und View-Wechseln verhindert, dass eine kleine Gruppe byzantinischer Validatoren zwei widersprüchliche Blöcke endgültig machen kann. HotStuff bleibt dabei auch bei großen Netzwerkverzögerungen sicher, kann Fortschritt aber erst dann garantiert machen, wenn das Netzwerk wieder stabil genug ist und ein korrekter Leader aktiv bleibt.

Die effiziente Bündelung von Stimmen und die Möglichkeit zum Pipelining machen HotStuff zu einer wichtigen Grundlage für moderne BFT-Varianten. Gleichzeitig bleibt es wichtig zu verstehen, dass HotStuff kein vollständig offenes Konsensmodell oder wirtschaftliches System ist: Auswahl von Validatoren, Stake und Anreize werden von der Blockchain oder der Implementierung darum herum geregelt.