La parola fork significa biforcazione. L’immagine è quella di una strada che, a un certo punto, si divide in due direzioni. In Bitcoin viene usata per fenomeni diversi, e proprio questa sovrapposizione crea confusione: può indicare una copia del software, una separazione temporanea tra due blocchi oppure un cambiamento delle regole di consenso.
Capire la differenza permette di rispondere a domande molto più importanti del significato del termine. Chi può cambiare Bitcoin? Un aggiornamento del software modifica automaticamente la rete? I miner decidono quali regole valgono? Se qualcuno crea una catena alternativa, ha cambiato Bitcoin oppure ha dato vita a un’altra rete?
Prima del fork vengono le regole
Bitcoin è una rete di partecipanti indipendenti che mantengono lo stesso registro senza affidarlo a un’autorità centrale. Per riuscirci, i full node applicano regole comuni, le regole di consenso: controllano la validità delle transazioni, impediscono la doppia spesa, verificano i blocchi e riconoscono soltanto l’emissione monetaria prevista dal protocollo.
Ogni nodo esegue questi controlli in autonomia. Se riceve un blocco che viola le regole scelte dal suo operatore, lo rifiuta anche quando quel blocco proviene da un miner con molta potenza di calcolo. La proof-of-work ordina i blocchi validi e rende costoso riscrivere la storia; non trasforma un blocco non valido in uno valido.
Le regole di consenso non sono le uniche che un nodo applica. Ogni nodo segue anche una propria policy: criteri locali, che ciascun operatore può configurare, con cui decide quali transazioni non ancora confermate accettare nella propria mempool e inoltrare agli altri. La policy non si applica ai blocchi, quindi può cambiare da un nodo all’altro senza dividere la rete. Le regole di consenso stabiliscono invece quali transazioni e quali blocchi sono validi e devono essere le stesse su tutti i nodi: per cambiarle serve un fork, ed è di queste che si occupa l’articolo.
Un fork diventa rilevante per il consenso quando partecipanti diversi applicano regole diverse allo stesso registro. Da quel momento un blocco può essere accettato da alcuni nodi e rifiutato da altri. Se la divergenza continua, non esiste più un’unica storia riconosciuta da tutti: la catena si biforca e ne nascono due parallele.
La stessa parola descrive tre fenomeni
Il fork del codice
Bitcoin Core è software libero. Chiunque può copiarne il codice, modificarlo e pubblicare una propria versione. Nel linguaggio dello sviluppo, questa copia è già un fork del software.
La rete, però, non cambia per il solo fatto che qualcuno abbia scritto codice diverso. Quel programma deve essere eseguito da persone reali e deve comunicare con nodi che ne riconoscono le regole. Bitcoin XT, Bitcoin Classic e Bitcoin Unlimited sono stati fork del software scritti per modificare le regole di consenso, ma nessuno dei tre ha prodotto un hard fork: perché avvenga, l’implementazione alternativa deve essere adottata e le nuove regole devono essere attivate da miner, wallet e nodi. Copiare un repository è facile; spostare il consenso di una rete monetaria è un’altra cosa.
La biforcazione temporanea della catena
Due miner possono trovare quasi nello stesso momento due blocchi validi alla stessa altezza. Una parte della rete riceve prima il blocco A, un’altra riceve prima il blocco B. Per alcuni minuti esistono allora due estremità possibili della catena, entrambe compatibili con le stesse regole.
La separazione si risolve quando uno dei due rami accumula più proof-of-work. I nodi seguono la catena valida con maggiore lavoro accumulato e il blocco rimasto sull’altro ramo diventa un blocco orfano. Le regole non sono cambiate: la rete ha soltanto impiegato del tempo per convergere sullo stesso ordine degli eventi.
Il fork delle regole di consenso
Il terzo significato riguarda il protocollo. Alcuni partecipanti adottano nuove regole per stabilire quali transazioni e quali blocchi siano validi. La relazione tra le regole precedenti e quelle nuove determina se il cambiamento è un soft fork oppure un hard fork.
Questa distinzione non misura quanto sia importante l’aggiornamento. Descrive la compatibilità tra due insiemi di regole.
Soft fork: le nuove regole sono più restrittive
Un soft fork restringe l’insieme dei blocchi validi. Tutto ciò che rispetta le nuove regole rispetta anche quelle precedenti, ma non vale il contrario:
blocchi validi con le nuove regole ⊂ blocchi validi con le vecchie regole
Un nodo non aggiornato può quindi ricevere un blocco prodotto secondo le nuove regole e considerarlo valido, perché quel blocco non viola le regole che conosce. Non verifica però i nuovi vincoli: per applicarli deve aggiornarsi.
Immaginiamo che le vecchie regole accettino fogli firmati con penna blu o nera, mentre le nuove accettino soltanto la penna nera. Un foglio conforme alla nuova regola passa anche il vecchio controllo. Un vecchio controllore, però, continuerebbe ad accettare la penna blu e non sarebbe in grado di far rispettare la restrizione aggiunta.
SegWit e Taproot sono esempi di aggiornamenti attivati come soft fork. La compatibilità riduce la necessità di separare immediatamente tutti i nodi non aggiornati, ma non rende il cambiamento automatico o privo di rischi: proposta, codice, attivazione e adozione restano passaggi distinti.
Hard fork: le nuove regole non sono compatibili con le precedenti
Un hard fork introduce regole che permettono almeno un blocco che i nodi precedenti rifiuterebbero. Il nuovo insieme dei blocchi validi non è contenuto in quello vecchio:
blocchi validi con le nuove regole ⊄ blocchi validi con le vecchie regole
Se un miner produce uno di questi blocchi, i nodi aggiornati possono accettarlo mentre quelli rimasti alle regole precedenti lo respingono. Quando entrambi i gruppi continuano a produrre e riconoscere blocchi, la separazione diventa persistente: nascono due storie incompatibili, sostenute da reti che non condividono più lo stesso consenso. È quanto accaduto con Bitcoin Cash: una nuova regola ammetteva blocchi più grandi di 1 MB, il limite che le regole di Bitcoin fissavano per la dimensione dei blocchi, e i nodi rimasti alle regole precedenti hanno respinto quei blocchi.
Creare la seconda rete non obbliga la prima a cambiare. I nodi che continuano ad applicare le regole precedenti non vengono convinti da un nome, da una campagna pubblicitaria o dalla quantità di codice modificato. Accettano soltanto ciò che supera i loro controlli.
Soft fork e hard fork a confronto
| Aspetto | Soft fork | Hard fork |
|---|---|---|
| Rapporto con le vecchie regole | Restringe l’insieme dei blocchi validi | Ammette blocchi che le vecchie regole rifiutano |
| Comportamento dei nodi non aggiornati | Possono accettare i nuovi blocchi, ma non applicano i nuovi vincoli | Rifiutano i blocchi validi soltanto secondo le nuove regole |
| Rischio di separazione | Temporaneo, se miner non aggiornati producono blocchi che violano le nuove regole | È strutturale quando entrambe le regole continuano a essere usate |
| Aggiornamento dei nodi | Necessario per verificare le nuove regole | Necessario per seguire la rete con le nuove regole |
Non ogni aggiornamento è un fork di consenso
Il software di un nodo contiene anche funzioni che non cambiano la validità dei blocchi: interfaccia, prestazioni, gestione della memoria, modalità di connessione e criteri locali con cui una transazione viene inoltrata. Modificare uno di questi aspetti può richiedere un aggiornamento importante senza produrre un soft fork o un hard fork.
Per capire se un cambiamento tocca il consenso bisogna chiedere: può far sì che due nodi giudichino diversamente la validità dello stesso blocco? Se la risposta è no, non siamo davanti a un fork delle regole di consenso.
Chi decide se le regole cambiano
Bitcoin non ha un parlamento del protocollo né un’autorità che possa imporre la propria volontà ai partecipanti, e nessuna categoria può decidere da sola. Anche quando un soft fork viene attivato attraverso la segnalazione dei miner, la soglia richiesta è molto alta, il 95% dei blocchi nel meccanismo del BIP 9 e il 90% per Taproot, perché un cambiamento delle regole richiede un consenso molto ampio.
Gli sviluppatori possono formulare una proposta, spesso attraverso un BIP, e scrivere il codice. Non possono installarlo sui computer altrui. I miner scelgono quali transazioni valide includere, producono blocchi e possono partecipare ai meccanismi di segnalazione o attivazione previsti da un aggiornamento. La loro proof-of-work non costringe un nodo ad accettare un blocco contrario alle proprie regole.
Gli operatori dei nodi scelgono quale software eseguire e applicano con quella scelta le regole che riconoscono. Wallet, servizi, imprese e utenti decidono inoltre quale rete usare, quale unità monetaria accettare e a quale infrastruttura attribuire valore economico. Nessun ruolo controlla da solo il processo: il cambiamento richiede coordinamento tra soggetti diversi, mentre ogni nodo conserva il potere concreto di rifiutare ciò che considera non valido.
Il consenso non è quindi il risultato di una votazione formale. È la convergenza difficile, pubblica e volontaria attorno a regole compatibili.
Perché Bitcoin cambia lentamente
La lentezza non è assenza di sviluppo. Le regole proteggono transazioni, proprietà e politica monetaria; modificarle con leggerezza trasferirebbe sugli utenti il rischio di errori, incompatibilità o divisioni della rete. Per questo una proposta importante attraversa discussione, specifica, implementazione e coordinamento prima di poter essere adottata.
Questa resistenza al cambiamento protegge anche il limite dei 21 milioni. Il limite non è una promessa affidata a un dirigente e non è una proprietà magica del codice. È una regola che i nodi verificano. Qualcuno può copiare il software e scrivere un’emissione diversa, ma non può costringere gli altri operatori ad accettarla come Bitcoin. Per riuscirci dovrebbe convincerli a rinunciare volontariamente alla regola che stavano già facendo rispettare.
La scarsità di bitcoin è verificabile proprio perché il controllo non è delegato a un’autorità. Vive nel software eseguito da partecipanti indipendenti e nella loro capacità di respingere blocchi incompatibili.
Una biforcazione rende visibile il consenso
Un fork mostra che Bitcoin non dipende da una singola copia del codice e nemmeno dall’ordine di un gruppo di sviluppatori o miner. Dipende da regole che molti partecipanti applicano in autonomia e continuano a riconoscere come base dello stesso sistema monetario.
Un soft fork cerca di cambiare quelle regole mantenendo compatibilità con i nodi precedenti. Un hard fork accetta l’eventualità che i due insiemi di regole non riconoscano più gli stessi blocchi. Una biforcazione temporanea, invece, non cambia le regole: è il modo con cui la rete risolve due possibili ordini della storia.
Bitcoin non è immutabile perché nessuno possa modificarne il codice. È resistente al cambiamento perché nessuno può modificare da solo le regole che gli altri verificano.
Fonti
- BIP 141 — Segregated Witness (Consensus layer) e BIP 341 — Taproot: SegWit version 1 spending rules, repository ufficiale dei BIP: entrambi classificati «Consensus (soft fork)», stato «Deployed».
- Bitcoin Core, Transaction Relay Policy, documentazione del repository ufficiale — definizione di policy e differenza rispetto alle regole di consenso.
- Andreas M. Antonopoulos, Mastering Bitcoin, traduzione italiana — sezioni «Cambiando le regole di consenso», «I fork della blockchain», «Hard fork», «Hard fork: software, network, mining e chain», «Soft fork», «Segnalazione soft fork con versione a blocchi» e «Sviluppo del software di consenso».
- Saifedean Ammous, The Bitcoin Standard — passaggi sul ruolo di sviluppatori, nodi e miner nel cambiamento delle regole.
- Micah Warren, Bitcoin: A Game-Theoretic Analysis — sezione 1.2.13, «Soft forks and hard forks».