Wat is het HotStuff-consensusprotocol en hoe werkt het?

Wat is het HotStuff-consensusprotocol?

HotStuff is een BFT-consensusprotocol waarmee een vaste groep validators het eens kan worden over één definitieve volgorde van transacties of andere opdrachten, zelfs als een deel van die groep fouten maakt of bewust misleidende berichten verstuurt.

BFT staat voor Byzantine Fault Tolerance. Dit betekent dat het protocol bestand is tegen validators die uitvallen, niet reageren, liegen of verschillende berichten naar verschillende deelnemers sturen. HotStuff zorgt ervoor dat de correct werkende validators toch dezelfde versie van de blockchain of gedeelde administratie volgen.

HotStuff werkt met een bekende validatorgroep. Het protocol bepaalt dus niet zelf wie validator mag worden, hoe staking is ingericht of hoe een open crypto-netwerk deelnemers selecteert. Zulke regels liggen buiten HotStuff. Het protocol richt zich op de vraag: hoe bereikt deze validatorgroep veilig overeenstemming?

Het oorspronkelijke model gaat uit van een validatorgroep met n = 3f + 1 deelnemers. Hierbij is n het totale aantal validators en is f het maximale aantal validators dat zich fout of kwaadwillend mag gedragen. Simpel gezegd: zolang minder dan een derde van de validators onbetrouwbaar is, blijft het systeem goed werken. Bij 4 validators mag er maximaal 1 onbetrouwbaar zijn. De andere 3 validators kunnen dan nog steeds samen een veilig besluit nemen. Bij 7 validators mogen maximaal 2 validators onbetrouwbaar zijn. Voor een geldig besluit moeten minimaal 5 validators het met elkaar eens zijn. HotStuff gebruikt hiervoor een quorum certificate, vaak afgekort als QC. Een QC is een compact cryptografisch bewijs dat genoeg validators voor hetzelfde voorstel hebben gestemd. Een quorum is de minimale hoeveelheid ondersteuning die nodig is om een besluit te nemen. In het oorspronkelijke model bestaat dat quorum uit n − f, oftewel 2f + 1, stemmen.

Bij 4 validators zijn dat 3 stemmen. Bij 7 validators zijn dat 5 stemmen. Deze hoge grens voorkomt dat een kleine groep onbetrouwbare validators zelfstandig een conflicterend blok kan laten goedkeuren.

HotStuff is ontworpen voor een partieel synchroon netwerk. Dat betekent dat berichten tijdelijk sterk vertraagd mogen zijn, maar dat het netwerk uiteindelijk weer stabiel genoeg moet worden om berichten op tijd te bezorgen. De veiligheid blijft behouden, ook tijdens grote vertragingen. Voortgang, zoals het finaliseren van nieuwe blokken, is pas gegarandeerd wanneer het netwerk voldoende stabiel is.

Korte samenvatting

• HotStuff is een BFT-consensusprotocol voor een vaste groep validators.
• Validators leggen samen één volgorde van transacties of opdrachten vast.
• Een quorum certificate bewijst cryptografisch dat voldoende validators hetzelfde voorstel ondersteunen.
• Het oorspronkelijke model verdraagt minder dan een derde Byzantijnse validators.
• HotStuff behoudt veiligheid bij netwerkvertragingen, maar heeft een stabiel netwerk nodig voor voortgang.

Hoe werkt het HotStuff-consensusprotocol?

HotStuff werkt in opeenvolgende rondes waarin één tijdelijke leader een voorstel coördineert en de validators daarover stemmen. Zo'n ronde heet een view. De leader is geen permanente block producer, maar heeft alleen tijdens die specifieke view een coördinerende rol.

In de oorspronkelijke Basic HotStuff-variant zijn drie stemfasen nodig voordat een besluit definitief wordt: prepare, pre-commit en commit. Iedere fase geeft de validators extra zekerheid dat er geen conflicterend voorstel kan worden afgerond.

