Cosa rende Bitcoin così sicuro?

Per una timechain a prova di apolicasse Zombie

Blockchain Trilemma

Breve premessa. L’utilizzo del termine blockchain per definire la base architetturale del Protocollo Bitcoin è fin troppo generico e fuorviante. La catena di blocchi e di transazioni contenute in essi costituisce un registro di eventi immutabile nel tempo: una linea temporale ben definita e scolpita e dunque una timechain. Non si tratta di un concetto estremista o massimalista, che dir si voglia, ma solo di comprensione e competenza sul/del Protocollo.

Detto questo, il concetto di blockchain trilemma prende in considerazione tre elementi chiave:

• Scalabilità
• Decentralizzazione
• Sicurezza

Tutti e tre insieme non è possibile averli: per limiti tecnici e funzionali né va sacrificato uno.

Bitcoin ha preferito “sacrificare” la scalabilità per massimizzare decentralizzazione e sicurezza.

Parliamoci chiaro: la blockchain come struttura dati non è poi così versatile e in chiave di una architettura distribuita e decentralizzata, per come la intendiamo, non scala.

Per consentire la scalabilità vanno prese in considerazione astrazioni di livello superiore (on top): si parla dunque spesso di L2, L3, ecc… anche se nel mondo di Bitcoin è più corretto di applicazioni funzionali di protocollo. Definire infatti, nel caso di Bitcoin, Lightining Network, o Liquid, come semplice Layer 2, sarebbe estremamente riduttivo e semplificativo: si tratta di un protocollo che poggia sulla sicurezza del Protocollo Bitcoin e della sua timechain.

Per quanto riguarda Bitcoin infatti ci si riferisce più a uno stack protocollare: LNP/BP (Lightining Network Protocol on Bitcoin Protocol).

La trattazione di questo argomento esula il post: la precedente digressione serve solo a chiarire un concetto molto spesso non pienamente compreso.

Esaminiamo dunque, qui di seguito quelli che a tutti gli effetti possono essere considerati i 7 punti cardine della sicurezza nel Protocollo.

Decentralizzazione

Il livello di decentralizzazione è in genere misurato con il “Coefficiente Nakamoto” che in soldoni indica quando facile, o difficile, sia fare un attacco al 51%. I dati raccolti dai miner, i client, i developers, gli owners ecc.. sono usati per stabilire questa misura. Più alto è il valore del coefficiente più sicurezza c’è.

Crittografia

Una forte base crittografica è essenziale per mettere “al sicuro” le transazioni sulla rete.

Bitcoin usa la crittografia a chiave asimmetrica.

Tale tecnica crittografica usa chiavi diverse per cifrare e decifrare. La chiave pubblica permette a perfetti sconosciuti, ambiente trustless, di scambiarsi dati cifrati, mentre la chiave privata di decifrare questi dati.

La chiave pubblica può essere derivata dalla privata ma non è vero il viceversa.

Meccanismo di Consenso

Il Consenso è l’elemento vitale per la sicurezza della rete.

E’ concepito in modo tale da consentire a un sistema decentralizzato con molteplici partecipanti, detti nodi, di convergere collettivamente sulla validità e l’ordine delle transazioni che andranno a far parte della timechain.

Il meccanismo di consenso utilizzato da Bitcoin è il Proof of Work (PoW) in cui sono i miner ad approvare le transazioni che entreranno a far parte dei blocchi.

Immutabilità

Al meccanismo di consenso è strettamente legato il concetto di immutabilità dei record, blocchi con transazioni, scritti sulla timechain. Più alta è la quantità di lavoro necessaria, difficulty, più sono i miner che contribuiscono al raggiungimento del consenso, hashrate, più è sicura la rete e di conseguenza immutabili i record.

Nessun ente centrale (sicurezza intrinseca della rete)

La natura decentralizzata della rete esclude intrisecamente l’esistenza di un unico point of failure il ché rende impossibile per un attaccante comprometterne l’integrità. Infatti, nel caso in cui un insieme di nodi risultasse compromesso, la timechain distribuita su una vasta rete a giro per il mondo sarebbe tutelata anche e soprattutto grazie al Consenso che eviterebbe a un attore malevole di raggiungere i propri scopi.

