---
title: "Finalità della blockchain: prove, ipotesi e livelli di regolamento"
description: "La finalità è la garanzia specifica di un protocollo che una decisione non venga sostituita senza violare le ipotesi di sicurezza o attivare un recupero eccezionale. Validità, fork choice, prova di finalità, limiti di guasto, dipendenze tra livelli e regolamento applicativo vanno separati."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Finalità della blockchain: prove, ipotesi e livelli di regolamento
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
La finalità è la garanzia specifica di un protocollo che una decisione accettata, come un blocco, checkpoint o impegno di stato, non venga sostituita senza violare le ipotesi di sicurezza dichiarate o ricorrere a un recupero eccezionale. Non è una proprietà fisica dei byte della transazione né significa soltanto «la transazione è riuscita». Ogni affermazione deve indicare oggetto, rete, versione, prove, modello di guasto e temporale, punto iniziale fidato e osservatore.
Validità, canonicità e finalità sono distinte. Un blocco valido soddisfa le regole di transizione e autorizzazione. Il fork choice seleziona la testa canonica corrente tra candidati validi. La finalizzazione applica un predicato aggiuntivo, come un certificato di commit o un checkpoint finalizzato, a un antenato della testa. Una transazione può riuscire in un blocco valido poi escluso; una testa può essere canonica ma non finalizzata; un evento finalizzato sulla catena sorgente può ancora fallire in un bridge, exchange o applicazione.
Il proof of work offre solitamente regolamento probabilistico, non un bit esplicito di finalità: accumulando lavoro valido sopra un blocco, sostituirlo diventa in genere meno probabile e più costoso sotto le ipotesi di hash power e rete. Un protocollo BFT può offrire finalità deterministica condizionale: dopo un certificato valido, due decisioni in conflitto non possono essere entrambe committed se il peso guasto resta sotto il limite dimostrato. In PoS può essere anche responsabile o economica, perché voti conflittuali identificano peso sottoponibile a slashing. Sono prove diverse, non sinonimi.
Nessun protocollo rende la storia assolutamente immutabile. Compromissione catastrofica di chiavi, violazione del limite di guasto, bug client, transizioni invalide accettate dalle implementazioni, governance o recupero sociale possono oltrepassare il modello. «Finalizzato» deve significare che il normale percorso di riorganizzazione non può sostituire quella decisione sotto tali ipotesi; recupero eccezionale e autorità vanno documentati a parte.
## Come analizzare la finalità
1. **Definire oggetto e ambito.** Identificare transazione, blocco, checkpoint, state root, messaggio cross-chain o prelievo; registrare catena, rete, livello, versione, altezza o slot, hash e checkpoint fidato.
2. **Verificare la validità prima dello stato.** Rieseguire o validare altrimenti transizione e ascendenza. Quorum, punteggio di lavoro o badge dell'interfaccia non possono finalizzare un oggetto invalido secondo le regole effettive.
3. **Separare selezione della testa e finalizzazione.** Ricostruire fork choice e percorso canonico, quindi trovare l'antenato finalizzato o committed. Registrare se è solo osservato, confermato, giustificato, sicuro, committed o finalizzato.
4. **Riprodurre le prove.** In PoW verificare header, target e chainwork cumulato sopra il blocco. Nei protocolli di voto verificare idoneità, snapshot dei pesi, dominio, sorgente e destinazione, altezza, round, disuguaglianza di quorum, firme, lock e ascendenza del certificato.
5. **Dichiarare ipotesi di safety e liveness.** Specificare peso bizantino o offline, sincronia, ritardo, equivocazione, compromissione di chiavi, correlazione client, cambi di membri, disponibilità dello slashing e comportamento allo stallo. Un arresto può preservare safety perdendo liveness.
6. **Mappare ogni livello di regolamento.** Seguire ricezione del sequencer, esecuzione L2, pubblicazione dati, inclusione L1, finalità L1, fine di prova o disputa, esecuzione bridge, accredito exchange e azione applicativa. Etichette simili tra livelli possono indicare predicati diversi.
7. **Definire e monitorare una policy applicativa.** Stabilire prove accettabili per valore e conseguenza, interrogare nodi indipendenti, gestire riorganizzazioni e allarmi di finalità conflittuale, sospendere azioni irreversibili se cadono le ipotesi e registrare chi autorizza il recupero.
Il numero di conferme è un'osservazione, non una regola universale. In Bitcoin Core, `confirmations` dipende dalla posizione del blocco nella catena attiva, mentre `chainwork` indica il lavoro atteso cumulato. In Ethereum, scelta della testa LMD-GHOST e giustificazione e finalizzazione Casper FFG sono transizioni separate. In CometBFT, un commit richiede oltre due terzi del potere in precommit per lo stesso blocco, altezza e round. Ogni stato va interpretato nel proprio protocollo.
## Esempi calcolati
### 1. Regolamento PoW probabilistico
Il white paper Bitcoin modella un attaccante con quota hash `q=0.10` che tenta di raggiungere la catena onesta dopo un vantaggio `z=6`. Con tentativi hash indipendenti e ipotesi di Poisson, la probabilità calcolata è:
`P=0.0002428 = 0.02428%`
È piccola, non zero, e non è una garanzia universale di «sei conferme». La policy reale considera valore, chainwork osservato, concentrazione hash, rischio eclipse o partizione, incentivi delle fee e credibilità della quota costante del modello.
### 2. Giustificazione e finalizzazione Ethereum
Si consideri un percorso semplificato di checkpoint consecutivi con saldo effettivo attivo totale `100`. Voti `67/100` che collegano il checkpoint giustificato `C_0` al target `C_1` raggiungono almeno due terzi e giustificano `C_1`. Un successivo link valido `67/100` da `C_1` al figlio diretto `C_2` può finalizzare `C_1` secondo la regola Casper FFG applicabile.
La testa può proseguire oltre `C_2` mentre la parte nuova resta non finalizzata. Se il saldo `34` è offline, rimane `66` e la finalizzazione immediata si blocca anche se fork choice e produzione continuano. Dopo oltre quattro epoch senza finalità, l'inactivity leak di Ethereum penalizza la mancata partecipazione affinché una supermaggioranza attiva possa recuperarla.
### 3. Safety e liveness in CometBFT
Siano il potere totale `100` e il requisito `>2/3` precommit per lo stesso blocco, altezza e round. Il potere intero `67` esegue il commit. Due insiemi di 67 si intersecano per almeno `67 + 67 - 100 = 34`. Con peso bizantino sotto un terzo e validatori onesti che rispettano i lock, due commit conflittuali non possono formarsi.
Se il peso `34` non è disponibile, solo `66` può votare e non si forma un commit. Il protocollo può preservare safety mentre la finalità si arresta. «Nessun blocco finalizzato conflittuale» e «i nuovi blocchi continuano a finalizzarsi» sono garanzie diverse.
### 4. Stati OP Stack e tempi di prelievo
Un sequencer OP Stack può esporre inizialmente un blocco L2 come `unsafe`. Quando è interamente derivabile dai dati della catena L1 canonica corrente, il nodo rollup può marcarlo `safe`. Quando gli input L1 corrispondenti ricevono il segnale di finalità L1, il blocco L2 derivato può diventare `finalized`.
Lo stato riguarda la derivazione da input finalizzati. Un output optimistic rollup o prelievo L2-L1 ha un proprio processo di prova e disputa e può dirsi «finalizzato» solo dopo la condizione di contestazione. Un'app che riduce conferma del sequencer, inclusione dati L1, finalità del consenso L1 ed esecuzione del prelievo a un solo istante può liberare valore troppo presto.
## Rischi ed errori di revisione
### Definizione e prove
- Chiamare «finale» ogni esecuzione, ricevuta, conferma, checkpoint o badge riuscito.
- Omettere catena, rete, versione, hash dell'oggetto, altezza o slot, livello e osservatore.
- Trattare la testa del fork choice come antenato finalizzato o presumere che la finalizzazione scelga la testa più recente.
- Contare blocchi o minuti senza validare ascendenza, target, lavoro, voti o certificati.
- Confrontare «due conferme» o «dieci minuti di finalità» tra protocolli con prove e guasti diversi.
- Verificare firme senza idoneità, peso, dominio, sorgente, target, altezza e round.
- Equiparare costo economico, prova slashable ed effettiva applicazione della sanzione.
- Descrivere rischio probabilistico come zero o safety deterministica condizionale come irreversibilità assoluta.
### Guasti di protocollo e operativi
- Superare il limite bizantino, perdere peso online necessario alla liveness o nascondere una partizione.
- Lasciare divergere le implementazioni su validità, fork choice, transizioni, arrotondamento del quorum o ascendenza del certificato.
- Accettare voti, commit, checkpoint o dati di weak subjectivity obsoleti, ripetuti o di altra rete.
- Concentrare chiavi, stake, hash power, client, relay, cloud o viste RPC dietro identità nominalmente distinte.
- Presumere che inactivity leak, timeout o view change ripristini subito e senza conseguenze il progresso.
- Non allertare su ritardo di finalità, certificati conflittuali, riorganizzazione profonda, equivocazione o root divergenti.
- Usare governance d'emergenza o recupero sociale senza documentare autorità, coordinamento, release client e garanzie coinvolte.
### Disallineamento tra livelli e applicazione
- Trattare inclusione del sequencer come safety L2, pubblicazione L1, finalità L1, accettazione prova e prelievo completato insieme.
- Rilasciare asset bridged prima che evento sorgente e verifica del bridge soddisfino la policy.
- Accreditare depositi o eseguire trade irreversibili dallo stato di un solo RPC senza riconciliazione indipendente.
- Presumere che la finalità garantisca verità dell'oracolo, correttezza del contratto, disponibilità dati, solvibilità o regolamento legale.
- Applicare la stessa soglia fissa a ogni valore, controparte, incentivo d'attacco e costo di recupero.
## Idee errate comuni
- **Una transazione riuscita è finale.** Il successo descrive una transizione in una storia candidata; canonicità e finalità richiedono altre prove.
- **Più conferme portano esattamente a zero il rischio PoW.** La probabilità può calare molto ma resta condizionata e non diventa impossibilità logica.
- **Due terzi significano sempre finalità.** Disuguaglianza, messaggio, peso, altezza, round, relazione sorgente-target e lock dipendono dal protocollo.
- **La finalità garantisce che la rete prosegua.** La safety può restare intatta mentre partecipazione o connettività insufficienti bloccano nuove finalizzazioni.
- **La finalità L1 completa ogni azione L2 o bridge.** Derivazione, prova di validità o frode, finestra di contestazione ed esecuzione destinazione aggiungono tempi e guasti distinti.
## Argomenti correlati
- [Conferme dei blocchi](/it/crypto/block-confirmation/)
- [Riorganizzazioni della catena](/it/crypto/chain-reorg/)
- [Meccanismi di consenso](/it/crypto/consensus-mechanism/)
- [Regole di fork choice](/it/crypto/fork-choice-rule/)
- [Weak subjectivity](/it/crypto/weak-subjectivity/)
## Fonti
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consultato: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consultato: 2026-08-19)
- [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (consultato: 2026-08-19)
- [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (consultato: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consultato: 2026-08-19)
- [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (consultato: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consultato: 2026-08-19)
- [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism (consultato: 2026-08-19)
Source: https://wiki.fcontext.com/it/crypto/finality/index.mdx