Tolleranza ai guasti bizantina nella blockchain

Negli ultimi decenni, l'industria delle criptovalute è cresciuta in modo significativo. Nuovi progetti appaiono costantemente, costringendo gli sviluppatori a trovare nuovi modi per risolvere i problemi esistenti nel settore. Un termine abbastanza comune è il meccanismo di consenso BFT. BFT è l'acronimo di Byzantine Fault Tolerance ed è considerato tale problema teorico dei sistemi informatici, con cui i creatori hanno dovuto fare i conti molto prima della comparsa di Bitcoin.

Tuttavia, molti sviluppatori di protocolli basati su blockchain stanno affrontando problemi con la tolleranza ai guasti bizantina, quindi diamo un'occhiata alla natura del problema e alle implicazioni che dobbiamo affrontare quando si presenta questo problema.

Il problema della tolleranza ai guasti bizantina

Problema La tolleranza ai guasti bizantina è una delle situazioni teoriche più frequentemente considerate quando si discutono le sfumature del consenso. Questo problema è stato riconosciuto per la prima volta come esistente nello studio "Major Problems of Byzantine Failure" di Leslie Lappport, Robert Szostak e Marshall Pease, apparso nel 1982.

Lo studio ha rilevato:

Un sistema informatico affidabile deve far fronte al guasto di uno o più componenti. Un componente guasto può comportarsi in un modo spesso trascurato, ovvero inviare informazioni contrastanti a diverse parti del sistema. Il problema di risolvere questo tipo di guasto è chiamato in astratto "Problema generale della tolleranza ai guasti bizantina".

Il nome deriva dall'analogia presentata nello studio.

Più precisamente, gli autori descrivono una situazione teorica in cui diverse unità dell'esercito bizantino erano di stanza fuori dalla città nemica. Ogni distaccamento aveva il suo comandante e ogni distaccamento era in un campo separato. I comandanti dovevano escogitare un piano di azione congiunta (avanzata o ritirata), ma potevano comunicare solo tramite messaggeri. D'altra parte, potrebbero esserci traditori tra i generali che potrebbero impedire ai generali leali di raggiungere un comune denominatore (consenso).

Pertanto, i generali dovevano trovare un modo per garantire che:

• tutti i generali leali seguono lo stesso piano d'azione,
• un piccolo manipolo di traditori non potrà impedire ai generali di adottare il piano giusto.

Quindi stiamo parlando di un sistema che può risolvere il problema sopra descritto e si chiama Soluzione di tolleranza ai guasti bizantina (BFS). Ecco da dove viene l'algoritmo di consenso BFT. Nel complesso, la soluzione Byzantine Fault Tolerance previene arresti anomali del sistema dovuti a partecipanti inaffidabili (non validi).

Risolvere il problema dei generali bizantini

Per risolvere il problema dei generali bizantini e creare una soluzione di tolleranza ai guasti bizantini (FTS), la maggior parte dei generali deve utilizzare la stessa strategia. Ciò si ottiene in modi diversi a seconda della natura del sistema e del suo scopo. Nella blockchain, due meccanismi, proof-of-stake e proof-of-work, possono anche raggiungere un consenso su una soluzione di emergenza bizantina utilizzando approcci diversi.

La maggior parte delle blockchain proof-of-stake può funzionare quando un terzo dei suoi nodi esistenti fallirà, dando libero sfogo alla regola "3f+1", dove F i si riferisce al numero di nodi non funzionanti. La formula stessa calcola il numero di nodi che devono essere presenti nel sistema affinché funzioni correttamente.

Ad esempio, per soddisfare la regola (3f+1), in un sistema con 4 nodi, tre nodi devono essere completamente funzionanti.

Come può la blockchain risolvere questo problema?

La tecnologia basata sulla blockchain avrebbe diversi modi per risolvere il problema dei generali bizantini. L'unica differenza è l'algoritmo di consenso necessario e il modo in cui viene applicato il BFTS. Diverse soluzioni possono essere trovate sia sul lato proof-of-work che sul lato proof-of-stake.

È interessante notare che Satoshi Nakamoto non ha menzionato il "problema dei generali bizantini" nel whitepaper bitcoin originale. Tuttavia, dopo il lancio della rete Bitcoin, l'ignoto creatore della prima criptovaluta ha proposto una soluzione al suddetto problema utilizzando un consenso "prova di lavoro". Satoshi ha creato un modo per utilizzare la sicurezza crittografica e la crittografia a chiave pubblica su una rete digitale. Per evitare perdite di dati, la sicurezza crittografica utilizza l'hashing e l'identità dell'utente della rete viene verificata utilizzando una chiave pubblica.

Le transazioni vengono catturate in blocchi che sono collegati al resto a scapito dell'hashing e sono protetti crittograficamente. Va anche notato che la blockchain utilizza un albero Merkle per verificare gli hash provenienti dal blocco principale. Tutti il blocco proveniente dal blocco di genesi è valido. Questi blocchi vengono verificati dai minatori che risolvono enigmi crittografici in una competizione per la creazione di blocchi di consenso.

Bitcoin ha stabilito un insieme di regole chiare e definitivamente obiettive che la blockchain deve seguire per superare il problema dei generali bizantini. Un partecipante alla rete deve pubblicare una prova di lavoro per aggiungere informazioni alla blockchain (da qui prova di lavoro). Ciò è costoso per il partecipante e lo scoraggia dal condividere informazioni false in quanto verrà confutato da altri partecipanti alla rete.

Tutte le regole sono chiare e obiettive, il che significa che le informazioni non possono essere modificate.

E la prova di partecipazione?

Le reti governate dall'algoritmo di consenso proof-of-stake non si basano sul mining, ma sullo staking. Per diventare un validatore di rete, un utente deve prima depositare fondi nel sistema. Coloro che detengono una quota maggiore possono anche impegnare più blocchi e ricevere ricompense maggiori. Coloro che cercano di falsificare le informazioni rischiano di perdere la posta in gioco.

Diversi sistemi affrontano questo problema in modi diversi. Ad esempio, Ethereum 2.0 utilizza l'algoritmo di Casper. Lo richiede almeno due terzi della maggioranza dei nodi hanno accettato un dato bloccoprima che venga creato e aggiunto alla rete.

Ci sono diversi tentativi per risolvere il problema a seconda della necessità del sistema e dell'approccio del team. Ad esempio, con la prova di partecipazione delegata (dPoS), il consenso viene raggiunto molto più rapidamente. D'altra parte, alcuni sistemi utilizzano nella pratica la tolleranza ai guasti bizantina.