Polkadot Consenso Parte 3: BABE

Questa è la terza parte della nostra serie sul consenso di Polkadot. Vedere la prima parte per l'introduzione e la seconda per una discussione su GRANDPA.

Blind Assignment for Blockchain Extension (BABE) è un motore di produzione di blocchi ispirato a Ouroboros Praos, un altro protocollo di proof-of-stake. Può essere utilizzato da solo perché fornisce una finalità probabilistica, oppure può essere abbinato a un sistema di finalità come GRANDPA.

BABE è un algoritmo basato su slot. Suddivide il tempo in epoche, e ogni epoca è suddivisa in slot. In Polkadot, ogni slot ha una durata di sei secondi,che sarà il nostro target per il tempo di blocco . BABE seleziona un autore (o più autori) per creare i blocchi.

Un modo per assegnare gli autori a questi slot sarebbe semplicemente quello di fare dei turni. Tuttavia, in uno schema a rotazione, gli aggressori sanno sempre chi è l'autore successivo e possono usare questa informazione per coordinare gli attacchi. Idealmente, nessuno sa chi è l'autore dello slot finché non lo dimostra.

Ogni slot può avere un autore primario e uno secondario (o "leader dello slot"). I leader degli slot primari sono assegnati in modo casuale. Poiché la funzione è casuale, tuttavia, a volte ci sono slot senza leader. Per garantire un tempo di blocco coerente, BABE utilizza un sistema di round-robin per assegnare agli slot dei leader secondari.

I Leaders Primari degli Slot

La leadership primaria viene concessa in base alla valutazione di una funzione casuale verificabile (VRF). C'è molto clamore intorno ai numeri casuali nella blockchain. Per farla breve, molte applicazioni dipendono dalla generazione di numeri casuali, ma può essere difficile trovare una casualità che sia condivisa da tutti (e non sfruttata in modo da avvantaggiare il generatore) quando tutte le operazioni sulla chain devono essere deterministiche e verificabili.

I VRF generano un numero pseudo casuale e una prova che sia stato generato correttamente. Prendono in input alcuni parametri, tra cui una chiave privata. Il nostro VRF prende dall'epoca un seed casuale (concordato in anticipo da tutti i nodi), un numero di slot e la chiave privata dell'autore. Poiché non esistono due nodi con la stessa chiave privata, ogni nodo può generare un valore pseudo casuale unico per ogni slot.

Ogni autore esamina il proprio VRF per ogni slot in un'epoca. Per ogni slot il cui output è inferiore a una soglia concordata, il validatore ha il diritto di autorizzare un blocco in quello slot. A causa del processo di assegnazione casuale degli slot, è possibile avere slot senza leader primari e slot con più leader primari. Discuteremo in seguito come gestire questo problema.

I leader secondari degli slot

Per gestire gli slot vuoti, BABE utilizza un round-robin fallback. Ogni slot ha un leader secondario. Se all'inizio dello slot nessuno dichiara di essere il leader principale, il secondario sarà l'autore del blocco. Questo fallback assicura che ogni slot abbia un autore del blocco e contribuisce a garantire un tempo di generazione dei blocchi costante.

Metti assieme BABE e GRANDPA

Finora abbiamo GRANDPA che finalizza le chain e BABE che crea nuovi blocchi. Alcune delle chain di BABE possono avere delle biforcazioni, poiché un singolo slot può avere più leader.

La prima regola per scegliere la chain migliore da estendere è semplice: BABE deve basarsi su una chain che è stata finalizzata da GRANDPA. Questo è uno dei requisiti per utilizzare GRANDPA.

Un secondo, più sottile, requisito per utilizzare GRANDPA è che l'algoritmo di produzione dei blocchi deve avere un modo per scegliere la chain "migliore". Questa proprietà fa sì che BABE abbia una finalità probabilistica (quindi si potrebbe usare senza GRANDPA).

La chain migliore in BABE è semplicemente quella con il maggior numero di blocchi scritti dai leader primari.

I fork sono comuni in BABE. Come discusso nell'articolo su GRANPA, la produzione di blocchi è O(n), il che significa che l'autore deve solo trasmettere il suo blocco a tutti, ma non è necessario che tutti inviino un messaggio a tutti (come in GRANDPA). Quindi, non tutti avranno la stessa visione della chain non finalizzata (i blocchi gialli nell'immagine).

Questo sistema ci permette di produrre blocchi in modo efficiente e di consentire a GRANDPA di finalizzare un insieme di blocchi.

Aspetta, l'orologio di chi?

Assegniamo gli slot in base al tempo, ma non abbiamo un'unica visione del tempo. Ogni computer ha il proprio orologio. Non possiamo usare un servizio di orario centralizzato (chiamato server NTP) perché questo è un singolo punto di attacco. Un aggressore potrebbe attaccare il server NTP, interrompendolo o prendendone il controllo per arrivare a comportamenti più spregiudicati, come l'invio di orari diversi a nodi diversi.

Se sei interessato, considera questo scenario:

Ricevo un tuo messaggio che dice "sono le 8:42:00". Il mio orologio dice che sono le 8:42:03. È possibile una delle tre cose:

1. I nostri orologi sono sincronizzati e la rete ha impiegato solo 3 secondi per consegnare il messaggio.

2. In realtà è stato necessario 1 secondo per consegnare il messaggio. I nostri orologi sono sfasati di 2 secondi.

3. Mi stai mentendo, non è quello che ha detto il tuo orologio.

BABE allinea i numeri degli slot all'orologio di un singolo computer utilizzando il tempo relativo. Quando un nodo riceve un blocco, controlla l'ora di ricezione e il numero di slot associato al blocco. Aggiunge quindi il numero di slot al tempo di ogni blocco per stimare gli slot futuri e utilizza il valore mediano dei suoi dati. Ricordiamo che i validatori conoscono in anticipo i numeri di slot per i quali saranno autori, quindi possono controllare i blocchi in arrivo in base a questo.

Finora abbiamo discusso come vengono create le chain (BABE) e come vengono finalizzate (GRANDPA). Il prossimo problema che dobbiamo risolvere è: come facciamo a far eseguire questi protocolli nel modo corretto? La parte finale di questa serie tratterà di come il runtime fornisce incentivi a eseguire BABE e GRANDPA e delle punizioni per gli errori.

Leggi la parte 4 sulla sicurezza →