Riassumendo la scoperta di MonadBFT Ieri Category Labs ha pubblicato il documento MonadBFT, che descrive il meccanismo di consenso che alimenterà Monad sulla mainnet. MonadBFT è uno sviluppo significativo nella ricerca di consenso poiché è la prima volta che Pipelined HotStuff diventa resistente al tail-forking. Il tail-forking si verifica quando uno slot mancato causa l'eliminazione e il riminaggio della proposta precedente. Si tratta di un grave problema nelle precedenti formulazioni di Pipelined HotStuff poiché apre ad attacchi MEV multi-blocco che destabilizzano il consenso. Alleviare questo problema è un grosso problema perché ci offre tutti i vantaggi di Pipelined HotStuff - blocchi frequenti, bassa latenza, grandi set di validatori - evitando il più grande svantaggio. MonadBFT offre anche un enorme aggiornamento per la finalità. È dotato di finalizzazione speculativa a slot singolo (500 ms) e finalità rigida a due slot (1s). "Finalità speculativa" significa "finalità che tornerà indietro solo in caso di equivoco (doppia firma) da parte della maggioranza dei validatori". L'equivoco è un reato grave nella maggior parte dei sistemi blockchain ed è comunemente penalizzato con lo slashing; Più grande è la penalità per l'equivoco, più si può pensare alla "finalità speculativa" alla finalità. La finalità speculativa a uno slot è un enorme sblocco per le applicazioni ad alte prestazioni, che possono visualizzare con sicurezza lo stato aggiornato del mondo subito dopo la ricezione del blocco successivo. Queste proprietà rendono MonadBFT un enorme progresso nel consenso e un degno complemento ad altri miglioramenti di composizione in Monad, tra cui l'esecuzione asincrona, l'esecuzione parallela ottimistica e MonadDb. Il resto di questo articolo serve come riassunto di come i successivi miglioramenti in HotStuff si siano costruiti l'uno sull'altro, al fine di spiegare il problema che MonadBFT risolve. Per riassumere: 1. HotStuff ci offre una complessità di comunicazione lineare in modo da poter avere grandi set di validatori, ma non è molto efficiente 2. Pipelined HotStuff ci offre efficienza e bassa latenza dalla proposta di blocchi ad ogni slot, ma soffre del problema delle forchette di coda 3. MonadBFT ci dà la resistenza del forchetta di coda e la finalità speculativa a uno slot --- HotStuff: la complessità della comunicazione lineare consente un numero elevato di nodi Gli algoritmi di HotStuff si completano nel corso di diversi cicli di comunicazione, che generalmente assumono la forma di una comunicazione "fan out, fan in" direttamente dai leader ai validatori e ai leader. Ogni round inizia con l'invio di un messaggio da parte del leader direttamente agli altri validatori, che inviano ciascuno un messaggio firmato attestante di aver ricevuto il messaggio. A condizione che una maggioranza qualificata (2/3) dei validatori invii un'attestazione, ogni round termina con il leader che aggrega le attestazioni firmate in un Quorum Certificate (QC), che funge da prova che la maggioranza qualificata ha attestato il messaggio precedente. Gli algoritmi di HotStuff hanno più cicli di comunicazione come questo. - Il primo messaggio del leader è una proposta in blocco - Il secondo messaggio è il QC per quella proposta di blocco - Il terzo messaggio è un controllo di qualità relativo al controllo di qualità precedente (ad esempio, un controllo qualità su controllo qualità) -E così via Se la procedura viene interrotta in qualsiasi momento prima della finalizzazione, il blocco non viene finalizzato e viene scartato; Le transazioni da quel blocco dovranno essere reincluse nel blocco successivo. Il protocollo HotStuff originale non ha pipelining e ha 3 cicli di comunicazione prima della finalizzazione; Lo stesso validatore svolge il ruolo di leader per ogni round. --- HotStuff pipelined: un nuovo blocco ad ogni slot aumenta l'efficienza Il pipelining è ciò che tutti noi facciamo in modo intuitivo quando abbiamo due carichi di biancheria da completare. Invece di aspettare che il carico 1 finisca il ciclo completo prima di avviare il carico 2, nel pipelining mettiamo il carico 1 nell'asciugatrice nello stesso momento in cui il carico 2 va nella lavatrice. Puoi pensare all'HotStuff originale come a quell'approccio ingenuo al fare il bucato (non iniziare con il carico 2 fino a quando il carico 1 non è completamente terminato), mentre HotStuff in pipeline sta eseguendo il comportamento intuitivo di far avanzare più carichi di biancheria in modo scaglionato. In Pipelined HotStuff scaglioniamo le proposte, in modo tale che ci sia un nuovo blocco proposto ad ogni round, con il nuovo blocco che si appoggia al messaggio che trasporta il QC dal blocco precedente. Le proposte di blocco marciano verso la finalizzazione nel corso di più round. I vantaggi del pipelining sono significativi. Il pipelining aumenta la densità delle proposte di blocco, poiché viene fatta una proposta di blocco in ogni slot, il che aumenta il throughput e riduce il tempo di finalizzazione. Tuttavia, c'è un grosso svantaggio del pipelining, che è meglio illustrato con un esempio. Si supponga che le linee guida per i blocchi N, N+1 e N+2 siano Alice, Bob e Charlie. Se Bob perde il suo slot, anche la proposta di Alice verrà invalidata, perché il messaggio di Bob contiene sia la sua proposta che un controllo di qualità per la proposta di Alice. Quando ciò accade, Charlie finisce per essere chiamato a produrre un blocco come se la proposta di Alice non fosse mai esistita. Ci riferiamo a questo comportamento come "tail-forking" e può essere pensato come una mini-riorganizzazione della profondità 1. La possibilità di tail-forking ha conseguenze significative, perché gli slot persi non sono necessariamente casuali. Se c'è l'opportunità di estrarre valore ri-estraendo il blocco di Alice mentre si riordinano o si omettono alcune delle transazioni, allora Bob e Charlie possono colludere per far sì che Bob perda intenzionalmente il suo slot, innescando un'opportunità per Charlie di ri-estrarre il blocco di Alice. Questo è stato uno svantaggio significativo dei protocolli HotStuff in pipeline (alcuni dei quali sono oggi in mainnet). --- MonadBFT cambia questa situazione MonadBFT è il primo protocollo ad abilitare il pipelining rendendo l'algoritmo resistente alla forchetta della coda. Questa resistenza al tail fork deriva dalla procedura di fallback quando Bob perde il suo slot, che consente ai validatori di mettere insieme la loro conoscenza collettiva della proposta di Alice e il suo livello di consenso all'interno del set di validatori. In particolare, sotto MonadBFT, se Bob perde il suo slot, la procedura di fallback prevede che i validatori comunichino tra loro con attestazioni firmate che indichino se hanno visto il blocco di Alice. Se la supermaggioranza attesta il blocco di Alice, allora Charlie è costretto a riproporre il blocco di Alice. Se Charlie desidera proporre un blocco diverso, deve fornire un'attestazione firmata dalla maggior parte dei validatori che attesti di non aver visto il blocco di Alice in tempo. Nel tipico caso in cui Charlie ripropone il blocco di Alice, arriva poi a proporre il suo blocco nel round successivo. Il risultato sono due importanti proprietà: resistenza alla forchettatura della coda e finalità speculativa a slot singolo. Abbiamo già parlato della resistenza al tail-forking, ma cerchiamo di capire l'impatto sulla finalità. Come in precedenza, si supponga che le linee guida per i blocchi N, N+1 e N+2 siano Alice, Bob e Charlie. In Pipelined 2-Phase HotStuff - cioè prima di MonadBFT - come validatore (o nodo completo), non è possibile finalizzare la proposta di blocco di Alice fino a quando non si vede la proposta di blocco di Charlie. Perché? Perché se finalizzi non appena vedi la proposta di Bob, è possibile che Bob ti stia prendendo in giro inoltrando SOLO la sua proposta a te, e in realtà ha intenzione di non inviare la sua proposta a tutti gli altri, perdendo così il suo slot. Ma in MonadBFT, non appena si vede la proposta di Bob, si può finalizzare "speculativamente" la proposta di Alice perché la proposta di Bob include un QC sulla proposta di Alice, che è la prova che i 2/3 della rete hanno attestato la proposta di Alice. Anche se Bob ti sta prendendo in giro inoltrando SOLO la sua proposta a te, e finirà per perdere il suo slot, sai che la stragrande maggioranza della rete ha visto la proposta di Alice e, quando parteciperà alla procedura di fallback, firmerà nuovamente la proposta di Alice. L'unico modo in cui il blocco di Alice non verrà finalizzato è se i validatori equivocano e firmano dicendo che non hanno visto il messaggio di Alice. Questo errore è facilmente dimostrabile: abbiamo firmato messaggi contrastanti da loro. Se la penalità per l'equivoco è sostanziale - e dovrebbe esserlo - questa finalità "speculativa" non è in realtà così speculativa. --- Da asporto MonadBFT è uno sviluppo estremamente interessante per il consenso ed è un degno complemento ad altri miglioramenti di composizione in Monad, tra cui l'esecuzione asincrona, l'esecuzione parallela ottimistica e MonadDb. Congratulazioni a @MohammadMJalal1 e @KushalBabel per questa significativa scoperta. MonadBFT sarà implementato a breve su Monad Testnet, che attualmente implementa Pipelined 2-Phase HotStuff. Per ulteriori letture, vedere il post del blog e l'articolo collegati nel prossimo tweet.