Een latere praktische vorm, Chained HotStuff, laat deze fasen overlappen over opeenvolgende blokken. Daardoor kan een nieuw blok tegelijk bewijs leveren voor de voortgang van eerdere blokken. De basisregels rond stemmen, quorums en veiligheid blijven daarbij hetzelfde.

Welke rol spelen validators en de leader?

Validators controleren of het voorstel van de leader veilig is voordat zij stemmen. Zij kijken onder meer of het voorstel voortbouwt op de juiste eerdere blokken en past binnen de veiligheidsregels van het protocol. Is dat het geval, dan sturen zij een digitaal ondertekende stem naar de leader.

De leader verzamelt de stemmen. Zodra de leader genoeg stemmen heeft, bundelt hij deze tot één QC. In plaats van alle losse stemmen steeds door te sturen, kan de leader dus één compact bewijs verspreiden dat laat zien dat een quorum heeft ingestemd.

Validators gebruiken ook een lock, oftewel een vergrendeling. Een lock is een regel die voorkomt dat een validator later zomaar een conflicterende tak ondersteunt. Een validator stemt normaal gesproken alleen voor een voorstel dat zijn vergrendelde tak uitbreidt. Een uitzondering is mogelijk wanneer een QC uit een hogere view volgens de veiligheidsregels aantoont dat een vervolg veilig is.

Wanneer een view geen voortgang maakt, bijvoorbeeld omdat de leader offline is, schakelen validators over naar een nieuwe view. Zij sturen dan een new-view-bericht naar de volgende leader. Daarin staat hun hoogste bekende prepareQC, dus het sterkste bewijs dat zij op dat moment kennen.

De nieuwe leader kiest de hoogste ontvangen QC als highQC. Dit is het uitgangspunt voor een veilig nieuw voorstel. Een vooraf bekende rotatie kan bepalen wie de volgende leader is. Een pacemaker, een mechanisme met time-outs, zorgt ervoor dat validators niet onbeperkt op een niet-functionerende leader blijven wachten.

Hoe verloopt het consensusproces?

In Basic HotStuff verloopt de besluitvorming stap voor stap via drie stemfasen. De volgende beschrijving laat zien hoe één voorstel van begin tot definitief besluit gaat.

1. De nieuwe leader verzamelt informatie. Bij een view-wissel ontvangt de nieuwe leader new-view-berichten van een quorum validators. De leader kiest de hoogste QC die daarin staat. Dit voorkomt dat de leader een voorstel doet dat botst met een eerder veilig voortgezet blok.

2. De leader doet een voorstel. De leader bouwt een nieuw blok voort op de tak die door de highQC wordt gerechtvaardigd en verstuurt dit naar alle validators. Het voorstel bevat dus ook bewijs waarom dit de veilige vervolgroute is.

3. Validators controleren en stemmen in de prepare-fase. Iedere validator controleert of het blok aan de veiligheidsregels voldoet. Voldoet het voorstel daaraan, dan stuurt de validator een prepare-stem terug naar de leader.

4. De leader vormt bewijzen voor prepare en pre-commit. Na 2f + 1 prepare-stemmen maakt de leader een prepareQC en verspreidt die voor de pre-commit-fase. Daarna verzamelen de validators opnieuw stemmen. Met weer 2f + 1 stemmen vormt de leader een precommitQC.

5. Validators vergrendelen en committen het voorstel. Validators leggen een lock vast op basis van de precommitQC en stemmen in de commit-fase. De leader bundelt vervolgens 2f + 1 commit-stemmen tot een commitQC. Een daaropvolgend decide-bericht maakt het voorstel uitvoerbaar en definitief.

Voorbeeld: Stel dat een groep uit 4 validators bestaat. Een leader stelt een blok voor. Minstens 3 validators moeten in iedere vereiste fase stemmen voordat de leader een QC kan vormen. Eén defecte validator kan het proces dus niet dwingen om een ander blok definitief te maken.