Sicurezza di Bitcoin Script (Smart Contract)

Script permette di creare transazioni programmate per consentire il passaggio di valore tra le parti (considerate ad esempio il caso del multisig in cui per sbloccare un output è necessario un numero di firme pari a quello stabilito dallo script di blocco). Usando gli smart contract è possibile far fuori del tutto gli intermediari è risolvere i “contenziosi” attraverso il codice.

Governance e Aggiornamenti

Sebbene immutabile e decentralizzata, la timechain può essere vista come un essere vivente che si evolve e si adatta a nuove necessità (vedi soft fork). Nulla di tutto ciò può però avvenire senza il consenso, nel senso di adozione, della maggior parte della rete e dei suoi attori. Non esiste il concetto di “one man show” e in genere chi ci prova si ritrova fra le mani un hard fork inutile (vedi bitcoin cash e la block size war).

Possibili, ma solo teoriche, insidie alla timechain

Trattandosi di un registro pubblico, i malintenzionati sono sempre dietro l’angolo…Esistono in particolar modo due tipi di attacchi che potrebbero insidiare la timechain di Bitcoin. Notiamo che si tratta di pura teoria visto che allo stato attuale di distribuzione della rete e sopratutto grazie al “potere” di Consenso raggiunto, hashrate, la probabilità che uno degli attacchi descritti possa avere successo è vicinissima allo zero.

51% attack

Si verificherebbe nel caso in cui un gruppo di miner riuscisse a racimolare il 51% percento di hashing power prendendo così il controllo della rete. Immaginatevi il costo economico di tale attacco e agli zero benifici ottenibili (leggi: compromessa una rete il valore del token diretto allo zero).

Sybil attack

In questo caso gli attaccanti andrebbero a generare molteplici identità sulla rete, nodi, cercando di saturarla e per certi versi comprometterne la credibilità. Il creare molteplici nodi potrebbe anche essere usato per attaccare la privacy degli utilizzatori della rete in particolare di chi non possiede e/o utilizza il proprio nodo come ingresso al Protocollo.

Per una timechain a prova di apolicasse Zombie

Abbiamo visto dunque che Bitcoin per sua natura “ha scelto” di dare priorità agli aspetti di decentralizzazione e sicurezza piuttosto che a quello di scalabilità (tanto mettetevi il cuor in pace che qualsiasi cosa cerchino di vendervi in giro, la blockchain non scala e se scala è qualcos’altro).

La natura fortemente decentralizzata della rete, nonché il Proof of Work, permettono di assicurare che in caso di uno degli attacchi descritti in precedenza, gli attaccanti non possano riscrivere la storia, e non si tratta di negazionismo, tanto meno svolgere attività fraudolente vista la potenza computazionale in gioco.

Altre due parole per quanta riguarda gli smart contract. In uno dei paragrafi precedenti abbiamo parlato di Script che è il linguaggio di programmazione che permette di aggiungere “della logica”, anche complessa, all’interno dello schema della transazione. Si tratta di un linguaggio limitato e proprio per questo motivo stanno venendo fuori dalla community molte proposte tra cui la più interessante pare essere allo stato attuale RGB on Lightining Network.

Introducendo questi protocolli on top oltre ad “aggiungere funzionalità” si rafforza il concetto di sicurezza di Bitcoin e soprattutto:

• più decentralizzazione perché i nodi Lightining sono nodi a se e per funzionare hanno la necessità di avere a disposizione un full node Bitcoin
• un altro livello di crittografia/cifratura per proteggere questo tipo di transazioni che “in genere” sono off-chain (lo spiegheremo in un post dedicato ma per completezza sono on-chain solo la transazione iniziale di apertura di un canale e quella di chiusura/aggiornamento dei saldi).

Tutto per dire che qualsiasi asset e i dati associati che si muovano on top al Protocollo Bitcoin ereditano un altissimo livello di sicurezza aggiungendone spesso dell’altro.

Con buona pace degli Zombie.