Una blockchain può essere pensata come un tipo di architettura informatica distribuita. In questa architettura, diversi nodi comunicano tra loro passando messaggi.
Non c’è un nodo centrale il cui fallimento causerebbe il fallimento dell’intero sistema. Il successo di questo tipo di sistema si basa sul fatto che tutti i nodi seguono coerentemente certe regole quando si passano i messaggi: ogni messaggio inviato deve essere ricevuto da ogni nodo e ogni messaggio può essere inviato solo una volta ad ogni dato nodo (questo implica che non ci dovrebbero essere loop nella rete).
I nodi che partecipano a questo tipo di rete potrebbero non fidarsi l’uno dell’altro o avere un obiettivo comune. Come tale, non c’è garanzia che ogni partecipante segua effettivamente queste regole a meno che non abbia qualche modo di farli rispettare.
Altrimenti, il sistema sarebbe aperto a certi tipi di attacchi che potrebbero renderlo inutilizzabile o almeno imprevedibile (questo è simile a una rete elettrica dove ogni casa è cablata in parallelo ma non ha una scatola di fusibili che coordina contro i sovraccarichi).
L’architettura blockchain fornisce un modo per risolvere questo problema, basato sul concetto di incentivi. L’idea è semplice: premiando il buon comportamento e punendo il cattivo comportamento, ogni nodo è incentivato a seguire le regole. In termini più pratici, questo significa che se un nodo provasse a inviare due messaggi diversi dicendo due cose diverse allo stesso tempo, gli altri nodi lo vedrebbero come un comportamento sospetto o addirittura malevolo.
Questo può funzionare perché tutti i nodi sono collegati tra loro e gli aggiornamenti si muovono rapidamente attraverso la rete .
Come semplice esempio, immaginiamo una rete con tre nodi: A, B e C.
La prima regola è che ogni nodo dovrebbe accettare solo l’aggiornamento più recente da qualsiasi altro nodo. Diciamo che Alice invia l’aggiornamento X a Bob e Bob invia l’aggiornamento Y a Charlie. Se questo accade, Charlie non riceverà entrambi gli aggiornamenti allo stesso tempo perché sono in conflitto tra loro (in realtà ci sarebbero più di due nodi che inviano messaggi ma per ora assumiamo che siano solo questi due).
Per prendere la sua decisione, Charlie guarderà quale di questi aggiornamenti ha più supporto in base a ciò che gli altri membri della rete hanno ricevuto: se ha ricevuto l’aggiornamento Y per primo allora sa che Bob ha ricevuto l’aggiornamento X prima di ricevere l’aggiornamento Y quindi dovrebbe ignorare l’aggiornamento X.
La rete può gestire un’altra regola in questo modo: poiché Charlie sa che Bob ha ricevuto l’aggiornamento Y, se più tardi Alice invia un aggiornamento che dice qualcosa di diverso deve essere il caso che o Bob non ha ricevuto l’aggiornamento originale o sta cercando di sovrascrivere quello che ha inviato originariamente. In altre parole, quando un nodo riceve aggiornamenti da più fonti che sono in conflitto tra loro, sceglierà il messaggio che è stato inviato dal maggior numero di nodi (la probabilità è dalla loro parte).
Diciamo che Alice invia un altro aggiornamento Z ma Charlie lo riceve solo dopo aver aggiornato il suo stato attuale con Y e X . Questo significa che non lo accetterà perché ci sono già due messaggi contrastanti su ciò che è successo nello stesso momento.
L’architettura della rete blockchain implementa questo tipo di comportamento in un modo intelligente che rende facile supportare questo tipo di regole. Le regole sono applicate transazione per transazione, ognuna delle quali viene trattata individualmente. Questo è chiamato l’ambiente del tempo di transazione.
Le transazioni sono raggruppate in blocchi e tutti i nodi della rete cercano di aggiungerli alla loro copia pubblica della catena (vedi [transazioni] ).
I blocchi hanno una parte di intestazione che contiene alcuni dati utili come: chi li ha creati, quali transazioni contengono e a che ora sono stati creati. Hanno anche una seconda parte chiamata “hash puzzle” che è risolta dai minatori usando prove ed errori basati su alcune restrizioni incorporate (vedi [mining] ).
Per prevenire i conflitti di blocco, c’è un regola che tutte le intestazioni dei blocchi devono essere diverse l’una dall’altra perché non possono contenere gli stessi dati. La regola stabilisce anche una differenza massima consentita per la marca temporale usata in ogni blocco per evitare che due nodi creino un blocco esattamente nello stesso momento per caso (vedi [mining] ).
L’effetto combinato di queste regole è che ogni nodo accetterà solo la versione più recente della catena, e questa catena non includerà blocchi con transazioni in conflitto. Quindi le transazioni vengono processate una per una ed è impossibile per qualsiasi nodo accettare due diversi aggiornamenti validi per la stessa cosa che accade nello stesso momento.
Come si risolve il problema di Brad?
Se qualcuno cerca di barare, i partecipanti alla rete possono automaticamente vedere che la loro copia della blockchain è stata cambiata e rifiutare la versione fraudolenta. Ma cosa succede se qualcuno cerca di cambiare segretamente una transazione avvenuta in passato?
Le persone potrebbero non notarlo immediatamente, ma non appena vorranno aggiungere una nuova transazione che dipende da quella che hanno appena cancellato, avranno un problema perché questa transazione non esiste più. Avrebbero bisogno di creare un blocco completamente nuovo da zero e se qualcun altro crea un altro blocco basato sulla loro copia originale della catena (che ora è diversa), entrambi i blocchi possono essere aggiunti creando due catene diverse: una con il tuo cambiamento segreto e una senza.
La persona che rende pubbliche le sue modifiche per prima vincerà e le applicazioni di tutti gli altri inizieranno automaticamente ad usare la loro blockchain invece di quelle precedenti.
Ci sono altri possibili scenari come cercare di rimuovere una transazione cambiando tutti i blocchi che vengono dopo di essa. Ancora una volta, i partecipanti alla rete lo noteranno perché le loro copie della blockchain saranno diverse da quelle di tutti gli altri e potranno rifiutare la versione fraudolenta (vedi [consensus] ).
L’ultimo tipo di problema è quando qualcuno cerca di impedire alle altre persone di completare un blocco inviando loro transazioni non valide che non dovrebbero accettare in nessun caso.
Per esempio, se qualcuno invia una richiesta che impedisce alle transazioni esistenti di essere elaborate o rimanda monete a se stessi senza autorizzazione (noto come doppia spesa), ci sono regole speciali costruite nel protocollo che assicurano che queste operazioni falliscano indipendentemente dalla potenza di calcolo utilizzata: “L’attaccante può spendere tutto il suo budget per coniare blocchi, ma ogni blocco può fare riferimento solo a due blocchi precedenti. A questo punto l’attaccante smette di creare nuovi blocchi perché non può creare una catena più lunga (vedi [hash crittografico] ).
Anche se riesce a creare temporaneamente una catena più lunga riutilizzando uno dei suoi blocchi precedenti, tutti gli altri noteranno immediatamente che qualcosa è andato storto e le loro applicazioni useranno automaticamente un altro ramo. Ma se anche un solo blocco viene aggiunto dopo l’attacco, sarà considerato valido e questa versione della storia con queste modifiche rimarrà intatta” (vedi [consensus] ).
Per garantire che i partecipanti alla rete siano d’accordo su quali transazioni sono state accettate nella blockchain in un dato momento, ci sono regole speciali su come i nodi comunicano tra loro e condividono le informazioni. Per esempio, tutti i nodi hanno esattamente le stesse copie transazioni che tutti gli altri nodi hanno, e ogni nodo può vedere se manca qualcosa nella propria copia (vedi [transazioni] ).
I nodi si contattano anche regolarmente per formare un consenso su quale versione della blockchain è stata più estesa. Se ci sono differenze tra queste versioni, usano funzioni hash crittografiche per scoprire quale sia il ramo più lungo in un dato momento. Tutti i nodi inizieranno automaticamente ad usare questo ramo per aggiungere nuovi blocchi (vedi [blockchain] ).
Inoltre, i partecipanti alla rete non hanno bisogno di conoscersi l’un l’altro o di fidarsi l’uno dell’altro perché questo sistema funzioni. Ogni nodo può scegliere con chi vuole connettersi e con quanti peer vuole stabilire connessioni a seconda della sua potenza di calcolo, disponibilità di banda e posizione geografica. I partecipanti possono anche cambiare questi parametri dinamicamente per riflettere la loro attuale potenza di calcolo e disponibilità (vedi [network] ).
Ciao, io sono Marco!
Sono un appassionato di informatica e tecnologia. Su questo blog condivido recensioni, guide e approfondimenti sul mondo del tech, web, internet, privacy e molto altro.
