---
title: "Conferme di blocco"
description: "Guida basata sulla verifica della profondità di conferma PoW, degli stati safe e finalized di PoS, della sostituzione nel mempool, delle riorganizzazioni e delle politiche di accredito dei depositi."
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.
# Conferme di blocco
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Una conferma di blocco è un'affermazione specifica dell'osservatore e del protocollo: una transazione è inclusa in un blocco della chain canonica corrente dell'osservatore. La comune convenzione inclusiva di Bitcoin Core conta il blocco contenente la transazione come prima conferma. Per altezza di inclusione `h` e altezza della best chain `H`, la profondità è `H - h + 1`. Alcuni servizi mostrano soltanto i discendenti come `H - h`; occorre quindi dichiarare la convenzione.
La profondità Proof of Work riduce il rischio di riorganizzazione sotto ipotesi esplicite, ma non crea un punto magico di finalità assoluta. I sistemi Proof of Stake possono esporre stati nativi del protocollo. Ethereum distingue `latest`, `safe` e `finalized`; un numero fisso di blocchi, slot o minuti non sostituisce tali etichette. Gli stati rilevato, accreditato, negoziabile e prelevabile di una piattaforma sono politiche interne distinte anche dopo il raggiungimento della soglia della chain.
## Come funziona
1. Fissa chain e rete, asset, identificatore della transazione, nodo o API, istante di osservazione, modello di consenso e convenzione di conteggio. Verifica destinatario, importo ed eventuale memo o tag prima di trattare un hash corrispondente come pagamento previsto.
2. Separa firmata, trasmessa, accettata dal mempool locale di un nodo e propagata. I mempool sono viste di policy, non una coda globale di consenso. Controlla stato delle commissioni, antenati non confermati, Replace-by-Fee o sostituzione con lo stesso nonce e spese in conflitto.
3. Verifica l'inclusione tramite hash del blocco, altezza, indice della transazione e discendenza canonica, non solo tramite altezza o badge dell'explorer. Nelle account chain, esamina anche stato della ricevuta, log e modifica effettiva dello stato; un'esecuzione inclusa può comunque revertire.
4. Applica il modello di consenso. Per PoW, dichiara la convenzione, calcola la profondità e confronta viste indipendenti di best chain e lavoro cumulato. Per PoS, interroga gli stati nativi head, safe, justified o finalized; non dedurli da una distanza fissa in blocchi o slot.
5. Registra il ciclo di vita con stati espliciti: creata, trasmessa, accettata nel mempool locale, inclusa, profondità canonica o stato safe/finalized, riorganizzata, reinclusa, sostituita o in conflitto. Una riorganizzazione non garantisce che la transazione originale ritorni in ogni mempool.
6. Mantieni separato il registro della piattaforma: osservata, soglia di rete raggiunta, accreditata, negoziabile e prelevabile. Applica la policy vigente specifica per asset, rete, importo e incidente; manutenzione, compliance e revisione manuale possono aggiungere ritardi indipendenti.
7. Confronta nodi o provider indipendenti e continua a monitorare fino allo stato richiesto. Registra hash, altezze, timestamp, etichette RPC e snapshot della policy, e simula sostituzione, riorganizzazione, ritardo della finalità, nodo obsoleto, relay del bridge e indisponibilità della piattaforma.
## Esempi svolti
- **Convenzione di conteggio.** Una transazione Bitcoin si trova nel blocco canonico `h = 900,000` e il tip della best chain è `H = 900,005`. La profondità inclusiva è `900,005 - 900,000 + 1 = 6 confirmations`; un display che conta solo i discendenti riporta `900,005 - 900,000 = 5`. La differenza è terminologica se entrambi si riferiscono allo stesso hash e alla stessa discendenza.
- **Riorganizzazione e reinclusione.** La transazione ha inizialmente `1 confirmation` nel blocco `900,000`; poi il blocco esce dalla best chain e il valore torna a `0` se resta valida e senza conflitti. Se viene reinclusa a `900,003` e il tip raggiunge `900,006`, la profondità inclusiva è `900,006 - 900,003 + 1 = 4 confirmations`. Se un conflitto confermato la sostituisce, Bitcoin Core può invece riportare conferme negative.
- **Le etichette PoS non sono conteggi di blocchi.** Supponiamo che una transazione Ethereum sia nel blocco di esecuzione `20,000,000` e che un nodo riporti `latest = 20,000,020`, `safe = 20,000,012` e `finalized = 19,999,980`, tutti sulla stessa discendenza. La profondità latest numerica è `20,000,020 - 20,000,000 + 1 = 21`; la transazione è safe, ma non finalized. Servono discendenza degli hash ed etichette del consenso; le altezze non bastano.
- **Soglia della chain e accredito della piattaforma.** La policy richiede `6 confirmations`. Un deposito nel blocco `900,000` è a `5/6` quando il tip è `900,004` e raggiunge `6/6` a `900,005`. Se poi si applica una `15-minute compliance hold`, idoneità on-chain e tempi di accredito, negoziazione o prelievo restano stati distinti; la sospensione non è una settima conferma.
## Rischi
- Esaminare chain, rete o asset sbagliati.
- Usare hash, destinatario, memo o tag errati.
- Trattare una transazione firmata ma non trasmessa come pending.
- Trattare il mempool di un nodo come stato globale della rete.
- Non rilevare rifiuto per policy, espulsione o mancata propagazione.
- Ignorare una sostituzione RBF, same-nonce o una spesa in conflitto.
- Interpretare male antenati, discendenti o package fee non confermati.
- Mescolare conteggi inclusivi e dei soli discendenti.
- Fidarsi di un nodo obsoleto, in sincronizzazione o isolato.
- Confrontare altezze senza verificare hash e discendenza.
- Perdere conferme in una breve riorganizzazione PoW.
- Trattare una profondità fissa come sicurezza assoluta per ogni valore e avversario.
- Confondere tempo trascorso, slot, epoch e blocchi prodotti.
- Trattare un head block PoS come safe.
- Trattare un blocco safe come finalized.
- Non rilevare ritardo della finalità mentre la chain produce ancora blocchi.
- Trattare un'esecuzione inclusa ma revertita come successo applicativo.
- Confondere log di token o UI dell'explorer con lo stato risultante.
- Equiparare rilevamento, accredito, negoziazione e permesso di prelievo.
- Trattare la conferma sulla source chain come completamento di bridge, emittente o flusso di destinazione.
## Errori comuni
- Un hash ricercabile o una voce del mempool locale sono già confermati.
- Una convenzione e la soglia di sei conferme valgono per ogni chain, importo e servizio.
- Una commissione più alta fa arrivare prima blocchi successivi o finalità PoS.
- Un conteggio fisso di blocchi o slot Ethereum equivale a `safe` o `finalized`.
- Inclusione o finalità garantisce esecuzione corretta, destinatario corretto, accredito o completamento del bridge.
## Argomenti correlati
- [Mempool](/it/crypto/mempool/)
- [Bitcoin](/it/crypto/bitcoin/)
- [Finalità](/it/crypto/finality/)
## Fonti
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consultato: 2026-08-13)
- [Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) - Bitcoin Developer Documentation (consultato: 2026-08-13)
- [gettransaction](https://developer.bitcoin.org/reference/rpc/gettransaction.html) - Bitcoin Developer Documentation (consultato: 2026-08-13)
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bips.dev/125/) - Bitcoin Improvement Proposals (consultato: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (consultato: 2026-08-13)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (consultato: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultato: 2026-08-13)
- [Cryptocurrency deposit processing times](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times) - Kraken Support (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/block-confirmation/index.mdx