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

# IntentionBFT

> Il consenso: come un ordinamento e un vettore di prezzi certificati vengono confermati insieme, e come è organizzata la rete.

IntentionBFT è il protocollo di consenso di Intention: un protocollo BFT della famiglia HotStuff esteso per l'infrastruttura finanziaria. La safety vale incondizionatamente sotto la soglia di guasti; la liveness vale dopo che la rete si è stabilizzata.

Qui il consenso fa due cose che il consenso di una catena generalista non fa: conferma un **ordinamento** come oggetto di prima classe e conferma un **vettore di prezzi certificati** nello stesso evento. Tutto ciò che il [kernel](/it/protocol/architecture/kernel) può garantire sull'esecuzione dipende dal fatto che entrambi siano stabiliti prima che l'esecuzione cominci.

<h2 id="model">
  Il modello
</h2>

IntentionBFT tollera un avversario bizantino che controlla fino a un terzo dello stake totale. Lo stake onesto è quindi sempre più di due terzi, e il quorum standard è un qualunque insieme di validatori il cui stake combinato supera i due terzi: ciò che queste pagine chiamano **quorum $2f+1$ pesato per stake**. La rete è parzialmente sincrona: prima di un punto di stabilizzazione i ritardi sono arbitrari; dopo, i ritardi tra validatori onesti sono limitati.

<div className="dg" data-dg="bft-prices">
  <div className="dg-c" style={{aspectRatio:"720 / 318"}}>
    <svg className="dg-w" viewBox="0 0 720 318" aria-hidden="true">
      <path className="dg-wire" d="M 163.00 78.00 L 176.60 78.00" />

      <path className="dg-head" d="M 183.00 78.00 L 176.60 82.40 L 176.60 73.60 Z" />

      <path className="dg-wire" d="M 350.00 78.00 L 363.60 78.00" />

      <path className="dg-head" d="M 370.00 78.00 L 363.60 82.40 L 363.60 73.60 Z" />

      <path className="dg-wire" d="M 537.00 78.00 L 550.60 78.00" />

      <path className="dg-head" d="M 557.00 78.00 L 550.60 82.40 L 550.60 73.60 Z" />
    </svg>

    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Sidecar oracolo</span><span className="dg-s">uno per validatore</span></div>
    <div className="dg-b dg--blue" style={{left:"25.9722%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Il validatore valida e firma</span><span className="dg-s">compresa la freschezza rispetto a soglie configurate</span></div>
    <div className="dg-b dg--blue" style={{left:"51.9444%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Gossip tra validatori</span><span className="dg-s">messaggio della rete di consenso</span></div>
    <div className="dg-b dg--green" style={{left:"77.9167%",top:"8.1761%",width:"22.0833%",height:"32.7044%"}}><span className="dg-t">Prezzi certificati</span><span className="dg-s">per epoch e round</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"0.0000%",top:"48.4277%",width:"100.0000%",height:"21.3836%"}}><span className="dg-t">La disponibilità del prezzo condiziona i blocchi</span><span className="dg-s">Un validatore è idoneo a proporre un blocco solo se può presentare osservazioni di prezzo valide per il round corrente — così le firme che confermano le transazioni confermano anche i prezzi contro cui vengono regolate.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"75.4717%",width:"100.0000%",height:"19.4969%"}}><span className="dg-t">Che cosa non garantisce</span><span className="dg-s">Lega il prezzo alla transazione; non rende il prezzo corretto. Il consenso certifica che un quorum di validatori ha inviato queste osservazioni in questo round, nulla di più.</span></div>
  </div>
</div>

Ogni round ha un leader designato. All'interno di un round una proposta raccoglie successivi aggregati di firme $2f+1$, e le fasi si sovrappongono in pipeline tra round adiacenti, così nel caso comune un blocco raggiunge la definitività in due round-trip di rete. In regime di optimistic responsiveness il progresso è limitato dal ritardo effettivo dei messaggi; il backoff del pacemaker entra in gioco solo quando la rete è ostile o partizionata.

