Sicurezza dei Dati - parte Blockchain

IL CONSENSO NELLA BLOCKCHAIN

L'obiettivo del protocollo di consenso nelle blockchain è di garantire che tutti i nodi partecipanti concordino sulla storia comune delle transazioni nella rete.

• Termination: Da ogni nodo onesto, una nuova transazione è sia scartata o accettata nella blockchain, all'interno del contenuto di un blocco.
• Agreement: Ogni nuova transazione e il suo blocco che la contiene deve essere sia scartata o accettata da tutti i nodi onesti. Un blocco accettato deve avere lo stesso numero di sequenza per ogni nodo onesto.
• Validity: Se ogni nodo riceve uno stesso blocco/transazione valida, esso deve essere accettato nella blockchain.
• Integrity: Per ogni nodo onesto, tutte le transazioni accettate devono essere consistenti tra loro, senza double spending. Tutti i blocchi accettati devono essere correttamente generati e collegati con hash in ordine cronologico.

Termination e validity sono simili a quanto visto nel classico consenso.

siccome rappresentano la liveness del sistema. Agreement e integrity sono simili a quanto visto nel classico consenso, siccome rappresentano la safety del sistema. Il teorema CAP (pag 12) si applica anche in blockchain. Nelle reali implementazioni di blockchain, non è mai possibile ottenere sia Consistenza che Availability, perché devono affrontare la tolleranza alle partizioni.

Nei sistemi permissionless in un gruppo aperto di nodi scelgono di privilegiare di garantire l'availability anziché la consistency, per poter essere in grado di utilizzare/inviare/ricevere criptovalute. I casi di fork rappresentano i momenti in cui l'inconsistenza è risolta nel tempo, così da garantire l'Eventual Consistency.

Nei sistemi permissioned in un gruppo chiuso di nodi scelgono di privilegiare di garantire la Consistency anziché l'Availability, perché non sono focalizzate su criptovalute ma la gestione di dati in ambito distribuito.

• Come vengono selezionati i partecipanti al consenso.
• Come viene realizzato il processo di raggiungimento del consenso.
• Come sono strutturati i dati nella blockchain.

1. La proposta di un blocco: generazione di blocchi e associazione di prove;
2. La propagazione di informazioni: disseminazione di blocchi e transazioni nella rete;
3. La validazione di blocchi: controllo dei blocchi per la generazione di prove e verifica dellavalidità delle transazioni.
4. La finalizzazione dei blocchi: raggiungimento del consenso sull'accettazione di blocchi validati.
5. Il meccanismo di incentivazione: promozione di partecipanti onesti e creazione di token di rete.

1. Tutti i server iniziano con lo stesso stato iniziale;
2. La primitiva di comunicazione è

Il Total-order broadcast: tutti i server ricevono la stessa sequenza di richieste secondo l'ordine di generazione dai client;

Tutti i server che ricevono la stessa richiesta emetteranno gli stessi risultati di esecuzione e termineranno nello stesso stato.

SMR è spesso realizzato in maniera leader-based (altri server sono repliche che ricevono le richieste e aggiornano il proprio stato), con un server primario che riceve le richieste dai client e inizia la procedura di broadcast, mentre gli altri ricevono le stesse richieste e aggiornano il proprio stato locale in modo che corrisponda a quello del leader.

L'algoritmo di Paxos è uno schema SRM progettato per garantire il consenso tollerante a guasti di tipo crash.

1. Il client è un learner e il leader tra i server è un proposer, mentre le repliche sono degli acceptors. Il client richiede il consenso su un singolo valore.
2. Il proposer propaga la richiesta agli acceptors, che si scambiano informazioni. Dopo

essersi aggiornati allostesso stato, tutti i server eseguono la richiesta, che lainviano al client.

3. Il client riceve i risultati dagli acceptors e formula l’esito a maggioranza. Quando il leaderè indisponibile per crash, le repliche ne eleggono uno nuovo.

