> ## 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.

# Archiviazione e prove

> Come lo stato consolidato viene persistito su tre store RocksDB, autenticato da un albero di Merkle versionato e dagli accumulatori, e sottoposto a pruning nel tempo.

Lo stato consolidato deve soddisfare due esigenze che tirano in direzioni opposte. All'esecuzione serve il valore corrente di una chiave, veloce, milioni di volte. Alla verifica serve la prova che, a una certa versione, un valore fosse quello che la rete dice. Servirle entrambe da un'unica struttura significa farle entrambe male.

L'archiviazione perciò divide il problema su store separati, ciascuno modellato sul proprio schema di accesso.

<h2 id="three-stores">
  Tre store
</h2>

<div className="dg" data-dg="storage-stores">
  <div className="dg-c" style={{aspectRatio:"720 / 332"}}>
    <svg className="dg-w" viewBox="0 0 720 332" aria-hidden="true">
      <path className="dg-wire dg--green dg-dash" d="M 434.00 48.00 L 459.60 48.00" />

      <path className="dg-head dg--green" d="M 466.00 48.00 L 459.60 52.40 L 459.60 43.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 434.00 144.00 L 459.60 144.00" />

      <path className="dg-head dg--green" d="M 466.00 144.00 L 459.60 148.40 L 459.60 139.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 434.00 240.00 L 459.60 240.00" />

      <path className="dg-head dg--green" d="M 466.00 240.00 L 459.60 244.40 L 459.60 235.60 Z" />

      <path className="dg-wire dg--blue dg-soft" d="M 135.00 144.00 L 172.54 53.91" />

      <path className="dg-head dg--blue" d="M 175.00 48.00 L 176.60 55.60 L 168.48 52.22 Z" />

      <path className="dg-wire dg--blue dg-soft" d="M 135.00 144.00 L 168.60 144.00" />

      <path className="dg-head dg--blue" d="M 175.00 144.00 L 168.60 148.40 L 168.60 139.60 Z" />

      <path className="dg-wire dg--blue dg-soft" d="M 135.00 144.00 L 172.54 234.09" />

      <path className="dg-head dg--blue" d="M 175.00 240.00 L 168.48 235.78 L 176.60 232.40 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"31.3253%",width:"18.0556%",height:"24.0964%"}}><span className="dg-t">Blocco consolidato</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"25.0000%",top:"2.4096%",width:"34.7222%",height:"24.0964%"}}><span className="dg-t">Ledger store</span><span className="dg-s">transazioni · output · eventi · write set · accumulatori · metadati del blocco</span></div>
    <div className="dg-b dg--green" style={{left:"65.2778%",top:"2.4096%",width:"34.7222%",height:"24.0964%"}}><span className="dg-t">Replay e audit</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"25.0000%",top:"31.3253%",width:"34.7222%",height:"24.0964%"}}><span className="dg-t">State KV store</span><span className="dg-s">valori correnti e storici, 16 shard, stato caldo in un livello proprio</span></div>
    <div className="dg-b dg--green" style={{left:"65.2778%",top:"31.3253%",width:"34.7222%",height:"24.0964%"}}><span className="dg-t">Query ed esecuzione</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"25.0000%",top:"60.2410%",width:"34.7222%",height:"24.0964%"}}><span className="dg-t">State Merkle store</span><span className="dg-s">albero di Merkle sparso versionato, più gli indici dei nodi soppiantati</span></div>
    <div className="dg-b dg--green" style={{left:"65.2778%",top:"60.2410%",width:"34.7222%",height:"24.0964%"}}><span className="dg-t">Verifica — prove</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"89.1566%",width:"100.0000%"}}><div className="dg-n">Chi legge solo un valore non paga la traversata dell'albero, e una prova non va ricostruita da uno store ottimizzato per letture puntuali.</div></div>
  </div>
</div>

**Il ledger store** contiene lo storico della catena: transazioni, i loro output e dati ausiliari, eventi, write set, metadati dei blocchi e gli accumulatori. È questo che si riesegue.

