In questo articolo di Vitalik Buterin che ti sto proponendo in una versione semplificata e in traduzione italiana lo stesso creatore di Ethereum parla dell’importanza della decentralizzazione di Ethereum.
Ora, considera le due risposte su Quora circa la domanda “qual è la differenza tra distribuito e decentralizzato”.
La prima essenzialmente ripete come un pappagallo il diagramma che puoi vedere qui di seguito, mentre la seconda rende l’intera differenza spiegando che “distribuito significa che non tutti i processi della transazione vengono fatti nello stesso posto” e che “decentralizzato significa che non c’è una singola entità che controlla tutto il processo”.
Nelle risposte migliori che puoi trovare nello stak exchange di Ethereum si propone un diagramma molto simile, ma le parole decentralizzato e distribuito sono scambiate! Ovviamente, c’è bisogno di una spiegazione migliore.
Tre tipi di Decentralizzazione
Mentre la gente parla di decentralizzazione del software, ci sono in realtà tre tipi di centralizzazione/decentralizzazione di cui potrebbero parlare. Mentre in alcuni casi è difficile averne una senza l’altra, in generale questi tre tipi sono indipendenti l’uno dell’altro.
- (De)centralizzazione architettonica – quanti sistemi sono realizzati da computer fisici? Quanti di questi computer sono in grado di tollerare ogni singolo guasto?
- (De)centralizzazione Politica —quanti individuai o organizzazioni controllano i computer di cui è fatto il sistema?
- (De)centralizzazione Logica— l’interfaccia e le strutture dati che presenta il sistema lo rendono più simile ad un singolo oggetto monolitico, o ad uno sciame amorfo? Se si taglia il sistema a metà, inclusi i fornitori e gli utenti, le due metà continueranno ad operare a pieno come unità indipendenti?
Nota che tutti questi punti sono altamente discutibili. Ma cerchiamo di spiegarli tutti:
- Le società tradizionali sono centralizzate politicamente (un amministratore delegato), centralizzate architettonicamente (una sede centrale) e centralizzate secondo logica (non puoi dividerle in due).
- Il diritto civile si basa su un corpo legislativo centralizzato, considerando che il diritto comune è costruito su un precedente realizzato da molti singoli giudici. Il diritto civile ha ancora qualche decentramento architettonico in quanto vi sono molti campi che hanno comunque una grande discrezione. Entrambi sono comunque logicamente centralizzati (“la legge è la legge”).
- Le lingue sono decentralizzate secondo logica; l’inglese parlato tra Alice e Bob e l’inglese parlato da Charlie e David non ha bisogno di andare d’accordo. Non c’è un’infrastruttura centralizzata richiesta dalla lingua per esistere, e le regole della grammatica inglese non sono create o controllate da una singola persona (mentre l’esperanto fu originariamente inventato da Ludwig Zamenhof, anche se ora funziona come una lingua a tutti gli effetti che si evolve senza autorità).
- BitTorrentè decentralizzato secondo logica come l’inglese. Il contenuto fornito dai network è simile ma controllato da una singola azienda.
- Le Blockchain sono politicamente decentralizzate (nessuno le controlla) e anche architettonicamente decentralizzate(nessun punto centrale di fallimento ), ma sono centralizzate per logica poiché c’è uno stato concordato di comune accordo e il sistema si comporta come un singolo computer.
Molte volte quando la gente parla delle virtù della blockchain, quest’ultima viene descritta come “un database centrale”; questa centralizzazione è centralizzazione secondo logica ed è un tipo di centralizzazione che è senza dubbio positiva (anche se Juan Benet della IPFS spingerebbe verso il decentramento logico laddove possibile, perché i sistemi logicamente decentralizzati tendono ad essere ottimi per sopravvivere alle partizioni della rete, per lavorare bene in regioni del mondo che hanno scarsa connettività, ecc…
La centralizzazione architettonica spesso porta ad una centralizzazione anche politica, sebbene non necessaria – in una democrazia formale, i politici si incontrano e gestiscono i voti in alcune fisiche camere governative, ma i manutentori di questa camera non ne ricavano alcun potere decisionale.
In un sistema computerizzato, la decentralizzazione architettonica ma non politica potrebbe funzionare se c’è una community online che usa per comodità un forum centralizzato, ma con un contratto sociale ampiamente concordato che spiega che se i proprietari del forum si comportano male, allora tutto si sposteranno su un diverso forum (le community che si formano attorno ad una ribellione contro ciò che vedono come censura in un altro forum hanno di solito questo tipo di comportamento).
La centralizzazione logica rende la decentralizzazione architettonica più difficile ma non impossibile: vedi come i network con consenso decentralizzato hanno già dimostrato di lavorarci, ma è molto più difficile che mantenere BitTorrent.
E la centralizzazione logica rende la decentralizzazione più difficile, in sistemi centralizzati per logica, poiché è più difficile risolvere le controversie semplicemente “vivendo e lasciando vivere”.
Tre ragioni per la Decentralizzazione
La domanda successiva è, perché la decentralizzazione è utile? Di solito ci sono alcuni argomenti:
- Tolleranza agli errori— i sistemi decentralizzati sono meno propensi ad avere problemi in modo accidentale perché si fondano su molte componenti separate.
- Resistenza agli attacchi — i sistemi decentralizzati sono più costosi da attaccare, distruggere o manipolare perché mancano di punti nevralgici sensibili che possono essere attaccati con costi minori rispetto al guadagno economico che se ne ricaverebbe.
- Resistenza alla collusione — è più difficile per i partecipanti ad un sistema decentralizzato si uniscano per attaccare il sistema ottenendo benefici a spese degli altri partecipanti, mentre le leadership delle corporazioni o governi possono agire in collusione ottenendo benefici.
Questi tre argomenti sono importanti e validi, ma tutti e tre possono portare a conclusioni diverse e interessanti, una volta che hai iniziato a pensare alle decisioni dei protocolli avendo presente questi tre punti. Proviamo ad espandere questi punti.
Circa la tolleranza agli errori, l’argomento chiave è semplice. Cosa è più probabile che accada, che un computer abbia problemi o che 5, 10 computer abbiano problemi tutti nello stesso momento? Il principio non è controverso ed è usato in molte situazioni quotidiane come i motori a reazione, i generatori di corrente in posti come ospedali, strutture miliari, la diversificazione di portafogli finanziari e, ovviamente, network informatici.
Comunque, questo tipo di decentralizzazione, sebbene utile e molto importante, spesso diventa poco meno di panacea rispetto al modello matematico ingenuo che viene certe volte predetto. La ragione è il fallimento comune. Certo, è meno probabile che quattro motori a reazione non funzionino, ma cosa succede se tutti e quattro fossero stati fabbricati nella stessa fabbrica e l’errore fosse stato introdotto in tutti e quattro dallo stesso impiegato distratto?
Le blockchain come sono oggi riescono a proteggersi contro questi fallimenti comuni? Non necessariamente. Consideriamo i seguenti scenari:
- Tutti i nodi della blockchain si appoggiano sullo stesso client software, e quest’ultimo ha un bug.
- Tutti i nodi della blockchain si appoggiano sullo stesso client software, e il team di sviluppo di questo software si rivela corrotto.
- Il team di ricerca che deve aggiornare il protocollo si rivela corrotto.
- In una proof of work blockchain, il 70% dei miner si trova nello stesso Paese e il governo di questo Paese decide di sequestrare tutte le mining farm per ragioni di sicurezza nazionale.
- La maggior parte di mining hardware è costruito dalla stessa azienda e questa si rivela corrotta o costretta a creare una backdoor che permette all’hardware di essere distrutto.
- In una proof of stake blockchain, il 70% delle monete è gestito da un exchange soltato.
Un punto di vista olistico della decentralizzazione della tolleranza agli errori guarderebbe a tutti questi aspetti e vedrebbe come possano essere minimizzati. Alcune conclusioni naturali che sorgono sono piuttosto ovvie:
- E’ di cruciale importanza avere multiple competing implementations.
- La conoscenza delle considerazione tecniche sui cambiamenti del protocollo deve essere democraticizzata, in modo che più gente possa sentirsi a suo agio nel partecipare alle discussioni di ricerca e criticare i cambiamenti al protocollo se sono chiaramente negativi.
- Gli sviluppatori core e i ricercatori dovrebbero lavorare per varie compagnie o organizzazioni (o essere volontari).
- Gli algoritmi di mining dovrebbero essere creati in modo che si minimizzi il rischio di centralizzazione
- Idealmente noi usiamo la proof of stake per rimuovere il rischio di centralizzazione
Commenti