---
title: "Blockchain: stato, consenso e verifica"
description: "Una blockchain è un protocollo versionato per ordinare e convalidare le transizioni di stato tra repliche. I collegamenti hash sono solo un componente; la fiducia dipende dal consenso, dalle autorizzazioni, dalla verifica indipendente, dalla disponibilità dei dati, dalla governance e dal ripristino."
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.
# Blockchain: stato, consenso e verifica
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Una blockchain è un protocollo versionato che consente a più repliche di ordinare le transazioni proposte, convalidare le transizioni di stato e convergere su una cronologia accettata secondo il consenso dichiarato e le ipotesi di rete. Un blocco è un contenitore definito dal protocollo con transazioni o altri dati, più impegni verso la cronologia precedente e lo stato risultante; la catena, o cronologia diretta, collega i contenitori accettati tramite impegni crittografici.
I collegamenti hash rendono rilevabili le modifiche storiche non autorizzate, ma da soli non rendono un sistema decentralizzato, immutabile o corretto. Tali proprietà dipendono da chi può proporre e convalidare, dalla possibilità per gli utenti di verificare in modo indipendente, dalle regole di scelta del fork e di finalità, dalla disponibilità dei dati, dalla diversità dei client, dalla governance, dal controllo delle chiavi, dagli incentivi e dalle procedure di recupero.
Le blockchain possono utilizzare modelli di stato UTXO, basati su account, oggetti o specifici dell'applicazione; proof of work, proof of stake, voto con tolleranza ai guasti bizantini o consenso permissioned; e finalità probabilistica o basata su checkpoint. La parola “blockchain” designa quindi un’ampia famiglia di architetture, non una garanzia di sicurezza né un singolo prodotto di database.
## Come funziona
1. Identifica con precisione la catena, la rete, la versione del protocollo, il modello di autorizzazione, il modello di stato e l'affermazione da verificare. Registra la genesi o il checkpoint attendibile, l'identificatore della catena, l'implementazione del client e l'autorità di aggiornamento.
2. Costruisci i byte esatti della transazione e dell'autorizzazione. Prima della trasmissione, controlla la proprietà del mittente o degli input, il nonce o i riferimenti agli output non spesi, l'importo, la destinazione, i limiti delle commissioni, la finestra di validità, le firme e le chiamate dell'applicazione.
3. Propagare la transazione attraverso peer o gateway. Distinguere l’ammissione locale e la politica di mempool dalla validità del consenso; un nodo può rifiutare, ritardare, sostituire o non ricevere mai una transazione che potrebbe essere valida in un blocco.
4. Un proponente seleziona e ordina le transazioni in un blocco candidato e si impegna a campi del protocollo come genitore, transazione, ricevuta, stato o radici dei dati. L'ordinazione può influire sui risultati di esecuzione, sulle commissioni, sulle liquidazioni e sul valore estraibile.
5. I nodi indipendenti deserializzano il blocco, verificano l'autorizzazione del consenso e ogni transizione di stato richiesta, ricalcolano gli impegni e rifiutano input non validi o non disponibili secondo le loro regole. Le firme del produttore o la prova del lavoro non annullano la convalida non riuscita.
6. La scelta del fork seleziona tra storie valide concorrenti, mentre conferme, voti o checkpoint modificano il rischio di riorganizzazione nel tempo. "Incluso", "sicuro" e "finalizzato" sono stati diversi e rimangono specifici del protocollo.
7. Riconcilia lo stato del protocollo con l'intento dell'applicazione, la custodia, la contabilità del bridge o della piattaforma e i requisiti di archiviazione. Conserva i byte della transazione, l'hash del blocco, l'altezza o lo slot, la ricevuta, i log, la prova dello stato, lo stato di finalità, la versione del client e le evidenze ottenute da un endpoint indipendente.
## Esempi realizzati
- **Riconciliazione dello stato dell'account.** Un account inizia con `10 ETH` e nonce `41`. Una transazione valida con nonce `41` trasferisce `2 ETH` e consuma `0.00042 ETH` in commissioni; lo stato successivo semplificato è quindi `10 - 2 - 0.00042 = 7.99958 ETH`, il destinatario riceve `2 ETH` e il nonce del mittente diventa `42`. Una firma valida, da sola, non dimostrerebbe né il saldo precedente né la corretta esecuzione.
- **Conservazione UTXO.** Una transazione spende input di `0.80 BTC` e `0.35 BTC`, per un totale di `1.15 BTC`. Uscite di `1.00 BTC` e `0.1496 BTC` totale `1.1496 BTC`; la differenza è di `1.15 - 1.1496 = 0.0004 BTC` in commissioni. I nodi devono inoltre verificare che ogni output di riferimento esista, non sia speso e soddisfi le condizioni di spesa.
- **Dimensione della prova dell'impegno.** In un albero Merkle binario bilanciato illustrativo con `8 leaves`, un percorso di inclusione richiede `log2(8) = 3 sibling hashes`. Con gli hash `256-bit = 32-byte`, questi fratelli occupano `3 * 32 = 96 bytes` prima degli indici e della codifica. La prova lega una foglia ad una radice dichiarata; non dimostra che i dati di origine siano veritieri o attualmente disponibili.
- **Il peso non è il conteggio dei nodi.** In un protocollo di voto illustrativo la cui regola di finalità dichiarata è `>= 2/3` di peso, i validatori mantengono `30%, 25%, 20%, 15%, 10%`. I primi tre totalizzano `30 + 25 + 20 = 75%` e superano la regola, mentre i primi due totalizzano `55%` e non lo fanno. Le soglie reali, la correlazione, l'equivoco e le regole di recupero devono provenire dal protocollo indicato.
## Rischi
- Utilizzo di catena, rete, fork, checkpoint o identificatore di catena errati.
- Trattare un marchio come un protocollo completo o una specifica del modello di fiducia.
- Supponendo che il solo collegamento hash impedisca le riscritture autorizzate o approvate dal consenso.
- Confondere la proposta di blocco di un produttore con la convalida del nodo indipendente.
- Trattare l'accettazione, la trasmissione, l'inclusione, il successo dell'esecuzione e la finalità di Mempool come un unico stato.
- Firma di byte, domini o destinazioni diverse da quanto visualizzato nell'interfaccia.
- Riutilizzare i nonce, spendere UTXO obsoleti o calcolare erroneamente commissioni e modifiche.
- Affidarsi ai simboli dei token, alle etichette, agli eventi o alle interpretazioni dell'esploratore invece degli identificatori e dello stato del protocollo.
- Trattare gli input firmati di Oracle, Bridge o documenti come prova che le affermazioni off-chain sono vere.
- Ignorare l'ordine delle transazioni, la censura, il front-running e la concentrazione del proponente o del costruttore.
- Conteggio di nodi o validatori senza risolvere operatori, pesi e infrastrutture comuni.
- Ignorare la concentrazione di clienti, cloud, geografia, governance, chiavi e catena di fornitura del software.
- Supponendo che tutti i modelli di consenso abbiano le stesse soglie di errore o semantica di finalità.
- Ignorare spartizioni, definitività ritardata, riorganizzazioni, equivoci e procedure di recupero.
- Accettare intestazioni di blocco o prove senza i presupposti richiesti sulla disponibilità dei dati.
- Dipendere da un solo RPC, explorer, portafoglio, indicizzatore o piattaforma di custodia come fonte della verità.
- Confondere il possesso o il controllo del protocollo con il titolo legale, il ricorso o la recuperabilità.
- Sottovalutare la crescita dello stato, la perdita di archivi, i costi di sincronizzazione e le barriere hardware.
- Ignorare chiavi di aggiornamento, pause di emergenza, recupero sociale e fork controversi.
- Dedurre privacy, scalabilità, valore dell'investimento o sicurezza dell'applicazione dall'etichetta blockchain.
## Errori comuni
- **Ogni blockchain è decentralizzata e immutabile.** Autorizzazione, indipendenza dell'operatore, scelta del fork, governance e ripristino determinano chi può modificare o rifiutare la cronologia.
- **I dati registrati sulla catena devono essere veri.** Il consenso può concordare sulla registrazione fedele di un prezzo falso, di un documento contraffatto o dell'input di un'applicazione dannosa.
- **Una transazione valida dimostra il risultato previsto.** Potrebbe prendere di mira l'indirizzo sbagliato, essere ripristinata dopo aver consumato le commissioni, emettere eventi fuorvianti o dipendere da passaggi successivi di bridge e custodia.
- **Più repliche migliorano sempre la sicurezza.** Le repliche sotto un unico operatore, client, cloud o chiave possono fallire insieme e potrebbero non fornire una verifica indipendente.
- **Una blockchain è sempre migliore di un database convenzionale.** Un operatore fidato, la cancellazione richiesta, un rendimento elevato o una semplice risoluzione delle controversie possono rendere un sistema convenzionale più appropriato.
## Argomenti correlati
- [Meccanismo di consenso](/it/crypto/consensus-mechanism/)
- [Hash crittografico](/it/crypto/cryptographic-hash/)
- [Nodo completo](/it/crypto/full-node/)
## Fonti autorevoli
- [Panoramica sulla tecnologia Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (accesso: 2026-08-18)
- [Bitcoin: un sistema di cassa elettronico peer-to-peer](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (accesso: 2026-08-18)
- [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin.org (accesso: 2026-08-18)
- [Blocchi](https://ethereum.org/developers/docs/blocks/) - Ethereum.org (accesso: 2026-08-18)
- [Transazioni](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (accesso: 2026-08-18)
- [Nodi e client](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (accesso: 2026-08-18)
- [Meccanismi di consenso](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (accesso: 2026-08-18)
- [Finalità](https://ethereum.org/developers/docs/consensus-mechanisms/pos/finality/) - Ethereum.org (accesso: 2026-08-18)
Source: https://wiki.fcontext.com/it/crypto/blockchain/index.mdx