**Lo state KV store** contiene i valori di stato, indirizzati per chiave e versione. È questo che leggono l'esecuzione e le query. È **suddiviso in sedici shard**, così le scritture di un blocco si distribuiscono su sedici istanze RocksDB indipendenti invece di contendersene una sola. Lo stato a cui si accede di frequente è tenuto anche in un livello proprio, così il working set di un mercato attivo non va cercato in mezzo a tutto ciò che la catena ha mai archiviato.

**Lo state Merkle store** contiene la struttura autenticata: i nodi dell'albero che permettono di provare un valore, e gli indici che tengono traccia di quali nodi sono stati soppiantati.

Separarli significa che una lettura a cui serve solo un valore non paga la traversata dell'albero, e che una prova non va ricostruita da uno store ottimizzato per le letture puntuali.

<h2 id="authentication">
  Autenticazione
</h2>

Due strutture di Merkle fanno lavori diversi.

<div className="dg" data-dg="storage-proofs">
  <div className="dg-c" style={{aspectRatio:"720 / 400"}}>
    <svg className="dg-w" viewBox="0 0 720 400" aria-hidden="true">
      <path className="dg-wire" d="M 173.50 98.50 L 173.50 110.10" />

      <path className="dg-head" d="M 173.50 116.50 L 169.10 110.10 L 177.90 110.10 Z" />

      <path className="dg-wire" d="M 173.50 169.00 L 173.50 180.60" />

      <path className="dg-head" d="M 173.50 187.00 L 169.10 180.60 L 177.90 180.60 Z" />

      <path className="dg-wire" d="M 173.50 239.50 L 173.50 251.10" />

      <path className="dg-head" d="M 173.50 257.50 L 169.10 251.10 L 177.90 251.10 Z" />

      <path className="dg-wire" d="M 546.50 122.00 L 546.50 133.60" />

      <path className="dg-head" d="M 546.50 140.00 L 542.10 133.60 L 550.90 133.60 Z" />

      <path className="dg-wire" d="M 546.50 216.00 L 546.50 227.60" />

      <path className="dg-head" d="M 546.50 234.00 L 542.10 227.60 L 550.90 227.60 Z" />
    </svg>

    <div className="dg-band" style={{left:"0.0000%",top:"6.5000%",width:"48.1944%",height:"72.5000%"}}><span className="dg-cap">Albero di Merkle sparso versionato</span></div>
    <div className="dg-band" style={{left:"51.8056%",top:"6.5000%",width:"48.1944%",height:"72.5000%"}}><span className="dg-cap">Accumulatori</span></div>
    <div className="dg-b dg--blue" style={{left:"2.2222%",top:"12.5000%",width:"43.7500%",height:"11.1250%"}}><span className="dg-t">La tua chiave e il suo valore</span></div>
    <div className="dg-b" style={{left:"2.2222%",top:"30.1250%",width:"43.7500%",height:"11.1250%"}}><span className="dg-t">hash fratello</span></div>
    <div className="dg-b" style={{left:"2.2222%",top:"47.7500%",width:"43.7500%",height:"11.1250%"}}><span className="dg-t">hash fratello</span></div>
    <div className="dg-b dg--green" style={{left:"2.2222%",top:"65.3750%",width:"43.7500%",height:"11.1250%"}}><span className="dg-t">Radice dello stato consolidata dal consenso</span></div>
    <div className="dg-b dg--blue" style={{left:"54.0278%",top:"12.5000%",width:"43.7500%",height:"17.0000%"}}><span className="dg-t">La tua transazione, o un evento</span></div>
    <div className="dg-b" style={{left:"54.0278%",top:"36.0000%",width:"43.7500%",height:"17.0000%"}}><span className="dg-t">Accumulatore transazioni · accumulatore eventi</span><span className="dg-s">ciascuno vincola tutto quanto incluso finora, nell'ordine</span></div>
    <div className="dg-b dg--green" style={{left:"54.0278%",top:"59.5000%",width:"43.7500%",height:"17.0000%"}}><span className="dg-t">Radice del ledger consolidata dal consenso</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"83.0000%",width:"100.0000%",height:"14.5000%"}}><span className="dg-s">L'albero prova quale fosse un valore; gli accumulatori provano che cosa è successo e in che ordine. Insieme rendono dimostrabile «questa transazione è nella catena in questa posizione» senza avere la catena.</span></div>
  </div>