Chained HotStuff maakt deze werkwijze efficiënter door fasen van verschillende blokken te combineren. Volgens de three-chain commit rule wordt het oudste blok in een reeks definitief wanneer drie opeenvolgende blokken volgens de protocolregels via geldige QCs met elkaar zijn verbonden. Die keten levert het commit-bewijs voor het oudste relevante blok.

Hoe gaat HotStuff om met Byzantine fouten?

HotStuff beperkt de schade van Byzantine fouten door een hoge stemdrempel, ondertekende stemmen, locks en duidelijke regels voor view-wissels te combineren. Een Byzantijnse validator is een validator die zich onvoorspelbaar of kwaadwillend gedraagt, bijvoorbeeld door te liegen, niet te reageren of verschillende voorstellen naar verschillende validators te sturen.

De foutgrens is minder dan een derde van de validators in een ongewogen groep. Bij n = 3f + 1 deelnemers mogen maximaal f validators Byzantijns zijn. Een QC vereist 2f + 1 stemmen, wat gelijk is aan n − f.

Het belangrijke gevolg is dat twee quorums altijd overlap hebben. Bij 7 validators zijn bijvoorbeeld 5 stemmen nodig voor een QC. Twee groepen van 5 stemmen moeten minimaal 3 validators gemeen hebben. Omdat hoogstens 2 validators Byzantijns mogen zijn, zit er in die overlap altijd minstens één correcte validator.

Een correcte validator stemt niet tweemaal voor conflicterende voorstellen in dezelfde fase en view. Daardoor kunnen twee conflicterende QC's voor dezelfde fase en view niet ontstaan. De locks en de safeNode-regel, de controle of een nieuw voorstel veilig voortbouwt op bekende bewijzen, zorgen er bovendien voor dat validators niet later zomaar naar een conflicterende tak overstappen.

Dit beschermt safety. Safety betekent hier dat twee conflicterende blokken niet allebei definitief kunnen worden gemaakt door correct werkende validators. Het netwerk kiest bij onzekerheid liever voor wachten dan voor het definitief maken van twee verschillende geschiedenissen.

Liveness gaat over voortgang: het vermogen om nieuwe blokken definitief te maken. HotStuff belooft die voortgang niet tijdens een langdurige netwerkpartitie of blijvende grote vertragingen. Zodra het netwerk weer voldoende stabiel is en een correcte leader lang genoeg dezelfde view leidt, kunnen validators weer quorums vormen en doorgaan.

Bij proof-of-stake-varianten wordt deze grens vaak uitgedrukt in stemgewicht in plaats van alleen in het aantal validators. Dan telt niet iedere validator even zwaar mee. De veiligheids- en voortgangsgaranties gelden alleen zolang minder dan een derde van het relevante stemgewicht Byzantijns is.

Waarvoor wordt het HotStuff-consensusprotocol gebruikt?

HotStuff wordt gebruikt om een groep servers of validators één definitieve volgorde van opdrachten te laten vastleggen. Dit heet state machine replication: meerdere computers voeren dezelfde opdrachten in dezelfde volgorde uit, zodat zij dezelfde uitkomst en dezelfde gedeelde administratie behouden.

In een blockchain kan die taak bestaan uit het ordenen en finaliseren van blokken met transacties. Nadat de validators de volgorde hebben vastgesteld, kunnen andere onderdelen van het netwerk de transacties uitvoeren en de ledger bijwerken. HotStuff zelf bepaalt dus vooral de volgorde en finaliteit van besluiten.

DiemBFT was een op HotStuff gebaseerde consensusfamilie voor de historische Diem-blockchain. Deze protocolfamilie ordende en finaliseerde transacties binnen een configureerbare validatorgroep.

Aptos gebruikt AptosBFT, een op Jolteon gebaseerd BFT-consensusprotocol. Het protocol werkt met stake-gewogen stemkracht en kan reputation-based leaderselectie toepassen, waarbij het gedrag en de prestaties van validators invloed hebben op de keuze van leaders. Daarbij kan het stemgewicht van validators verschillen op basis van stake.

