Cos’è il protocollo di consenso HotStuff e come funziona?

Cos’è il protocollo di consenso HotStuff?

HotStuff è un protocollo di consenso BFT che permette a un gruppo fisso di validator di mettersi d’accordo su un’unica sequenza definitiva di transazioni o altri comandi, anche se una parte del gruppo sbaglia o invia intenzionalmente messaggi fuorvianti.

BFT sta per Byzantine Fault Tolerance. Vuol dire che il protocollo regge anche se alcuni validator vanno offline, non rispondono, mentono o inviano messaggi diversi a partecipanti diversi. HotStuff fa sì che i validator che funzionano correttamente seguano comunque la stessa versione della blockchain o del registro condiviso.

HotStuff funziona con un gruppo di validator noto. Quindi il protocollo non decide da solo chi può diventare validator, come è strutturato lo staking o come un network crypto aperto seleziona i partecipanti. Queste regole stanno fuori da HotStuff. Il protocollo si concentra sulla domanda: come fa questo gruppo di validator a raggiungere un accordo in modo sicuro?

Il modello originale parte da un gruppo di validator con n = 3f + 1 partecipanti. Qui n è il numero totale di validator e f è il numero massimo di validator che possono comportarsi in modo errato o malevolo. In parole semplici: finché meno di un terzo dei validator è inaffidabile, il sistema continua a funzionare bene. Con 4 validator, al massimo 1 può essere inaffidabile. Gli altri 3 validator possono comunque prendere insieme una decisione sicura. Con 7 validator, al massimo 2 validator possono essere inaffidabili. Per una decisione valida, almeno 5 validator devono essere d’accordo. HotStuff usa per questo un quorum certificate, spesso abbreviato in QC. Un QC è una prova crittografica compatta che dimostra che abbastanza validator hanno votato per la stessa proposta. Un quorum è la quantità minima di supporto necessaria per prendere una decisione. Nel modello originale quel quorum è n − f, cioè 2f + 1, voti.

Con 4 validator sono 3 voti. Con 7 validator sono 5 voti. Questa soglia alta evita che un piccolo gruppo di validator inaffidabili possa far approvare da solo un blocco in conflitto.

HotStuff è progettato per una rete parzialmente sincrona. Significa che i messaggi possono subire forti ritardi temporanei, ma che la rete deve poi tornare abbastanza stabile da consegnare i messaggi in tempo. La sicurezza resta valida anche durante ritardi importanti. L’avanzamento, come la finalizzazione di nuovi blocchi, è garantito solo quando la rete è sufficientemente stabile.

In breve

• HotStuff è un protocollo di consenso BFT per un gruppo fisso di validator.
• I validator fissano insieme un’unica sequenza di transazioni o comandi.
• Un quorum certificate dimostra in modo crittografico che abbastanza validator supportano la stessa proposta.
• Il modello originale tollera meno di un terzo di validator bizantini.
• HotStuff mantiene la sicurezza con ritardi di rete, ma ha bisogno di una rete stabile per avanzare.

Come funziona il protocollo di consenso HotStuff?

HotStuff funziona in round consecutivi in cui un leader temporaneo coordina una proposta e i validator votano su di essa. Un round del genere si chiama view. Il leader non è un block producer permanente, ma ha solo un ruolo di coordinamento durante quella specifica view.

Nella variante originale Basic HotStuff servono tre fasi di voto prima che una decisione diventi definitiva: prepare, pre-commit e commit. Ogni fase dà ai validator più certezza che non si possa completare una proposta in conflitto.

Una forma pratica successiva, Chained HotStuff, fa sovrapporre queste fasi su blocchi consecutivi. Così un nuovo blocco può allo stesso tempo fornire prova dell’avanzamento dei blocchi precedenti. Le regole di base su voti, quorum e sicurezza restano comunque le stesse.

Che ruolo hanno i validator e il leader?

I validator controllano se la proposta del leader è sicura prima di votare. Guardano, tra le altre cose, se la proposta costruisce sui blocchi precedenti corretti e se rientra nelle regole di sicurezza del protocollo. Se va tutto bene, inviano al leader un voto firmato digitalmente.

Il leader raccoglie i voti. Appena ne ha abbastanza, li raggruppa in un unico QC. Invece di inoltrare ogni volta tutti i voti separati, il leader può quindi diffondere una prova compatta che mostra che un quorum ha approvato.