</div>

**Un albero di Merkle sparso e versionato** autentica lo stato. Ogni chiave ha una posizione determinata dal proprio hash, e ogni versione dell'albero condivide i nodi che non sono cambiati: scrivere una chiave in un blocco aggiunge un percorso, non un albero. La prova di una chiave a una certa versione è il percorso dalla foglia di quella chiave fino alla radice che la rete ha consolidato.

**Gli accumulatori** autenticano la sequenza. Uno accumula le transazioni e uno gli eventi, e ciascuno produce una radice che vincola tutto ciò che è stato incluso fino a quel punto, nell'ordine. È questo a rendere dimostrabile «questa transazione è nella catena in questa posizione» senza avere la catena.

Fra le due: l'albero dello stato prova *quale fosse un valore*, gli accumulatori provano *che cosa è successo e in che ordine*.

<h3 id="speculative-state">
  Stato speculativo
</h3>

I risultati di un blocco esistono prima di essere consolidati. Invece di scriverli nell'albero durevole e disfare tutto se il blocco non viene consolidato, lo stato non consolidato è tenuto in un **overlay di Merkle sparso in memoria** sopra l'ultima versione consolidata.

L'esecuzione legge attraverso l'overlay e vede una vista coerente. Se il blocco viene consolidato, l'overlay viene materializzato. Se non lo è, l'overlay viene scartato e nulla di durevole è mai stato toccato. È questo che impedisce all'esecuzione speculativa di lasciare detriti nell'archiviazione.

### Caching

I nodi dell'albero sono messi in cache su due livelli: una cache consapevole delle versioni, che tiene indirizzabili quelle recenti, e sotto una cache least-recently-used. Lo schema di accesso di una catena di negoziazione — un piccolo insieme di chiavi calde toccate a ogni blocco, contro una coda lunga toccata di rado — è esattamente lo scenario per cui queste cache esistono.

## Pruning

Conservare per sempre ogni versione è una scelta, non un obbligo. Tre pruner indipendenti girano sui tre store, ciascuno con la propria policy di conservazione: uno sul ledger, uno sui valori di stato, uno sui nodi di Merkle.

I pruner di Merkle e dei valori di stato sono guidati da **indici di obsolescenza** scritti insieme ai dati. Quando una versione soppianta un nodo o un valore, la voce soppiantata viene registrata come obsoleta a quella versione. Il pruning diventa così una scansione per intervalli su un indice invece di una caccia alla spazzatura: chi ha scritto ha già detto che cosa sarebbe diventato raccoglibile e quando.

<Note>
  La conservazione è una decisione dell'operatore, con conseguenze reali. Un nodo sottoposto a pruning aggressivo serve lo stato corrente in modo efficiente e non può rispondere a query storiche né servire la sincronizzazione dello stato a un nodo che parte da più indietro. Un nodo di archivio tiene tutto e lo paga. Vedi [Gestire un nodo](/it/developers/run-a-node).
</Note>

<h2 id="backup-and-restore">
  Backup e ripristino
</h2>

Gli store possono essere sottoposti a backup e ripristinati indipendentemente dal nodo in esecuzione: è questo che rende possibile mettere in piedi un nodo da uno snapshot invece di rieseguire dal genesis, e verificare lo stato di un nodo ripristinato rispetto alle radici consolidate invece di fidarsi del backup.

<h2 id="where-to-go-next">
  Dove proseguire
</h2>

<CardGroup cols={2}>
  <Card title="Sincronizzazione dello stato" href="/it/protocol/architecture/state/sync">
    Come un nodo si mette in pari con la catena senza rieseguirla tutta.
  </Card>

  <Card title="Modello di stato" href="/it/protocol/architecture/state/model">
    Che cosa viene archiviato, e quale rappresentazione fa fede.
  </Card>

  <Card title="Indexer" href="/it/protocol/architecture/indexer">
    Ricostruire lo storico dai registri consolidati.
  </Card>

  <Card title="Gestire un nodo" href="/it/developers/run-a-node">
    I ruoli dei nodi, e come chiedere di gestirne uno.
  </Card>
</CardGroup>
