Migliorare il consenso BFT con protocolli DAG

I sistemi di Tolleranza ai Guasti Bizantini (BFT) sono progettati per garantire affidabilità anche in caso di guasti all'interno di una rete. Mantengono un'operazione corretta anche se alcuni replicanti o server falliscono o si comportano in modo errato. I protocolli di consenso BFT sono stati ampiamente applicati, specialmente nei sistemi decentralizzati come le blockchain, per garantire che le transazioni vengano elaborate in modo accurato ed efficiente.

#Protocolli BFT Tradizionali

I primi protocolli BFT si concentravano sul problema di raggiungere un consenso in un ambiente distribuito. Il protocollo di Tolleranza ai Guasti Bizantini Pratico (PBFT) è stata una delle prime implementazioni di successo, permettendo a un gruppo di server di concordare l'ordine delle transazioni. PBFT raggiunge una bassa Latenza, richiedendo solo tre scambi di messaggi per impegnare una transazione in uno scenario senza guasti. Tuttavia, si basa su un unico leader per proporre l'ordine dei comandi, creando un rischio di guasto e limitando la capacità di elaborazione.

#La Sfida della Latenza e del Throughput

I protocolli BFT attuali spesso faticano a bilanciare latenza e throughput. Mentre i protocolli BFT tradizionali ottimizzano per la latenza, i protocolli più recenti danno priorità a un alto throughput, sacrificando i tempi di risposta nel processo. Questo crea una tensione nel design dei sistemi BFT, dove raggiungere sia una bassa latenza che un alto throughput rimane una sfida significativa.

#Introduzione ai Protocolli DAG-BFT

Recentemente, è emersa una nuova classe di protocolli BFT, noti come protocolli BFT basati su Grafi Direzionati Acyclici (DAG-BFT). Questi protocolli disaccoppiano la diffusione dei dati dal consenso, consentendo a ciascun replicante di agire come proponente. Utilizzando una struttura DAG, possono raggiungere una migliore scalabilità e throughput. Tuttavia, i protocolli DAG-BFT esistenti spesso presentano alta latenza, rendendoli meno adatti per applicazioni in tempo reale.

#La Struttura dei Protocolli DAG-BFT

In un DAG, ogni nodo rappresenta una transazione, e i bordi rappresentano relazioni tra le transazioni, come la causalità. Quando un replicante propone un nuovo lotto di transazioni, aggiunge un nodo al DAG. Affinché una transazione sia considerata impegnata, deve essere referenziata da un nodo ancorato impegnato. Questo design consente uno strato di diffusione dei dati parallelo e reattivo, fondamentale per aumentare il throughput.

#Il Problema della Latenza nei Protocolli DAG-BFT

Nonostante i loro vantaggi, i protocolli DAG-BFT sono attualmente ostacolati da significativi problemi di latenza. In media, richiedono oltre dieci scambi di messaggi per impegnare una transazione. Questa mancanza di efficienza può compromettere le capacità in tempo reale che molte applicazioni moderne richiedono.

#Suddivisione dei Componenti di Latenza

La latenza totale dei protocolli DAG-BFT può essere suddivisa in tre componenti chiave:

1. Latenza di Code: Questo è il tempo che una transazione aspetta prima di essere inclusa in una proposta. Proposte di transazione perse significano aspettare il turno successivo per inviare la transazione.
2. Latenza di Ancoraggio: Questo è il tempo di attesa affinché una transazione venga referenziata da un'Ancora impegnata. La frequenza dei candidati ancorati influisce su questa latenza.
3. Latenza di Impegno dell'Ancora: Questo è il tempo necessario per impegnare una proposta di ancoraggio e le transazioni associate.

#Approcci per Ridurre la Latenza

Per affrontare questi problemi di latenza, possono essere implementate diverse tecniche per snellire il processo di impegno delle transazioni nei protocolli DAG-BFT.

#Ottimizzazione delle Regole di Impegno dell'Ancora

Un approccio fondamentale per ridurre la latenza di impegno dell'ancora implica il miglioramento delle regole che governano quando le ancore possono impegnare le transazioni. Consentendo un impegno più veloce quando vengono soddisfatte determinate condizioni, come quando più nodi non certificati si collegano a un'ancora, il sistema può realizzare latenze ridotte.

#Aumentare il Numero di Ancore

Un'altra strategia efficace è aumentare dinamicamente il numero di ancore per giro. Questo approccio può minimizzare la latenza di ancoraggio poiché più nodi hanno opportunità di essere referenziati dalle ancore, accelerando così il processo di impegno.

#Operare più DAG in Parallelo

Un terzo approccio è operare più istanze di DAG contemporaneamente. Staggerando queste istanze, il sistema può garantire che le transazioni possano essere proposte più frequentemente. Questo aiuta a mitigare la latenza di code esperita nei sistemi tradizionali, permettendo una lavorazione più efficiente delle transazioni.

#Valutazione delle Prestazioni

Per determinare l'efficacia di questi miglioramenti, sono stati condotti vari esperimenti confrontando il nuovo protocollo DAG-BFT con i sistemi esistenti. I risultati indicano miglioramenti significativi sia nel throughput che nella latenza.

#Risultati dell'Implementazione delle Nuove Tecniche

• L'uso di regole ottimizzate per l'impegno delle ancore ha portato a una riduzione della latenza di impegno delle ancore, permettendo di finalizzare le transazioni più rapidamente.
• Aumentare la frequenza delle ancore ha ridotto efficacemente la latenza di ancoraggio, migliorando la tempistica complessiva di impegno delle transazioni.
• Operare più DAG in parallelo ha ridotto significativamente la latenza di code, risultando in una lavorazione più veloce delle transazioni in arrivo.

#Conclusione

I protocolli DAG-BFT hanno un potenziale significativo per migliorare il throughput nei sistemi distribuiti. Implementando strategie per ridurre la latenza senza compromettere il throughput, può essere stabilito un meccanismo di consenso più efficiente. I progressi fatti qui evidenziano che, con il giusto design e ottimizzazioni, raggiungere sia un alto throughput che una bassa latenza nei sistemi BFT non è solo possibile, ma pratico per applicazioni del mondo reale.