I validator usano anche un lock, cioè un “blocco”. Un lock è una regola che impedisce a un validator di supportare più avanti, così a caso, un ramo in conflitto. Di norma un validator vota solo per una proposta che estende il ramo su cui è bloccato. Un’eccezione è possibile quando un QC di una view più alta dimostra, secondo le regole di sicurezza, che un seguito è sicuro.

Quando una view non fa progressi, per esempio perché il leader è offline, i validator passano a una nuova view. In quel caso inviano un messaggio new-view al leader successivo. Dentro c’è il loro prepareQC più alto conosciuto, cioè la prova più forte che hanno in quel momento.

Il nuovo leader sceglie il QC più alto ricevuto come highQC. Questo è il punto di partenza per una nuova proposta sicura. Una rotazione nota in anticipo può stabilire chi è il prossimo leader. Un pacemaker, un meccanismo con time-out, fa sì che i validator non aspettino all’infinito un leader che non funziona.

Come si svolge il processo di consenso?

In Basic HotStuff la decisione avviene passo dopo passo attraverso tre fasi di voto. La descrizione seguente mostra come una proposta va dall’inizio fino alla decisione definitiva.

1. Il nuovo leader raccoglie informazioni. Con un cambio view, il nuovo leader riceve messaggi new-view da un quorum di validator. Il leader sceglie il QC più alto presente lì dentro. Questo evita che il leader faccia una proposta che va in conflitto con un blocco già proseguibile in modo sicuro.

2. Il leader fa una proposta. Il leader costruisce un nuovo blocco sul ramo giustificato dall’highQC e lo invia a tutti i validator. Quindi la proposta contiene anche la prova del perché questa è la strada di continuazione sicura.

3. I validator controllano e votano nella fase prepare. Ogni validator controlla se il blocco rispetta le regole di sicurezza. Se la proposta le rispetta, il validator invia un voto prepare al leader.

4. Il leader crea prove per prepare e pre-commit. Dopo 2f + 1 voti prepare, il leader crea un prepareQC e lo diffonde per la fase pre-commit. Poi i validator raccolgono di nuovo i voti. Con altri 2f + 1 voti il leader crea un precommitQC.

5. I validator bloccano e fanno commit della proposta. I validator impostano un lock sulla base del precommitQC e votano nella fase commit. Il leader poi raggruppa 2f + 1 voti commit in un commitQC. Un successivo messaggio decide rende la proposta eseguibile e definitiva.

Esempio: mettiamo che un gruppo sia composto da 4 validator. Un leader propone un blocco. Almeno 3 validator devono votare in ogni fase richiesta prima che il leader possa formare un QC. Quindi un validator difettoso non può costringere il processo a rendere definitivo un altro blocco.

Chained HotStuff rende questo modo di lavorare più efficiente combinando le fasi di blocchi diversi. Secondo la three-chain commit rule, il blocco più vecchio in una serie diventa definitivo quando tre blocchi consecutivi sono collegati tra loro secondo le regole del protocollo tramite QCs validi. Quella catena fornisce la prova di commit per il blocco rilevante più vecchio.

Come gestisce HotStuff gli errori bizantini?

HotStuff limita i danni degli errori bizantini combinando una soglia di voto alta, voti firmati, lock e regole chiare per i cambi view. Un validator bizantino è un validator che si comporta in modo imprevedibile o malevolo, per esempio mentendo, non rispondendo o inviando proposte diverse a validator diversi.

Il limite di guasto è meno di un terzo dei validator in un gruppo non pesato. Con n = 3f + 1 partecipanti, al massimo f validator possono essere bizantini. Un QC richiede 2f + 1 voti, che è uguale a n − f.

La conseguenza importante è che due quorum si sovrappongono sempre. Con 7 validator, per esempio, servono 5 voti per un QC. Due gruppi da 5 voti devono avere almeno 3 validator in comune. Siccome al massimo 2 validator possono essere bizantini, in quella sovrapposizione c’è sempre almeno un validator corretto.

Un validator corretto non vota due volte per proposte in conflitto nella stessa fase e view. Quindi non possono esistere due QC in conflitto per la stessa fase e view. Inoltre i lock e la regola safeNode, cioè il controllo che una nuova proposta costruisca in modo sicuro su prove conosciute, fanno sì che i validator non passino più avanti, così a caso, a un ramo in conflitto.

Questo protegge la safety. Qui safety significa che due blocchi in conflitto non possono diventare entrambi definitivi tramite validator che funzionano correttamente. Quando c’è incertezza, la rete preferisce aspettare piuttosto che rendere definitive due storie diverse.