<h2 id="committing-an-ordering">
  Confermare un ordinamento
</h2>

L'ordine delle transazioni dentro un blocco è promosso a oggetto confermato dal consenso invece di restare un artefatto dell'esecuzione. L'hash del blocco copre il payload ordinato, quindi qualunque riordino successivo al consenso invalida le firme che lo hanno confermato.

L'effetto: una volta che un blocco è finalizzato, un quorum $2f+1$ pesato per stake ha firmato un impegno su quell'esatto ordinamento, e nessun validatore onesto avrà firmato un ordinamento diverso delle stesse transazioni nello stesso round. Unito all'esecuzione sequenziale su quell'ordine confermato, è questo a trasformare il replay deterministico da convenzione implementativa a proprietà che chiunque può verificare.

<Note>
  La discrezionalità del leader dentro una singola proposta — quali batch disponibili includere e come disporli — resta una superficie di attacco residua, mitigata dalla reputazione del leader e dal fatto che senza osservazioni di prezzo valide un leader non può produrre alcun blocco. Costruzioni di fair ordering più forti sono in valutazione come possibile aggiornamento futuro.
</Note>

<h2 id="batch-availability">
  Disponibilità dei batch
</h2>

In un protocollo ingenuo il leader propone un blocco il cui payload porta tutte le transazioni del round, legando la dimensione dei messaggi di consenso al throughput. IntentionBFT separa la diffusione dei dati dall'ordinamento.

I validatori diffondono in continuo batch di transazioni in background. Ogni batch continua a raccogliere conferme finché chi lo ha originato non può dimostrare una disponibilità $2f+1$ pesata per stake, e solo allora una proposta può farvi riferimento — tramite digest, non tramite contenuto. I messaggi di consenso restano piccoli indipendentemente dal throughput, e un blocco confermato è sempre rieseguibile, perché nessun blocco può riferirsi a dati detenuti dalla sola minoranza bizantina.

<h2 id="certifying-prices">
  Certificare i prezzi
</h2>

I validatori sono anche osservatori di prezzo, e un blocco porta con sé i prezzi contro cui è stato eseguito.

