Affinché Bitcoin funzioni, tutti gli utenti devono concordare una cronologia delle transazioni (la blockchain) e una serie di regole fondamentali che definiscano cosa è accettato su questa blockchain e cosa non è accettato su questa blockchain. Quando questo consenso non può essere raggiunto, la comunità di utenti può essere divisa in due reti distinte, ognuna con le proprie regole. Questo è esattamente quello che è successo nel 2017 durante l'hard fork che ha dato vita a Bitcoin Cash (BCH).
Ma come ci siamo arrivati? In questo articolo, vi invito a rivivere questo periodo di conflitti all'interno della comunità Bitcoin, noto come «Blocksize War», per capire come questo dibattito abbia plasmato in modo permanente l'ideologia dei bitcoiner.
L'origine del conflitto
La Blocksize War è nata da un dibattito tecnico sulla capacità di Bitcoin di gestire un volume crescente di transazioni. Questo è talvolta chiamato «scalabilità» o «scalabilità». Essendo adottata come metodo di pagamento, l'invenzione di Satoshi deve essere in grado di gestire le transazioni dei nuovi utenti, mantenendo costi ragionevoli.
Tra queste limitazioni tecniche che riducono il flusso delle transazioni, c'è ovviamente il limite di dimensione dei blocchi sulla blockchain. Più grandi sono i blocchi, più transazioni che devono essere confermate possono essere incluse.
Quando è stato lanciato nel 2009, Bitcoin non aveva un limite esplicito a queste dimensioni. Tuttavia, nel 2010, Satoshi Nakamoto ha introdotto un limite fissato a 1 megabyte (tramite la costante DIMENSIONE MASSIMA DEL BLOCCO). Lo scopo di questa modifica era prevenire gli attacchi di spam nelle transazioni e garantire un certo decentramento della rete impedendo che blocchi eccessivamente grandi monopolizzassero le risorse degli operatori dei nodi.
All'epoca, la dimensione di 1 MB era più che sufficiente per supportare il basso numero di transazioni sulla rete. Tuttavia, man mano che Bitcoin cresceva in popolarità, la comunità iniziò a discutere sulla necessità di aumentare questo limite per consentire una migliore gestione del volume delle transazioni senza aumentare le commissioni. È così che è emersa una prima frattura all'interno della comunità Bitcoin. Alcuni, che in seguito sarebbero stati chiamati «grandi bloccanti», ritenevano che un aumento delle dimensioni dei blocchi fosse una soluzione semplice e diretta per risolvere i problemi di congestione. Al contrario, altri, che verranno definiti «piccoli bloccanti», hanno sostenuto che questo approccio rischiava di centralizzare la rete aumentando i requisiti hardware dei nodi.
Infatti, poiché ogni nodo completo deve controllare e quindi archiviare l'intera blockchain in memoria, blocchi più grandi richiedono dischi di maggiore capacità, il che è più costoso e riduce gli incentivi a gestire il proprio nodo. Se ci sono meno nodi Bitcoin, la sicurezza del sistema è distribuita meno bene, aumentando i rischi individuali di coercizione concentrando la sicurezza su un numero minore di attori.
Queste discussioni sulle dimensioni dei blocchi sono ancora più antiche del periodo 2015-2017. In realtà, già nel 2010, erano già state fatte proposte per aumentare il limite, ad esempio La patch proposta da Jeff Garzik.
Ma è stato proprio a partire dal 2015 che il dibattito si sarebbe trasformato in conflitto, con una prima offensiva da parte degli sviluppatori di Bitcoin XT, un client alternativo lanciato da Mike Hearn e supportato da Gavin Andresen (ex main maintainer di Bitcoin dopo la partenza di Satoshi Nakamoto). Bitcoin XT era originariamente un'implementazione del protocollo Bitcoin compatibile con Bitcoin Core. Tuttavia, nell'agosto 2015, la versione 0.11A di Bitcoin XT ha adottato BIP101: un hard fork che aumenta immediatamente il limite di dimensione dei blocchi da 1 MB a 8 MB, con l'aggiunta di un meccanismo per raddoppiare tale limite ogni due anni, fino a raggiungere poco più di 8 GB per blocco nel 2036. Di fatto, i nodi Bitcoin XT si sono quindi separati dal resto della rete Bitcoin. Questo tour de force è considerato da molti il casus belli della guerra a blocchi.
Bloccanti piccoli contro grandi bloccanti
Il conflitto Blocksize War era strutturato attorno a due fazioni opposte: i «grandi bloccanti» e i «piccoli bloccanti», ognuno dei quali difendeva un approccio diverso alla risoluzione del problema della scalabilità di Bitcoin.
I «big blocker» erano favorevoli all'aumento delle dimensioni dei blocchi, per consentire a Bitcoin di elaborare un numero maggiore di transazioni. Per loro, un simile approccio era necessario per ridurre le commissioni di transazione e migliorare l'esperienza utente man mano che Bitcoin cresceva in popolarità. Sostenevano inoltre che questa soluzione fosse tecnicamente semplice da implementare tramite hard fork. In particolare, i «big blocker» sono stati sostenuti dai primi sviluppatori, come Gavin Andresen, Jeff Garzik, Mike Hearn, e da attori influenti come Roger Ver e la maggior parte delle società minerarie. Per loro, l'aumento della dimensione dei blocchi era sinonimo di un aumento dei loro ricavi. Infatti, se riesci a inserire più transazioni in ogni blocco, puoi anche riscuotere più commissioni.
Al contrario, gli «small blocker», rappresentati principalmente da sviluppatori di Bitcoin Core come Pieter Wuille, Wladimir van der Laan, Peter Todd, Gregory Maxwell o Luke Dashjr, hanno adottato un approccio più conservativo. Sostenevano che l'aumento delle dimensioni dei blocchi comporterebbe rischi di centralizzazione della rete, poiché comporterebbe un carico maggiore sui nodi, il che limiterebbe la distribuzione dei rischi. Anche gli «small blocker» volevano che Bitcoin fosse scalabile, ma preferivano soluzioni di scalabilità che allontanassero le transazioni dalla blockchain principale, come ad esempio il Lightning Network. L'idea era di gestire un grande volume di transazioni senza modificare il protocollo di base per preservare il decentramento della rete e quindi la distribuzione della sua sicurezza. Gli small blocker preferiscono inoltre le modifiche conservative apportate tramite soft fork piuttosto che hard fork.
Il dibattito tecnico tra queste due visioni della scalabilità ha diviso profondamente la comunità Bitcoin. Ogni schieramento ha mobilitato strategie di propaganda e influenza per cercare di far passare le proprie idee.
Le proposte e i tentativi di Forks
I tentativi e le proposte di Forks si sono moltiplicati tra il 2015 e il 2017. Come abbiamo visto, il primo vero tentativo di fork durante la Blocksize War è stato quello del BIP101 su Bitcoin XT. Questa proposta è stata sostenuta da un gran numero di minatori e da aziende influenti all'epoca come BitPay, Blockchain.info o Circle. Alla fine, Bitcoin XT non sarà in grado di ottenere un supporto sufficiente dalla comunità e Mike Hearn alla fine annuncerà la sua partenza e la vendita dei suoi bitcoin. Esprimerà la sua delusione in un post sul blog in cui affermerà in particolare che» Bitcoin ha fallito ». Bitcoin XT ha quindi segnato l'inizio di profonde differenze nella comunità e presto sono seguiti altri fork.
All'inizio di dicembre 2015, Pieter Wuille e Gregory Maxwell, sviluppatori di Bitcoin Core, hanno proposto un soft fork chiamato «SegWit» (Testimone segregato). Questa proposta mirava a separare i dati delle firme dai dati delle transazioni nella blockchain, al fine di risolvere il problema della malleabilità delle transazioni. Questo problema, legato all'ECDSA, l'algoritmo di firma digitale utilizzato su Bitcoin dal 2009, consente di modificare leggermente una firma valida per crearne un'altra valida per la stessa transazione. Questa vulnerabilità ha impedito l'implementazione di Lightning Network. L'intenzione di Maxwell e Wuille con SegWit era quindi quella di consentire un'implementazione sicura del Lightning Network e quindi di risolvere i problemi di scalabilità di Bitcoin. SegWit includeva anche un leggero e virtuale aumento della dimensione dei blocchi, pur rimanendo compatibile con i vecchi nodi (soft fork). Questa proposta è diventata rapidamente la punta di diamante dei piccoli bloccanti.
Tuttavia, in seguito al fallimento di Bitcoin XT, Gavin Andresen e Jeff Garzik sono tornati qualche settimana dopo con una nuova idea: Bitcoin Classic. Proposto all'inizio del 2016, questo fork suggeriva un approccio più moderato e consensuale rispetto a Bitcoin XT, con un aumento della dimensione del blocco a 2 MB (tramite BIP109). L'iniziativa è stata sostenuta da numerose aziende del settore come Coinbase e dai minatori.
Man mano che Bitcoin Classic cresceva in popolarità e minacciava di dividere la rete, il 20 febbraio 2016 è stata organizzata una riunione di emergenza: il Tavola rotonda di Hong Kong. Questo evento ha riunito minatori (tra cui Jihan Wu e Micree Zhan, i co-fondatori di Bitmain), alcune aziende influenti e sviluppatori di Bitcoin Core (tra cui Luke Dashjr, Matt Corallo e Peter Todd). Dopo lunghe ore di negoziazione, è stato raggiunto un accordo. Gli sviluppatori principali si impegnano a implementare un hard fork per SegWit e a raddoppiare il limite di dimensione dei blocchi. Da parte loro, i minatori e le aziende promettono di supportare questo fork e di utilizzare esclusivamente il client Bitcoin Core, al fine di preservare l'unità della rete Bitcoin.
Questo accordo avrebbe dovuto porre fine alla Blocksize War, ma alla fine ha creato più conflitti. Ciascuna parte ha interpretato l'accordo in modo diverso e alla fine non verrà mai implementato.
Anche alcuni eventi esterni hanno indebolito questo accordo, in particolare l'hacking di The DAO su Ethereum, che ha portato a un hard fork per recuperare i fondi rubati, provocando così la divisione tra ETH (Ethereum) ed ETC (Ethereum Classic). Questo hard fork si è rivelato un disastro per Ethereum, in particolare a causa degli attacchi di replay che hanno sconvolto l'intero settore (le transazioni da una blockchain potrebbero essere ritrasmesse in modo identico sull'altra blockchain). Questo fiasco ha messo in luce tutti i rischi che un hard fork potrebbe comportare per Bitcoin e ha quindi fornito un argomento importante per i piccoli blocker, che si sono trovati in una posizione di forza. Allo stesso tempo, altri eventi hanno offuscato la reputazione di alcuni grandi blocker, riducendone la credibilità presso la community. Questo accordo di Hong Kong ha avuto comunque il merito di frenare lo slancio di Bitcoin Classic.
Gli small blocker sfruttano questa reputazione per lanciare da soli la reportistica SegWit, impostando che il soft fork si attivi se il 95% della potenza di calcolo lo approva in un determinato periodo di tempo. Tuttavia, durante le prime settimane, le segnalazioni rimangono basse e i minori non sembrano voler collaborare. Allo stesso tempo, una nuova proposta di fork sta guadagnando popolarità con Bitcoin Unlimited. Questo cliente alternativo, promosso in particolare dall'imprenditore Roger Ver (soprannominato «Bitcoin Jesus»), propone di aumentare le dimensioni dei blocchi in modo flessibile tramite un hard fork. A differenza di Bitcoin Classic, Bitcoin Unlimited non stabilisce un limite massimo alla dimensione dei blocchi, consentendo agli utenti di impostare le proprie impostazioni.
È stato sotto la minaccia di questo nuovo fork che BIP148 è stato pubblicato a marzo 2017 da uno sviluppatore anonimo che si fa chiamare Shaolin Fry. L'obiettivo di BIP148 è forzare l'attivazione dell'aggiornamento SegWit sul protocollo Bitcoin, a fronte della stagnazione della segnalazione di questo soft fork da parte dei miner tramite il classico metodo BIP9. Per raggiungere questo obiettivo, propone l'implementazione di un UASF (Soft Fork attivato dall'utente), per attivare forzatamente SegWit da parte dei nodi il 15 novembre 2017, se i miner non avessero bloccato SegWit entro il 1 agosto 2017. Se BIP148 viene seguito dagli utenti, i nodi della rete Bitcoin rifiuteranno i blocchi che non segnalano il supporto a SegWit, facendo pressione sui minatori affinché adottino l'aggiornamento.
La comunità vede questa proposta dell'UASF come un'opportunità per abbattere finalmente i grandi blocchi e sta quindi iniziando a sostenerla attivamente. L'abbigliamento con l'acronimo UASF appare alle conferenze e la comunicazione si sta intensificando su Twitter.
Di fronte alla minaccia dell'UASF, i grandi bloccanti sono costretti a tornare al tavolo di discussione nonostante la loro posizione di forza a seguito della mancata segnalazione di SegWit. Così, il 23 maggio 2017, è stato organizzato un nuovo incontro privato a New York, a margine della conferenza Consenso 2017, che riunisce più di 50 aziende dell'ecosistema Bitcoin. Da questo incontro è nata la proposta Segwit2x, che prevede due importanti modifiche al protocollo Bitcoin:
L'adozione di SegWit con una soglia di attivazione fissata all'80% di segnalazione;
Un hard fork per aumentare la dimensione massima del blocco da 1 MB a 2 MB.
James Hilliard (ingegnere di Bitmain) ha quindi proposto BIP91 per facilitare l'attivazione del soft fork SegWit, definito in BIP141, BIP143 e BIP147, tramite un MASF all'80%. Questo metodo mira a rendere obsoleto il BIP148 (UASF) e ad evitare una potenziale divisione della blockchain il 1° agosto 2017. BIP91 è stato finalmente attivato il 23 luglio 2017 (al blocco 477.120), poco prima della data critica del 1 agosto fissata dal BIP148. Ciò consente di forzare la segnalazione di SegWit da parte di minori, che verrà finalmente bloccata il 9 agosto al blocco 479 808, quindi attivata il 24 agosto al blocco 481 824.
Quindi l'UASF non è mai esistito, ma ha svolto un ruolo decisivo nell'adozione di SegWit costringendo i minatori a bloccare il soft fork tramite BIP91. A lungo termine, il BIP148 ha creato un precedente importante, dimostrando l'influenza che gli utenti possono esercitare attraverso i loro nodi completi sulle decisioni di governance del protocollo Bitcoin, anche se le grandi aziende e i minatori non sono d'accordo.
Parallelamente all'attivazione di SegWit, il 1° agosto 2017 al blocco 478 559, parte della comunità Bitcoin sta effettuando un hard fork per aumentare la dimensione del blocco a 8 MB. Questa divisione, denominata Bitcoin Cash (BCH), esiste ancora oggi insieme a Bitcoin, sebbene la sua valutazione sia molto bassa in confronto.
Dopo l'attivazione di SegWit, la seconda parte di SegWit2x doveva ancora essere implementata nel blocco 494 784, cioè durante il mese di novembre 2017, tramite un hard fork destinato a raddoppiare le dimensioni dei blocchi. Tuttavia, i piccoli blocker si sono fortemente opposti a questo aggiornamento, soprattutto perché si trattava di un hard fork senza tutti i meccanismi di sicurezza necessari. Una nuova campagna di comunicazione, denominata» NO2X », è poi emerso per impedire questo aumento delle dimensioni dei blocchi. L'8 novembre, l'hard fork è stato definitivamente abbandonato all'ultimo minuto, a causa della mancanza di consenso e di fronte al rifiuto della comunità. Questa data è spesso considerata la fine della Blocksize War.
Questo episodio della Blocksize War ha lasciato innegabilmente un segno nella comunità Bitcoin. Quello che era iniziato come un semplice dibattito tecnico si è gradualmente trasformato in un conflitto che avrebbe potuto mettere in pericolo l'esistenza stessa di Bitcoin, o almeno indebolirlo in modo significativo. Questo periodo ha anche influenzato profondamente il modo in cui sono state progettate le evoluzioni dei protocolli: oggi, la maggioranza dei bitcoiner preferisce un approccio cauto e conservativo agli aggiornamenti, privilegiando i soft fork rispetto agli hard fork, anche se ciò complica il processo. Inoltre, l'ideologia degli small blocker è ora ampiamente accettata dagli utenti.
Anche la Blocksize War ha creato un precedente, dimostrando che l'UASF potrebbe essere un potente strumento deterrente per consentire agli utenti di mantenere il proprio potere di fronte ai minatori e ai principali attori del settore.
Per approfondire questo argomento di Blocksize War, ti consiglio di leggere il libro La guerra delle dimensioni dei blocchi di Jonathan Bier, che ho usato per scrivere questo articolo.
.png)
.png)
.png)
.png)
.png)
.png)