Questo algoritmo tollera f crash dei server il cui numero N è maggiore o uguale 2f+1, ma nontollera guasti bizantini. Un algoritmo che tollera invece i guasti bizantini è il PBFT (PracticalByzantine Fault Tolerance). Il leader è scelto per ogni round dell’algoritmo. I nodi sono ordinatiin base al proprio identificativo , il leader il nodo i=v mod N, v = vista, N = numero server.

1. Tutti i risultati inviati al client devono essere uguali, altrimenti il client decide amaggioranza. Il client invia una richiesta al nodo primario (leader), che la trasmette atutti i nodi secondari (backup) assegnando un numero di sequenza alla richiesta.

2. I nodi secondari e il leader si accordano

1. La generazione di blocchi richiede una Proof-of-Work mediante la risoluzione di un puzzle crittografico con un determinato grado di difficoltà tale da mantenere un intervallo di generazione e un grado di protezione adatti.
2. Viene utilizzato il gossiping.
3. Un blocco o transazione deve essere validata prima di essere inviata in broadcast agli altri nodi collegati alla coda di una catena locale. La validità si realizza evitando il double spending o controllando la PoW allegata al blocco.
4. La catena più lunga rappresenta il raggiungimento del consenso in caso di disaccordo (che ha causato la fork).
5. Chi ha generato un blocco accettato con successo può ottenere un reward o premio.

Il consenso di Nakamoto è caratterizzato dalla tolleranza ai guasti, espressa in termini di percentuale di potenza di hashing avversaria tollerabile. Finché meno del 50% della potenza di hashing totale è controllata in modo malizioso, i blocchi prodotti dai miners onesti vengono propagati tempestivamente e la catena principale è quella della maggioranza onesta che eventualmente supera qualsiasi ramo malizioso.

Nel consenso del BFT classico, se più di 1/3 della popolazione è maliziosa, i nodi onesti finiranno per decidere valori contrastanti, portando al fallimento del consenso. Nel consenso di Nakamoto, tuttavia, le decisioni contrastanti sono temporaneamente consentite sotto forma di fork della blockchain, a condizione che alla fine verranno eliminate dal continuo sforzo della maggioranza onesta.

Il consenso di Nakamoto presenta alcune limitazioni, principalmente è particolarmente lento, ci vogliono 10 minuti tra la generazione di blocchi, diminuendo il throughput.

• Attacco Eclisse: Se un potente attacco riesce a dominare la comunicazione in entrata/uscita tra un miner vittima e la rete principale, allora la vittima non sarà più in grado di contribuire all'estensione della catena principale. L'attacco eclisse sfrutta la connettività debole, per risolvere bisogna aumentare la connettività e la diversità geografica delle connessioni peer-to-peer.
• Selfish Mining: Un gruppo di miners maligni non pubblicizza i blocchi ma li tiene segreti. Gli altri miners estendono la catena con blocchi validi. Il miner egoista continua a estendere il suo ramo segreto fino a quando la catena pubblica è ad un passo indietro e pubblica la sua. Poiché la catena segreta

Le transazioni validate. Il DPoS (delegate proof of stake) consente ai nodi che detengono lo stake maggiore, stakeholders, di votare per eleggere i verificatori di blocchi. Questo fa si che i detentori di stake concedono il diritto di creare blocchi ai delegati che sostengono invece di creare blocchi stessi, riducendo così il loro consumo di potenza computazionale a 0. PoS ha lo svantaggio di accentrare le ricchezze nelle mani di pochi e nel caso di una fork i validatori saranno incentivati a operare su entrambe le catene. PoS e DPoS sono stati applicati nel contesto di classici algoritmi BFT al fine di consentirne l'applicazione in contesti open e permissionless. Un algoritmo PBFT che utilizza PoS è Tendermint. Ogni nuovo blocco viene validato o meno in una iterazione dell'algoritmo, che si compone in più round per poter giungere a consenso. Si tratta di un consenso di tipo CP, dove la consistenza viene fortemente garantita. Non tutti i validatori avranno lo

stesso peso, infat