La liveness riguarda l’avanzamento: la capacità di rendere definitivi nuovi blocchi. HotStuff non promette questo avanzamento durante una partizione di rete prolungata o ritardi grandi permanenti. Appena la rete torna abbastanza stabile e un leader corretto guida la stessa view per abbastanza tempo, i validator possono di nuovo formare quorum e andare avanti.

Nelle varianti proof-of-stake questo limite viene spesso espresso in peso di voto invece che solo nel numero di validator. In quel caso non tutti i validator contano allo stesso modo. Le garanzie di sicurezza e avanzamento valgono solo finché meno di un terzo del peso di voto rilevante è bizantino.

Per cosa viene usato il protocollo di consenso HotStuff?

HotStuff viene usato per far sì che un gruppo di server o validator fissi un’unica sequenza definitiva di comandi. Questo si chiama state machine replication: più computer eseguono gli stessi comandi nello stesso ordine, così mantengono lo stesso risultato e lo stesso registro condiviso.

In una blockchain quel compito può essere ordinare e finalizzare blocchi con transazioni. Dopo che i validator hanno fissato l’ordine, altre parti della rete possono eseguire le transazioni e aggiornare la ledger. Quindi HotStuff decide soprattutto l’ordine e la finalità delle decisioni.

DiemBFT era una famiglia di consenso basata su HotStuff per la storica blockchain Diem. Questa famiglia di protocolli ordinava e finalizzava transazioni dentro un gruppo di validator configurabile.

Aptos usa AptosBFT, un protocollo di consenso BFT basato su Jolteon. Il protocollo funziona con potere di voto pesato per stake e può applicare una selezione dei leader basata sulla reputazione, dove il comportamento e le prestazioni dei validator influenzano la scelta dei leader. In questo contesto il peso di voto dei validator può variare in base allo stake.

Flow usa la famiglia di consenso HotStuff ed è migrato a Jolteon a gennaio 2023. Jolteon è una variante ottimizzata di HotStuff. Quindi questi sistemi non usano necessariamente la specifica originale di HotStuff esattamente così com’è stata progettata; dettagli come la selezione dei leader e l’elaborazione possono cambiare.

Quali sono i vantaggi di HotStuff?

HotStuff ha un vantaggio importante: organizza in modo più efficiente la comunicazione tra validator rispetto ai protocolli in cui tutti devono comunicare continuamente con tutti gli altri validator.

• Prove compatte: il leader raggruppa i voti dei validator con threshold signatures in un unico QC. Le threshold signatures sono firme digitali aggregate che dimostrano che abbastanza validator hanno votato. Così un validator non deve ricevere ogni volta tutti i voti separati per controllare il quorum.

• Comunicazione lineare con un leader corretto: nel modello originale, il carico di comunicazione e autenticazione per un leader corretto cresce più o meno insieme al numero di validator, invece di crescere molto più in fretta. Questo non dice automaticamente quante transazioni può gestire un’intera blockchain, perché anche esecuzione, storage, hardware e propagazione delle transazioni possono essere colli di bottiglia.

• Cambi leader più efficienti: HotStuff è progettato per richiedere meno comunicazione rispetto a PBFT anche quando c’è un leader failure. Questo è importante quando un leader cade o non diffonde una proposta utilizzabile.

• Pipelining in Chained HotStuff: nuove proposte possono contribuire a finalizzare blocchi precedenti. Così la rete non deve chiudere ogni fase completamente “a parte” prima di iniziare con una proposta successiva.

• Finalità deterministica: un blocco in commit è definitivo dentro le assunzioni di sicurezza. Finalità deterministica vuol dire che i validator corretti non possono poi accettare come definitivo anche un blocco in conflitto.

HotStuff ha anche optimistic responsiveness. Dopo che la rete è diventata stabile, un leader corretto non deve per forza aspettare sempre un ritardo massimo di rete fissato in anticipo se i messaggi necessari sono già arrivati prima. Questo può migliorare l’avanzamento quando le condizioni di rete sono favorevoli.

Quali sono i limiti di HotStuff?

HotStuff non offre protezione illimitata o avanzamento garantito in ogni condizione. Il suo funzionamento dipende da assunzioni chiare su validator, comunicazione di rete e implementazione scelta.

• Limiti alla tolleranza ai guasti: l’analisi formale di sicurezza vale quando meno di un terzo dei validator o del peso di voto è bizantino. Con una frazione inaffidabile più grande, le garanzie di sicurezza e avanzamento escono dal modello.

