Finalità, fork e riorganizzazioni

Perché questa lezione torna sulla finalità

Il Modulo 1 ha introdotto la finalità come questione pratica: quando può un utente o un’istituzione considerare regolato un trasferimento registrato? Questa lezione approfondisce i meccanismi di consenso sottostanti, invece di ripetere la prospettiva introduttiva. Una blockchain può contenere blocchi proposti di recente la cui posizione è ancora soggetta a modifiche. Partecipanti distinti possono costruire temporaneamente su storici validi differenti, ma il protocollo ha bisogno di una regola per convergere su un unico ramo accettato. La finalità descrive la solidità e la natura della garanzia che una determinata cronologia rimanga accettata. La scelta del fork, le soglie di voto e l’accumulo di lavoro spiegano perché il livello di fiducia cambia nel tempo.

È essenziale distinguere tra una transazione osservata, una transazione inclusa e una transazione finalizzata. Una transazione osservata è stata annunciata a una parte della rete. Una transazione inclusa compare in un blocco proposto o accettato. Una transazione finalizzata è protetta dalla condizione di regolamento più solida dichiarata dal sistema, se il sistema ne definisce una. Questi termini non significano che una banca, un tribunale, un registro o un’agenzia corrispondenti abbiano completato tutte le procedure esterne. Anche dopo la finalizzazione a livello di protocollo, al di fuori della struttura dati della blockchain possono ancora esistere rettifiche amministrative o rimedi legali.

Cosa crea un fork

Un fork si verifica quando blocchi o cronologie differenti si sviluppano a partire da un punto comune oppure quando le comunità adottano regole di protocollo diverse. Queste situazioni non vanno confuse. Un fork temporaneo dei blocchi può verificarsi naturalmente perché i messaggi richiedono tempo per propagarsi: vengono proposti due blocchi validi per la stessa posizione prima che tutti i nodi ne siano a conoscenza. Un fork di protocollo può anche derivare da modifiche software che cambiano i blocchi che i partecipanti considerano validi. In quest’ultimo caso, le differenze nei set di regole possono persistere, anziché essere risolte con la normale selezione del ramo. Una descrizione a livello formativo deve specificare quale significato di fork si intende.

Una riorganizzazione, spesso abbreviata in reorg, si verifica quando un nodo modifica la testa della catena selezionata e passa a un altro ramo valido secondo le regole di scelta del fork del protocollo. I blocchi che in precedenza facevano parte del ramo selezionato potrebbero non farne più parte. Le transazioni contenute in tali blocchi possono quindi avere diversi esiti: alcune vengono incluse nuovamente nel ramo alternativo, altre restano idonee a essere incluse in seguito e altre ancora diventano non valide a causa di transazioni in conflitto o di modifiche allo stato. Una riorganizzazione, pertanto, non significa che ogni transazione interessata scompaia definitivamente e non dimostra necessariamente che qualcuno abbia attaccato la rete.

Una cronologia esemplificativa

Al tempo uno, i nodi concordano sul blocco P. In seguito, vengono costruite due proposte, A1 e B1, a partire da P. Inizialmente, alcuni nodi selezionano il ramo che passa per A1 perché lo hanno rilevato per primo o perché soddisfa temporaneamente i criteri locali di scelta del fork. Al tempo due, il ramo che passa per B1 acquisisce un peso sufficiente, definito dal protocollo, per essere preferito. I nodi che avevano selezionato A1 si riorganizzano e passano al ramo B. Annullano le modifiche allo stato associate ai blocchi rimossi e applicano i blocchi sostitutivi nella sequenza appropriata. L’elaborazione interna precisa dipende dal protocollo, ma il risultato concettuale è una nuova cronologia canonica.

Fiducia probabilistica nella proof of work

In una tipica rete proof-of-work, la quantità cumulativa di lavoro valido a sostegno di un ramo aumenta man mano che vi vengono aggiunti altri blocchi. Una transazione ottiene conferme quando vengono aggiunti blocchi dopo quello che la include, sebbene i criteri di conteggio varino; alcune interfacce considerano il blocco iniziale come la prima conferma. Con l’accumularsi di altro lavoro, sostituire il ramo contenente quella transazione diventa generalmente più difficile, in base a ipotesi sulla quota di hash rate dell’attaccante e sul comportamento dei miner concorrenti. Si tratta di fiducia probabilistica, non di una promessa matematica esplicita che l’inversione sia impossibile dopo un numero esatto di conferme.

