Vai al contenuto
Financial Context Wiki

Hard fork e soft fork: compatibilità, attivazione e divisione della catena

Hard fork e soft fork descrivono rapporti diversi di compatibilità tra vecchie e nuove regole di consenso. Occorre analizzare separatamente insiemi di blocchi validi, attivazione, verifica dei nodi, produttori, preparazione operativa, rischio di replay e ogni divisione della catena.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Hard fork e soft fork classificano una modifica alle regole di consenso in base a come i nodi aggiornati e non aggiornati giudicano i blocchi. Sia V_old l’insieme accettato dalle vecchie regole e V_new quello nuovo. Un soft fork limita la validità così che V_new subset V_old: ogni blocco valido secondo le nuove regole è valido anche secondo le vecchie, ma il vecchio nodo non applica il vincolo aggiunto. Un hard fork consente almeno un blocco valido nuovo che il vecchio nodo rifiuta: exists b: b in V_new and b not in V_old. Gli insiemi possono essere un’espansione o risultare incomparabili; “hard” non significa solo blocco più grande o funzione più radicale.

La compatibilità è asimmetrica. In un soft fork riuscito, i nodi non aggiornati restano sulla stessa catena perché accettano i blocchi dei produttori aggiornati, ma possono accettare ciò che i nuovi nodi rifiutano e offrire garanzie inferiori. In un hard fork, appena un produttore crea un blocco fuori dal vecchio insieme valido, i vecchi nodi non possono seguirlo. Se partecipanti economicamente rilevanti sostengono entrambi gli insiemi, possono nascere due reti durevoli; se un lato non ha supporto effettivo, non devono necessariamente restare due asset.

Le etichette descrivono regole, non legittimità della governance, sicurezza, sostegno economico o metodo di attivazione. Una proposta può essere detta hard fork prima dell’attivazione, una modifica attivata può non generare una divisione durevole e un’incompatibilità involontaria può dividere la catena senza voto. La segnalazione dei produttori coordina la preparazione, ma non rende valido per un full node un blocco rifiutato dalle sue regole.

Non confondere un fork di consenso con una biforcazione temporanea a regole uguali, una riorganizzazione, un fork del repository o un aggiornamento applicativo. La domanda operativa è quale rete, insieme di regole, condizione di attivazione e cronologia riconosca ogni nodo, wallet, exchange, custode, oracolo e contratto.

Come analizzare un fork di protocollo

  1. Fissare identità e ambito. Registrare chain, network, client version, proposta di attivazione, genesi o checkpoint finalizzato, hash corrente e livello interessato. Lo stesso nome su testnet, mainnet, esecuzione, consenso o applicazione può indicare regole diverse.
  2. Confrontare la validità di consenso. Elencare ogni regola modificata per blocchi, transazioni, firme, transizioni di stato, gas, timestamp, finalità o fork choice. Classificare oggetti rappresentativi come valid, invalid o unknown in entrambe le versioni; le note di rilascio non bastano.
  3. Dimostrare il rapporto tra insiemi. Verificare se ogni oggetto valido nuovo resta valido con le vecchie regole. In tal caso è possibile la compatibilità soft fork; un solo blocco valido nuovo ma invalido prima richiede per quei nodi una transizione hard fork. Testare anche gli oggetti prima validi che diventano invalidi.
  4. Riprodurre l’attivazione. Verificare altezza, epoca, tempo mediano, soglia di segnalazione, ritardo di lock-in, difficoltà totale o trigger di governance nella specifica e nel codice distribuiti. Segnalazione, lock-in, attivazione e applicazione sono stati distinti.
  5. Mappare i partecipanti. Misurare il peso di produzione aggiornato e identificare full node, relay, wallet, exchange, custodi, bridge, emittenti di stablecoin, oracoli e contratti per ciascun lato. Hashrate o stake da soli non determinano l’accettazione economica.
  6. Seguire divisione e transazioni. Tracciare hash genitori e validità con entrambi gli insiemi. Controllare conferme, divergenza del mempool, protezione replay, formati degli indirizzi, chain ID, domini di firma, percorsi di prelievo ed esecuzione su entrambi i rami.
  7. Impostare controlli operativi. Sospendere o allungare il regolamento se l’ascendenza è ambigua; aggiornare e fare backup con metodo; riconciliare saldi e passività per ramo; testare firma e recupero offline; riprendere solo con criteri espliciti di catena, nodo, controparte e finalità.

Il metodo separa quattro eventi spesso compressi in “fork”: proposta di regola, condizione di attivazione, divergenza osservata e successiva sopravvivenza economica di uno o più rami. Nessuno dimostra automaticamente il successivo.

Esempi svolti

1. Compatibilità degli insiemi validi

Supponiamo che le vecchie regole accettino 100 forme di blocco e le nuove solo 80. Se queste 80 sono tutte nell’insieme vecchio, esiste la relazione soft fork; le altre 20 forme valide prima sono respinte dai nodi aggiornati. I numeri illustrano insiemi, non probabilità o soglie di voto.

Se le nuove regole accettano una forma che ogni vecchio nodo rifiuta, questo solo controesempio interrompe l’accettazione retroattiva anche se quasi tutti gli altri blocchi sono validi in entrambi i sistemi. La durata della divisione dipende poi da produttori, utenti e infrastruttura economica.

