Vai al contenuto
Financial Context Wiki

Regole di fork choice: rami validi, peso e head canonica

Una regola di fork choice associa la vista locale convalidata di un nodo a una head canonica corrente. Validità, ascendenza, lavoro o peso dei voti, checkpoint, tempistica, spareggi, riorganizzazioni e finalità vanno analizzati separatamente.

Aggiornato

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

Risposta diretta

Una regola di fork choice è la procedura del protocollo che associa la vista locale convalidata di un nodo, composta da blocchi e messaggi di consenso concorrenti, a una head canonica corrente. Il risultato è provvisorio e relativo all’osservatore: due nodi onesti possono scegliere per poco tempo head diverse perché hanno ricevuto blocchi, voti o eventi temporali validi differenti. Quando le loro viste ammissibili convergono entro le ipotesi di rete del protocollo, anche la regola dovrebbe convergere.

La fork choice non rende valido un blocco invalido. Controlli su transizione di stato, autorizzazione, prove, ascendenza e disponibilità dei dati determinano quali candidati siano ammissibili prima di confrontarne il peso. La head selezionata non è inoltre necessariamente finalizzata. La fork choice individua il ramo da estendere ora; una regola di finalità può proteggere un antenato più vecchio con prove di sicurezza più forti. Sostituire la head corrente può essere normale, mentre sostituire un checkpoint finalizzato oltrepasserebbe un diverso confine del protocollo.

“Catena più lunga” non è una formula universale. Bitcoin seleziona una catena valida con il maggior lavoro: conta la prova di lavoro attesa cumulativa, non l’altezza grezza. LMD-GHOST di Ethereum parte da un checkpoint giustificato, filtra i rami praticabili e segue avidamente il figlio con il maggior saldo attestante dell’ultimo messaggio, più l’eventuale proposer boost; per ciascun validatore contribuisce solo l’ultimo messaggio idoneo. Altri protocolli possono usare certificati di disponibilità, lock del leader, round o certificati di commit espliciti anziché una competizione persistente tra rami più pesanti.

Il risultato dipende da input precisi: catena e rete, versione del fork, ancora fidata, tempo o slot corrente, blocchi validi noti, legami parentali, snapshot del lavoro o del peso di voto, ultimi messaggi, prove di equivocation, checkpoint giustificati e finalizzati, stato di disponibilità, tempistica del proposer e spareggi deterministici. Il badge di un explorer o un singolo risultato RPC è l’osservazione dell’output di un nodo, non la regola né una prova indipendente dei suoi input.

Come analizzare una regola di fork choice

  1. Fissa identità e versione. Registra catena, rete, fork di consenso, versione del client, genesis o ancora fidata, altezza o slot corrente e regola esatta attiva. Non trasferire la logica mainnet a testnet, sidechain, rollup o proposte future.
  2. Costruisci il grafo dei blocchi ammissibili. Verifica hash, parent, prove di consenso, transizioni di stato, stato dell’execution payload e disponibilità dei dati richiesta. Contrassegna esplicitamente nodi sconosciuti, optimistic, invalidi e potati: il peso non può salvare un ramo invalido.
  3. Ricostruisci ascendenza e vincoli. Trova l’antenato comune e verifica quali candidati discendano da checkpoint, lock o certificati obbligatori. Distingui l’albero grezzo osservato dall’albero filtrato che la regola può davvero considerare.
  4. Riproduci ogni input di peso. Per PoW, decodifica i target e somma la prova per blocco nel chainwork cumulativo. Per le regole di voto verifica identità del validatore, saldo effettivo attivo o altro peso, dominio del messaggio, root di destinazione, slot o epoca, sostituzione dell’ultimo messaggio, trattamento dell’equivocation ed eventuali boost temporanei.
  5. Esegui esattamente selezione e spareggi. Applica la ricorsione o il comparatore specificato a ogni biforcazione, con arrotondamento e ordine deterministico del protocollo. Registra se la parità consente una preferenza locale temporanea anziché presentarla come accordo finale.
  6. Riconcilia i cambi di head. Quando cambia il vincitore, identifica blocchi staccati e collegati, ripristina e riesegui lo stato, riconcilia ricevute, log e mempool e calcola la profondità della riorganizzazione dall’antenato comune. Mantieni distinti head, safe, justified, committed e finalized.
  7. Sottoponi a stress e monitora il sistema. Prova blocchi ritardati o trattenuti, partizioni, voti obsoleti, equivocation, bilanciamento, tempistica del proposer, disaccordo tra client, checkpoint deboli e dati indisponibili. Confronta nodi indipendenti e segnala divergenze inattese della head, riorganizzazioni profonde o conflitti con lo stato finalizzato prima di azioni irreversibili a valle.