Il numero di conferme non va considerato separatamente dal modello di sicurezza della rete. È importante sapere se il nodo ha convalidato integralmente i blocchi pertinenti, se la rete sta subendo riorganizzazioni insolite e se un avversario può disporre di risorse computazionali sostanziali. Destinatari diversi possono scegliere soglie operative diverse per azioni che comportano rischi differenti. Un conteggio standardizzato può essere utile per le procedure interne, ma non è una legge di natura. Il documento originale di Bitcoin illustra questo modello di catena basato sul lavoro; anche NIST IR 8202 descrive il consenso e i fork senza suggerire che i soli collegamenti hash impediscano ogni riorganizzazione.

Finalità esplicita in alcuni sistemi proof-of-stake

Alcuni protocolli PoS aggiungono un processo in cui i validatori attestano o votano a favore di checkpoint e, al raggiungimento di una soglia, contrassegnano come finalizzata la cronologia precedente. Un checkpoint è una posizione identificata in modo specifico nella catena e utilizzata per le decisioni di consenso. Nel design Casper FFG di Ethereum, checkpoint giustificati collegati possono portare alla finalizzazione, sulla base del voto di una supermaggioranza dello stake. Si intende che annullare un blocco finalizzato sia estremamente oneroso, perché una finalizzazione in conflitto richiederebbe gravi violazioni delle ipotesi e l’applicazione di penalità ai validatori pertinenti. Altre reti PoS implementano soglie, voti o terminologie differenti; alcune non offrono affatto una finalità esplicita comparabile.

La finalità esplicita non significa che un dispositivo o un’istituzione possano smettere di monitorare la rete dopo aver ricevuto un messaggio favorevole. Chi osserva la rete ha bisogno di dati accurati provenienti dai nodi, di comprendere la regola di finalità e di protezioni ragionevoli contro fonti di informazioni disoneste o compromesse. Durante un incidente di rete, la finalizzazione può interrompersi mentre i blocchi continuano a essere proposti, oppure i client software possono temporaneamente non concordare sullo stato. Gli operatori dovrebbero distinguere tra «finalità ritardata» e «cronologia precedentemente finalizzata invertita». Il primo caso può essere un problema di disponibilità o di operatività; il secondo solleva una questione sostanzialmente diversa sulle ipotesi di sicurezza del protocollo o sulla sua implementazione.

La scelta del fork può cambiare prima della finalità

Nei design che combinano la scelta del fork e la finalità dei checkpoint, la testa della catena può cambiare mentre l’ultimo checkpoint finalizzato resta invariato. È facile non cogliere questa distinzione se un pannello di controllo mostra soltanto l’altezza dell’ultimo blocco. La punta preferita è una rappresentazione operativa dei progressi recenti; il checkpoint finalizzato è un confine di consenso più solido. Una transazione vicina alla punta può essere inclusa senza essere ancora protetta dalla finalizzazione. Per un’istituzione che attende prima di aggiornare un altro sistema, registrare entrambi gli stati può evitare che una fase iniziale del flusso di lavoro venga scambiata per un regolamento completato.

Le modifiche alle regole del protocollo sono un fenomeno distinto

In genere, un soft fork restringe le regole di validità in modo da preservare determinate proprietà di compatibilità per i nodi che applicano regole più datate. Un hard fork introduce modifiche non retrocompatibili secondo le regole di convalida pertinenti. Queste descrizioni semplificate sono comuni, ma non vanno usate per dedurre l’esito della governance di ogni aggiornamento. I partecipanti alla rete possono scegliere software diversi, i miner o i validatori possono esprimere le proprie preferenze e le organizzazioni possono comunicare con le proprie comunità. La compatibilità del protocollo, il coordinamento della comunità, gli identificativi legali e la denominazione sul mercato sono questioni diverse. Un aggiornamento controverso può produrre cronologie persistenti; un aggiornamento ordinario potrebbe non farlo.

