Come concordare: Diversi tipi di consenso per la Blockchain

Esistono molti altri tipi di consenso oltre alla proof of work e alla proof of stake. Qui presentiamo le alternative più importanti.

In termini più semplici, una blockchain è costituita da dati elaborati e registrati da un gruppo di computer che collaborano per garantire l’autenticità e la sicurezza di queste transazioni.

Ma come possiamo garantire che queste transazioni siano effettivamente verificate e sicure? Le blockchain sono, per loro natura, decentralizzate e distribuite, il che significa che non esiste un’autorità centrale che eserciti una governance sul sistema. Per garantire il rispetto delle regole del protocollo e prevenire qualsiasi comportamento non etico, le blockchain applicano vari algoritmi per ottenere il cosiddetto consenso tra entità prive di fiducia.

Definizione rapida di consenso

Il consenso può essere definito come l’accordo di un gruppo di agenti sui loro stati comuni attraverso l’interazione locale.

Nel contesto della blockchain, il consenso è una procedura in cui i peer di una rete blockchain raggiungono un accordo sullo stato attuale dei dati nella rete. Sono questi algoritmi di consenso a stabilire l’affidabilità e la fiducia nei sistemi Blockchain.

Mentre il consenso è abbastanza facile da ottenere nelle reti centralizzate, dove si ha fiducia in un’autorità di governo che convalidi le transazioni e salvaguardi i record, è molto meno semplice nel caso dei sistemi decentralizzati.

Il consenso nella Blockchain

La blockchain funziona aggiungendo blocchi di dati e l’essenza del consenso consiste nel garantire che ogni blocco aggiunto alla catena sia la sola e unica versione della verità concordata da tutti i nodi del sistema. È una caratteristica fondamentale della natura decentralizzata della blockchain.

Le regole di base per il consenso nella blockchain includono:

• L’obiettivo di raggiungere un accordo
• Collaborazione, cooperazione e pari diritti per ogni nodo/peer, e
• Partecipazione obbligatoria di ogni nodo al processo

Esistono molti approcci diversi per raggiungere il consenso sui sistemi decentralizzati. Qui esaminiamo i diversi modi di concordare e formare il consenso.

Consenso Nakamoto

Il protocollo di consenso Nakamoto, la madre di tutte le blockchain, è stato ideato da Satoshi Nakamoto nel 2009 come nuovo mezzo per verificare l’autenticità di una rete blockchain e per prevenire i doppi pagamenti. Si tratta di un algoritmo di consenso a tolleranza di errore bizantina che funziona insieme alla proof of work (PoW) per governare la blockchain di Bitcoin.

La tolleranza ai guasti bizantina (BFT) è una condizione in cui un sistema distribuito può rimanere tollerante ai guasti in presenza di attori maligni e imperfezioni della rete.

Mentre PoW si riferisce al meccanismo crittografico in base al quale i minatori competono l’uno contro l’altro per risolvere puzzle computazionali estremamente complessi (e costosi) al fine di guadagnare il diritto di convalidare un nuovo blocco e ottenere una “ricompensa di blocco”. Questa ricompensa monetaria incentiva i minatori a seguire le regole e a rimanere onesti, mentre i costi di partecipazione servono a disincentivare economicamente gli attacchi alla rete Bitcoin, proteggendo ulteriormente la blockchain.

Attraverso la combinazione di BFT e PoW, Nakamoto ha cercato di aggirare alcuni dei problemi di scalabilità insiti in BFT, scoraggiando al contempo i malintenzionati. Creando una misura standard per la validità della blockchain – in questo caso, la quantità di risorse computazionali (o “potenza di hashing”) spese su di essa – Nakamoto ha aperto una nuova direzione per risolvere il Problema dei Generali Bizantini in una configurazione senza permessi. Una che porterebbe alla nascita di molti nuovi algoritmi di consenso, tra cui proof of stake (PoS), proof of authority (PoA), proof of reputation (PoR) e proof of importance (PoI).

Prova di X

L’idea alla base di questo consenso proof of something (PoX) è quella di utilizzare alcune risorse scarse X dove i malintenzionati non possono ottenere X facilmente. In questo modo, il sistema può rimanere sicuro in modo decentralizzato e senza permessi. Ecco come funziona di solito.

Per ottenere il privilegio di convalidare le transazioni e di estrarre nuove monete, i nodi di una rete PoX devono dimostrare di aver soddisfatto con successo X criteri. Spesso questo processo comporta una sorta di sacrificio. Ad esempio, la potenza e lo sforzo di calcolo in PoW e le monete puntate in PoS. In modi diversi, questi servono come incentivi per i minatori a rimanere onesti.

In generale, PoX appartiene alla classe del consenso di Nakamoto. Il consenso di Nakamoto normalmente adotta le seguenti scelte progettuali:

• Tolleranza ai guasti bizantina: le reti sono in grado di continuare a funzionare anche se alcuni nodi si guastano o agiscono in modo malevolo.
• Sincrono: i messaggi vengono consegnati entro un tempo prestabilito.
• Probabilistico – i nodi concordano sulla probabilità che il valore sia corretto
• Basato sui leader: i leader vengono eletti per convalidare le transazioni.

E quindi può ottenere le seguenti proprietà:

• I compagni possono entrare e uscire quando vogliono
• Si concentra sulla vivacità (cioè un peer può sempre produrre nuovi blocchi) a scapito della sicurezza (cioè le decisioni prese possono essere annullate).
• Autosufficienza: i peer sono incentivati a mantenere la rete.

Esistono troppi protocolli PoX per introdurli tutti. I lettori interessati possono leggere la nostra guida per principianti ai meccanismi di consenso per una sintesi dei consensi PoX più noti oggi.

Consenso classico

Il consenso classico, invece, raggiunge il consenso attraverso il voto. Questi protocolli confermano le transazioni più velocemente rispetto ai tipi di consenso Nakamoto discussi in precedenza, poiché la dimensione della rete di consenso è fissa e i progressi possono essere compiuti non appena vengono visualizzati i voti necessari.

Ecco alcuni importanti esempi di consenso classico:

Tolleranza ai guasti bizantina pratica (pBFT)

Introdotta alla fine degli anni ’90 da Barbara Liskov e Miguel Castro, la tolleranza ai guasti bizantina pratica (pBFT) mira a risolvere molti dei problemi associati alle soluzioni di tolleranza ai guasti bizantina (BFT) già citate.

pBFT utilizza una macchina a stati trifase e un’elezione a blocchi per selezionare il leader. Le tre fasi del pBFT sono note come pre-preparazione, preparazione e impegno. Dove Nel caso abituale, il consenso si ottiene con lo scambio di messaggi tra i nodi che portano una transizione progressiva al loro stato locale. Altrimenti, in caso di guasto di un nodo, verrà attivato un “cambio di vista”, che porterà a una nuova selezione del leader in modo round-robin. pBFT è in grado di gestire meno di ⅓ dei guasti bizantini, il che può essere visto come 3f+1= Totale nodi dove f=ammontare dei guasti bizantini.

Tuttavia, presenta alcuni svantaggi:

• Leadership debole – i nodi possono rifiutare le richieste del leader e proporre la rielezione, ma richiede servizi di autorità per la selezione del leader.
• Tolleranza ai guasti bizantina – il 33% dei nodi può essere maligno.
• Bassa scalabilità della rete: a causa dell’elevato overhead di comunicazione e della latenza dei cicli di messaggi multipli, l’aumento del numero di nodi aumenterebbe quadraticamente la complessità del sistema.
• Velocità di transazione: fino a 50.000 tx al secondo con un tempo di conferma di 1 secondo.
• Caso d’uso – blockchain consortile con un validatore autorizzato limitato.

Tolleranza ai guasti bizantina delegata (dBFT)

La tolleranza ai guasti delegata bizantina (dBFT) è stata proposta dal progetto NEO nel 2014. A differenza di pBFT, che richiede servizi di autorità per selezionare il leader, il sistema di votazione di dBFT consente una partecipazione su larga scala, in modo simile alla prova di partecipazione delegata (DPoS).

La procedura di consenso complessiva è molto simile a quella di pBFT, ma si differenzia per il modo in cui vengono contati i voti. In dBFT, il peso del voto è proporzionale al numero di gettoni in possesso dei partecipanti al momento del voto. I partecipanti possono delegare i loro token (voti) a rappresentanti fidati. Questo migliora le prestazioni, ma significa anche che il sistema potrebbe diventare più centralizzato nel tempo a causa di questo ulteriore livello di rappresentanza. Un contro di questo metodo è che i delegati eletti non possono più essere anonimi. I delegati sulla blockchain NEO lavorano con identità reali.

Accordo Federato Bizantino (FBA)

L’accordo federato bizantino (FBA) è un algoritmo che supporta l’adesione aperta, consentendo ai validatori di unirsi liberamente alla rete. Si distingue per l’elevato throughput, la scalabilità e i bassi costi di transazione.

FBA può essere considerato un BFT senza permessi. Tuttavia, una transazione deve essere firmata da un gruppo specifico di firmatari. In un sistema FBA, i validatori sono in grado di scegliere gli altri validatori di cui si fidano e da qui formano il cosiddetto quorum slice. In un sistema con molti validatori possono esserci più fette di quorum e con più fette di quorum si verifica una sovrapposizione con alcuni nodi che sono affidabili in più fette. Queste sovrapposizioni si uniscono per formare il quorum generale. Che viene utilizzato come metodo per raggiungere un consenso in FBA. I progetti che utilizzano FBA sono Ripple (XRP) e Stellar (XLM).

Alcuni vantaggi dell’FBA sono:

• La barriera all’ingresso è bassa, in quanto l’adesione è aperta a chi è affidabile e si unisce a una fetta di quorum.
• Chiunque può unirsi e andarsene in qualsiasi momento, ma il sistema è ancora in grado di funzionare.

Zattera

Sviluppato da Diego Ongaro e John Ousterhout nel 2014, Raft si basa sul protocollo Paxos ed è stato progettato per essere più semplice da comprendere e implementare. Rispetto a molti altri algoritmi di consenso, Raft ha una maggiore dipendenza dal leader. I nodi si fideranno del leader una volta che i timer randomizzati lo avranno eletto, e sarà rieletto solo se il leader attuale fallisce.

Questo ha migliorato notevolmente la situazione:

• Leadership forte – i nodi non rifiuterebbero le richieste del leader, nessuna rielezione fino a quando il leader non è disponibile.
• Crash fault-tolerant – il 49% dei nodi può bloccarsi o diventare non disponibile.
• Elevata scalabilità della rete – La complessità di questo algoritmo di consenso è linearmente proporzionale al numero di nodi.

Esempi:

Consenso senza leader

L’ultimo tipo di consenso che presenteremo è una nuova direzione emergente: il consenso senza leader.

Come già detto, per consenso si intende l’accordo di un gruppo di agenti sui loro stati comuni attraverso l’interazione locale.

In un problema di consenso senza leader non è necessario un leader virtuale, mentre in un problema di consenso con leader-seguace è necessario un leader virtuale che specifichi l’obiettivo per l’intero gruppo. In particolare, il consenso con un leader virtuale statico è chiamato problema di regolazione del consenso, mentre il consenso con un leader virtuale dinamico è chiamato problema di inseguimento del consenso.

Esempi di progetti di consenso senza leader sono Avalanche, IOTA e NKN. Qui presenteremo Avalanche e IOTA ad alto livello.

Valanga

Il whitepaper Avalanche è stato rilasciato in forma anonima a metà maggio 2018 da un team che si identifica solo come Team Rocket. In seguito, AVA Labs è stata fondata per sviluppare il token Avalanche (AVA), e si ritiene che un gruppo di informatici della Cornell University (Emin Gün Sirer, Kevin Sekniqi, Ted Yin) sia strettamente associato al progetto.

Il Team Rocket ha definito il protocollo di consenso una “nuova famiglia di protocolli di consenso metastabili per le criptovalute” e lo ha descritto come “una nuova famiglia di protocolli di tolleranza ai guasti bizantini senza leader, costruita su un meccanismo metastabile”.

Avalanche fa uso di ripetuti sottocampi casuali per la votazione al fine di raggiungere un consenso. Ogni nodo deve campionare un certo numero di vicini per verificare i loro stati e vedere se si allinea con la maggioranza. In caso contrario, cambieranno i loro Stati seguendo la maggioranza. Il processo si ripeterà ancora e ancora, per cui alla fine l’intera rete arriverà a una conclusione onnipresente nel lungo periodo.

Avalanche ha dichiarato che il suo meccanismo di consenso può raggiungere 1.300 tps con una latenza di 4 secondi.

Secondo il team, il rilascio della mainnet di Avalanche è previsto per settembre 2020.

IOTA

IOTA è stata fondata nel 2015 da David Sonstebo, Sergey Ivancheglo, Dominik Schiener e Dr. Serguei Popov. IOTA è tra le prime monete a proporre l’utilizzo di un grafo aciclico diretto (DAG) come struttura dati sottostante per una tecnologia di registro distribuito (DLT) invece della blockchain.

La versione attuale di IOTA utilizza un protocollo chiamato Tangle. Il Tangle ha le seguenti proprietà, diverse da quelle del bitcoin:

• Utilizza una struttura dati basata su DAG per formare il grafo delle transazioni invece di raggruppare le transazioni in blocchi concatenati.
• Elimina il ruolo dei minatori e richiede all’utente di verificare due transazioni precedenti (non confermate) se intende inviare nuove transazioni alla rete.
• Il consenso/il voto si basa su informazioni locali e non richiede l’interazione con l’intera rete. Si ottiene invece attraverso un processo di cammino casuale ponderato chiamato catena di Markov Monte-Carlo (MCMC).
• Tuttavia, il whitepaper non specifica chiaramente come si possa raggiungere il consenso in un ambiente distribuito. Per questo motivo, fino a oggi la rete si è affidata a un “coordinatore” centralizzato, che la comunità crittografica ha ampiamente criticato.

Recentemente, la Fondazione IOTA ha dichiarato la propria tabella di marcia chiamata “Coordicidio” per rinnovare il protocollo e rimuovere il coordinatore. Sono stati proposti due consensi: il consenso veloce probabilistico (FPC) e il consenso cellulare (CC). Entrambe le soluzioni appartengono alla classe del consenso senza leader.

Consenso e scalabilità della Blockchain

Ecco una panoramica dei meccanismi di consenso più comunemente utilizzati. Come tutte le parti che fanno muovere una blockchain, anche in questo caso possiamo notare una netta evoluzione, dal concetto originale a versioni più veloci e agili che aiutano a scalare le blockchain per velocità più elevate e reti più grandi. Se volete saperne di più sulle funzioni di base della blockchain, date un’occhiata anche ai nostri articoli sulle sidechain e su come aiutano a costruire molto di più di un semplice sistema di pagamento sulla catena.