Flow gebruikt de HotStuff-consensusfamilie en migreerde in januari 2023 naar Jolteon. Jolteon is een geoptimaliseerde variant van HotStuff. Deze systemen gebruiken dus niet noodzakelijk de oorspronkelijke HotStuff-specificatie precies zoals die is ontworpen; details zoals leaderselectie en verwerking kunnen verschillen.

Wat zijn de voordelen van HotStuff?

HotStuff heeft als belangrijk voordeel dat het de communicatie tussen validators efficiënter organiseert dan protocollen waarin iedereen voortdurend met alle andere validators moet communiceren.

• Compacte bewijzen: De leader bundelt validatorstemmen met threshold signatures tot één QC. Threshold signatures zijn samengevoegde digitale handtekeningen die bewijzen dat genoeg validators hebben gestemd. Daardoor hoeft een validator niet telkens alle losse stemmen te ontvangen om het quorum te controleren.

• Lineaire communicatie bij een correcte leader: In het oorspronkelijke model groeit de communicatie- en authenticatielast per correcte leader ongeveer mee met het aantal validators, in plaats van veel sneller. Dit zegt niet automatisch hoeveel transacties een volledige blockchain kan verwerken, omdat uitvoering, opslag, hardware en verspreiding van transacties ook beperkend kunnen zijn.

• Efficiëntere leaderwissels: HotStuff is ontworpen om ook bij een leader failure minder communicatie nodig te hebben dan PBFT. Dat is belangrijk wanneer een leader uitvalt of geen bruikbaar voorstel verspreidt.

• Pipelining in Chained HotStuff: Nieuwe voorstellen kunnen bijdragen aan het finaliseren van eerdere blokken. Hierdoor hoeft het netwerk niet iedere fase volledig los af te ronden voordat het met een volgend voorstel begint.

• Deterministische finaliteit: Een gecommit blok is binnen de veiligheidsaannames definitief. Deterministische finaliteit betekent dat correct werkende validators niet later ook een conflicterend blok als definitief kunnen accepteren.

HotStuff heeft daarnaast optimistic responsiveness. Nadat het netwerk stabiel is geworden, hoeft een correcte leader niet steeds te wachten op een vooraf ingestelde maximale netwerkvertraging als de benodigde berichten al eerder zijn ontvangen. Dat kan de voortgang in gunstige netwerkomstandigheden verbeteren.

Wat zijn de beperkingen van HotStuff?

HotStuff biedt geen onbeperkte bescherming of gegarandeerde voortgang onder alle omstandigheden. De werking hangt af van duidelijke aannames over validators, netwerkcommunicatie en de gekozen implementatie.

• Grenzen aan fouttolerantie: De formele veiligheidsanalyse geldt wanneer minder dan een derde van de validators of het stemgewicht Byzantijns is. Bij een grotere onbetrouwbare fractie vallen de veiligheids- en voortgangsgaranties buiten het model.

• Geen voortgang bij een blijvende partitie: Safety blijft behouden bij onbeperkte netwerkvertragingen, maar HotStuff maakt niet gegarandeerd nieuwe blokken definitief zolang het netwerk langdurig verdeeld of instabiel blijft.

• Afhankelijkheid van de leader: Een slechte, gecrashte of onbereikbare leader kan een view laten mislukken. De pacemaker en leaderrotatie helpen het netwerk uiteindelijk herstellen wanneer de synchronieaanname weer geldt, maar veroorzaken eerst extra vertraging.

• Vaste validatorgroep als uitgangspunt: Het oorspronkelijke protocol gaat uit van een bekende, geauthenticeerde validatorgroep en threshold signatures. HotStuff bepaalt niet zelf hoe een open netwerk validators kiest, stake verdeelt of economisch wangedrag bestraft.