I responsabili dovrebbero evitare di considerare ogni elemento etichettato come «fork» una prova di un incidente di sicurezza. Una modifica ingegneristica può essere pianificata, mentre in una rete decentralizzata può essere prevedibile un ramo concorrente di breve durata. Al contrario, una riorganizzazione profonda e inattesa può richiedere un’indagine urgente. La prima domanda appropriata è che cosa sia cambiato: l’ordine dei blocchi a parità di regole oppure l’insieme delle regole accettate dai partecipanti? Modifiche diverse richiedono risposte, registrazioni e comunicazioni agli utenti diverse.

Monitoraggio e decisioni istituzionali

Un piano di monitoraggio operativo può tenere traccia della testa della catena selezionata, dell’ultima altezza o slot convalidato integralmente, del checkpoint finalizzato più recente ove applicabile, della profondità osservata delle riorganizzazioni, della partecipazione dei validatori o del lavoro di rete e delle discrepanze tra fonti di informazioni indipendenti. Il piano di monitoraggio dovrebbe definire con precisione il significato di ciascuna metrica. Dovrebbe inoltre distinguere i guasti del software client dagli esiti del consenso. Un avviso che indica «blocco sostituito» può essere ordinario in determinate circostanze, mentre «checkpoint finalizzato invertito» implicherebbe una deviazione dalle aspettative molto più grave nei sistemi che dichiarano tale proprietà.

Per esempio, un’agenzia potrebbe registrare i pagamenti in entrata prima di autorizzare un servizio dipendente da essi. I suoi controlli potrebbero richiedere che una transazione inclusa sia osservata in modo indipendente, che la rete raggiunga la condizione di accettazione documentata e che il sistema conservi prove dello stato al momento della decisione. Se in seguito la transazione scompare dalla cronologia selezionata, il flusso di lavoro deve prevedere un percorso per gestire l’eccezione. La risposta corretta dipende dai poteri legali dell’agenzia, dagli accordi contrattuali e dalla sua tolleranza al rischio operativo; il consenso definisce le prove tecniche, ma non fornisce la politica decisionale completa dell’istituzione.

Correzione di alcuni equivoci comuni

Una catena collegata tramite hash non è automaticamente immune alle riorganizzazioni. La regola delle «sei conferme» non è universale per tutte le reti o tutti i casi d’uso. La finalità esplicita non equivale a un esito immediato e legalmente irrevocabile. Un fork non crea sempre un asset o un protocollo separato e permanente. Un block explorer è un servizio informativo, non una garanzia indipendente del consenso. Queste precisazioni sono importanti perché termini che sembrano definitivi spesso riassumono affermazioni condizionali. Una spiegazione utile indica la catena, la regola di scelta del fork, la regola di finalità, il metodo di osservazione e tutte le ipotesi rilevanti.

Riferimento rapido

Cosa ricordare

Il consenso deve risolvere i disaccordi temporanei tra cronologie concorrenti di blocchi validi. La riorganizzazione descrive un nodo che adotta un altro ramo accettato e applica lo stato corrispondente. In genere, la PoW offre una fiducia probabilistica crescente grazie al lavoro accumulato; alcuni design PoS prevedono una finalità economica esplicita basata sul voto. I fork causati dalla produzione simultanea di blocchi sono diversi dagli aggiornamenti delle regole del protocollo. La questione operativa non è semplicemente se una transazione compare su uno schermo, ma quale condizione tecnica è stata raggiunta e cosa l’organizzazione può fare responsabilmente sulla base di tali prove.

Focus d’esame: Distinguere i fork causati da blocchi concorrenti dai fork dovuti a modifiche delle regole del protocollo; spiegare le riorganizzazioni e il loro effetto sullo stato delle transazioni; e confrontare la fiducia probabilistica con la finalità dei checkpoint definita dal protocollo, senza descrivere nessuna delle due come una garanzia legale incondizionata.

Note sulle fonti

Riferimenti pertinenti: NIST IR 8202 (2018), Blockchain Technology Overview, sezioni sul consenso e sui fork; Satoshi Nakamoto (2008), Bitcoin: A Peer-to-Peer Electronic Cash System; e la documentazione di Ethereum sulla proof-of-stake, sulla scelta del fork e sulla finalità.