L’algoritmo Clique — Consenso Proof of Authority

Pietro Vaccarello
Sep 9 · 5 min read

BLOCKCHAIN PERMISSIONED

Prima di iniziare è necessario introdurre il concetto di blockchain di tipo permissioned o consortium come un particolare tipo di blockchain dove i partecipanti del sistema necessitano di una sorta di autorizzazione per partecipare al network. Immagina il tutto come un insieme di aziende conosciute che stanno costruendo un ambiente blockchain chiuso per scambiarsi risorse tra di loro: non possono permettere a nessuno di entrare nel loro network poiché il mercato e l’ambiente sono chiusi e devono essere tenuti sotto controllo.

Questo va un pò contro l’apertura e l’anonimato tipico del movimento blockchain, ma come spesso accade con la tecnologia, questa si adatta agli scopi delle aziende.

La chiave di questi sistemi chiusi è che l’anonimato e il decentramento non siano rigidi, perché ogni nodo del sistema è ben noto e localizzato, e questo non è poi così male. Il livello di governance di questo sistema, ad esempio, è davvero elevato poiché un numero chiuso di parti può votare e gestire le decisione prese riguardo al sistema stesso, mentre in un contesto pubblico, dove la comunità è virtuale e non così definita, è totalmente diverso.

CONSENSUS

Se le proprietà e la struttura del sistema cambiano in un ambiente chiuso, cambia anche l’algoritmo di consenso. È un dato di fatto che non sia necessario fornire resilienza contro Sybil Attacks o DDos né fornire un forte algoritmo basato sull’anonimato come PoW o PoS.

Questo è il motivo per cui nei sistemi blockchain chiusi, è stato definito un nuovo algoritmo di consenso, che va sotto il nome di Proof of Authority (PoA).

PROOF OF AUTHORITY (PoA)

Qui, un insieme predefinito di parti conosciute, chiamato authorities, mantiene e gestisce la blockchain agendo come una sorta di “miners” o validatori. In qualsiasi momento la serie di validatori è definita e pubblica e un not random based algorithm può essere usato per scegliere il validatore successivo o il leader che propagherà il suo blocco.

Questo porta ad avere sistemi in cui un semplice algoritmo di rotazione del leader può essere eseguito tra l’intero insieme di authorities in qualsiasi momento, in cui, dividendo il tempo in steps, ogni step ha un solo leader che si occuperà di propagare il blocco per quello specifico step.

Differenze fra gli algoritmi di consenso PoW, PoS e PoA

Qui di seguito sarà descritto il più comune degli algoritmi di PoA, Clique, utilizzato di default dal client Ethereum, Geth.

Un’attenzione particolare sarà dedicata alla proprietà BFT o Byzantine Fault Tolerant di questo algoritmo che è uno dei criteri più importanti di un algoritmo di consenso.

Si dice che un algoritmo di consenso è BFT se è progettato per funzionare e restituire un valore corretto anche in presenza di un certo numero di utenti bizantini all’interno del sistema, dove bizantino significa utenti che possono essere corrotti, dannosi o difettosi, in una parola, utenti su cui non puoi fare affidamento. Questi tipi di algoritmi sono più lenti ma più robusti rispetto ai più semplici FT (Fault Tolerant) che sostanzialmente potrebbero non restituire il valore corretto in presenza di un singolo nodo bizantino sul sistema.

L’algoritmo BFT più famoso si chiama PBFT, che è in genere un po’ più lento poiché richiede 3 messaggi per ogni step/round prima di concordare un singolo valore: anche Clique è BFT ma è molto più veloce.

CLIQUE

Clique è incorporato nel client Geth di Ethereum, quindi è progettato per seguire i meccanismi della blockchain di Ethereum appunto. Clique si basa su epoche, in cui ogni epoca è definita da una sequenza speciale di blocchi e ogni volta che inizia una nuova epoca viene trasmesso uno speciale TRANSITION BLOCK contenente principalmente l’insieme di authorities che parteciperanno al consenso per quella specifica epoca.

Step e Leader sono calcolati seguendo una determinata formula che utilizza sostanzialmente l’operatore modulo tra il numero di authorities al fine di avere un leader unico per ogni round. Qui si vede l’algoritmo BFT poiché in Clique per ogni step non esiste un solo “leader” che potrebbe essere bizantino e quindi inaffidabile.

Per ogni step non esiste un solo leader ma poche authorites cui è consentito pubblicare e trasmettere anche i loro blocchi insieme al leader di quel particolare round. La formula leader consente a ciascuna authorites di inviare un blocco solo ogni (N / 2 +1) blocchi, e cioé dopo solo N-(N / 2 + 1) passaggi. Anche questo meccanismo è progettato per eseguire il backup del leader se dovesse essere difettoso/dannoso, inviando per ogni round almeno un blocco.
Questo aspetto potrebbe portare a forks poiché è possibile propagare più di un blocco per round, ma Clique è progettato per cooperare con il protocollo GHOST della blockchain di Ethereum dove il percorso canonico della blockchain è quello con il più alto punteggio sommato.
Notare che Clique assegna per ogni round un punteggio a ciascun blocco, dove il leader ha il punteggio più alto del round e se due blocchi vengono propagati in un singolo round, quello con il punteggio più basso verrà scartato.

Per capire meglio come funziona e perché è byzantine tolerant, va definito che per ogni passaggio, sole le authorites N-(N / 2 + 1) (leader contati) sono autorizzate a proporre i loro blocchi, ma tra questi solo il leader propagherà il suo blocco dopo un ritardo casuale al fine di evitare forks deterministici o sistematici.
Quindi, se il leader è attivo, trasmette il suo blocco con il punteggio più alto, altrimenti, una delle authorites del round selezionato proporrà il suo blocco che probabilmente sarà quello con il minor ritardo casuale.

PERFORMANCES

Per ogni round, ci sono al massimo N-(N / 2 + 1) blocchi propagati (nel peggiore dei casi) o solo un messaggio del leader(nel migliore dei casi). I blocchi recuperati dai nodi vengono automaticamente salvati in modo che la latenza sia 1 e alla fine modificheranno il percorso principale della loro blockchain locale solo se dovesse arrivare un blocco con punteggio più alto.
Quindi questo non è esattamente BFT ma è molto più veloce e fornisce un eventuale meccanismo di coerenza grazie al GHOST PROTOCOL.

Sources:
https://eprints.soton.ac.uk/415083/2/itasec18_main.pdf
https://github.com/ethereum/EIPs/issues/225
https://medium.com/poa-network/proof-of-authority-consensus-model-with-identity-at-stake-d5bd15463256

vivido-it

Blockchain on demand software company

Pietro Vaccarello

Written by

@vivido Team Member. #blockchain #Dapps #watson #supplychain revolution interested

vivido-it

vivido-it

Blockchain on demand software company

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade