Pure Proof of Stake (PPoS) | Spiegazione del consenso in Algorand

In questa lezione approfondiremo l’algoritmo di consenso di Algorand: Pure Proof of Stake (PPoS), a volte chiamato anche Proof of Weight (PoWeight).

Cercheremo di andare nel dettaglio e daremo per scontate alcune nozioni di base, pertanto, se non sapete cosa sia un algoritmo di consenso, vi rimando alla lezione dedicata a questo argomento.

Spiegare un algoritmo di consenso in modo dettagliato ma comprensibile da tutti non è facile. Come sappiamo, la blockchain nasce dall’incontro di tre campi: la teoria dei giochi, la crittografia e l’informatica.

Una spiegazione estremamente dettagliata di PPoS richiederebbe delle conoscenze approfondite in ambito crittografico, come le ha Silvio Micali, il creatore di questo algoritmo, grande esperto di crittografia, professore del MIT, nonché vincitore del prestigioso Turing Award nel 2012, proprio per il suo lavoro nell’ambito della crittografia.

Ciò non deve sorprendere, perché il mondo della blockchain e delle criptovalute ha le sue radici nel movimento cypherpunk, che vede nella crittografia informatica la chiave per il cambiamento sociale e politico.

A ulteriore prova dell’approccio di Micali, fortemente improntato sulla matematica, basti pensare che il nome Algorand è dato dall’unione di “algorithm” (“algoritmo”) e “randomic” (“randomico”), due termini che alla fine di questa lezione avranno acquisito un senso ben preciso.

1- Il trilemma della blockchain e i limiti degli algoritmi di consenso esistenti

Quando si affronta la tecnologia della blockchain è inevitabile mettere in luce una delle sue principali criticità: il trilemma della blockchain.

Non è scopo di questa lezione approfondire questo tema ma è fondamentale introdurlo, visto che l’algoritmo di Micali è nato proprio per risolvere questo trilemma.

Nel corso della storia della blockchain, il trilemma è stato proposto in varie forme ma sicuramente la forma più nota è quella presentata da Vitalik Buterin, il creatore di Ethereum.

Secondo il trilemma è impossibile (o molto difficile) che una blockchain sia contemporaneamente:

• Decentralizzata: ovvero priva di un ente centrale (in informatica, paradigma client-server) ma composta da enti alla pari (in informatica, paradigma peer-to-peer);
• Sicura: in grado di resistere agli attori malevoli che potrebbero attaccarla;
• Scalabile: in grado di reggere un numero molto elevato di utenti e in grado di processare molte operazioni (in particolare le transazioni) in tempi brevi.

Ogni blockchain sarà più forte in alcuni di questi aspetti ma ancora non si è arrivati a una soluzione ottimale.

Gli studi di Micali si sono concentrati proprio sulla risoluzione del trilemma e sullo sviluppo di un algoritmo di consenso sul quale basare una blockchain decentralizzata, sicura e scalabile.

Micali è partito dai limiti degli algoritmi di consenso già esistenti, cercando di superarli e di riutilizzarne gli aspetti migliori.

1.1- Proof of Work (PoW)

Il primo algoritmo di consenso, in ambito blockchain, è stato ovviamente quello della prima blockchain: Bitcoin.

Satoshi Nakamoto, il creatore di Bitcoin, sviluppò l’algoritmo Proof of Work (PoW), che si basa sulla risoluzione di puzzle crittografici ad alto costo computazionale, processo detto “mining”, per poter proporre un nuovo blocco da aggiungere alla catena.

Gli aspetti critici di PoW sono diversi:

• Alto consumo energetico per la risoluzione dei puzzle crittografici;
• Necessità di possedere hardware dedicato e sempre più prestante, cosa che, attualmente, rende impossibile a un singolo utente competere per la creazione del blocco, visto che sono nate concentrazioni di potere (i mining pool), gruppi di miners che uniscono la loro potenza computazionale per aumentare le possibilità di riuscita. Ciò ovviamente comporta una minor decentralizzazione, perché vuol dire che il processo di creazione dei blocchi è controllato per la maggior parte dai principali mining pool;
• Possibilità che la catena si forki quando vengono proposti due blocchi nello stesso momento. In questi casi, la catena si divide in due rami ai quali possono aggiungersi nuovi blocchi, fin quando quello più lungo (o meglio la cui potenza computazionale complessiva utilizzata è stata maggiore) vince e tutti gli altri blocchi dell’altra diramazione vengono eliminati, portando all’annullamento delle transazioni che contenevano.
  Ciò comporta un problema dal punto di vista della scalabilità, dovendo aspettare in media un’ora per essere sicuri che una transazione sia confermata.

1.2- Proof of Stake (PoS)

In seguito a PoW, sono nati altri algoritmi, tra i quali il più noto è Proof of Stake (PoS).

PoS non si basa sulla potenza computazionale, bensì sullo staking, ovvero sul bloccare una parte dei propri fondi. Gli user possono scegliere se mettere in stake una parte dei loro fondi. Ogni volta che deve essere creato un blocco viene estratto il creatore tra chi ha dei fondi in stake. La probabilità di essere estratti è proporzionale alla quantità di fondi messa in stake.

Inoltre, in caso di comportamenti malevoli, l’utente viene privato della somma messa in staking.

Come si può intuire, vengono risolti alcuni dei problemi di PoW, come ad esempio l’oneroso costo energetico, ma emergono nuove problematiche:

• Ancora una volta, è facile che nascano concentrazioni di potere, e che chi ha più soldi da mettere in staking (e quindi è anche più predisposto al rischio di perderli) può facilmente guadagnare sempre più potere. Anche in questo caso poi sono nati staking pools, che funzionano in modo simile ai mining pools;
• Non viene risolto il problema dei fork.

1.3- Delegated Proof of Stake (DPoS)

Una variante di PoS è la Delegated Proof of Stake (DPoS), in cui a un gruppo di delegati viene dato il potere di creare blocchi per un certo lasso di tempo.

Si intuisce facilmente che, in questo caso, il principale problema è la possibilità, per un attore malevolo, di corrompere i delegati o di un attacco Denial of Service (DoS) che li rende non operativi.

Delegare a una parte degli attori infatti comporta una distribuzione minore e quindi un numero minore di attori da corrompere o attaccare.

Vi sono molti altri algoritmi di consenso ma questa breve panoramica basta per introdurre le problematiche che Algorand si propone di risolvere.

2- Gli obiettivi della Pure Proof of Stake di Algorand

Viste le criticità degli algoritmi esistenti, Micali nel 2017 ha proposto Pure Proof of Stake, l’algoritmo che ha visto in Algorand una prima applicazione pratica.

Ricordiamo che ci troviamo nell’ambito dei sistemi distribuiti, in cui quindi vi sono più nodi distribuiti e dislocati in comunicazione tra di loro.

L’obiettivo fondamentale è chiaramente quello di raggiungere il consenso riguardo a delle decisioni (la creazione di un nuovo blocco per esempio).

L’esempio classico è quello del problema dei generali Bizantini, che abbiamo già spiegato nella lezione introduttiva agli algoritmi di consenso. Proprio da questo esempio nascono i Byzantine Agreement protocols, nei quali una delle assunzioni fondamentali è che almeno i 2/3 dei nodi di un sistema devono essere onesti, affinché il protocollo abbia successo.

Algorand ha le fondamenta nei procolli di Byzantine Agreement ma cerca di sviluppare una soluzione ancora migliore, ponendosi principalmente i seguenti obiettivi:

• Evitare Sybil attacks, ovvero gli attacchi informatici in cui un attore malevolo crea molti pseudonimi per avere più peso decisionale (ritorniamo ai 2/3 dei nodi onesti della byzantine fault tolerance). Invero, anche PoW e PoS hanno affrontato questo problema, in modi diversi. Da una parte con la potenza computazionale richiesta per risolvere i puzzle crittografici, dall’altra con lo staking. In entrambi i casi l’intento è quello di far sì che un attore malevolo non possa trarre vantaggio dalla creazione di pseudonimi, cosa che invece potrebbe essere molto pericolosa in un sistema in cui ogni attore esprime un voto non pesato.
• Scalare milioni di user, raggiungendo dimensioni impossibili da immaginare per i protocolli di consenso bizantino esistenti;
• Resistente agli attacchi DoS, riuscendo a operare anche se molti nodi della rete cadono;
• Evitare forks, facendo sì che a ogni round venga proposto un solo blocco, impedendo alla catena di forkarsi.

3- La soluzione di Algorand ad alto livello

La soluzione proposta da Micali è PPoS: un algoritmo di consenso Bizantino con elezione di leader, che riprende elementi della PoS e che funziona se almeno i 2/3 degli attori coinvolti sono onesti.

L’algoritmo di consenso di Algorand procede per round e ogni round deve portare alla creazione di un nuovo blocco da aggiungere alla catena.

A ogni round vengono estratti degli user per competere alla creazione del blocco e in seguito vengono estratti degli altri user per formare un comitato che deve raggiungere il consenso su un blocco da approvare.

Le estrazioni avvengono attraverso Verifiable Random Functions (VRF), ovvero delle funzioni che prendono come input una chiave e un valore e producono un output pseudo-randomico, con una prova che può essere usata da chiunque per verificare il risultato della funzione.

Il funzionamento della VRF è simile a quello di una lotteria: ogni account online (ovvero un account che partecipa al protocollo di consenso, come vedremo meglio nel paragrafo seguente) a ogni round esegue la VRF per scoprire se è stato selezionato per creare il blocco e in seguito per capire se farà parte del comitato di valutazione (per approfondire le VRF, vi sarà un paragrafo apposta più avanti nella lezione).

Qui entra in gioco la somiglianza con PoS, infatti, più Algo si possiedono sul proprio conto, più aumenta la possibilità di essere estratti, perché ogni Algo è come se fosse un biglietto della lotteria.

Si risolve così dunque il problema dei Sybil Attacks, infatti è inutile creare multipli account, ciò che conta è la quantità di Algo posseduti.

Rispetto a PoS però, si noterà che c’è un vantaggio fondamentale: non vi è la necessità di mettere una parte del proprio patrimonio in stake per poter partecipare al consenso.

Ogni Algo presente in ogni account è un biglietto della lotteria, senza bisogno di metterlo in stake. Ne consegue che, a partecipare al processo di consenso, non è una micro-porzione dell’economia complessiva ma l’economia nella sua totalità.

4- Come si partecipa al protocollo di consenso

Per partecipare al processo di consenso, è necessario avere un account online.

Come indicato nell’overview di Algorand, gli account possono essere online o offline. I primi non partecipano al protocollo di consenso, i secondi sì.

Per rendere il proprio account online è necessario firmare un’apposita transazione che permette di ricevere una partecipation key, una chiave che serve per partecipare al protocollo di consenso e che è completamente distinta dalle spending keys, le chiavi utilizzate per effettuare le transazioni.

Le partecipation keys sono contenute in un nodo.

La scelta di distinguere le tipologie di chiavi è stata fatta per ragioni di sicurezza, in modo che, nel caso in cui la partecipation key dovesse essere compromessa (o addirittura che un intero nodo dovesse essere compromesso), le spending keys sarebbero in ogni caso al sicuro.

Sempre per ragioni di sicurezza, la partecipation key non è eterna, bensì è valida solo per un certo numero di round.

Per incrementare ulteriormente il livello di sicurezza del protocollo, la partecipation key viene utilizzata per generare e firmare un set di chiavi effimere che sono valide esclusivamente per firmare i messaggi di un singolo round, dopo al quale vengono eliminate.

Importante è sottolineare il fatto che le chiavi vengano eliminate dopo ogni round, perché ciò rende impossibile compromettere vecchi blocchi della catena usando le vecchie chiavi.

4.1- Spiegazione pratica

Cerchiamo ora di spiegare come si genera una partecipation key e in seguito come si rende un account online.

Il processo è molto tecnico quindi cercheremo di restare abbastanza ad alto livello, per non complicare troppo la lezione. Per i più esperti e i developer rimando a questa pagina delle risorse per developers di Algorand.

Il processo si divide in due fasi:

• Generazione della partecipation key;
• Transazione per registrare un account online.

La partecipation key viene generata eseguendo l’apposito comando

 goal account addpartkey

all’interno di un nodo. Il comando richiede di specificare l’indirizzo dell’account per il quale si sta generando la partecipation key, insieme ad altri dati.

Questo comando genera la coppia di chiavi da utilizzare per la VRF, oltre che il set di chiavi da utilizzare per i singoli round.

Una volta generata la partecipation key bisognerà scaricare dal nodo i dati appena generati con l’apposito comando

goal account partkeyinfo

che restituirà un output di questo tipo:

EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4.6000000.9000000.partkey { "acct": "EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4", "first": 6000000, "last": 9000000, "sel": "X84ReKTmp+yfgmMCbbokVqeFFFrKQeFZKEXG89SXwm4=", "vote": "eXq34wzh2UIxCZaI1leALKyAvSz/+XOe0wqdHagM+bw=", "voteKD": 1730 } ... ```

Si può ora passare alla seconda fase e creare la transazione per registrare l’account online.

Va ricordato che non basta essere online per poter partecipare al consenso, bisogna infatti avere la partecipation key ottenuta col primo passaggio. Se si salta il primo passaggio si risulterà online senza poter effettivamente partecipare al consenso. Se si è online ma non si può partecipare, si sarà considerati utenti disonesti.

Questo è un esempio di transazione per registrare un account online:

{ 
    "txn": { 
        "fee": 2000, 
        "fv": 6002000, 
        "gh": "SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=", 
        "lv": 6003000, 
        "selkey": "X84ReKTmp+yfgmMCbbokVqeFFFrKQeFZKEXG89SXwm4=", 
        "snd": "EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4", 
        "type": "keyreg", 
        "votefst": 6000000, 
        "votekd": 1730, 
        "votekey": "eXq34wzh2UIxCZaI1leALKyAvSz/+XOe0wqdHagM+bw=", 
        "votelst": 9000000 
    } 
}

Si può notare che la transaction fee è più alta rispetto a quella delle transazioni normali (2000 microalgo in questo caso contro ai tradizionali 1000 microalgo, in altri termini 0.002 Algo contro allo 0.001 tradizionale).

Gli altri dati sono quelli contenuti nell’output generato dal comando visto precedentemente, come ad esempio la “votekey”.

5- Verifiable Random Function (VRF)

Algorand si basa su verifiable random functions (VRFs), funzioni che permettono di ottenere un’estrazione crittografica, in modo da scegliere un subset di user, tra gli user totali, basato sui pesi dei singoli user (determinati dalla quantità di Algo che detengono).

Le VRF permettono agli user di dimostrare che sono stati estratti per un determinato ruolo e necessita che ogni user abbia una coppia di chiavi privata/pubblica.

Una VRF prende in input una stringa x e ritorna come output due valori: un hash e una prova.

L’hash è determinato univocamente dalla chiave privata dell’user e dalla string x di input e impossibile da determinare per chiunque non possieda la chiave privata dell’user.

La prova invece permette a chiunque possegga la chiave pubblica dell’user di verificare che l’hash corrisponde alla stringa x inserita come input della VRF, senza aver bisogno di sapere la chiave privata dell’user.

L’hash di output della VRF è detto hashed credential e ritornerà più volte nel corso di questa lezione.

6- Gossip Protocol

In Algorand, gli user comunicano tra di loro tramite un gossip protocol, simile a quello implementato da Bitcoin.

Gli user si inviano messaggi firmati con chiavi private, in modo che gli altri user possano verificarne l’autenticità.

Questi messaggi possono essere di diverso tipo, dalle transazioni, alle proposte di blocco, alle votazioni.

PPoS si basa proprio su questo gossip protocol, necessario per far comunicare le varie parti e farle giungere a un accordo.

7- Pure Proof of Stake nel dettaglio

Andiamo ora a illustrare il funzionamento di PPoS nel dettaglio.

In Algorand il consenso viene raggiunto in tre step obbligatori, più uno opzionale:

• Block proposal;
• Soft Vote;
• Certify Vote;
• Recovery mode.

Descriviamo i primi tre step, considerando il caso ideale in cui non vi siano attori malevoli e che il network non sia partizionato (ovvero che non vi siano nodi del network down), per poi vedere l’ultimo step, che riguarda i casi di malfunzionamento.

7.1- Block Proposal

In questa fase vengono selezionati gli account che proporranno i nuovi blocchi al network in un determinato round.

Per prima cosa ogni nodo esegue la VRF per ogni account Online che gestisce e che possieda una partecipation key valida.

In questo modo vengono estratti gli account che hanno “vinto” la lotteria in quel round. Va sempre ricordato che si tratta di una lotteria pesata, quindi la VRF viene eseguita su ogni Algo posseduto da ogni account online.

Ne conseguono due cose:

• Più Algo si possiedono, più aumenta la probabilità di essere selezionati;
• Vi è la possibilità di essere selezionati più di una volta per round, dato che ogni Algo è come se fosse un biglietto per la lotteria e che quindi potrebbero esserci più biglietti vincenti all’interno di un singolo account (si rimanda al paragrafo dedicato a questo tema).

Una volta che sono stati selezionati gli account, i nodi propagano nel network i blocchi proposti dagli account insieme all’output della VRF, necessario per verificare che l’account sia stato realmente selezionato per proporre il blocco.

Qui vale la pena di scendere ancora di più nel dettaglio introducendo dei nuovi concetti.

Innanzitutto bisogna specificare che in ogni round viene scelto un leader per proporre il blocco. Come abbiamo detto vengono estratti vari account che possono proporre il blocco ma vi sarà sempre un leader in ogni round, che sarà colui la cui hashed credential (ovvero l’attestato di selezione generato dalla VRF) è il più piccolo tra tutti i potenziali leader estratti per la creazione del blocco.

In secondo luogo, come dicevamo prima, i blocchi proposti dagli utenti estratti devono essere propagati insieme alle credenziali (output della VRF) per verificare la validità della selezione.

Qui l’algoritmo di Algorand prevede due accorgimenti che è giusto sottolineare, in quanto fanno ben intendere il grande lavoro che è stato fatto per velocizzare il network e renderlo quindi più scalabile:

• I messaggi inviati dai nodi in questa fase sono di due tipi: i messaggi contenenti i blocchi il cui peso è nell’ordine di qualche mega-byte e i messaggi di controllo, quelli contenenti solo l’output della VRF in relazione a un account, che pesano qualche centinaio di bits.
  In questo modo i nodi potranno leggere prima i messaggi più brevi per verificare la validità dell’output della VRF e solo in seguito leggere i messaggi contenenti i blocchi, in modo da risparmiare tempo e larghezza di banda.
• Il secondo accorgimento è forse ancora più utile. Come appena detto, il leader di un round è colui che avrà l’hashed credential più breve. I singoli nodi hanno un registro di partecipation keys relative a un certo numero di account ma ovviamente non conoscono tutti gli account esistenti.
  Quindi un singolo nodo non potrà sapere, senza comunicare con la rete, chi sarà il leader. La cosa che può fare però è inviare al network solo il blocco e l’output della VRF relativi all’account, tra quelli che gestisce, con l’hashed credential più breve, in modo da trasmettere meno dati e velocizzare il processo.
  Questo meccanismo detto di selective propagation permette inoltre ai nodi, quando ricevono i messaggi dagli altri nodi, di controllare con il messaggio contenente solo le credenziali degli account estratti, la lunghezza del’hashed credential e di decidere in base a questa se aprire anche il messaggio contenente il blocco proposto e se propagarlo a sua volta nel network.
  In questo modo, molto velocemente si riducono i blocchi dei potenziali leader, fino a quando non ne resta solo uno, quello del vero leader del round.
  Ma qui stiamo già sconfinando nella fase di soft vote.

7.2- Soft vote

A questo punto ogni nodo della rete avrà ricevuto e inviato diverse proposte. L’obiettivo del soft vote è quello di filtrare gradualmente le proposte fin quanto non ne resterà solo una, portando dunque ad avere un solo blocco certificato, come appena accennato in riferimento alla selective propagation.

Ogni nodo verifica la firma dei messaggi ricevuti e controlla l’output della VRF per vedere se l’user che ha proposto il blocco è stato veramente estratto.

In seguito ogni nodo esegue nuovamente la VRF per ogni account partecipante al consenso che gestisce, in modo da estrarre il comitato per il soft vote. Anche in questo caso si tratta di una lotteria pesata in base al numero di Algo posseduti dagli account.

Se un account viene scelto, avrà diritto a un voto pesato in base al numero di Algo posseduti. Gli account voteranno la proposta di blocco con l’hashed credential più bassa.

Questo processo continua per un periodo di tempo fissato (dato dal tempo di propagazione dei messaggi di controllo, quelli contenenti solo il risultato della VRF), e scelto in modo tale da ottimizzare due fattori:

• La durata non deve essere eccessiva, per non rallentare il processo di creazione e di aggiunta del nuovo blocco alla catena, cosa che comprometterebbe la scalabilità;
• La durata non deve essere troppo breve, per far sì che i voti possano essere propagati tra tutto il netowrk.

Alla fine del periodo di votazione, invieranno i voti agli altri nodi, insieme all’output della VRF per verificare che sono stati estratti come partecipanti del comitato per il soft vote.

Ogni nodo validerà la prova VRF dei membri del comitato prima di conteggiare i voti.

Queto processo viene eseguito le volte necessarie a raggiungere un quorum.

Ogni volta che viene rieseguito, viene selezionato un nuovo comitato, di dimensione diversa, quantificata in base al numero di voti, non di account.

Per raggiungere il quorum è necessaria una determinata percentuale di voti, in base alla dimensione del comitato.

Va specificato che in questa fase il comitato non ha bisogno di vedere il contenuto dei blocchi ma solo l’hashed credential, per selezionare quella minore. In questo modo il network può procedere molto velocemente, senza rischiare di essere intasato.

7.3- Certify vote

In questa terza fase, detta certify vote, viene estratto un nuovo comitato, sempre tramite VRF, come nello step precedente.

Il nuovo comitato dovrà controllare il blocco proposto dalla fase di soft vote, controllando se ci sono problemi di vario tipo, come overspending o double-spending.

I membri del comitato voteranno (ancora una volta voto pesato in base agli Algo posseduti) se il blocco è valido o no.

I voti vengono propagati nel network, validati dai nodi tramite VRF, fino al raggiungimento di un quorum.

A questo punto, se il quorum è stato raggiunto, il blocco viene aggiunto alla blockchain e viene iniziato un nuovo round che seguirà le fasi esposte finora.

Il processo si ripete così all’infinito.

7.4- Recovery mode

Vi è una quarta fase, opzionale, che entra in gioco nei casi in cui il commitato per il certify vote non raggiunge il quorum in un determinato lasso di tempo.

La recovery mode è una fase in cui si entra quando il newtork va in stallo, cosa che può avvenire essenzialmente per due ragioni:

• Problemi di rete;
• Comportamenti dannosi da parte di attori malevoli.

In entrambi i casi il network entra in recovery mode, in attesa dei messaggi di recovery, in cui i nodi segnalano alla rete che dovrebbe continuare a processare l’ultima proposta di blocco nota oppure proporre un nuovo blocco.

Anche in questo caso avviene una votazione, da parte dei nodi, e una volta scelta una delle due opzioni, il sistema riprenderà a operare normalmente.

In caso di comportamenti dannosi da parte di attori malevoli, il protocollo potrebbe scegliere un nuovo leader.

In caso di problemi di rete invece, continuerà a essere processata la proposta di blocco corrente o verrà proposto un nuovo blocco da analizzare.

7.5- Dataflow del consenso in Algorand

Per concludere, può essere utile avere uno schema riassuntivo che illustri i vari passaggi esposti, dal momento in cui viene inviata una transazione a quando viene inserita in un blocco.

Per comodità, prenderemo l’esempio di una transazione che parte da Algorand Wallet, va specificato che il flusso potrebbe cambiare nel caso si decidesse di creare manualmente le transazioni e inviarle a un nodo.

1. Si crea la transazione da Algorand Wallet e la si invia al network. In particolare, per Algorand Wallet, viene effettuata una chiamata http (POST) a un endpoint predeterminato;
2. La transazione viene ricevuta da un nodo che la propaga in rete attraverso gossip protocol;
3. Ogni nodo avrà un set di transazioni da inserire dentro a un nuovo blocco;
4. Inizio round;
5. Block proposition;
6. Soft Vote;
7. Certify vote;
8. Recovery mode (opzionale, se non viene raggiunto il quorum dopo tot tempo);
9. Fine round, blocco creato;
10. Inizio nuovo round.

8- Cosa succede se uno stesso account viene estratto più volte nello stesso round

Come detto finora, la VRF è di fatto una lotteria pesata, in cui ogni Algo equivale a un voto. Ogni account online viene sottoposta alla VRF che controlla ogni Algo posseduto dall’account per vedere se è un biglietto vincente per un determinato round.

Ciò serve a evitare Sybil Attacks e ha come conseguenza il fatto che un user possa essere selezionato più volte all’interno di un round, cosa tanto più probabile, quanti più Algo possiede.

Dunque, è possibile che un user X che possiede tanti Algo venga scelto N volte per lo stesso ruolo all’interno di un round.

In questi casi, l’user X parteciperà con N sub-user differenti, dove ogni Algo è considerato come un sub-user (ogni Algo vale un voto).

Qui si arriva a un concetto importante, che si ricollega all’hashed credential (o priorità del blocco) di cui abbiamo parlato più volte.

Infatti per ogni sub-user dell’user X, verrà applicata una hash function a cui si passerà come input l’output della VRF concatenato all’indice del sub-user.

Tra gli hash ottenuti, verrà scelto quello con priorità più alta (ovvero l’hash più breve) e verrà utilizzato come hashed credential per il blocco proposto dall’user X.

9- Cosa succede in caso di attori malevoli (adversaries)

Andiamo più nel dettaglio per quanto riguarda la presenza di attori malevoli.

Per prima cosa vediamo che tipologie di attori malevoli (adversaries) possono esserci:

• Static adversary = è un attore malevolo che controlla un gruppo di user, scelto prima che inizi l’esecuzione del protocollo;
• Dynamic adversary = è un attore malevolo che dinamicamente corrompe user in qualsiasi fase del protocollo;
• Network adversary = è un attore malevolo che può controllare la comunicazione della rete usata dagli user. Può provocare delay nei messaggi o addirittura non farli arrivare.

PPoS, essendo un algoritmo di consenso basato sul Byzantine Agreement, necessità della super-maggioranza degli user (2/3) onesti per poter funzionare. Posto questo assunto iniziale, è in grado di resistere a tutte le tre tipologie di avversari.

Vediamo ora diversi tipi di attacchi e come Algorand riesce a resistervi:

9.1- Sybil Attacks

Per quanto concerne i Sybil Attacks, abbiamo già specificato come Algorand renda inutile la creazione di pseudonimi nel processo di consenso, rendendo le votazioni pesate in base alla quantità di Algo detenuti dagli user.

9.2- Corrompere gli user onesti

Vi può essere poi un attacco volto a corrompere gli user onesti. Algorand è realizzato appositamente per prevenire che un avversario possa corrompere abbastanza user da guadagnare il controllo della creazione del blocco.

Non c’è un gruppo stabile di delegati, come nella DPoS, i comitati scelti dalle VRF cambiano in ogni fase, ovvero dopo pochi secondi. Inoltre si tratta di una selezione randomica e segreta, senza comunicazione tra user.

Perciò un avversario non riuscirà a scoprire chi è il leader estratto, se non dopo che il blocco è già stato proposto.

9.3- Network Attacks

Infine vediamo il caso dei network attacks, i più pericolosi per qualsiasi sistema distribuito.

È una tipologia di attacco in cui un avversario crea partizioni all’interno del network, dividendolo e rendendo difficile o impossibile la comunicazione tra user.

In questo modo le varie partizioni di user non saranno a conoscenza di ciò che succede nelle altre partizioni.

In questi momenti il network è completamente asincrono e gli attori malevoli controllano la comunicazione all’interno del network. Gli avversari potrebbero convincere diverse partizioni ad accettare blocchi differenti allo stesso tempo, cosa che porterebbe, tra le altre cose, a problemi come il double-spending.

In Algorand può essere accettato un solo blocco per ogni round, anche se il network è diviso, nonostante la durata dell’attacco. Può essere sempre accettato uno solo blocco.

Inoltre Algorand, come visto nel paragrafo precedente, possiede una Recovery Mode, che si attiva quando i nodi non vedono progressi nel raggiungimento del consenso dopo un certo lasso di tempo.

Quando sono in Recovery Mode, i nodi si scambiano dei messaggi particolari, visti in precedenza, che permettono di scegliere in che modo agire.

Nonappena la rete torna operativa, i nodi si riallineano e si riprende con la creazione dei blocchi, permettendo una recupero praticamente istantaneo dall’attacco.

10- Mining vs Staking vs Rewards

Un’ultima questione da affrontare è quella relativa alle ricompense di Algorand.

Come spiegato nell’overview, dal 2019 al 2022 Algorand prevede delle ricompense di partecipazione che si ottengono solo per il fatto di possedere degli Algo in un proprio indirizzo.

Può ricordare le ricompense ottenute dai miners in PoW o quelle ottenute con lo stake di PoS.

Nel caso di PoW la ricompensa è giustificata dal fatto che viene richiesta ai miners un’elevata potenza di calcolo messa a disposizione per la risoluzione dei quiz crittografici. Ciò comporta un consistente consumo energetico e quindi un costo da parte dei miners, che vengono dunque ricompensati, quando riescono a vincere un blocco, con delle ricompense.

Allo stesso modo in PoS, mettendo in staking una parte del proprio patrimonio, si ha lo svantaggio di non poter usare quei soldi fin quando rimangono in staking.

Inoltre ci si espone al rischio di poterli perdere, in caso di comportamenti scorretti.

Nel caso di Algorand e di PPoS invece, le ricompense sono completamente svincolate dal processo di creazione dei blocchi, nonostante vengano distribuite a ogni round, proporzionalmente alle quantità di Algo possedute dai vari account.

Infatti, il costo computazionale per la creazione di un blocco in Algorand è quasi nullo e si può tranquillamente installare un nodo in un normale laptop, tenendolo attivo in background mentre si eseguono altre operazioni.

Dato che il costo computazionale è irrisorio, non necessita di una retribuzione, come avviene invece nel caso di PoW.

Allo stesso modo, è una forma pura di Stake, quindi non bisogna vincolare una parte dei propri soldi per partecipare al processo di consenso, basta possederli e li si può utilizzare in qualsiasi momento.

Anche in questo caso quindi non sarebbe giustificata una retribuzione, perché di fatto non si rischia nulla.

In Algorand dunque, le ricompense di partecipazione (che, come spiegato in questa lezione, verranno sostituite nel 2022 dalle ricompense per la governance) servono essenzialmente ad attrarre nuovi utenti ea distribuire gradualmente la supply di Algo che è stata mintata nel primo blocco (10 mld).

Bibliografia e sitografia

• Algorand, Silvio Micali, Jing Chen
• Algorand: Scaling Byzantine Agreements for Cryptocurrencies, Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, Nickolai Zeldovich
• Algorand: A secure and efficient distributed ledger, Jing Chen, Silvio Micali
• Algorand Agreement: Super Fast and Partition Resilient Byzantine Agreement, Jing Chen, Sergey Gorbunov, Silvio Micali, Georgios Vlachos
• Algorand Protocol Overview
• https://www.algorand.com/technology/security
• https://www.algorand.com/technology/faq
• https://www.algorand.com/technology/core-blockchain-innovation
• https://www.algorand.com/technology/protocol-overview
• https://www.algorand.com/technology/pure-proof-of-stake
• https://www.algorand.com/resources/blog/proof-of-stake-vs-pure-proof-of-stake-consensus
• https://www.algorand.com/resources/algorand-announcements/secure-blockchain-decentralization-via-committees
• https://www.algorand.com/technology/algorand-protocol
• https://developer.algorand.org/docs/run-a-node/participate/generate_keys/
• https://developer.algorand.org/docs/clis/goal/account/addpartkey/
• https://developer.algorand.org/docs/get-details/algorand_consensus/#verifiable-random-function
• https://developer.algorand.org/docs/clis/goal/account/addpartkey/
• https://developer.algorand.org/docs/get-details/transactions/#register-account-online
• https://developer.algorand.org/docs/run-a-node/participate/
• https://developer.algorand.org/docs/get-details/algorand_consensus/#participation-keys