> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Sincronizzazione dello stato
> Come un nodo che non ha mai visto la catena arriva alla versione corrente, e come ci resta.
Un nodo che entra nella rete deve rispondere a due domande: come arrivo al punto in cui la catena si trova adesso, e come ci resto. La sincronizzazione dello stato risponde a entrambe, e il compromesso fra le due è esplicito invece che nascosto.
Due modi per mettersi in pari
Il bootstrap — arrivare alla versione corrente partendo da zero — si può fare in due modi radicalmente diversi.
**Rieseguire lo storico.** Si parte dal genesis e si va avanti, rieseguendo ogni transazione oppure applicando gli output che l'esecuzione ha già prodotto. Il risultato è un nodo che detiene l'intero storico: ogni versione, ogni prova, ogni transazione. È anche lento, e diventa più lento ogni giorno che la catena resta in funzione.
**Scaricare lo stato corrente.** Si salta lo storico e si prendono chiavi e valori di stato come stanno all'ultima versione, verificati rispetto alla radice consolidata. Il nodo è aggiornato in una frazione del tempo, e non sa nulla di come la catena ci sia arrivata.
Un nuovo nodo
Modalità di bootstrap
Rieseguire lo storicoriesecuzione o applicazione degli output, dal genesislento, e più lento ogni giorno di catena
Scaricare lo stato correntechiavi e valori all'ultima versione, verificati sulla radice consolidataaggiornato in una frazione di tempo
Versione correntesincronizzazione continua
I due percorsi non sono equivalentiUn nodo che ha scaricato lo stato corrente non può servire query storiche né dire come una posizione sia arrivata dov'è. A un nodo che alimenta un indexer o un audit serve lo storico saltato.
Dentro il percorso di replay c'è un'ulteriore scelta: rieseguire le transazioni, applicare gli output memorizzati, oppure lasciare che il nodo scelga di volta in volta il più veloce. Rieseguire è il controllo più forte, perché riproduce il risultato invece di fidarsi di un risultato registrato; applicare gli output è più rapido. La modalità mista esiste perché la risposta giusta cambia con quanto il nodo è indietro.
Questa è una decisione operativa, non un default da accettare senza pensarci. Un nodo che ha scaricato lo stato corrente non può servire query storiche né rispondere a domande su come una posizione sia arrivata dov'è: non ha storico da leggere. A un nodo che alimenta un [indexer](/it/protocol/architecture/indexer) o un processo di audit serve lo storico che ha saltato.
Restare aggiornati
Arrivato alla versione corrente, un nodo si mantiene in pari consumando i blocchi consolidati man mano che arrivano, di nuovo eseguendo le transazioni oppure applicando gli output, con lo stesso compromesso fra forza della verifica e velocità.
La differenza rispetto al bootstrap è che il divario è piccolo e costante, invece che grande e in riduzione. Un nodo che accumula troppo ritardo rientra nel percorso di bootstrap, invece di provare a colmare un divario arbitrario in modo incrementale.
Come si muovono i dati
La sincronizzazione non è un nodo che chiede a un altro un intervallo di blocchi. Si divide in livelli, così che nessun singolo peer sia una dipendenza e nessun singolo guasto fermi l'avanzamento.
| Livello | Ruolo |
| --------------------- | ------------------------------------------------------------------------------------------------- |
| **Storage service** | Serve dati agli altri nodi: transazioni, output, valori di stato e le prove che li accompagnano |
| **Data client** | Sceglie i peer, tiene traccia di chi ha cosa, invia le richieste e gestisce quelle che falliscono |
| **Streaming service** | Trasforma «portami da qui a lì» in un flusso ordinato di chunk verificati |
| **Driver** | Decide che cosa serve al nodo dopo, e applica ciò che arriva |
La conseguenza da capire: un nodo che si sincronizza non si fida di un peer. Ogni chunk arriva con una prova rispetto a una radice che la rete ha consolidato, e un peer che serve qualcosa di incoerente viene rifiutato invece che creduto. La scelta dei peer è una decisione di prestazioni, non di fiducia.
Verifica
Nella sincronizzazione dello stato nulla viene accettato in base a chi lo ha inviato.
I valori di stato sono verificati rispetto alla radice dello stato consolidata. Transazioni e output sono verificati rispetto agli accumulatori. Un nodo che finisce il bootstrap ha uno stato la cui radice coincide con ciò che un quorum di validatori ha firmato. È questo a rendere sicuro il percorso veloce: scaricare lo stato corrente salta lo storico, ma non salta la verifica.
Dove proseguire
Le strutture che rendono verificabile la sincronizzazione.
I ruoli dei nodi, e come chiedere di gestirne uno.
Con quale livello di nodo parla un peer che si sincronizza.
Le domande a cui risponde lo storico e a cui lo stato corrente non può rispondere.