<div className="dg" data-dg="bft-topology">
  <div className="dg-c" style={{aspectRatio:"720 / 322"}}>
    <svg className="dg-w" viewBox="0 0 720 322" aria-hidden="true">
      <path className="dg-wire dg-soft" d="M 215.00 95.00 L 215.00 99.00" />

      <path className="dg-wire dg-soft" d="M 215.00 167.00 L 215.00 171.00" />

      <path className="dg-wire dg-soft" d="M 215.00 239.00 L 215.00 243.00" />
    </svg>

    <div className="dg-b dg--blue dg-left" style={{left:"0.0000%",top:"9.3168%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Validatori</span><span className="dg-s">consenso · mempool · sidecar oracolo · kernel · archiviazione</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"9.3168%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Gli unici partecipanti che votano</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"0.0000%",top:"31.6770%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Full node dei validatori</span><span className="dg-s">seguono ed eseguono i blocchi confermati; non votano</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"31.6770%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Isolamento — assorbono il traffico pubblico di lettura e le connessioni dei peer, così i validatori non sono esposti alla rete aperta</span></div>
    <div className="dg-b dg--sky dg-left" style={{left:"0.0000%",top:"54.0373%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Full node pubblici</span><span className="dg-s">chiunque può gestirne uno; seguono, eseguono, servono letture</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"54.0373%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Il livello aperto</span></div>
    <div className="dg-b dg--green dg-left" style={{left:"0.0000%",top:"76.3975%",width:"59.7222%",height:"19.2547%"}}><span className="dg-t">Client</span><span className="dg-s">front end · agenti di trading · market maker · indexer</span></div>
    <div className="dg-b dg-plain dg-left" style={{left:"63.6111%",top:"76.3975%",width:"36.3889%",height:"19.2547%"}}><span className="dg-s">Si collegano ai full node, mai ai validatori. Un client che vuole la vista più completa e a latenza più bassa ne gestisce uno.</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"0.0000%",width:"59.7222%"}}><div className="dg-n">Quattro livelli, dal consenso in fuori</div></div>
    <div className="dg-free" style={{left:"63.6111%",top:"0.0000%",width:"36.3889%"}}><div className="dg-n">Perché il livello esiste</div></div>
  </div>
</div>

Ogni validatore esegue il proprio [sidecar dell'oracolo](/it/protocol/architecture/oracle), che raccoglie i dati delle sedi di negoziazione e produce un prezzo indice per strumento. Il validatore preleva quel prezzo, lo valida — compresa la freschezza rispetto a soglie configurate — lo firma e lo diffonde in gossip agli altri validatori come messaggio della rete di consenso. I prezzi certificati vengono assemblati per epoch e round e portati nel blocco, così le firme che confermano le transazioni confermano anche i prezzi contro cui quelle transazioni vengono regolate.

Un validatore è idoneo a proporre un blocco solo se può presentare osservazioni di prezzo valide per il round corrente. La disponibilità del prezzo è quindi una precondizione della produzione dei blocchi, non un input che l'esecuzione spera di trovare.

<Warning>
  Questo lega il prezzo alla transazione; non rende il prezzo corretto. Il consenso certifica che un quorum di validatori ha inviato queste osservazioni in questo round. Se le sedi di negoziazione sottostanti siano state accurate è un'altra questione, affrontata dalle regole di aggregazione nella pagina [Oracolo](/it/protocol/architecture/oracle) e delimitata dall'[informativa sui rischi](/it/protocol/security/risks).
</Warning>

<h2 id="leader-reputation">
  Reputazione del leader
</h2>

I leader vengono selezionati round per round con una rotazione deterministica pesata per stake, estesa da un'euristica di reputazione su una finestra scorrevole. Un validatore con proposte fallite ripetute — segno di indisponibilità o di comportamento ostile — viene retrocesso nelle selezioni successive e i suoi slot ridistribuiti a validatori che hanno risposto di recente, così un validatore non disponibile non manda in stallo il progresso rivendicando la leadership degli slot che gli spettano.

Poiché le osservazioni di prezzo condizionano l'idoneità a proporre, la reputazione deve anche evitare di concentrare la leadership tra i validatori con la migliore connettività ai dati di mercato. Un requisito di diversità delle sedi di negoziazione — osservazioni tratte da più fonti indipendenti per ogni strumento — chiude quella strada.

<h2 id="epochs-and-reconfiguration">
  Epoch e riconfigurazione
</h2>

Il tempo è organizzato in epoch. All'interno di un'epoch il set di validatori e la maggior parte dei parametri restano costanti. Ai confini tra epoch possono cambiare tramite una riconfigurazione autorizzata dalla governance: modifiche al set di validatori, modifiche ai parametri di consenso, aggiornamenti dei parametri di rischio e azioni d'emergenza. Le transizioni sono atomiche: ogni validatore onesto vede la stessa transizione alla stessa altezza di blocco.

<h2 id="network-topology">
  Topologia della rete
</h2>

<div className="dg" data-dg="bft-round">
  <div className="dg-c" style={{aspectRatio:"720 / 318"}}>
    <svg className="dg-w" viewBox="0 0 720 318" aria-hidden="true">
      <path className="dg-rule dg-dash" d="M 90 40 L 90 266" />

      <path className="dg-rule dg-dash" d="M 360 40 L 360 266" />

      <path className="dg-rule dg-dash" d="M 630 40 L 630 266" />

      <path className="dg-wire dg--blue" d="M 94.00 64.00 L 349.60 64.00" />

      <path className="dg-head dg--blue" d="M 356.00 64.00 L 349.60 68.40 L 349.60 59.60 Z" />

      <path className="dg-wire dg--sky" d="M 364.00 92.00 L 414.00 92.00 L 414.00 114.00 L 374.40 114.00" />

      <path className="dg-head dg--sky" d="M 368.00 114.00 L 374.40 109.60 L 374.40 118.40 Z" />

      <path className="dg-wire dg--sky dg-dash" d="M 356.00 146.00 L 100.40 146.00" />

      <path className="dg-head dg--sky" d="M 94.00 146.00 L 100.40 141.60 L 100.40 150.40 Z" />

      <path className="dg-wire dg--blue" d="M 94.00 218.00 L 349.60 218.00" />

      <path className="dg-head dg--blue" d="M 356.00 218.00 L 349.60 222.40 L 349.60 213.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 364.00 254.00 L 619.60 254.00" />

      <path className="dg-head dg--green" d="M 626.00 254.00 L 619.60 258.40 L 619.60 249.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"2.2222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Leader</span></div>
    <div className="dg-b dg--sky" style={{left:"39.7222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Validatori</span></div>
    <div className="dg-b dg--green" style={{left:"77.2222%",top:"0.0000%",width:"20.5556%",height:"9.4340%"}}><span className="dg-t">Catena</span></div>
    <div className="dg-b dg-dashed dg-tight dg-solid" style={{left:"14.4444%",top:"52.2013%",width:"33.6111%",height:"8.1761%"}}><span className="dg-s">Aggregato 2f+1 pesato per stake</span></div>
    <div className="dg-b dg--green" style={{left:"68.8889%",top:"86.7925%",width:"31.1111%",height:"11.9497%"}}><span className="dg-s">Ordinamento e prezzi ora sono immutabili</span></div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"15.0943%",width:"34.4444%",whiteSpace:"normal"}}>Propone il blocco — digest dei batch e prezzi certificati</div>
    <div className="dg-lbl" style={{left:"72.7778%",top:"32.3899%",width:"26.3889%",whiteSpace:"normal"}}>Verifica disponibilità, ordinamento, prezzi</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"40.8805%"}}>Voto</div>
    <div className="dg-lbl" style={{left:"31.2500%",top:"63.5220%"}}>Certifica il round</div>
    <div className="dg-lbl" style={{left:"68.7500%",top:"74.8428%"}}>Conferma</div>
  </div>
</div>

**I validatori** partecipano al consenso. Ognuno esegue l'intero stack: consenso, mempool, un sidecar dell'oracolo, l'esecuzione del kernel e l'archiviazione. Sono gli unici partecipanti che votano.

**I full node dei validatori** stanno subito dietro ai validatori. Seguono i blocchi confermati e li eseguono, ma non votano. Il loro scopo è l'isolamento: assorbono il traffico pubblico di lettura e le connessioni dei peer, così i validatori non sono esposti direttamente alla rete aperta.

**I full node pubblici** sono il livello aperto. Chiunque può gestirne uno. Seguono la catena, eseguono i blocchi confermati, servono le letture e alimentano i sistemi a valle.

**I client** — front end, agenti di trading, market maker, indexer — si collegano ai full node, non ai validatori. Un client che ha bisogno della vista più completa e a latenza più bassa gestisce un proprio full node invece di dipendere da quello di qualcun altro.

I nodi che entrano in rete non rieseguono dal blocco genesi per impostazione predefinita; vedi [sincronizzazione dello stato](/it/protocol/architecture/state/sync) per come un nuovo nodo si mette in pari.

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

<CardGroup cols={2}>
  <Card title="Mempool" href="/it/protocol/architecture/mempool">
    Che cosa arriva al consenso, in quale ordine e che cosa viene scartato.
  </Card>

  <Card title="IntentionKernel" href="/it/protocol/architecture/kernel">
    Che cosa succede a un blocco una volta confermati ordinamento e prezzi.
  </Card>

  <Card title="Oracolo" href="/it/protocol/architecture/oracle">
    Come viene prodotto un prezzo indice prima che un validatore lo firmi.
  </Card>

  <Card title="Gestire un nodo" href="/it/developers/run-a-node">
    Perché il set di validatori è chiuso e come chiedere di entrare.
  </Card>
</CardGroup>