Bitcoin è un sistema di pagamento distribuito. Per sua natura, nessuna persona o entità lo gestisce. Tuttavia, il suo protocollo viene talvolta modificato per introdurre nuove funzionalità. Queste modifiche vengono generalmente apportate tramite un meccanismo noto come «soft fork».
Per implementare questi soft fork in modo ottimale mantenendo l'integrità del consenso attuale, vengono utilizzati metodi di attivazione specifici. Questi meccanismi, sebbene a volte sconosciuti, svolgono un ruolo cruciale nella comprensione delle dinamiche associate ai cambiamenti nel protocollo Bitcoin. In questo articolo, esploriamo i vari metodi di attivazione dei soft fork utilizzati su Bitcoin.
Qual è la differenza tra una forcella morbida e una forcella rigida?
Il protocollo Bitcoin è qualcosa di intangibile in natura. Rappresenta semplicemente un gruppo di regole non dette, che consentono a diversi nodi di sincronizzarsi e formare una rete. Tutti questi nodi implementano le regole del protocollo tramite software, il più utilizzato è Bitcoin Core.
Quando si verifica una modifica a queste regole del protocollo, questo evento viene chiamato «fork». Ogni nodo è quindi libero di scegliere se implementare questo fork o se rifiutarlo. In questo modo si cerca il consenso per ogni modifica di Bitcoin, senza la necessità di ricorrere a un'autorità centrale.
Esistono due tipi principali di forcelle: hard fork e soft fork. La differenza tra i due è la retrocompatibilità dell'aggiornamento.
L'hard fork modifica il protocollo rimuovendo le regole o rendendo quelle esistenti meno restrittive, rendendolo non retrocompatibile con i nodi precedenti. Quindi fa sì che la blockchain venga separata in due catene distinte: quella con i nodi aggiornati e quella con i vecchi nodi.
Il soft fork, invece, modifica il protocollo aggiungendo regole o rendendo più restrittive quelle esistenti. In questo modo, il nuovo protocollo rimane retrocompatibile con quello vecchio e non si suppone che si verifichino separazioni di catena. Su Bitcoin, tranne in casi eccezionali, preferiamo utilizzare i soft fork per modificare le regole del protocollo.
La difficoltà sta nel fatto che, anche con l'uso di un soft fork, a volte può esserci una separazione della blockchain in due rami. Questo scenario si verifica quando i minori che non si sono aggiornati rappresentano più del 50% della potenza di calcolo della rete. In questo caso, la ramificazione in due catene distinte persiste fintanto che la catena che non ha integrato il soft fork ha più lavoro accumulato rispetto alla catena che l'ha adottata.
Per preservare l'unità di Bitcoin, vogliamo evitare tali filiali a tutti i costi. Per fare ciò, ai minatori verrà chiesto di decidere in anticipo se accettare un soft fork. Sebbene un'ampia maggioranza dichiari di essere d'accordo a sostenerlo, i rischi di un fork durante l'attivazione del soft fork sono notevolmente ridotti. Questo processo di consultazione e consenso preventivo è chiamato «metodo di attivazione».
Qual è la differenza tra un UASF e un MASF?
Quindi distinguiamo tra due categorie di soft fork. Quando la sua implementazione proviene direttamente dagli utenti, si parla di «UASF» (Soft Fork attivato dall'utente). Questo metodo si verifica quando i nodi della rete scelgono di applicare un soft fork modificando il proprio software, senza attendere l'approvazione dei minatori. Generalmente utilizzato in situazioni di emergenza, soprattutto quando la maggioranza dei minori si oppone all'adozione di un soft fork, l'UASF è in realtà uno strumento deterrente che consente agli utenti di contrastare un potenziale abuso di potere da parte di minori. Tuttavia, l'UASF non è privo di rischi: può portare a una branca della blockchain, collocando così gli utenti che la adottano su una catena potenzialmente priva di valore economico e meno sicura.
In un processo più consensuale, preferiamo utilizzare l'attivazione del soft fork da parte dei minori. Parliamo quindi di un «MASF» (Forcella morbida attivata da minerali). In questo caso, i minori possono dare la loro approvazione per la modifica del protocollo. Quando una grande maggioranza di essi esprime il proprio consenso all'implementazione del soft fork, l'aggiornamento viene quindi convalidato e attivato poco dopo. Questo metodo consente di evitare la ramificazione della blockchain e di mantenere l'unità della rete.
Come puoi vedere, poiché non esiste una pianificazione centralizzata su Bitcoin, ogni aggiornamento può diventare rapidamente caotico. Gli sviluppatori hanno quindi proposto vari metodi di attivazione per eseguire un soft fork riducendo al contempo il rischio di violare il consenso su Bitcoin.
Metodi di attivazione informali
All'epoca di Satoshi Nakamoto, non esisteva una procedura formale per l'attivazione dei soft fork. Satoshi stesso ha apportato le modifiche, che sono state generalmente adottate senza molta opposizione da una comunità ancora piccola. A volte, non li ha nemmeno annunciati in anticipo, come quando ha imposto unilateralmente un limite di dimensione dei blocchi di 1 MB nel 2010.
Tra i primi metodi utilizzati, troviamo anche il «Flag Day». Consisteva nell'impostare e imporre una data specifica per l'attivazione del soft fork. Sebbene semplice, questo metodo è molto rigido e non consente di prendere in considerazione eventuali disaccordi all'interno della comunità.
Dopo che Satoshi se ne andò all'inizio del 2011, iniziarono a emergere procedure di attivazione più formalizzate. L'attivazione del BIP16, che introduce il P2SH (Pagamento su script hash), è stato al centro di uno dei primi grandi dibattiti all'interno della comunità. Fu durante questo periodo di tensione che furono utilizzati i primi metodi di attivazione che tenevano conto dell'opinione dei minori.
Dopo questi dibattiti sul P2SH, Gavin Andresen ha proposto il BIP34, che ha introdotto un framework iniziale per i metodi di attivazione. Questo approccio ha permesso di tenere conto dell'opinione dei minori e di eseguire il soft fork una volta raggiunta una determinata soglia di approvazione.
Successivamente, altri soft fork hanno utilizzato metodi simili, con finestre di attivazione che si estendevano per diverse settimane. Tuttavia, non esisteva ancora un metodo standardizzato per attivare una modifica del protocollo. Le attivazioni sono state eseguite più o meno in linea con le raccomandazioni del BIP34, ma quest'ultimo non ha tenuto conto della segnalazione simultanea di più soft fork.
Attiva un soft fork con BIP9
Il BIP9, progettato nel 2015 da Pieter Wuille, Peter Todd, Peter Todd, Greg Maxwell e Rusty Russell, stabilisce un framework standard per l'attivazione dei soft fork, migliorando il concetto iniziale del BIP34. Il suo funzionamento è molto semplice. Quando viene deciso un soft fork, la comunità lo sottopone alla segnalazione dei minorenni. A tale scopo, vengono determinate una data di inizio e una durata massima per la segnalazione. Durante questo periodo, i minatori possono utilizzare un bit specifico nel campo della versione del blocco per indicare che supportano il soft fork.
Non appena il 95% dei blocchi dichiara la propria approvazione per un periodo fisso di 2016 blocchi, il soft fork viene bloccato. Questo periodo coincide con ogni aggiustamento della difficoltà della prova di lavoro. Dopo questo blocco, viene concesso un breve periodo di tempo ai miner per allinearsi all'aggiornamento, prima che il soft fork venga effettivamente eseguito. Se la soglia di approvazione del 95% non viene raggiunta entro il tempo specificato, il soft fork viene abbandonato.
Rispetto al BIP34, il BIP9 offre la possibilità di segnalare più soft fork contemporaneamente. Tuttavia, ha anche i suoi svantaggi, incluso il fatto che si basa interamente su un MASF, conferendo così ai minori un notevole potere. In effetti, se la soglia del 95% di segnalazione non viene raggiunta durante la finestra di voto, la modifica proposta viene semplicemente abbandonata.
In particolare, BIP9 è stato utilizzato per attivare SegWit nel 2017. Come probabilmente sapete, le cose non sono andate secondo i piani. Per mesi, la maggioranza dei minori si è rifiutata di segnalare il proprio accordo con SegWit, nonostante il consenso degli utenti.
Pertanto, il BIP9 introduce una certa ambiguità nella governance di Bitcoin, inducendo i miner a pensare di controllare l'attivazione dei soft fork. In realtà, il loro ruolo si limita a segnalare la loro disponibilità ad adottare il nuovo codice, per evitare che si crei una branca della blockchain. Nonostante la complessità della materia, sono gli utenti ad esercitare il controllo definitivo sul protocollo, tramite i loro nodi completi.
Per questo motivo, lo sviluppatore Shaolin Fry ha proposto il BIP148 a marzo 2017, che consentiva agli utenti di eseguire un UASF. L'obiettivo era imporre SegWit ai minori, senza il loro consenso. Questa iniziativa, ampiamente sostenuta dalla comunità, ha esercitato una pressione sufficiente sui minatori, che, per paura di perdere il loro reddito, hanno finalmente approvato SegWit attraverso un processo di segnalazione più tradizionale.
Il processo di attivazione di SegWit si è così trasformato in un fiasco e avrebbe potuto essere un disastro per Bitcoin. Per questo motivo, nel 2017, Shaolin Fry e Luck Dashjr hanno proposto BIP8, un nuovo metodo di attivazione che riprende l'idea del BIP9 aggiungendo un meccanismo UASF automatico alla fine del periodo di votazione.
Specifica un nuovo parametro chiamato «LOT» (Blocca il timeout), che può assumere il valore di «vero» o «falso». Se questa variabile è impostata su «false», BIP8 funziona in modo simile a BIP9. Viene specificata una finestra di approvazione per i minori e, una volta raggiunta la soglia, il soft fork viene bloccato. D'altra parte, se il parametro LOT è impostato su «true», BIP8 prevede che se la soglia richiesta non viene raggiunta alla fine del periodo di votazione, gli utenti attiveranno automaticamente un UASF. Questo meccanismo mira a fare pressione sui minatori affinché forzino l'attivazione del soft fork in caso di blocco nel processo di approvazione.
Il BIP8 con LOT attivato è quindi un metodo molto più aggressivo contro i minori. Li lascia con solo due scelte:
Sii cooperativo e quindi facilita il processo di attivazione;
Non cooperare, nel qual caso gli utenti eseguono un UASF per far rispettare il soft fork.
Il BIP8 ha inoltre corretto alcuni difetti del BIP9. Invece di utilizzare i timestamp per specificare il periodo di voto, lo imposta sulle altezze dei blocchi. In questo modo, BIP8 elimina la possibilità che i minatori causino un brusco calo dell'hash rate sulla rete per distorcere il processo. Inoltre, aggiunge la possibilità di determinare liberamente la soglia minima di voto e introduce un parametro che specifica un'altezza minima del blocco, al di sotto della quale il soft fork non può essere attivato. Questa impostazione dà ai minori il tempo di prepararsi alla modifica del codice, consentendo loro di firmare in anticipo il proprio consenso.
Attiva un soft fork in Speedy Trial
Il processo «Speedy Trial», proposto da David A. Harding all'inizio del 2021 sulla base di un'idea di Russell O'Connor, è un nuovo metodo di attivazione progettato inizialmente per il soft fork Taproot. Si basa sull'uso del BIP8 con il parametro LOT impostato su «false», ma con una significativa riduzione della finestra di attivazione a soli tre mesi. In questo modo, l'approvazione dei minori può essere verificata molto rapidamente. Se la soglia richiesta viene raggiunta durante uno dei periodi, il soft fork viene attivato diversi mesi dopo, lasciando ai miner il tempo sufficiente per aggiornare il proprio software. Sebbene questo metodo non sia stato ancora formalizzato in un BIP specifico, è stato già utilizzato per attivare Taproot nel novembre 2021.
Nonostante la sua efficacia per Taproot, che ha riscosso un ampio consenso nella community, il metodo Speedy Trial non è necessariamente il più adatto per tutti gli aggiornamenti di Bitcoin. Alcuni sviluppatori esprimono delle riserve sul suo utilizzo futuro, temendo che possa favorire una successione di soft fork troppo rapida e, quindi, che possa compromettere la stabilità del protocollo Bitcoin.
I metodi per attivare i soft fork su Bitcoin si stanno evolvendo con nuovi aggiornamenti. È un modello di prova ed errore che è sempre molto simile: definiamo un metodo di attivazione standard, lo usiamo per il prossimo grande soft fork; non va come previsto; quindi definiamo un altro standard considerando i nostri errori passati.
Ad oggi, esistono principalmente tre metodi di attivazione:
BIP9, che consente ai minori di chiedere la loro approvazione prima di attivare un soft fork;
BIP8, che è essenzialmente come il BIP9, ma aggiunge la possibilità dell'UASF automatico se i minori non sono cooperativi;
E lo Speedy Trial, che è come il BIP8, ma con un periodo di voto molto breve.
