---
title: "Meccanismi di consenso: validità, scelta del fork e finalità"
description: "Un meccanismo di consenso coordina repliche su cronologie compatibili sotto ipotesi esplicite di guasto e rete. Occorre analizzare separatamente decisione, partecipanti e pesi, validità, proposta, scelta del fork, finalità, sicurezza, vitalità e distribuzione."
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.
# Meccanismi di consenso: validità, scelta del fork e finalità
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un meccanismo di consenso è il protocollo con cui repliche non guaste convergono su decisioni compatibili riguardo a un registro ordinato o a uno stato, nonostante ritardi, concorrenza e guasti contemplati dal modello. In una blockchain il meccanismo completo può includere selezione del proponente, convalida di blocchi e transizioni di stato, voti o prove, scelta del fork, commit o finalità, recupero e regole di appartenenza. Non è soltanto “molti computer conservano lo stesso file”, una soglia di voto, mining, staking o un piano di incentivi.
Tre proprietà vanno dichiarate separatamente. `safety` (sicurezza) impedisce decisioni incompatibili tra partecipanti non guasti; `liveness` (vitalità) indica che il lavoro valido può infine avanzare nelle condizioni specificate; `validity` (validità) limita ciò che può essere deciso. Un protocollo può arrestarsi preservando la sicurezza oppure avanzare sotto ipotesi che consentono una successiva riorganizzazione. La parola “consenso” da sola non dice quale garanzia valga, quando valga o di quali prove un client debba fidarsi.
Validità della transazione e selezione canonica sono diverse. Un nodo completo respinge autonomamente una transizione che viola le regole correnti. Se due transazioni singolarmente valide spendono lo stesso input, ordinamento o scelta del fork decide quale entra nella cronologia canonica; una maggioranza di risorse non le rende entrambe valide. Analogamente, concordare byte non dimostra che un fatto di un oracolo, un'affermazione di un bridge, un calcolo applicativo o un'asserzione legale siano veri.
Proof of Work e Proof of Stake forniscono di norma resistenza Sybil, influenza sulla proposta o peso di voto attribuibile, ma i loro nomi non specificano un protocollo completo. Bitcoin combina prova di lavoro, convalida e scelta della catena per lavoro cumulativo. Gasper di Ethereum combina attestazioni ponderate per stake, scelta LMD-GHOST e finalità dei checkpoint Casper FFG. Un BFT a round come CometBFT usa messaggi, soglie, ipotesi temporali e finalità differenti. Le percentuali non sono intercambiabili.
## Metodo di analisi
1. **Definire decisione e ambito.** Specificare se le repliche decidono un valore, un registro ordinato, un blocco per altezza, un checkpoint o uno stato applicativo; identificare catena, rete, livello, versione e punto iniziale fidato.
2. **Definire partecipanti e influenza.** Separare proponenti, votanti, validatori completi, client leggeri e osservatori. Registrare ingresso e uscita delle identità, influenza da hash power, stake, appartenenza paritaria o altro peso e difesa dalle identità duplicate economiche.
3. **Separare le fasi.** Documentare validità di transazioni e stato, costruzione e diffusione della proposta, voto o prova, scelta del fork, commit, finalità e recupero. Un blocco valido può perdere la scelta e una testa canonica può non essere ancora finale.
4. **Dichiarare il modello di sistema.** Definire canali autenticati, sincronia o sincronia parziale, ritardi e timeout, guasti crash e bizantini, equivoco, omissione, corruzione adattiva, furto di chiavi, partizioni e massimo numero o peso guasto `f`.
5. **Tracciare una decisione.** Seguire domini dei messaggi, altezze, round, genitori, lock, certificati e stato locale dalla proposta alla decisione. Mostrare cosa accade con messaggi tardivi, proponente equivoco, timeout del round o due rami validi.
6. **Verificare separatamente sicurezza e vitalità.** Derivare intersezione dei quorum, crescita della catena o altre condizioni con insieme e istantanea dei pesi esatti. Verificare poi se restano connettività e partecipazione oneste sufficienti; non dedurre vitalità da una soglia di sicurezza.
7. **Mappare la prova alla distribuzione.** Controllare versioni dei client, cambi di parametri, concentrazione di membri e stake, custodia delle chiavi, diversità dei peer, ruoli di builder o sequencer, checkpoint, regole di soggettività debole, riorganizzazioni e politica di conferma dell'applicazione.
FLP non afferma che il consenso distribuito sia impossibile. Nel modello di messaggi completamente asincrono, anche un solo guasto crash lascia un'esecuzione ammissibile in cui un protocollo deterministico non termina. I protocolli reali ottengono garanzie utili aggiungendo sincronia o sincronia parziale, casualità, rilevatori di guasto, ipotesi economiche o promesse di terminazione più deboli. Queste aggiunte vanno nominate, non nascoste dietro un'etichetta.
## Esempi svolti
### 1. Validità non significa ordinamento canonico
Un output non speso `U` vale 1 BTC. La transazione `T_B` lo spende a favore di Bob, mentre `T_C` spende lo stesso output a favore di Carol. Rispetto allo stesso stato genitore, ciascuna può avere firma e formato corretti, ma una cronologia valida non può consumare `U` due volte.
Se due blocchi validi concorrenti contengono una transazione ciascuno, la convalida conserva localmente entrambi i rami candidati e la scelta del fork ne seleziona uno canonico. Quando `T_B` entra nella cronologia scelta, `T_C` confligge con lo stato risultante. Il consenso ha scelto un ordine; non ha corretto una firma errata né deciso chi meritasse moralmente il pagamento.
### 2. Lavoro cumulativo, non numero di nodi
Supponiamo che due rami validi in stile Bitcoin abbiano lavoro cumulativo `W_A=240` e `W_B=235` nella stessa unità arbitraria. Un nodo validatore sceglie A in base al lavoro cumulativo anche se ha ricevuto prima B da più peer. Il numero di peer non è peso di consenso.
Se B aggiunge poi 10 unità e A nessuna, si ha `W_B=245` contro `W_A=240`; dopo aver convalidato il ramo, il nodo può riorganizzarsi su B. Questa aritmetica semplificata mostra perché la conferma PoW è probabilistica: sostituire cronologia profonda diventa progressivamente più costoso, non logicamente impossibile dopo un numero fisso di blocchi.
### 3. Quorum BFT ponderato e arresto della vitalità
Sia il peso totale dei validatori `100` e un commit in stile CometBFT richieda precommit `>2/3` per lo stesso blocco, altezza e round. Il peso intero `67` supera la soglia. Due quorum di peso 67 si intersecano per almeno `34`, perché 67 + 67 - 100 = 34. Se il peso bizantino è inferiore a un terzo, l'intersezione contiene peso onesto che non deve firmare commit in conflitto.
La stessa soglia mostra il limite di vitalità. Se 34 di peso è offline, resta `66` e non può formarsi un commit anche se tutti i validatori online sono onesti. Il protocollo può fermarsi preservando la sicurezza; un voto di governance o il numero di operatori non sostituisce il peso mancante.
### 4. Scelta del fork e finalità dei checkpoint sono distinte
In una traccia Gasper semplificata, siano `C_0`, `C_1` e il figlio diretto `C_2` i checkpoint. Voti pari a `67/100` del saldo effettivo attivo possono creare un collegamento di supermaggioranza da `C_0` a `C_1`, giustificando `C_1`. Un successivo collegamento idoneo da `C_1` a `C_2` può finalizzare il checkpoint precedente secondo la regola FFG applicabile.
Tra checkpoint, LMD-GHOST usa le attestazioni più recenti per scegliere la testa tra i discendenti praticabili del checkpoint giustificato, mentre i vincoli del checkpoint finalizzato filtrano i rami incompatibili. Scelta della testa, giustificazione e finalizzazione sono quindi transizioni correlate ma differenti; “il 67% ha votato questo blocco” non descrive completamente nessuna delle tre.
## Rischi ed errori di revisione
### Modello e garanzie
- Dire “la rete raggiunge il consenso” senza definire decisione, sicurezza, vitalità, validità e terminazione.
- Trattare Proof of Work, Proof of Stake, mining, staking o una percentuale come specifica completa.
- Applicare `51%`, `2/3` o `n=3f+1` universalmente a modelli diversi di guasto, tempo, peso e finalità.
- Confondere crash, comportamento bizantino, furto di chiavi, canali guasti, software correlato e cattura della governance.
- Invocare FLP come divieto del consenso pratico anziché per il suo ambito deterministico, completamente asincrono e con terminazione garantita.
- Contare nodi o chiavi senza misurare operatori indipendenti, peso, client, cloud e custodia.
- Presumere che canonico, safe, giustificato, committed e finalizzato siano stati intercambiabili.
- Dedurre verità esterna, ordine equo, privacy, decentralizzazione o valore dall'accordo replicato.
### Protocollo e implementazione
- Accettare blocchi o voti senza vincolo a catena, versione, altezza, round, genitore, payload, mittente ed epoca di appartenenza.
- Consentire divergenze tra implementazioni su transizione, serializzazione, dominio di firma, scelta, spareggio o arrotondamento.
- Verificare un certificato senza ricostruire istantanea del peso idoneo e trattamento dei firmatari duplicati.
- Riprodurre voti, lavoro o certificati tra fork, reti, round, aggiornamenti o cambi dei validatori.
- Aggiornare male lock, checkpoint giustificati o certificati più alti durante timeout, cambio di vista o recupero.
- Trattare una testa locale o l'etichetta di un solo RPC come prova indipendente della finalità di rete.
- Provare solo il percorso normale, non ritardo, partizione, equivoco, proposta non valida, riorganizzazione e recupero.
### Distribuzione e applicazione
- Concentrare hash power, stake, client, relay, builder, sequencer, cloud o firma dietro identità nominalmente separate.
- Impostare timeout o intervalli inferiori ai tempi reali di propagazione e convalida, danneggiando la vitalità o aumentando i fork.
- Accreditare depositi, coniare attività collegate da bridge o compiere azioni irreversibili prima della finalità richiesta di origine e applicazione.
- Presumere che slashing, ricompense o prezzo del token creino sempre un budget di sicurezza sufficiente e liquido.
- Usare recupero sociale o governance senza dichiarare chi coordina, quale catena installano i client e quale garanzia precedente cambia.
## Errori comuni
- **Consenso e convalida sono uguali.** La convalida respinge dati contrari alle regole; il consenso sceglie decisioni compatibili tra candidati forse validi localmente.
- **Più nodi significano automaticamente più sicurezza.** Influenza, indipendenza, topologia, diversità software e modello di guasto contano più del numero grezzo.
- **Un attaccante al 51% può falsificare qualsiasi firma.** La maggioranza di risorse può consentire censura o riorganizzazione in un protocollo, ma non rivela chiavi né autorizza spese non valide.
- **Due terzi significano sempre finalità.** Disuguaglianza, messaggio, round, istantanea di peso, regola di lock e condizione di finalità dipendono dal protocollo.
- **Blocchi rapidi dimostrano consenso forte.** Intervalli brevi possono aumentare gare di propagazione e pressione sulle risorse; valutare latenza insieme a sicurezza, vitalità e finalità.
## Argomenti correlati
- [Tolleranza ai guasti bizantini](/it/crypto/byzantine-fault-tolerance/)
- [Problema dei generali bizantini](/it/crypto/byzantine-generals-problem/)
- [Finalità](/it/crypto/finality/)
- [Regola di scelta del fork](/it/crypto/fork-choice-rule/)
- [Proof of Stake](/it/crypto/proof-of-stake/)
## 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)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (consultato: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (consultato: 2026-08-19)
- [Impossibility of Distributed Consensus with One Faulty Process](https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf) - Journal of the ACM (consultato: 2026-08-19)
- [Consensus in the Presence of Partial Synchrony](https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf) - Journal of the ACM (consultato: 2026-08-19)
- [CometBFT Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (consultato: 2026-08-19)
- [HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069) - arXiv (consultato: 2026-08-19)
Source: https://wiki.fcontext.com/it/crypto/consensus-mechanism/index.mdx