Un soft fork è un aggiornamento retrocompatibile delle regole di consenso di un protocollo blockchain, in cui l'insieme dei blocchi validi secondo le nuove regole è un sottoinsieme rigoroso dei blocchi validi secondo le vecchie regole. In termini pratici, ciò significa che i nodi che utilizzano il vecchio software continueranno ad accettare i blocchi prodotti dai nodi aggiornati, perché i nuovi blocchi sono conformi alle vecchie regole, ma sono semplicemente più restrittive. A differenza di un hard fork, che crea tipi di blocchi completamente nuovi che i vecchi nodi rifiuterebbero (potenzialmente dividendo la blockchain), un soft fork consente l'evoluzione del protocollo senza richiedere a tutti i partecipanti di aggiornarsi simultaneamente.
La retrocompatibilità dei soft fork è la loro caratteristica distintiva e il loro principale vantaggio. Quando un soft fork si attiva, i miner o i validatori aggiornati iniziano ad applicare le nuove regole più restrittive. I nodi non aggiornati considerano questi blocchi validi perché sono ancora conformi alle regole originali, meno restrittive. Tuttavia, se un miner non aggiornato produce un blocco che viola le nuove regole (ma è conforme a quelle vecchie), i nodi aggiornati lo rifiuteranno. Questo crea un'asimmetria: i nodi aggiornati applicano un insieme di regole più restrittive, mentre i nodi non aggiornati vengono "ingannati" e accettano i blocchi più restrittivi perché non violano le vecchie regole. Finché la maggioranza della potenza di mining (o della potenza di staking, nei sistemi proof-of-stake ) applica le nuove regole, la blockchain convergerà sul set di regole aggiornato senza dividersi.
Fin dai primi anni della rete, i soft fork sono stati il meccanismo preferito per gli aggiornamenti del protocollo Bitcoin. I principali miglioramenti di Bitcoin, tra cui Pay-to-Script-Hash (P2SH), Segregated Witness (SegWit) e Taproot, sono stati tutti implementati tramite soft fork. Questo approccio riflette una filosofia conservativa nella cultura di sviluppo di Bitcoin: le modifiche dovrebbero essere minimamente invasive, retrocompatibili e realizzabili senza costringere l'intera rete ad aggiornarsi in blocco. Il compromesso è che i soft fork sono più limitati nelle modifiche che possono introdurre: possono inasprire le regole o aggiungere nuovi tipi di transazione che i vecchi nodi interpretano come output "chiunque può spendere", ma non possono allentare le regole esistenti o alterare in modo fondamentale la struttura dei blocchi.
Il meccanismo con cui un soft fork mantiene la compatibilità con le versioni precedenti spesso implica astuti accorgimenti tecnici. Ad esempio, SegWit ha introdotto un formato di transazione completamente nuovo con una struttura dati witness, ma i vecchi nodi interpretavano semplicemente le transazioni SegWit come spese provenienti da indirizzi che "chiunque può spendere" – valide secondo le vecchie regole, ma con un nuovo significato secondo le regole aggiornate. Questo schema di codifica di nuove semantiche all'interno di framework di regole esistenti è un segno distintivo dell'ingegneria dei soft fork, che richiede notevole ingegno per implementare modifiche complesse entro i vincoli di compatibilità con le versioni precedenti.
Origine e storia
2010: Il primo soft fork de facto in Bitcoin si verificò quando Satoshi Nakamoto introdusse diverse modifiche al codice sorgente di Bitcoin per inasprire le regole, tra cui l'aggiunta degli opcode OP_NOP e il limite di dimensione del blocco di 1 MB. Queste modifiche resero non validi comportamenti precedentemente esistenti, costituendo di fatto dei soft fork, sebbene il termine non fosse ancora in uso.
2012: BIP 16 ha introdotto Pay-to-Script-Hash (P2SH), uno dei primi aggiornamenti soft fork di Bitcoin formalmente riconosciuti. Proposto da Gavin Andresen, P2SH ha permesso l'utilizzo di script di transazione più complessi, mantenendo al contempo la compatibilità con le versioni precedenti, codificando l'hash di uno script in un indirizzo dall'aspetto standard. Questo aggiornamento è entrato in funzione il 1° aprile 2012 e ha stabilito molti dei precedenti per il coordinamento dei soft fork di Bitcoin.
2015: BIP 65 (OP_CHECKLOCKTIMEVERIFY) e BIP 66 (codifica rigorosa della firma DER) sono stati attivati come soft fork, introducendo transazioni con blocco temporale e una convalida della firma più rigorosa. Questi aggiornamenti hanno utilizzato la segnalazione dei miner "IsSuperMajority", che richiede che 950 degli ultimi 1,000 blocchi segnalino il loro supporto prima dell'attivazione.
2016: La comunità Bitcoin ha dato inizio al dibattito pluriennale sulla scalabilità che avrebbe definito il rapporto tra soft fork e hard fork. La proposta SegWit (BIP 141) è stata presentata come una soluzione soft fork per la malleabilità delle transazioni e un modesto aumento di capacità, mentre le fazioni opposte sostenevano un hard fork per aumentare direttamente il limite della dimensione del blocco. Questo dibattito ha cristallizzato la distinzione filosofica tra soft fork e hard fork nella cultura delle criptovalute.
2017: Segregated Witness (SegWit), il soft fork più significativo nella storia di Bitcoin fino ad allora, è stato bloccato l'8 agosto 2017, dopo che il 100% dei miner in un periodo di segnalazione ha raggiunto la soglia del 95%, ed è stato attivato il 24 agosto 2017, all'altezza del blocco 481,824. SegWit ha separato i dati della firma dai dati delle transazioni, risolvendo il problema della malleabilità delle transazioni, abilitando il Lightning Network e aumentando la capacità effettiva dei blocchi. La sua attivazione è stata catalizzata dal movimento User Activated Soft Fork (UASF), in cui gli operatori dei nodi minacciavano di imporre SegWit indipendentemente dalla segnalazione dei miner.
2021: Taproot, il successivo importante soft fork di Bitcoin, è stato bloccato il 12 giugno 2021 al blocco 687,284 dopo aver raggiunto una soglia di segnalazione dei miner del 90%, ed è stato attivato il 14 novembre 2021 al blocco 709,632. Proposto inizialmente da Greg Maxwell e formalizzato attraverso i BIP scritti da Pieter Wuille, Tim Ruffing, AJ Townes e Jonas Nick, Taproot ha introdotto le firme Schnorr e i Merkelized Alternative Script Trees (MAST), migliorando significativamente la privacy, l'efficienza e le capacità degli smart contract di Bitcoin. Taproot ha utilizzato il meccanismo di attivazione Speedy Trial (una variante del BIP 8), raggiungendo la soglia di segnalazione dei miner del 90% richiesta in una singola finestra di segnalazione.
2023-2026: La comunità Bitcoin si è impegnata in un acceso dibattito su potenziali soft fork futuri, tra cui le proposte per OP_VAULT (BIP 345) per una maggiore sicurezza della custodia, OP_CAT (BIP 347) per la funzionalità dei covenant e CTV (OP_CHECKTEMPLATEVERIFY, BIP 119) per la creazione di modelli di transazione. Queste proposte hanno evidenziato la continua tensione tra la filosofia conservativa di Bitcoin in materia di aggiornamenti e il desiderio di funzionalità avanzate.
In parole semplici
L'analogia con l'aggiornamento del codice edilizio: immaginate una città che aggiorna il proprio codice edilizio per richiedere fondamenta più solide per i nuovi edifici. Tutti gli edifici esistenti rimangono validi, poiché sono stati costruiti secondo il vecchio codice. Tuttavia, qualsiasi nuovo edificio deve rispettare gli standard più rigorosi. Un "soft fork" funziona allo stesso modo: inasprisce le regole per il futuro, mantenendo validi tutti gli edifici costruiti secondo le vecchie normative.
Analogia sulla riduzione del limite di velocità: immaginate un'autostrada in cui il limite di velocità scende da 70 mph a 55 mph. Le auto già in strada che viaggiano a 55 mph o meno sono in regola sia con le vecchie che con le nuove regole. Ma chi viaggia a 65 mph infrangerebbe la nuova regola, anche se prima era legale. I nodi aggiornati applicano il limite di 55 mph; i nodi non aggiornati considerano ancora le 70 mph come velocità accettabile, ma rilevano solo traffico che viaggia a 55 mph o meno.
L'analogia del codice di abbigliamento al ristorante: un ristorante che prima non aveva un codice di abbigliamento ora richiede un abbigliamento "business casual". I clienti che già indossano un abito (e che quindi soddisfano i nuovi requisiti) possono ancora entrare. I clienti abituali, che conoscono solo la regola "nessun codice di abbigliamento", non vedono nulla di male nella presenza di persone ben vestite. Ma chiunque si presenti in infradito verrà allontanato dal personale aggiornato (i nodi aggiornati), anche se i clienti abituati alle vecchie regole non si sarebbero accorti dell'infrazione.
L'analogia con l'aggiornamento software: è come quando il sistema operativo del telefono riceve un aggiornamento che limita le app che possono accedere alla fotocamera. Le app che già rispettano la privacy della fotocamera funzionano perfettamente. Le app che prima accedevano alla fotocamera senza chiedere ora vengono bloccate. Il telefono continua a eseguire tutte le vecchie app, ma applica autorizzazioni più restrittive in futuro.
Importante: sebbene i soft fork siano meno dirompenti degli hard fork, non sono esenti da rischi. Se i miner si dividono tra utenti con software aggiornato e utenti con software non aggiornato, possono verificarsi interruzioni temporanee della blockchain. Inoltre, le tecniche di retrocompatibilità utilizzate nei soft fork (come far apparire i nuovi tipi di transazione come "accessibili a chiunque" ai vecchi nodi) possono creare problemi di sicurezza temporanei per gli utenti che non hanno aggiornato il software. Si raccomanda sempre di aggiornare il software del nodo all'ultima versione dopo l'attivazione di un soft fork.
Principali caratteristiche tecniche
Meccanismo di compatibilità all'indietro
Le nuove regole sono un sottoinsieme rigoroso delle vecchie regole: qualsiasi blocco valido secondo le nuove regole è valido anche secondo le vecchie regole.
I nodi non aggiornati accettano blocchi dai miner aggiornati senza riconoscere la nuova applicazione delle regole
I nodi aggiornati rifiutano i blocchi che violano le nuove regole, anche se tali blocchi sarebbero validi secondo le vecchie regole.
Questa asimmetria significa che è sufficiente la maggioranza (non l'unanimità) della potenza di calcolo o della quota di partecipazione affinché il fork abbia successo.
Il modello "chiunque può spendere" consente di codificare una nuova semantica nelle transazioni che i vecchi nodi trattano come banalmente valide.
Meccanismi di attivazione
BIP 9 (bit di versione): i miner segnalano la loro prontezza impostando bit specifici nei campi della versione del blocco; l'attivazione avviene quando viene raggiunta una soglia (in genere il 95%) entro un periodo di segnalazione.
BIP 8 (BIP 9 modificato con attivazione forzata): simile al BIP 9 ma include un'opzione di "blocco al timeout" in cui il soft fork si attiva indipendentemente dalla segnalazione dei miner dopo una data specificata, progettato per impedire ai miner di bloccare indefinitamente gli aggiornamenti.
Prova rapida: una variante di BIP 8 utilizzata per Taproot, che offre ai miner una breve finestra temporale (circa tre mesi) per segnalare il proprio supporto con una soglia del 90%, in caso di mancato raggiungimento della quale la comunità prenderà in considerazione percorsi di attivazione alternativi.
Soft Fork attivato dall'utente (UASF): gli operatori dei nodi e i partecipanti economici impongono nuove regole indipendentemente dalla segnalazione dei miner, utilizzando incentivi economici per obbligare i miner alla conformità – una minaccia nota durante il periodo di attivazione di SegWit (BIP 148).
Giorno della bandiera: una data/altezza di blocco predeterminata in cui entrano in vigore nuove regole, indipendentemente dalla segnalazione – il meccanismo più semplice, ma che richiede un ampio consenso sociale
Come funziona una forchetta morbida
Gli sviluppatori propongono una modifica al protocollo e redigono una Bitcoin Improvement Proposal (BIP) che specifica le nuove regole di consenso.
La proposta viene sottoposta a un'ampia revisione paritaria, a test su testnet/signet e a un dibattito nella comunità che dura mesi o anni.
Il codice che implementa le nuove regole viene integrato nel client di riferimento (Bitcoin Core) tramite un meccanismo di attivazione.
Gli operatori dei nodi e i minatori aggiornano il loro software per includere il nuovo codice
I minatori iniziano a segnalare la loro prontezza all'attivazione impostando bit specifici nelle intestazioni dei blocchi
Quando la soglia di segnalazione viene raggiunta entro un periodo definito, il soft fork si "blocca" e si attiva dopo un periodo di grazia.
Dopo l'attivazione, i minatori potenziati producono blocchi conformi alle nuove regole più severe.
I nodi non aggiornati accettano questi blocchi come validi (compatibilità con le versioni precedenti), ma i blocchi che violano le nuove regole vengono abbandonati dalla maggioranza aggiornata.
Gli incentivi economici incoraggiano i miner che non hanno ancora effettuato l'aggiornamento a farlo, poiché i loro blocchi non conformi verrebbero rifiutati dalla blockchain di maggioranza.
SegWit: Anatomia di una forchetta morbida Landmark
Separazione dei dati del testimone (firma) dall'identificativo della transazione, risolvendo il problema di lunga data relativo alla malleabilità delle transazioni.
È stata introdotta una nuova struttura dati "testimone" aggiunta ai blocchi ma invisibile ai vecchi nodi (che vedono un blocco "spogliato" entro il limite di 1 MB).
Aumento della capacità effettiva del blocco da circa 1 MB a circa 2-4 MB a seconda del mix di transazioni (misurata in "unità di peso" - 4 milioni di unità di peso per blocco).
Ha reso possibili i protocolli di secondo livello come Lightning Network, rendendo immutabili gli ID delle transazioni.
È stato utilizzato un sistema di "versioni witness" che consente ai futuri aggiornamenti soft-fork di aggiungere nuove versioni dello script (Taproot ha utilizzato la versione witness 1).
Taproot: Aggiornamento per la privacy e l'efficienza
Sostituzione di ECDSA con firme Schnorr (BIP 340), consentendo l'aggregazione delle firme e la convalida in batch.
È stato introdotto il MAST (Merkelized Alternative Script Trees) tramite il BIP 341, consentendo che le condizioni di spesa complesse rimangano nascoste a meno che non vengano invocate
Ha reso le transazioni multi-firma e con smart contract indistinguibili dalle semplici transazioni a firma singola on-chain
Riduzione delle dimensioni e delle commissioni delle transazioni per gli script complessi, ampliando al contempo la programmabilità di Bitcoin.
Bloccato al blocco 687,284 (12 giugno 2021) e attivato tramite il meccanismo Speedy Trial al blocco 709,632 (14 novembre 2021)
Unisciti a UEEx
Scopri la piattaforma di gestione patrimoniale digitale leader al mondo
Nessuna divisione della catena: la blockchain rimane un'unica catena continua perché i nodi non aggiornati continuano ad accettare i nuovi blocchi come validi.
Il requisito della compatibilità con le versioni precedenti limita significativamente le modifiche che possono essere introdotte; gli aggiornamenti veramente trasformativi potrebbero richiedere hard fork.
Flessibilità di aggiornamento
I partecipanti possono effettuare l'aggiornamento secondo i propri ritmi; non esiste una scadenza "finale" in cui i nodi non aggiornati vengano disconnessi forzatamente.
I nodi non aggiornati potrebbero avere un falso senso di sicurezza, convalidando blocchi che non comprendono appieno (ad esempio, trattando gli output di SegWit come "utilizzabili da chiunque").
Coesione comunitaria
I soft fork sono generalmente meno divisivi a livello politico rispetto agli hard fork perché non impongono ai partecipanti una decisione di aggiornamento totale o nulla.
La percezione di una minore urgenza può portare a un'adozione lenta: ci sono voluti circa cinque anni dall'attivazione di SegWit perché l'adozione si stabilizzasse intorno all'80-85%.
Modello di sicurezza
Per l'applicazione è sufficiente la maggioranza della potenza di calcolo (non l'unanimità), il che rende l'attivazione possibile anche in presenza di alcuni partecipanti contrari.
Se la soglia di potenza di calcolo della maggioranza non viene raggiunta, può verificarsi una divisione temporanea della catena, con cronologie delle transazioni potenzialmente diverse sulle catene aggiornate e non aggiornate.
Eleganza tecnica
Trucchi di codifica intelligenti (versioning dei testimoni, riutilizzo del codice operativo NOP) consentono nuove funzionalità sostanziali all'interno dei framework di regole esistenti
Questi trucchi di codifica aggiungono complessità tecnica e possono creare "debito tecnico", ovvero strati di soluzioni di compatibilità con le versioni precedenti che rendono il codice sorgente più difficile da comprendere nel tempo.
Esperienza dello sviluppatore
Meccanismi di attivazione consolidati (BIP 9, BIP 8, Speedy Trial) forniscono processi strutturati e collaudati per coordinare gli aggiornamenti a livello di rete.
La progettazione del meccanismo di attivazione è di per sé fonte di controversie: il dibattito sull'attivazione di SegWit è durato oltre due anni, in parte a causa di disaccordi sull'opportunità di utilizzare meccanismi segnalati dai miner o attivati dagli utenti.
Segnale di governance
La segnalazione dei minatori fornisce un indicatore misurabile della prontezza dell'ecosistema, consentendo decisioni di attivazione basate sui dati.
La segnalazione dei minatori può essere manipolata o bloccata strategicamente: i minatori possono bloccare gli aggiornamenti che riducono i loro guadagni o modificano l'economia del mining, anche quando la comunità in generale supporta il cambiamento.
Reversibilità
In linea di principio, un soft fork può essere "disgiunto" da un successivo soft fork che allenta nuovamente le regole (anche se ciò è estremamente raro e complesso nella pratica).
L'irreversibilità dei soft fork implementati nella pratica significa che gli aggiornamenti mal progettati possono gravare in modo permanente sul protocollo con decisioni di progettazione non ottimali.
Risk Management
Rischio di divisione della catena e di blocco orfano
Se un soft fork si attiva senza un supporto sufficiente in termini di potenza di calcolo (ad esempio, solo il 60% dei miner effettua l'aggiornamento), la rete potrebbe temporaneamente generare due catene concorrenti: una che segue le nuove regole e una che segue le vecchie. I blocchi della catena minoritaria rimarrebbero orfani una volta che la catena maggioritaria si allinea, causando potenzialmente l'annullamento delle transazioni. Soluzione: utilizzare soglie di attivazione elevate (segnalazione del 90-95%), implementare rollout graduali con periodi di segnalazione prolungati e garantire un ampio consenso dell'ecosistema prima dell'attivazione. Gli utenti dovrebbero attendere ulteriori conferme durante i periodi di attivazione.
Vulnerabilità del nodo non aggiornato
I nodi che non vengono aggiornati dopo l'attivazione di un soft fork potrebbero convalidare le transazioni in modo errato. Ad esempio, un nodo non aggiornato potrebbe accettare una transazione che spende un output SegWit senza verificare i dati del witness, trattandola come un output "utilizzabile da chiunque". Sebbene ciò non metta a rischio l'intera rete (i miner aggiornati applicano le regole reali), i singoli utenti non aggiornati potrebbero essere ingannati da transazioni che la rete aggiornata rifiuterebbe. Soluzione: aggiornare tempestivamente il software dei nodi dopo l'attivazione del soft fork, monitorare i canali ufficiali per gli annunci di aggiornamento e utilizzare SPV (verifica semplificata dei pagamenti) con i peer aggiornati.
Controversie sul meccanismo di attivazione
La scelta del meccanismo di attivazione può diventare fonte di conflitto all'interno della comunità. L'attivazione segnalata dai miner (BIP 9) può essere bloccata da una minoranza di miner, mentre i meccanismi attivati dagli utenti (UASF/BIP 148) comportano il rischio di scissioni della blockchain se il consenso economico viene valutato erroneamente. La controversia sull'attivazione di SegWit ha dimostrato che le dispute sui meccanismi di attivazione possono dominare il dibattito per anni. Soluzioni: costruire un ampio consenso sociale prima di proporre l'attivazione, coinvolgere tempestivamente tutti i gruppi di stakeholder (miner, operatori di nodi, exchange, sviluppatori di wallet) e utilizzare finestre di attivazione a tempo limitato (modello Speedy Trial) per evitare ritardi indefiniti.
Complessità tecnica e bug di implementazione
I vincoli di retrocompatibilità dei soft fork richiedono complessi accorgimenti di codifica che possono introdurre bug subdoli. L'interazione tra le nuove regole del soft fork e la logica di consenso esistente deve essere testata in modo esaustivo. Un bug nell'implementazione del soft fork potrebbe causare fallimenti del consenso, divisioni della blockchain o vulnerabilità di sicurezza. Misure di mitigazione: revisione approfondita da parte di esperti (le proposte di soft fork di Bitcoin Core in genere richiedono dai 12 ai 24 mesi di revisione), suite di test dettagliate, incluso il fuzzing, implementazione su testnet e signet prima della mainnet e attivazione graduale con periodi di monitoraggio.
Impatto economico e di mercato
L'attivazione di un soft fork può creare incertezza sul mercato, soprattutto in presenza di disaccordo all'interno della community in merito all'aggiornamento. Il dibattito su SegWit del 2017 ha coinciso con una significativa volatilità del prezzo di Bitcoin e ha portato, in ultima analisi, all'hard fork di Bitcoin Cash (da parte della fazione opposta). Anche i soft fork di successo possono causare perturbazioni di mercato a breve termine, mentre i partecipanti valutano le implicazioni. Possibili soluzioni: comunicazione chiara sullo scopo e sulla tempistica dell'aggiornamento, coordinamento tra exchange e fornitori di wallet per una transizione senza intoppi ed evitare di effettuare operazioni di trading basate esclusivamente su speculazioni relative al fork.
Rilevanza culturale
I soft fork occupano un posto speciale nella cultura e nella filosofia di governance di Bitcoin. Rappresentano l'approccio conservativo della rete all'evoluzione del protocollo: l'idea che i cambiamenti debbano essere il meno dirompenti possibile, retrocompatibili e realizzabili attraverso un ampio consenso piuttosto che tramite un decreto dall'alto. Questa filosofia riflette i valori fondamentali di Bitcoin, ovvero la decentralizzazione e la sovranità individuale: nessuna singola entità dovrebbe essere in grado di obbligare i partecipanti ad aggiornare il protocollo e la rete dovrebbe continuare a funzionare anche per coloro che scelgono di non farlo.
La saga dell'attivazione di SegWit (2015-2017) è stata un momento cruciale nella storia culturale di Bitcoin. Ha contrapposto i "piccoli blocchi", favorevoli al soft fork di SegWit, ai "grandi blocchi", che desideravano un hard fork per aumentare la dimensione dei blocchi. Il dibattito non era meramente tecnico: si trattava di una guerra per procura sull'identità, la governance e la direzione futura di Bitcoin. L'attivazione finale di SegWit, ottenuta grazie alla pressione della comunità e al movimento UASF, ha stabilito il precedente secondo cui gli utenti e gli operatori di nodi di Bitcoin, e non solo i miner, hanno un'influenza significativa sulle regole del protocollo. La narrazione secondo cui "gli operatori di nodi detengono il vero potere" rimane un pilastro della cultura di governance di Bitcoin.
Il movimento UASF, simboleggiato dalla campagna BIP 148 e dai meme ad essa associati, ha dimostrato che l'attivazione del soft fork è tanto un problema di coordinamento sociale quanto tecnico. Il movimento è associato alla frase "No2x" (in opposizione al compromesso hard fork SegWit2x) e ha dimostrato che una comunità motivata di operatori di nodi può fare pressione sui miner affinché attivino un aggiornamento, minacciando di invalidare i blocchi non di segnalazione.
L'attivazione relativamente agevole di Taproot nel 2021, tramite il meccanismo Speedy Trial, è stata vista da molti nella comunità come una maturazione del processo di governance di Bitcoin. Le lezioni apprese dalle guerre di SegWit hanno portato a un approccio più snello, sebbene i dibattiti sulle future proposte di soft fork (OP_CTV, OP_CAT, OP_VAULT) continuino a mettere alla prova la capacità della comunità di raggiungere un consenso sulle modifiche al protocollo. Il peso culturale dei soft fork in Bitcoin va oltre la loro funzione tecnica: rappresentano un meccanismo fondamentale attraverso il quale la comunità gestisce la tensione tra innovazione e stabilità.
Unisciti a UEEx
Scopri la piattaforma di gestione patrimoniale digitale leader al mondo
Esempio 1: Attivazione di Segregated Witness (SegWit) – Bitcoin
Scenario: Bitcoin ha riscontrato un bug di malleabilità delle transazioni che ha impedito la creazione affidabile di canali di pagamento (necessari per il Lightning Network) e un crescente accumulo di transazioni non confermate, poiché i blocchi raggiungevano costantemente il limite di 1 MB. Era urgentemente necessario un aumento di capacità senza suddividere la rete.
Implementazione: SegWit (BIP 141) è stato progettato come un soft fork che separava i dati dei testimoni dagli ID delle transazioni, risolvendo il problema della malleabilità e aumentando al contempo la capacità effettiva dei blocchi attraverso una nuova metrica di "peso del blocco". Dopo un lungo dibattito e la minaccia di un Soft Fork attivato dagli utenti (UASF tramite BIP 148), i miner hanno raggiunto la soglia di segnalazione del 95% l'8 agosto 2017 e SegWit è stato attivato. L'attivazione è avvenuta al blocco 481,824 il 24 agosto 2017.
Esito: SegWit è stato attivato con successo senza causare una divisione della blockchain sulla rete Bitcoin (sebbene in seguito gli oppositori abbiano creato Bitcoin Cash tramite un hard fork). La malleabilità delle transazioni è stata corretta, consentendo alla Lightning Network di passare da una fase sperimentale a una rete in grado di gestire un volume significativo di pagamenti. Nel 2026, circa l'85-90% delle transazioni Bitcoin utilizzava almeno un input SegWit. L'aggiornamento ha dimostrato che i controversi soft fork potevano essere risolti attraverso una combinazione di merito tecnico, pressione economica e coordinamento della comunità.
Esempio 2: Attivazione Taproot – Bitcoin
Scenario: Le capacità di scripting di Bitcoin erano limitate, le transazioni complesse con firme multiple e i contratti intelligenti erano costosi e compromettevano la privacy (esponendo l'intero script sulla blockchain), e le firme ECDSA non potevano essere aggregate in modo efficiente. Era necessario un aggiornamento per migliorare la privacy, l'efficienza e la programmabilità.
Implementazione: Taproot (BIP 340, 341, 342) ha combinato le firme Schnorr, MAST e una nuova versione dello script (witness v1) in un unico soft fork. Utilizzando il meccanismo di attivazione Speedy Trial (una finestra di segnalazione a tempo limitato), i miner hanno raggiunto la soglia di segnalazione del 90%, bloccando l'aggiornamento il 12 giugno 2021 al blocco 687,284. Taproot si è quindi attivato al blocco 709,632 il 14 novembre 2021, dopo un periodo di grazia di circa cinque mesi per la preparazione dell'ecosistema.
Esito: L'attivazione di Taproot è stata notevolmente fluida rispetto a SegWit, senza significative interruzioni di rete. Ha consentito l'utilizzo di schemi multi-firma basati su Schnorr che appaiono identici alle transazioni a firma singola sulla blockchain, migliorando la privacy. MAST ha permesso di mantenere nascoste condizioni di spesa complesse, a meno che non vengano attivate, riducendo le dimensioni delle transazioni. L'adozione di Taproot è stata discontinua: ha raggiunto un picco di oltre il 40% delle transazioni all'inizio del 2024 a causa dell'attività legata a Ordinals e Runes, per poi stabilizzarsi intorno al 15-20% con il raffreddamento di tale attività speculativa.
Esempio 3: P2SH (Pay-to-Script-Hash) – Bitcoin
Scenario: Nei primi anni di Bitcoin, l'invio di transazioni a script complessi (portafogli multi-firma, contratti a tempo determinato) richiedeva al mittente di includere l'intero script nella transazione, il che risultava macchinoso, costoso ed esponeva pubblicamente le condizioni di spesa prima che i fondi venissero effettivamente utilizzati.
Implementazione: BIP 16 (proposto da Gavin Andresen nel gennaio 2012) ha introdotto P2SH come soft fork che consentiva ai mittenti di pagare all'hash di uno script anziché allo script stesso. Lo script completo sarebbe stato rivelato solo al momento della spesa dei fondi. I nodi più vecchi consideravano gli output P2SH come un tipo di transazione standard, mantenendo la compatibilità con le versioni precedenti. Il soft fork è stato attivato il 1° aprile 2012.
Risultato: P2SH ha semplificato drasticamente l'uso di portafogli multi-firma e script complessi, diventando il fondamento dell'ecosistema multi-firma di Bitcoin. Ha stabilito il modello di codifica delle nuove funzionalità all'interno di formati di transazione retrocompatibili, un modello che SegWit e Taproot avrebbero poi seguito. Gli indirizzi P2SH (che iniziano con "3") sono diventati onnipresenti e rimangono ampiamente utilizzati ancora oggi. L'aggiornamento è considerato uno dei soft fork più puliti e di maggior successo nella storia di Bitcoin.
Esempio 4: La fusione di Ethereum (contesto per la discussione su Soft Fork e Hard Fork)
Scenario: Sebbene la transizione di Ethereum dal proof-of-work al proof-of-stake (The Merge, settembre 2022) sia stata tecnicamente un hard fork, il processo ha messo in luce il compromesso tra soft fork e hard fork in un diverso ecosistema blockchain in cui gli hard fork rappresentano il meccanismo di aggiornamento standard.
Implementazione: Storicamente, la cultura di sviluppo di Ethereum ha privilegiato gli hard fork per gli aggiornamenti del protocollo, con hard fork programmati regolarmente (Istanbul, Berlino, Londra, ecc.) all'incirca ogni 6-12 mesi. La Merge stessa ha richiesto l'aggiornamento di tutti i nodi, un hard fork per definizione. Questo contrasta con la preferenza di Bitcoin per i soft fork, riflettendo diverse filosofie di governance: Ethereum dà priorità all'innovazione rapida e accetta i costi di coordinamento degli hard fork, mentre Bitcoin dà priorità alla stabilità e alla retrocompatibilità tramite i soft fork.
Esito: L'esecuzione efficace degli hard fork regolari da parte di Ethereum dimostra che questi possono funzionare quando esiste un forte consenso sociale e una chiara struttura di leadership tra gli sviluppatori principali. Tuttavia, questo approccio ha anche prodotto scissioni della blockchain (Ethereum Classic nel 2016) quando il consenso è venuto meno. Il contrasto tra la cultura di Bitcoin, che privilegia i soft fork, e la normalizzazione degli hard fork di Ethereum illustra come le diverse comunità blockchain risolvano la tensione fondamentale tra velocità di innovazione e stabilità della rete.
Tavola di comparazione
Caratteristica
Forchetta morbida
Forcella dura
Biforcazione controversa (divisione della catena)
Retrocompatibilità
Sì, i nodi non aggiornati accettano i nuovi blocchi come validi
No, i nodi non aggiornati rifiutano i nuovi blocchi, creando una divisione
No, la rete si divide intenzionalmente in due catene incompatibili.
Requisito di aggiornamento
Opzionale (ma consigliato): i nodi possono continuare a funzionare senza aggiornamento.
Obbligatorio: tutti i nodi devono essere aggiornati o rimarranno su una catena incompatibile.
I partecipanti devono scegliere quale catena seguire; nessun aggiornamento è “neutrale”.
Continuità della catena
Catena continua singola (ipotizzando l'adozione della potenza di calcolo maggioritaria)
Catena unica se adottata all'unanimità; due catene in caso di disaccordo.
Due catene permanenti per definizione (ad esempio, Bitcoin contro Bitcoin Cash)
Direzione della modifica delle regole
È possibile solo inasprire le regole (ridurre l'insieme valido) o aggiungere nuovi tipi di transazione tramite accorgimenti di retrocompatibilità.
È possibile inasprire o allentare le regole, modificare la struttura dei blocchi e alterare i parametri fondamentali.
Rappresenta un disaccordo fondamentale sulle regole che la catena dovrebbe seguire.
Soglia di attivazione
Potenza di calcolo della maggioranza (minimo ~51%; in genere 90-95% per sicurezza)
Richiede un ampio consenso sociale; nessuna soglia di segnalazione formale può garantire il successo
Nessuna soglia: qualsiasi gruppo può creare una biforcazione della catena in qualsiasi momento.
Generalmente meno invasivo; può comunque essere controverso (il dibattito su SegWit è durato più di due anni).
Costi di coordinamento più elevati; può causare divisioni permanenti all'interno della comunità in caso di mancanza di consenso.
Estremamente divisivo; crea comunità, marchi ed ecosistemi economici concorrenti.
Termini correlati
Forcella dura: Un aggiornamento del protocollo non retrocompatibile che richiede l'aggiornamento di tutti i nodi, con la potenziale conseguenza di dividere la catena – l'equivalente di un soft fork.
SegWit (Segregated Witness): il soft fork di Bitcoin del 2017, che ha separato i dati del witness dalle transazioni per risolvere i problemi di malleabilità e aumentare la capacità dei blocchi.
Taproot: un soft fork di Bitcoin del 2021 che introduce le firme Schnorr e MAST per migliorare la privacy, l'efficienza e le funzionalità dei contratti intelligenti.
BIP (Bitcoin Improvement Proposal): Il processo formale attraverso il quale le proposte di soft fork vengono documentate, esaminate e standardizzate per la rete Bitcoin.
Regole di consenso: L'insieme di regole di validazione su cui tutti i partecipanti alla rete devono concordare – i soft fork modificano queste regole in modo retrocompatibile.
UASF (User Activated Soft Fork): un meccanismo di attivazione in cui gli operatori dei nodi impongono nuove regole indipendentemente dalla segnalazione dei miner, enfatizzando la sovranità dell'utente sul controllo dei miner.
Segnalazione dei miner: il processo mediante il quale i miner indicano la propria disponibilità per un soft fork impostando bit specifici nelle intestazioni dei blocchi, utilizzato in BIP 9 e nell'attivazione di Speedy Trial.
Rete Lightning: A Strato 2 Una rete di canali di pagamento resa possibile dalla correzione apportata da SegWit alla malleabilità delle transazioni, a dimostrazione di come i soft fork possano sbloccare l'innovazione dell'ecosistema.
Malleabilità delle transazioni: un bug nella progettazione originale di Bitcoin che permetteva di modificare gli ID delle transazioni senza invalidarle – risolto dal soft fork SegWit.
Schnorr Signatures: uno schema di firma digitale introdotto nel soft fork di Taproot che consente l'aggregazione delle firme e la convalida in batch per una maggiore efficienza e privacy.
Peso del blocco: una metrica introdotta da SegWit che ha sostituito il semplice limite di dimensione del blocco, misurando i blocchi in "unità di peso" per incentivare l'adozione del nuovo formato di transazione.
albero di merkle: Una struttura dati crittografica utilizzata nei blocchi blockchain su cui si basa MAST (Merkelized Alternative Script Trees) di Taproot per una verifica efficiente degli script.
FAQ
Qual è la differenza tra un soft fork e un hard fork? Un soft fork inasprisce le regole di consenso, riducendo l'insieme dei blocchi validi: i nodi non aggiornati continuano ad accettare i nuovi blocchi perché questi sono conformi alle vecchie regole, meno restrittive. Un hard fork, invece, allenta o modifica le regole in modo che i nuovi blocchi vengano rifiutati dai nodi meno recenti, obbligando tutti ad aggiornare il proprio sistema. In breve, i soft fork sono retrocompatibili (il vecchio software funziona), mentre gli hard fork non lo sono (il vecchio software smette di funzionare). Bitcoin predilige i soft fork per garantire la stabilità; Ethereum utilizza regolarmente gli hard fork per accelerare l'innovazione.
Un soft fork può causare la divisione di una blockchain in due catene? In teoria, un soft fork non dovrebbe causare una divisione permanente della catena perché i nodi non aggiornati continuano ad accettare i nuovi blocchi. Tuttavia, una divisione temporanea può verificarsi se una minoranza significativa di miner continua a produrre blocchi secondo le vecchie regole che violano le nuove. La maggioranza aggiornata "orfana" questi blocchi e la catena convergerà sulle nuove regole. Una divisione permanente si verificherebbe solo se la comunità fosse in disaccordo fondamentale e la minoranza effettuasse intenzionalmente un fork, ma tecnicamente si tratterebbe di un hard fork da parte della minoranza, non di una conseguenza del soft fork stesso.
Perché Bitcoin preferisce i soft fork agli hard fork? La cultura di sviluppo di Bitcoin privilegia la stabilità, la retrocompatibilità e la minimizzazione del carico di coordinamento per i partecipanti alla rete. I soft fork consentono alla rete di aggiornarsi senza richiedere l'aggiornamento simultaneo di ogni nodo, riducendo il rischio di divisioni della blockchain. Questo approccio conservativo riflette l'etica di Bitcoin come rete decentralizzata e senza leader, dove nessuna singola entità può imporre aggiornamenti. Gli hard fork, che richiedono la partecipazione universale, sono visti da molti nella comunità Bitcoin come più dirompenti e inclini a divisioni controverse (come dimostrato da Bitcoin Cash nel 2017).
Cos'è stato il soft fork SegWit e perché è stato importante? Segregated Witness (SegWit), attivato nell'agosto 2017, è stato un soft fork che ha separato i dati della firma della transazione (witness) dall'ID della transazione. Questo ha risolto il bug della malleabilità delle transazioni (per cui terze parti potevano alterare gli ID delle transazioni), consentendo soluzioni di secondo livello come il Lightning Network. Ha anche aumentato la capacità effettiva dei blocchi introducendo una metrica di "peso del blocco". SegWit è stato probabilmente l'aggiornamento più influente e controverso nella storia di Bitcoin fino a quel momento, con un dibattito sulla sua implementazione durato oltre due anni.
In che modo Taproot migliora Bitcoin? Taproot (attivato a novembre 2021) ha introdotto tre miglioramenti chiave tramite soft fork: (1) le firme Schnorr, che sono più efficienti di ECDSA e consentono l'aggregazione delle firme; (2) MAST (Merkelized Alternative Script Trees), che consente di mantenere nascoste le condizioni complesse degli smart contract a meno che non vengano utilizzate, migliorando la privacy e riducendo le commissioni; (3) un nuovo sistema di versioni degli script che rende le transazioni complesse e multi-firma identiche ai semplici pagamenti on-chain. Insieme, questi cambiamenti rendono Bitcoin più privato, più efficiente e più programmabile.
Cosa significa effettivamente "retrocompatibile" nel contesto di un soft fork? Retrocompatibile significa che i nodi che eseguono software obsoleto (precedente al soft fork) possono ancora partecipare alla rete e convalidare i nuovi blocchi. Non è necessario che eseguano un aggiornamento per rimanere connessi. Questo è possibile perché le nuove regole sono più rigorose delle precedenti: qualsiasi blocco valido secondo le nuove regole è automaticamente valido anche secondo le vecchie. Tuttavia, i nodi non aggiornati potrebbero non comprendere appieno la semantica dei nuovi tipi di transazione; potrebbero considerarli banalmente validi anziché eseguire una convalida completa. Per questo motivo, l'aggiornamento è comunque consigliato, anche se non obbligatorio.
Che cos'è un Soft Fork Attivato dall'Utente (UASF)? Un UASF è un metodo di attivazione di un soft fork in cui gli operatori dei nodi (anziché i miner) impongono le nuove regole. Invece di attendere che i miner segnalino la propria disponibilità, gli operatori dei nodi impostano un'altezza di blocco o una data specifica dopo la quale rifiuteranno i blocchi che non sono conformi alle nuove regole. Questo esercita una pressione economica sui miner affinché si conformino, poiché i blocchi rifiutati dagli operatori dei nodi non possono contenere transazioni valide o generare commissioni. La minaccia UASF più famosa è stata la BIP 148 durante l'attivazione di SegWit, ampiamente considerata come uno dei fattori che hanno contribuito a catalizzare la segnalazione da parte dei miner. Gli UASF rappresentano il principio secondo cui, nei sistemi proof-of-work, i nodi economici – e non solo i miner – esercitano un'influenza significativa sulle regole di consenso.
fonti
Documentazione di Bitcoin Core: "Attivazione del Soft Fork"
Archivio delle proposte di miglioramento di Bitcoin (BIP)