2. L’attivazione di BIP 34 non è la definizione

BIP 34 impose l’altezza nella transazione coinbase e usò un meccanismo mobile di preparazione. Con 750 of 1,000 blocchi precedenti di versione 2 o superiore si respingevano blocchi versione 2 invalidi; dopo 950 of 1,000 anche quelli versione 1. Il BIP indica il blocco 227,835 come ultimo di versione 1.

Le soglie coordinarono il deployment, ma non definirono il soft fork. La compatibilità derivava dai nodi aggiornati più restrittivi mentre i vecchi client accettavano blocchi conformi. In seguito BIP 9 separò stati di deployment e bit di versione, distinguendo rapporto tra regole e meccanismo di attivazione.

3. Segregated Witness come soft fork

BIP 141 introdusse dati witness e impegnò il relativo albero tramite la transazione coinbase nella struttura esistente. I vecchi nodi potevano accettare blocchi conformi senza validare le nuove regole witness, mentre quelli aggiornati le applicavano.

È accettazione retroattiva, non verifica equivalente. Un vecchio nodo può vedere gli output disciplinati dalle nuove regole come meno vincolati; chi dipende dalle nuove proprietà di sicurezza necessita di verifica aggiornata. “Il vecchio software continua a funzionare” non completa l’analisi del rischio.

4. Il DAO Fork di Ethereum

EIP-779 documenta il DAO Fork al blocco mainnet 1,920,000: una modifica irregolare dello stato trasferì saldi dall’elenco L al contratto WithdrawDAO, senza cambiare opcode EVM, formato delle transazioni o struttura dei blocchi.

I nodi che applicarono la transizione e quelli che la rifiutarono calcolarono stati diversi. Un hard fork non richiede quindi blocchi più grandi o nuovi opcode: basta una regola di transizione una tantum, e il sostegno continuato a entrambe le storie può preservare reti separate.

Rischi ed errori di revisione

Errori di classificazione e specifica

  • Chiamare hard fork ogni punta concorrente temporanea, anche se tutti usano le stesse regole e la normale fork choice la risolve.
  • Definire ogni allentamento hard fork e ogni restrizione soft fork senza testare i veri insiemi validi.
  • Equiparare accettazione retroattiva e piena sicurezza; i vecchi nodi non applicano i nuovi vincoli.
  • Dedurre il consenso da marchio, roadmap, release note o ramo del repository anziché da codice e parametri distribuiti.
  • Mescolare aggiornamenti mainnet, testnet, esecuzione, consenso, bridge, rollup e applicazioni.
  • Considerare proposta, rilascio client, segnalazione, lock-in e attivazione lo stesso evento.
  • Trattare il segnale dei produttori come voto vincolante di utenti, exchange, custodi o full node.

Rischi di divisione e transazione

  • Supporre che l’attivazione garantisca una divisione o che la divisione garantisca due asset liquidi e durevoli.
  • Usare solo l’altezza quando i rami possono avere blocchi diversi alla stessa altezza; verificare hash e ascendenza.
  • Inviare durante la divisione senza verificare replay, chain ID, domini di firma e costruzione specifica del ramo.
  • Accreditare depositi su un ramo e regolare passività o prelievi sull’altro.
  • Dipendere da un solo explorer, RPC o etichetta di custodia quando i provider possono seguire regole diverse o essere in ritardo.
  • Ignorare riorganizzazioni, finalità bloccata, partizioni, mining minoritario, equivoci o dati non disponibili.
  • Presumere uguale garanzia dell’emittente per ticker, contratto, stablecoin, prezzo oracle o credito bridge sui due rami.

Rischi di governance e operativi

  • Presentare la compatibilità come prova di legittimità, decentralizzazione, sicurezza o sostegno economico.
  • Aggiornare nodi di produzione senza binari riproducibili, backup, limiti di rollback, test di migrazione e hash indipendenti.
  • Presumere sempre sicuro il downgrade dopo nuovi dati di stato, formati wallet o condizioni di slashing.
  • Spostare chiavi o “rivendicare coin del fork” con software non verificato che può esporre segreti o ripetere firme.
  • Considerare spendibili i saldi snapshot senza verificare maturità, blocchi, stato del contratto e regole del custode.
  • Concludere su imposte, contabilità o valore prima di stabilire proprietà, controllo, liquidità e norme locali.

Errori comuni

  • Un hard fork crea sempre una nuova moneta. Un secondo asset richiede produzione continua, utenti, infrastruttura e mercato; molti aggiornamenti convergono su una storia.
  • Un soft fork è privo di rischio perché i vecchi nodi funzionano. Possono seguire la catena ma non applicano la nuova regola e verificano meno.
  • La maggioranza di hash o stake può cambiare da sola ogni regola. I full node rifiutano blocchi invalidi per le proprie regole; il peso agisce solo tra blocchi accettati.
  • Hard significa controverso e soft unanime. I termini classificano la compatibilità, non consenso sociale, qualità della governance o controversia.
  • Ogni fork visto da un explorer è un aggiornamento. Blocchi concorrenti con regole uguali e riorganizzazioni avvengono senza cambiare il consenso.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...