• Nessun avanzamento con una partizione permanente: la safety resta valida con ritardi di rete illimitati, ma HotStuff non rende garantitamente definitivi nuovi blocchi finché la rete resta a lungo divisa o instabile.

• Dipendenza dal leader: un leader scarso, crashato o irraggiungibile può far fallire una view. Il pacemaker e la rotazione dei leader aiutano la rete a riprendersi alla fine quando torna valida l’assunzione di sincronia, ma prima causano ritardi extra.

• Gruppo fisso di validator come punto di partenza: il protocollo originale parte da un gruppo di validator noto e autenticato e dalle threshold signatures. HotStuff non decide da solo come una rete aperta sceglie i validator, distribuisce lo stake o punisce il comportamento scorretto a livello economico.

• Più fasi per la finalità: Basic HotStuff ha bisogno di tre fasi di voto prima che una proposta sia definitiva. Chained HotStuff aumenta la capacità grazie al pipelining, ma il tempo alla finalità dei primi blocchi e il comportamento durante i cambi leader restano dipendenti da ritardi di rete, time-out e implementazione.

Quindi il leader riduce la quantità di comunicazione reciproca, ma diventa anche un importante punto di coordinamento temporaneo. Quel leader deve raccogliere in tempo i voti di quorum e diffondere nuove prove.

Come si confronta HotStuff con altri protocolli di consenso?

HotStuff fa parte della famiglia dei protocolli BFT leader-based, ma si differenzia per come organizza voti, quorum e cambi leader. Non esiste una classifica diretta: i protocolli fanno scelte diverse su gruppi di validator, condizioni di rete e finalità.

Rispetto a PBFT, HotStuff è progettato per ridurre la comunicazione durante l’avanzamento normale e durante un cambio view. Nel confronto originale, la complessità degli autenticatori di HotStuff con un leader corretto e in caso di leader failure cresce in modo lineare con il numero di validator. In PBFT, nello stesso confronto, quel carico cresce più velocemente. Per complessità degli autenticatori si intende nello specifico la quantità di informazioni di autenticazione da elaborare dentro il protocollo, non direttamente transazioni al secondo o latenza per l’utente.

Tendermint e Casper condividono con HotStuff l’approccio BFT con leader temporanei, quorum e finalità. Nel confronto originale, le varianti di Tendermint e Casper di allora hanno un carico di comunicazione più alto. Ottimizzazioni tecniche, come le threshold signatures, possono cambiare quei costi in implementazioni specifiche.

HotStuff è chiaramente diverso dalla consensus di Nakamoto, come Bitcoin. HotStuff lavora con un gruppo di validator noto e può finalizzare in modo deterministico decisioni in commit sotto la soglia di guasto. Bitcoin usa un modello permissionless proof-of-work in cui chiunque può partecipare e la finalità è probabilistica. Significa che la probabilità di un rollback diminuisce man mano che arrivano più blocchi, invece di avere un momento che dà finalità assoluta dentro le regole del protocollo.

Rispetto ai protocolli BFT completamente asincroni, HotStuff sceglie la sincronia parziale. Così il protocollo può avanzare in modo reattivo dopo che la rete si stabilizza, ma non promette liveness durante una partizione di rete permanente.

Varianti successive si basano sulle idee di HotStuff. DiemBFTv4 adatta l’approccio con uno steady-state commit in due passaggi, mentre Flow usa Jolteon come variante HotStuff ottimizzata. Questi derivati possono avere proprietà diverse rispetto al protocollo originale.

In conclusione

HotStuff è un protocollo di consenso BFT che aiuta un gruppo fisso di validator a fissare in modo sicuro un’unica sequenza di transazioni o comandi. Il leader temporaneo raccoglie i voti, mentre i quorum certificate dimostrano che abbastanza validator hanno controllato e supportato la stessa proposta.

La combinazione di soglie di voto alte, firme digitali, lock e cambi view impedisce che un piccolo gruppo di validator bizantini possa rendere definitivi due blocchi in conflitto. HotStuff resta sicuro anche durante forti ritardi di rete, ma può garantire l’avanzamento solo quando la rete torna abbastanza stabile e un leader corretto resta attivo.

L’aggregazione efficiente dei voti e la possibilità di pipelining rendono HotStuff una base importante per varianti BFT moderne. Allo stesso tempo, è fondamentale capire che HotStuff non è un modello di consenso completamente aperto o un sistema economico: selezione dei validator, stake e incentivi vengono gestiti dalla blockchain o dall’implementazione attorno ad essa.