• Meerdere fasen voor finaliteit: Basic HotStuff heeft drie stemfasen nodig voordat een voorstel definitief is. Chained HotStuff verhoogt de doorvoer door pipelining, maar de tijd tot finaliteit van de eerste blokken en het gedrag bij leaderwissels blijven afhankelijk van netwerkvertragingen, time-outs en de implementatie.

De leader verlaagt dus de hoeveelheid onderlinge communicatie, maar wordt ook een belangrijk tijdelijk coördinatiepunt. Die leader moet quorumstemmen tijdig verzamelen en nieuwe bewijzen verspreiden.

Hoe verhoudt HotStuff zich tot andere consensusprotocollen?

HotStuff hoort bij de familie van leader-based BFT-protocollen, maar verschilt in de manier waarop het stemmen, quorums en leaderwissels organiseert. Een directe rangorde bestaat niet: protocollen maken verschillende keuzes over validatorgroepen, netwerkvoorwaarden en finaliteit.

Vergeleken met PBFT is HotStuff ontworpen om de communicatie tijdens normale voortgang en een view-wissel te verminderen. In de oorspronkelijke vergelijking groeit de authenticatorcomplexiteit van HotStuff bij een correcte leader en bij een leader failure lineair met het aantal validators. Bij PBFT groeit die last in dezelfde vergelijking sneller. Authenticatorcomplexiteit gaat specifiek over de hoeveelheid te verwerken authenticatie-informatie binnen het protocol, niet rechtstreeks over transacties per seconde of gebruikerslatentie.

Tendermint en Casper delen met HotStuff de BFT-benadering met tijdelijke leaders, quorums en finaliteit. In de oorspronkelijke vergelijking hebben de toenmalige Tendermint- en Casper-varianten een hogere communicatielast. Technische optimalisaties, zoals threshold signatures, kunnen die kosten in specifieke implementaties veranderen.

HotStuff verschilt duidelijk van Nakamoto-consensus, zoals Bitcoin. HotStuff werkt met een bekende validatorgroep en kan gecommitte besluiten onder de foutgrens deterministisch finaliseren. Bitcoin gebruikt een permissionless proof-of-work-model waarin deelnemers vrij kunnen meedoen en finaliteit probabilistisch is. Dat betekent dat de kans op terugdraaien kleiner wordt naarmate meer blokken volgen, in plaats van dat één moment absolute finaliteit geeft binnen de protocolregels.

Vergeleken met volledig asynchrone BFT-protocollen kiest HotStuff voor partiële synchronie. Het protocol kan daardoor responsief voortgang maken nadat het netwerk stabiliseert, maar belooft geen liveness tijdens een blijvende netwerkpartitie.

Latere varianten bouwen voort op de ideeën van HotStuff. DiemBFTv4 past de aanpak aan met een steady-state commit in twee stappen, terwijl Flow Jolteon gebruikt als geoptimaliseerde HotStuff-variant. Zulke afgeleiden kunnen andere eigenschappen hebben dan het oorspronkelijke protocol.

Conclusie

HotStuff is een BFT-consensusprotocol dat een vaste validatorgroep helpt om veilig één volgorde van transacties of opdrachten vast te leggen. De tijdelijke leader verzamelt stemmen, terwijl quorum certificates aantonen dat genoeg validators hetzelfde voorstel hebben gecontroleerd en ondersteund.

De combinatie van hoge stemdrempels, digitale handtekeningen, locks en view-wissels voorkomt dat een kleine groep Byzantijnse validators twee conflicterende blokken definitief kan maken. HotStuff blijft daarbij veilig tijdens grote netwerkvertragingen, maar kan pas gegarandeerd voortgang maken wanneer het netwerk weer stabiel genoeg is en een correcte leader actief blijft.

De efficiënte bundeling van stemmen en de mogelijkheid tot pipelining maken HotStuff een belangrijke basis voor moderne BFT-varianten. Tegelijk blijft het essentieel om te begrijpen dat HotStuff geen volledig open consensusmodel of economisch systeem is: selectie van validators, stake en prikkels worden door de blockchain of implementatie daaromheen geregeld.