Nel Bitcoin Core attuale, l’ordinamento dei candidati confronta prima nChainWork; a parità di lavoro li ordina poi per la prima sequenza attivabile, con uno spareggio interno di riserva. Il campo RPC blocks è l’altezza della catena con maggior lavoro completamente convalidata, mentre bestblockhash ne identifica la punta. Nell’attuale specifica di fork choice di Ethereum, get_head(store) parte da justified_checkpoint, percorre un albero filtrato e a ogni passo sceglie il figlio che massimizza (get_weight(store, child), child.root). Sono dettagli specifici di protocollo e versione, non definizioni generiche del consenso.

Esempi svolti

1. Cambio per lavoro cumulativo in Bitcoin

Due rami validi condividono l’antenato comune C. Le head correnti hanno chainwork(A)=240 e chainwork(B)=235, quindi il nodo sceglie A anche se una semplice visualizzazione dell’altezza fa sembrare simili i rami. Un nuovo blocco valido aggiunge lavoro 10 al ramo B:

chainwork(B') = 235 + 10 = 245

Poiché 245 > 240, B diventa il candidato con maggior lavoro. Il nodo scollega i blocchi di A dopo C, collega B fino a B' e riconcilia le transazioni. Il numero grezzo di blocchi non basta quando i target per blocco differiscono, e la parità di lavoro è un caso temporaneo, non una prova di finalità.

2. Sottoalbero osservato più pesante con scelta greedy

Usiamo un albero LMD-GHOST semplificato radicato nel checkpoint giustificato J. I figli sono A e B. Gli ultimi messaggi idonei dei validatori danno all’intero sottoalbero A peso 61 e al sottoalbero B peso 39, quindi il primo passo greedy sceglie A. A ha figli A_1 e A_2 con pesi di sottoalbero 34 e 27; il passo seguente sceglie A_1.

La head si trova scegliendo ripetutamente il figlio più pesante, non contando la lunghezza del ramo né scegliendo la foglia con il maggior voto diretto isolato. Le regole di produzione includono anche filtro di praticabilità, snapshot dei saldi, gestione dell’equivocation, tempistica del proposer e spareggi omessi da questo albero didattico.

3. Sostituzione dell’ultimo messaggio

Supponiamo che gli ultimi messaggi idonei diano inizialmente al ramo A peso 55 e al ramo B peso 45. Un validatore di peso 20 invia poi un messaggio idoneo più recente a favore di un discendente di B. La contabilità dell’ultimo messaggio rimuove il vecchio sostegno da A e lo aggiunge a B:

A: 55 - 20 = 35; B: 45 + 20 = 65

Il peso viene contato una sola volta, non su entrambi i rami, perciò il percorso scelto può cambiare. Non è un’autorizzazione a votare in modo incoerente: se prove valide di attester slashing identificano equivocation, lo store Ethereum attuale registra il validatore responsabile e ne esclude il peso dal normale punteggio delle attestazioni.

4. Filtro dei checkpoint e proposer boost

Supponiamo che un nodo osservi peso grezzo dell’ultimo messaggio 70 su un ramo in conflitto con il checkpoint finalizzato e peso 30 su un discendente praticabile. Il ramo in conflitto viene escluso prima della selezione della head; una maggioranza grezza non può superare il vincolo del checkpoint finalizzato mediante la normale fork choice.

Consideriamo ora due figli praticabili nello slot corrente con pesi di attestazione 35 e 50. Nella configurazione Ethereum citata, un proposer boost tempestivo equivale al 40% del peso di un comitato, non al 40 percento dello stake totale. Se il peso del comitato è 100 e il boost si applica al figlio di peso 35, il suo punteggio diventa 35 + 40 = 75, superando 50 in quel passo. Il boost è temporaneo e specifico del fork; non è né un voto aggiuntivo né finalità.

Rischi ed errori di revisione

Insieme dei candidati e prove

  • Confrontare il peso dei rami prima di convalidare parent, transizioni di stato, prove, stato del payload o dati richiesti.
  • Trattare esecuzione sconosciuta o optimistic, dati indisponibili o una vista di sole intestazioni come stato pienamente convalidato.
  • Usare altezza, timestamp, numero di transazioni, commissioni o popolarità su un explorer al posto del peso specificato.
  • Sommare la difficoltà mostrata anziché riprodurre prova per blocco e chainwork cumulativo con i target corretti.
  • Contare ogni voto storico anziché l’ultimo messaggio idoneo di ciascun validatore con lo snapshot di peso corretto.
  • Ignorare dominio, root, slot, epoca, tempestività e firma del messaggio, nonché prove di equivocation e slashing.
  • Confrontare rami grezzi resi inammissibili dal filtro di checkpoint, lock, certificati o disponibilità del protocollo.
  • Applicare una specifica futura, un parametro di un’altra rete o un’ottimizzazione implementativa come regola di consenso corrente.

Selezione e guasti operativi

  • Descrivere la regola di Bitcoin come semplice “altezza massima” o quella di Ethereum come voto della head a due terzi.
  • Sostituire la ricorsione greedy sul sottoalbero con un punteggio globale delle foglie, oppure omettere proposer boost, arrotondamento e spareggi sulla root.
  • Presumere che nodi con ordine di arrivo, orologi o viste dei messaggi differenti debbano indicare subito la stessa head.
  • Non scollegare e rieseguire correttamente stato, ricevute, log, indici e voci del mempool durante una riorganizzazione.
  • Permettere ai client di divergere su validità, praticabilità dei checkpoint, ultimi messaggi, tempistica o spareggi.
  • Non rilevare condizioni di bilanciamento, withholding, equivocation, partizione, eclipse, voti ritardati e proposer reorganization.
  • Fidarsi di un solo RPC, explorer, relay, famiglia di client, cloud o operatore di validatori come vista indipendente del consenso.

Finalità e disallineamento applicativo

  • Definire la head selezionata finalizzata, irreversibile o sicura senza le prove separate di finalità richieste dal protocollo.
  • Rilasciare depositi, messaggi bridge o scambi irreversibili su una head transitoria senza una policy proporzionata al valore.
  • Presumere che un antenato finalizzato garantisca correttezza o disponibilità di ogni head, payload, oracle o risultato applicativo più recente.
  • Usare un numero fisso di conferme su catene con modelli differenti di lavoro, voto, checkpoint e recupero.
  • Trattare checkpoint di emergenza, ancore di weak subjectivity o social recovery come normali input della fork choice privi di confini di fiducia.

Idee errate comuni

  • Vince sempre il ramo più lungo. Il protocollo può confrontare lavoro cumulativo, ultimi messaggi ponderati, certificati o un altro punteggio; l’altezza grezza non è universale.
  • Il ramo osservato più pesante è automaticamente valido. Validità e disponibilità filtrano i candidati prima che il peso possa scegliere tra loro.
  • Fork choice e finalità sono la stessa regola. La fork choice seleziona la head corrente da estendere; la finalità protegge un antenato a condizioni di sicurezza aggiuntive.
  • Ogni voto del validatore resta per sempre nel totale. Nelle regole dell’ultimo messaggio, un nuovo messaggio idoneo sostituisce il precedente sostegno del validatore.
  • Un explorer prova quale sia la catena canonica. Riporta la vista di uno stack infrastrutturale; servono comunque convalida e riconciliazione indipendenti.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...