In questo articolo/analisi, gentilmente offertoci da Lorenzo Negri di CriptOnIt, azienda di Parma specializzata nello studio e sviluppo di soluzioni blockchain per applicazioni business, verrà effettuata un'analisi sui possibili rischi degli attacchi centellinanti negli stake di una blockchain caratterizzata da un meccanismo di consenso di tipo Proof of Stake.
Per prima, cosa, cerchiamo di descrivere il funzionamento di un attacco ad una Blockchain (PoS) senza una protezione dei checkpoints.
Cosa sono i checkpoints?
Avete presente nei videogiochi (stile Crash Bandicoot) quando durante una missione raggiungevate un checkpoint che, qualora più avanti nel percorso foste incorsi nel perdere sfortunatamente una vita, vi garantiva di poter ricominciare a giocare dall’ultimo checkpoint raggiunto e non quindi dall’inizio della missione?
Ecco, allo stesso modo esistono anche nelle Blockchain checkpoints similari che in sostanza proteggono il network da un attacco, in quanto risulterebbe impossibile invertire le transazioni inserite prima di un determinato punto scelto. Una sorta di scudo retroattivo.
I checkpoints sono “hard coded” direttamente dentro lo standard client. Il concetto è quindi quello di accettare solo ed unicamente transazioni dopo un determinato checkpoint, rendendole valide ed irreversibili. Se chiunque cercasse di effettuare per esempio un fork partendo da un blocco antecedente all’ultimo checkpoint, il client non accetterebbe il fork. Nel termine specifico si intende quindi che i blocchi sono stati “set in stone”, in maniera irreversibile.
Come è facile intendere, i checkpoint sono dunque un potente scudo contro gli attacchi, ma al tempo stesso rappresentano una possibile barriera architettonica, rendendo quindi questo strumento un’arma utilizzata dai developers molto al contagocce. Difatti la dipendenza dai checkpoints nel fattore sicurezza sta sempre più scemando e sono ormai utilizzati solo in casi veramente specifici. C’è persino chi sostiene che la rimozione più che totale dei checkpoints sia un “long-term goal” in quanto siano unitamente causa di confusione e centralizzazione del potere nelle mani dei developers.
E’ inconfutabile però come l’utilizzo dei checkpoints rimanga essenziale nella prevenzione degli attacchi come quelli che andremo a spiegare adesso, non avendo (ancora) alternative disponibili.
Discutiamo quindi della ampia categoria degli attacchi a lungo termine, e del rischio di tali attacchi che incrementa proporzionalmente con l’aumentare del numero di “honest transactions”, potendo essere un attacco lanciato quindi da chiunque controlli una qualsiasi frazione di stake. Ciò dimostra come le transaction fees ed i reward siano strettamente correlati alle proprietà di sicurezza di un protocollo PoS.
Sappiamo tutti che il Proof of Stake è visto come una soluzione all’immenso consumo energetico dovuto ai minatori del classico Proof of Work, ed, ultimamente, anche come una possibile soluzione (se specificamente adattato) al problema della scalabilità.
Uno dei problemi più discussi - persino da Buterin - del PoS è proprio la vulnerabilità agli attacchi a lungo termine. Consiste cioè nell’abilità di un “minority set of stackholders” di eseguire la blockchain partendo dal blocco genesi (o qualsiasi specifico punto di partenza) e produrre una storia alternativa del sistema. In sostanza un attacco da parte di un “minority set of stackholders” potrebbe manipolare il sistema con un double-spend o cancellando transazioni passate.
E’ stato osservato che vi è una differenza sostanziale tra le blockchain sostenute dai “minority set of stackholders” e quelle invece sorrette dalle “honest majority”, dimostrazione per cui una “longest chain rule” favorirebbe in ogni momento le blockchain sorrette dalle “parti oneste”.
In questo caso specifico dividiamo così i protocolli PoS:
- Eventual-consensus: quei protocolli che applicano solo in parte la “longest chain rule” alla blockchain. In questo caso l’immutabilità dei blocchi aumenta proporzionalmente con il numero dei blocchi generati in seguito;
- Blockwise-BA: protocollo capace invece di raggiungere l’immutabilità dei singoli blocchi attraverso una completa esecuzione di un “Byzantine Agreement protocol” (BA) prima di generare in seguito qualsiasi altro blocco.
Per corrompere le chiavi private in un punto qualsiasi del passato c’è da tenere a mente che alcuni account che prima avevano una grossa forza di stake hanno poi nel presente uno stake piccolo o persino uguale a zero. Questo espone le chiavi private ad un alto rischio di attacco, offrendo la possibilità di imbastire un attacco a lungo termine, in quanto la densità della blockchain in quesitone nel tempo rimarrebbe indistinguibile dalla controparte onesta.
Esistono diverse forme di tutela ai problemi menzionati prima. Riassumiamo i tre tipi principali, sempre nell’ambito di uno studio sulle Blockchain PoS:
- Checkpointing Mechanism: di cui abbiamo già discusso in precedenza;
- Key-Evolving Cryptogaphy: una tutela algoritmica capace di evolvere la complessità delle chiavi private, in cui viene dato ai nodi stessi il potere di cancellare i dati privati;
- Strict Chain Density Statistics: ovvero rendere noto in ogni momento il numero esatto di partecipanti al protocollo. Ciò però crea dei vincoli non da poco, in quanto il sistema non sarà poi in grado di operare in un ambiente che permette di invocare un arbitrario numero di parti per l’esecuzione della transazione.
Il metodo di tutela Key-Evoving Cryptography è sufficiente a prevenire tutti i possibili attacchi a lungo termine?La risposta è negativa, in quanto esistono una nuova tipologia di attacchi a lungo termine contro gli eventual-consensus Proof of Stake, chiamati Attacchi Centellinanti agli Stake.
Gli Attacchi Centellinanti agli Stake rispecchiano un'ottima strategia per rinforzare quegli attacchi a lungo termine che non possono fare affidamento su una “posterior corruption”.
L’idea che sta alla base di un Attacco Centellinante agli Stake è che una coalizione di stakeholders di minoranza che vogliono lanciare un attacco a lungo termine includa tutte le transazioni della parte “onesta” della blockchain alla propria copia parallela privata. Dopodiché verranno raccolte dalla coalizione “malvagia” un certo numero di transaction fees nella blockchain privata dell’attacco ed, assumendo che sia attiva da un certo periodo di tempo (torniamo in seguito a definire quanto occorra), è concepibile che le fees maturate durante questo tempo trasformino la coalizione d’attacco da minoranza a maggioranza, rendendo la blockchain privata dell’attacco più veloce di quella pubblica. Ciò avviene quindi attaccando un punto scelto nel passato, riscrivendo poi la storia delle transazioni dal lì in poi.
Il limite di tempo teorico per lanciare un attacco di questo tipo è studiato in:
Dove αA è lo stake relativo della coalizione di minoranza e f le fee disponibili per unità di tempo.≅ (2 - 4αA) / f
Gli Attacchi Centellinanti agli Stake, come detto prima, partono da blockchain private usate per l’attacco, che inizialmente hanno una densità di blocchi molto sparsa e che gradualmente andrà però ad incrementare.
Un possibile meccanismo di tutela, consiste nell'introdurre dei context in ogni transazione.
Un context-sensitive è una transazione che semplicemente include gli hash della blockchain in un certo punto precedente. Questo tipo di transazioni non possono essere trasferite ad altre blockchain private detenute dagli stakeolders “maligni”. Questo tipo di tutela in realtà, è stata ideata per prevenire la possibilità di trasferire delle “coin-age-destroyed” ad altre blockchain segrete, ma risulta comunque utile anche nel nostro caso.
Gli Attacchi Centellinanti agli Stake permettono poi a chi attacca di non avere bisogno di controllare lo stato delle transazioni, di non essere vincolati a delle “dynamic corruptions” e soprattutto non hanno bisogno di introdurre nuove parti oneste, o disattivarne di pre-esistenti.
Con il termine “pure longest chain rule” si intende una sezione specifica della blockchain che considera la sua lunghezza unico criterio “sine qua non”. Tutto questo ovviamente per i protocolli Proof of Stake conosciuti finora, senza l'uso dei checkpoints.
Vediamo ora un esempio di attacco suggerito da Aggelos Kiayias dell'University of Edinbourgh & IOHK.
Nell’esempio in questione abbiamo riportato uno stake αA <1/2 dove chi attacca (A) simula un protocollo onesto e mantiene una copia della blockchain attuale (C), creando una blockchain alternativa (C') inizialmente vuota e che sarà tenuta nascosta dalla parte onesta.
Facciamo quindi ora un riassunto dei requisiti per un Attacco Centellinante agli Stake:
- No Checkpoints;
- Proof of Stake;
- Context Transactions;
- Validity of low growth chains: i protocolli PoS supportano gli “sleepy majority”, necessari per essere sicuri che la blockchain (C') sia considerata valida.
Da quanto detto finora, uno dei modi naturali per tutelarsi da attacchi come questi è quello di modificare le regole interne dei Proof of Stake, violando quindi uno solo dei requisiti necessari all’attacco, che però azzera ogni rischio.
Discutiamo quindi dei due tipi possibili di tutela algoritmica in questi casi:
- Minimum Chain Density in the Time-Domain: ritorniamo a discutere del periodo iniziale di una blockchain dove la sua densità è molto sparsa e poco concentrata e rimangono quindi un certo numeri di “slots” vuoti senza i blocchi corrispondenti. Questo consente al protocollo di individuare ed estirpare blockchain sospette rispetto a quella onesta, riconosciuta da questa differenza di “vuoti”;
- Contex Sensitive Transactions: fondamento principale di un Attacco Centellinante agli Stake è portare una transazione “out of context”, ovvero includendo gli hash del blocco più recente in ogni transazione interna. Così facendo non sarebbe possibile avere dei “centellinamenti” degli honest stake in nessuna blockchain privata. Questo risolve anche il problema del rischio di attacchi in relazione ad ipotetici fork per raccogliere le transaction fees emesse negli ultimi blocchi dalle parti oneste.
Dato l'attuale profilo statistico delle criptovalute, non sono quindi di immediata preoccupazione. Ciononostante, indicano una considerazione progettuale importante dal punto di vista della prospettiva crittografica, mostrando come sia possibile costruire un attacco a lungo termine senza fare affidamento a corruzioni posteriori.
Da ciò è anche facilmente deducibile che anche se la crittografia è in grado di evolversi, di per sé non è una tutela sufficiente contro gli attacchi a lungo termine ed è importante studiare ulteriori attenuazioni algoritmiche per ostacolare questi attacchi, senza il ricorso ai checkpoints o ad altre assunzioni limitanti il modello.
[sc name="firma"]
Fonti:
Peter Gazi [IOHK]
Aggelos Kiayias [University of Edinbourgh & IOHK]
Alexander Russel [University of Connecticut]
Posted from my blog with SteemPress : https://www.cryptominando.it/2018/07/12/attacchi-centellinanti-agli-stake-blockchain-proof-of-stake/