blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il 23 marzo 2026, alle 15:49 UTC, il blocco 941.881 di Bitcoin, estratto da AntPool, è arrivato ai nodi di monitoraggio; due minuti dopo il blocco 941.882 di ViaBTC si è posato sopra il primo. I wallet mostravano le transazioni come confermate, prima una volta e poi due. Verso le 15:55 Foundry ha pubblicato un ramo lungo tre blocchi, tutti i nodi sono passati a quello e i due blocchi sono usciti dalla catena. Nessun furto e nessuna regola violata, eppure due conferme erano svanite: è di questo che parla la finalità della blockchain. Secondo il thread del Bitcoin Network Operations Collective sull’episodio, la precedente riorganizzazione a due blocchi di cui si ha notizia risaliva al maggio 2023.
Una transazione può essere vista, inclusa in un blocco, sepolta sotto altri blocchi, votata come definitiva dai validatori o considerata tale da una legge, e ogni rete si ferma su un gradino diverso di questa scala. Bitcoin non raggiunge mai una finalità assoluta: un pagamento diventa soltanto più costoso da annullare a ogni blocco. Ethereum finalizza con un voto dei suoi staker, almeno 12,8 minuti dopo l’arrivo di una transazione e in pratica dopo circa 15. Solana ha attivato il 21 ottobre 2026 un nuovo sistema di voto che i suoi sviluppatori si aspettano finalizzi in una frazione di secondo, un obiettivo non ancora misurato sulla mainnet. Le catene Cosmos si fermano invece di biforcarsi.
Questa lezione avanzata ti dà gli strumenti per giudicare qualsiasi catena con tre domande. Come può sparire un blocco che vedo oggi? Quanto in profondità è già successo? Quanto costerebbe farlo accadere di proposito? Segue la nostra lezione sul problema della doppia spesa, che mostrava come un attaccante usi una riorganizzazione per spendere due volte le stesse monete; qui guardiamo le riorganizzazioni in sé e le regole di finalità costruite per impedirle.
Finalità blockchain: tre garanzie molto diverse
La parola «definitivo» nasconde tre garanzie di forza molto diversa. Gli ingegneri le raggruppano in famiglie, e ogni catena che usi appartiene a una di esse, a volte a due insieme.
La finalità probabilistica appartiene alle catene proof of work come Bitcoin, Litecoin o Monero. Un blocco non è mai definitivo per regola. Diventa più difficile da sostituire man mano che altri blocchi si accumulano sopra, perché un ramo concorrente dovrebbe rifare tutto quel lavoro e poi superare la catena onesta. La probabilità di un annullamento scende in modo grosso modo esponenziale con la profondità, ma non arriva mai a zero. La Banca dei regolamenti internazionali lo ha scritto chiaramente in un rapporto del 2017 del suo comitato sui pagamenti (CPMI), in inglese: «In arrangements that use a proof-of-work model, settlement is probabilistic.», cioè nei sistemi proof of work il regolamento è probabilistico.
Ethereum offre invece la finalità economica. I validatori che hanno bloccato ether come deposito votano dei checkpoint. Quando due terzi dello stake hanno votato un checkpoint come definitivo, per annullarlo servirebbe che almeno un terzo di tutto l’ether in staking violasse le regole di voto in un modo che il protocollo sa dimostrare e punire. L’annullamento resta possibile, ma gli attaccanti perderebbero i loro depositi, ed è questo il punto.
Terza famiglia, la finalità deterministica, a volte venduta come «finalità istantanea», viene dal voto classico a tolleranza ai guasti bizantini, come in CometBFT (già Tendermint), nelle milestone di Polygon PoS e nel nuovo consenso Alpenglow di Solana. Un blocco è definitivo non appena un ampio quorum di stake lo ha firmato, di solito entro un blocco. Non c’è un indurimento graduale: prima del quorum il blocco non è definitivo, dopo le regole vietano qualsiasi blocco in conflitto.
Due parole aiutano a confrontarle. La safety (sicurezza) significa che due nodi onesti non accettano mai storie in conflitto. La liveness (vitalità) significa che la catena continua ad aggiungere blocchi. Bitcoin privilegia la liveness: produce sempre blocchi, e la safety è questione di probabilità. Le catene BFT privilegiano la safety: se troppi validatori tacciono, si fermano. Ethereum cerca di tenere entrambe, con una regola di scelta del ramo che fa avanzare i blocchi e un meccanismo di finalità separato che può mettersi in pausa mentre la catena va avanti, come ha mostrato il maggio 2023.
Se ti serve un ripasso sul perché possano comparire due blocchi validi alla stessa altezza, la nostra guida a come funziona una blockchain spiega la regola di base per accordarsi su una sola catena. Per il costo di riscrivere la storia passata e le basi degli attacchi del 51%, vedi perché una blockchain è considerata immutabile.
Cos’è un reorg e come avviene su Bitcoin
Due blocchi validi, una sola catena che sopravvive
Un blocco di Bitcoin impiega del tempo ad attraversare la rete. Se due miner trovano un blocco valido quasi nello stesso istante, una parte della rete sente parlare prima dell’uno e una parte dell’altro. Entrambi sono validi. Ogni nodo continua a costruire sul primo che ha visto e si ricorda dell’altro. Il pareggio si rompe quando arriva il blocco successivo: i nodi seguono il ramo con più lavoro accumulato, che in pratica di solito è il più lungo. Il blocco perdente diventa un blocco stale. Molti lo chiamano «orfano», un uso più approssimativo del termine che la prossima lezione di questo percorso, sui fork, mette in ordine.
Il passaggio si chiama riorganizzazione della catena, o reorg. Il nodo scollega il blocco o i blocchi perdenti, annulla il loro effetto sul proprio registro delle monete non spese, collega i blocchi vincenti e rimette nella mempool ogni transazione che era nei blocchi persi ma non in quelli nuovi. La maggior parte di quelle transazioni viene estratta di nuovo nel giro di pochi minuti, perché di solito anche il miner vincente le aveva. Una transazione in conflitto con una della catena nuova viene scartata per sempre: è esattamente ciò che spera chi tenta una doppia spesa.
La latenza è la causa principale dei blocchi stale accidentali, ed è per questo che i miner investono nei sistemi di propagazione veloce dei blocchi. La nostra lezione sulle reti peer-to-peer spiega come viaggiano i blocchi e perché una propagazione lenta rende più probabili i blocchi stale.
Quanto spesso e quanto in profondità: il registro di Bitcoin
Nessuno può vedere tutti i blocchi stale, perché un nodo viene a sapere solo dei blocchi concorrenti che lo raggiungono. Il miglior registro pubblico è il dataset bitcoin-data/stale-blocks su GitHub, alimentato dagli operatori di nodi che conservano i blocchi visti e scartati dai loro nodi. Letto il 7 novembre 2026, conteneva 4.194 voci. Contandole in base al timestamp nell’intestazione di ogni blocco si ottiene questo quadro.
| Anno | Blocchi stale registrati | Anno | Blocchi stale registrati |
|---|---|---|---|
| 2015 | 572 | 2021 | 83 |
| 2016 | 175 | 2022 | 28 |
| 2017 | 195 | 2023 | 70 |
| 2018 | 89 | 2024 | 49 |
| 2019 | 68 | 2025 | 93 |
| 2020 | 123 | 2026 (al 3 novembre) | 61 |
Due avvertenze. Il dataset sottostima, perché dipende da chi contribuisce e quando, quindi confrontare un anno con l’altro è al massimo approssimativo. Anthony Towns, sviluppatore di Bitcoin Core, ha notato nel thread BNOC che il suo nodo non aveva mai visto i blocchi in corsa di Foundry prima del reorg, e questo potrebbe voler dire che i blocchi stale da un solo blocco sono più frequenti di quanto indichi il registro. Bitcoin produce circa 52.500 blocchi all’anno, quindi le 93 voci del 2025 suggeriscono che circa un blocco su cinquecento finisca stale: è una stima ricavata da questo dataset, non un tasso misurato. L’ultima voce, all’altezza 974.400, è del 3 novembre 2026.
Quasi tutti sono reorg di un solo blocco. Due blocchi di profondità sono rari. Nel thread BNOC sull’episodio del marzo 2026, lo sviluppatore Anthony Towns ha elencato le precedenti catene stale a due blocchi presenti nel dataset: ottobre 2013, giugno 2015, novembre 2020 e maggio 2023. La sua stima approssimativa della frequenza era «every ~3 years or 150k blocks?», punto interrogativo compreso. Foundry quel pomeriggio ha poi estratto sette blocchi di fila. Quando un sito pubblico di monitoraggio dello stratum non ha mostrato lavoro di Foundry sui blocchi in corsa, chi aveva aperto il thread, b10c, ha avanzato l’ipotesi di una configurazione regionale, di un errore del monitoraggio o di selfish mining; il gestore del sito ha poi spiegato di non essere mai riuscito a raccogliere i template di Foundry. Il thread non ha stabilito nessuna causa.
I reorg più profondi su Bitcoin sono nati da bug, non da gare. Nell’agosto 2010 un errore di overflow dei valori permise al blocco 74.638 di creare circa 184 miliardi di bitcoin; un client corretto uscì nel giro di poche ore e la catena corretta superò quella viziata all’altezza 74.691, sostituendo circa 53 blocchi secondo il nostro calcolo sulle due altezze indicate dal wiki di Bitcoin (in inglese), il reorg più profondo della storia di Bitcoin (la storia completa è nella nostra guida per capire se una blockchain può essere hackerata). Nel marzo 2013 un blocco con più input di transazione di quanti il software più vecchio sapesse gestire fu accettato dai nodi con versione 0.8 e rifiutato da molti nodi 0.7, come spiega l’analisi di Gavin Andresen, il BIP 50. Due grandi pool, BTCGuild e Slush, tornarono alla 0.7 perché la maggior parte della potenza di calcolo sostenesse la catena vecchia. Il ramo 0.8, che Bitcoin Magazine riferì essere a un certo punto in vantaggio di 13 blocchi, fu abbandonato: la divisione durò 24 blocchi a partire dall’altezza 225.430, circa sei ore.
Perché la profondità rende un pagamento più sicuro ma mai certo
Ogni blocco in più moltiplica il lavoro che un ramo concorrente deve rifare. Per un attaccante con una minoranza della potenza di calcolo, la probabilità di recuperare si riduce molto in fretta con la profondità, ed è il ragionamento dietro la convenzione delle sei conferme; la nostra lezione sulla mempool e sulle commissioni di transazione ripercorre la tabella di probabilità del white paper. Quello che la profondità non può fare è trasformare la probabilità in certezza. Un attaccante con più della metà della potenza di calcolo può, in linea di principio, superare la catena onesta a qualsiasi profondità, finché paga energia e hardware.
Sulle catene proof of work più piccole, dove noleggiare abbastanza potenza costa meno, non è teoria. Ethereum Classic ha subito reorg profondi migliaia di blocchi nell’agosto 2020 e Bitcoin Gold è stata colpita nel 2018; quegli attacchi del 51% sono raccontati nella nostra guida agli hack delle blockchain linkata sopra. Un caso più recente riguarda Monero. Il 14 settembre 2025 il Monero Research Lab, un gruppo di ricerca non ufficiale, ha dato l’allarme per una riorganizzazione di 18 blocchi a partire dall’altezza 3.499.659, secondo The Block, che ha contato circa 117-118 transazioni rimaste sul ramo abbandonato per quasi 40 minuti. Le ricostruzioni della comunità indicavano il progetto di mining Qubic, il cui fondatore ha respinto alcune di quelle accuse; The Block ha scritto che la responsabilità non era stata accertata.
La lezione per chi riceve è che la profondità va commisurata al valore in gioco e al costo di attaccare proprio quella catena. Sei blocchi su Bitcoin, che ha la maggiore potenza di calcolo tra le reti proof of work, danno molta più sicurezza di sei blocchi su una catena piccola che condivide l’algoritmo di mining con una più grande.
Finalità di Ethereum: un voto garantito da un terzo di tutto lo stake
Slot, epoche e checkpoint
Il consenso proof of stake di Ethereum, chiamato Gasper, ha due parti. Una regola di scelta del ramo, LMD-GHOST, individua la testa della catena a ogni slot seguendo il ramo con i voti più recenti dei validatori. Un meccanismo di finalità, Casper FFG, lavora a un ritmo più lento. Le specifiche del consenso fissano lo slot a 12 secondi e l’epoca a 32 slot, quindi un’epoca dura 6,4 minuti.
Il primo blocco di ogni epoca è un checkpoint. Durante l’epoca ogni validatore attivo emette un’attestazione, che vota anche per una coppia di checkpoint: una sorgente e un obiettivo. Quando i validatori che detengono due terzi dell’ether in staking votano per lo stesso obiettivo, quel checkpoint è giustificato. Quando a un checkpoint giustificato segue un checkpoint giustificato nell’epoca successiva, il primo diventa finalizzato, insieme a tutti i blocchi che lo precedono.
Nel caso normale una transazione è quindi definitiva alla fine dell’epoca successiva a quella in cui è stata inclusa, per cui l’attesa dipende da dove è capitata all’interno dell’epoca. Il minimo sono due epoche, cioè almeno 12,8 minuti; in pratica sono circa 15 minuti, la cifra che indica ethereum.org, e la documentazione di Circle prevede da 15 a 19 minuti. Una lettura in diretta della beacon chain alle 09:53 UTC del 7 novembre 2026 ha mostrato il consueto schema: testa nell’epoca 487.555, ultima epoca giustificata 487.554, ultima epoca finalizzata 487.553.
Le applicazioni vedono queste fasi attraverso i tag di blocco dell’interfaccia JSON-RPC di Ethereum. La specifica execution-apis dice che il blocco latest «may be re-orged out of the canonical chain even under healthy/normal conditions», cioè può essere espulso dalla catena canonica anche in condizioni normali. Il blocco safe è al riparo dai reorg sotto una maggioranza onesta e alcune ipotesi sui tempi della rete. Il blocco finalized è il più recente che «cannot be re-orged outside of manual intervention driven by community coordination», cioè non può essere riorganizzato senza un intervento manuale deciso con un coordinamento della comunità. Un wallet che mostra la spunta verde dopo un blocco ti sta mostrando «latest», il più debole dei tre.
Quanto costerebbe annullare un blocco finalizzato
Due checkpoint in conflitto non possono essere entrambi finalizzati a meno che almeno un terzo dello stake non abbia firmato voti contraddittori. Quei voti sono una prova: chiunque può presentarli e il protocollo applica lo slashing ai validatori coinvolti, bruciando parte del deposito e costringendoli a uscire. Il progetto di Ethereum ammette che un attaccante abbastanza grande potrebbe comunque finalizzare una storia in conflitto, ma garantisce che perderebbe almeno un terzo di tutto l’ether in staking. La nostra voce di glossario sul proof of stake spiega in generale il modello di deposito e penalità.
La formula della execution-apis citata sopra, «manual intervention driven by community coordination», è la nota onesta a piè di pagina. Se una supermaggioranza finalizzasse mai una catena sbagliata, la via d’uscita sarebbe una decisione sociale degli operatori dei nodi di rifiutarla, non una regola automatica. Su mainnet Ethereum non è mai successo.
Quando si muove la testa: il reorg di sette blocchi del maggio 2022
Sono i blocchi vecchi a essere protetti dalla finalità; la testa della catena può ancora muoversi. Il 25 maggio 2022, tra le 08:55 e le 08:57 UTC, la beacon chain ha riorganizzato sette blocchi, dagli slot 3.887.075 a 3.887.081. Era prima del Merge, quindi la beacon chain non trasportava ancora transazioni degli utenti. Nella sua analisi dell’episodio, il ricercatore della Ethereum Foundation Barnabé Monnot lo ha ricondotto a un blocco in ritardo e a un’introduzione parziale di una modifica della scelta del ramo chiamata proposer boost: alcuni client la applicavano e altri no, così per qualche slot non erano d’accordo su quale fosse la testa. La finalità non ha subito ritardi.
Quando la finalità si ferma: maggio 2023 e l’inactivity leak
Il guasto opposto è avvenuto due volte nel maggio 2023. I blocchi continuavano ad arrivare, ma la catena non riusciva a finalizzare. Secondo il postmortem del client Prysm e un’analisi di Thomas Thiery su ethresear.ch, alcuni client di consenso, tra cui Prysm e Teku, gestivano male le attestazioni valide che puntavano a vecchi checkpoint: ciascuna li costringeva a ricostruire uno stato passato, e quando ne arrivavano in gran numero i nodi Prysm esaurivano le risorse. Lighthouse scartava quelle attestazioni e andava avanti.
L’11 maggio, da circa le 20:07 UTC, la finalità si è fermata per circa quattro epoche, più o meno 25 minuti, con la partecipazione scesa a circa il 40% e circa 47 blocchi mancati. Il 12 maggio, dalle 17:20 UTC, si è fermata per circa nove epoche, poco più di un’ora. La partecipazione è scesa al 30,7%, che il postmortem di Prysm ha definito la più bassa di qualsiasi epoca della mainnet, e sono stati mancati circa 149 blocchi. In entrambi i casi la catena si è ripresa senza intervento manuale e Prysm v4.0.4 ha portato le correzioni. Il postmortem afferma che le transazioni degli utenti finali sono state toccate in misura minima: i blocchi continuavano ad arrivare, e a restare in attesa sono stati i servizi che aspettano i blocchi finalizzati.
Il secondo episodio ha fatto scattare l’inactivity leak. Quando la catena resta per più di quattro epoche senza finalità, il protocollo comincia a erodere i saldi dei validatori che non votano, tanto più in fretta quanto più dura l’interruzione. L’obiettivo è ridurre la quota offline finché i validatori ancora online tornano a detenere due terzi dello stake rimanente, così che la finalità possa riprendere anche se un terzo della rete fosse sparito per sempre. Secondo la stima del postmortem, i validatori hanno pagato circa 28 ETH di penalità e rinunciato ad almeno 55 ETH di ricavi potenziali.
Un campanello d’allarme è suonato poche ore dopo l’aggiornamento Fusaka, attivato a tarda sera del 3 dicembre 2025. Da circa le 02:45 UTC del 4 dicembre, quasi tutti i nodi Prysm hanno esaurito le risorse mentre verificavano certe attestazioni, riporta la stessa pagina di postmortem. Nelle 42 epoche che conta come colpite, 248 slot su 1.344 sono rimasti senza blocco, la partecipazione è scesa fino al 75% e i validatori hanno mancato circa 382 ETH di ricompense di attestazione; l’incidente è stato considerato mitigato alle 07:12 UTC. Il team di Prysm attribuisce il danno contenuto alla diversità dei client e spiega che cosa era in gioco: un client con più di un terzo della rete «would have caused a temporary loss in finality», mentre uno con più di due terzi «could finalize an invalid chain».
Lo stesso documento aggiunge un avvertimento. Citando dati di Miga Labs del 12 dicembre 2025, afferma che Lighthouse potrebbe far girare più del 56% della rete, soglia che definisce pericolosamente vicina al livello a cui il bug di un solo client potrebbe finalizzare una catena non valida.
Finalità più rapida: per ora è ricerca
Quindici minuti sono tanti per un pagamento, e i ricercatori di Ethereum lavorano da anni alla single-slot finality, che finalizzerebbe ogni blocco entro il proprio slot. Al 7 novembre 2026 ethereum.org dice ancora che la single-slot finality è in fase di ricerca e non è attesa per diversi anni. Sono stati proposti anche progetti che finalizzano in pochi slot, come il protocollo di finalità a 3 slot pubblicato da D’Amato, Saltini, Tran e Zanolini nel novembre 2024. Nulla di tutto questo è in programma: il prossimo aggiornamento previsto, Glamsterdam, il 7 novembre 2026 non aveva ancora un’epoca di attivazione su mainnet nella specifica del consenso.
Finalità deterministica: le catene che si fermano invece di biforcarsi
CometBFT e le catene Cosmos
La maggior parte delle catene Cosmos usa CometBFT, il motore già noto come Tendermint. I validatori attraversano turni di proposta e voto per ogni altezza, e un blocco viene confermato solo quando più di due terzi del potere di voto lo hanno firmato. La documentazione di CometBFT promette che, con meno di un terzo di validatori difettosi, «validators will never commit conflicting blocks at the same height», cioè i validatori non confermeranno mai blocchi in conflitto alla stessa altezza. Non c’è nessun reorg da aspettare: un blocco confermato è definitivo in un blocco, di solito pochi secondi.
Il prezzo è la liveness. I validatori avanzano solo dopo aver sentito più di due terzi dell’insieme, quindi se più di un terzo è offline o isolato da un guasto di rete, non viene prodotto alcun blocco. La catena si ferma finché non tornano abbastanza validatori. Per un exchange o un bridge è il guasto più amichevole: una catena ferma fa perdere tempo, una catena che si biforca può far perdere denaro.
Solana: da 32 slot ad Alpenglow
Solana espone la finalità come tre livelli di commitment che wallet e applicazioni chiedono al proprio nodo. Con il consenso Tower BFT, in uso fino a ottobre 2026, la documentazione di Anza li definisce così: processed significa che un nodo ha ricevuto il blocco sul fork di maggioranza; confirmed significa che il 66% o più dello stake ha votato per esso; finalized significa che sopra sono stati costruiti almeno 31 blocchi confermati. Con lo slot nominale di 400 millisecondi, quei 32 blocchi fanno circa 12,8 secondi.
Il 21 ottobre 2026 alle 13:36 UTC, allo slot 459.648.000, il primo slot dell’epoca 1064, la mainnet di Solana ha attivato il feature gate di Alpenglow, come mostra l’account della funzionalità sulla catena. Anza chiama Votor la parte di Alpenglow dedicata a voto e finalità; una parte separata, Rotor, cambia il modo in cui i blocchi si diffondono nella rete. Con le nuove regole la stessa documentazione unifica confirmed e finalized: entrambi richiedono il 60% dello stake in voto per finalizzare, oppure l’80% in voto per notarizzare un blocco, ed entrambi significano che la transazione non può più essere annullata. Nel suo annuncio del maggio 2025, Anza ha scritto di aspettarsi che Alpenglow «can achieve actual finality in about 150 ms (median)», a volte fino a 100 ms. Quei numeri vanno letti come l’obiettivo degli sviluppatori, scritto più di un anno prima dell’attivazione, non come un risultato misurato sulla mainnet.
Lo stesso annuncio dice che Votor finalizza in un solo turno di voto quando partecipa l’80% dello stake, e in due turni quando risponde solo il 60%.
Polygon PoS: da un reorg di 157 blocchi alle milestone
Polygon PoS mostra perché una catena veloce senza finalità forte renda nervosi i bridge. Il 22 febbraio 2023, al blocco 39.599.624, la catena ha riorganizzato 157 blocchi, circa cinque minuti di storia. Un post sul forum di Polygon ha collegato il lungo reorg a un’interruzione parziale della rete. Per chi aveva accreditato depositi dopo poche decine di blocchi, cinque minuti di storia annullata erano un’esposizione reale.
Polygon ha poi aggiunto le milestone: i validatori votano sui blocchi recenti e, quando due terzi del potere di voto concordano, la documentazione di Polygon dice che ogni transazione fino a quella milestone è definitiva, anche prima che il checkpoint periodico venga scritto su Ethereum. Anche le milestone possono guastarsi. Nel settembre 2025 sono rimaste indietro di 10-15 minuti per un bug dei nodi e la rete ha rilasciato un hard fork d’emergenza il 10 settembre alle 15:00 UTC, secondo The Block; non è stato segnalato alcun reorg, solo una finalità più lenta.
Layer 2: tre modi di essere «confermato»
I rollup aggiungono una loro scala sopra quella di Ethereum. Se la differenza tra una catena di base e un rollup è nuova per te, il nostro confronto tra layer 1 e layer 2 la spiega. Qui conta che cosa significhi «confermato» a ogni gradino.
La documentazione di OP Stack descrive tre stadi per catene come OP Mainnet e Base. Una transazione è unsafe dopo circa due secondi, quando il sequencer l’ha messa in un blocco non ancora pubblicato su Ethereum. Diventa safe nel giro di pochi minuti, quando i suoi dati stanno in un blocco di Ethereum. È finalized dopo circa 15-30 minuti, quando Ethereum ha finalizzato quel blocco. La documentazione di Arbitrum descrive il feed del sequencer allo stesso modo: «a sub-second provisional confirmation that depends on the Sequencer behaving honestly», cioè una conferma provvisoria sotto il secondo che dipende dall’onestà del sequencer, seguita dalla finalità definitiva quando il batch è finale su Ethereum.
Un errore comune è confondere la finalità con la finestra di contestazione. Sui rollup optimistic i prelievi verso Ethereum tramite il bridge ufficiale attendono circa una settimana, perché le frodi possano essere contestate; la documentazione di OP Stack indica un minimo di sette giorni per il suo Standard Bridge. Quel ritardo vale per il prelievo, non per la transazione in sé: la documentazione di OP Stack dice che il periodo di contestazione «does not impact transaction finality on the OP Stack chain». Un trasferimento su un rollup è definitivo non appena è finalizzato il blocco Ethereum che ne contiene i dati.
Quante conferme servono: cosa aspettano exchange, bridge e commercianti
Ogni servizio che accetta crypto sceglie un gradino della scala e accetta il rischio che sta sotto. La tabella riassume da dove viene la finalità di ciascuna catena, al 7 novembre 2026.
| Catena | Tipo di finalità | Cosa rende definitivo un blocco | Tempo tipico |
|---|---|---|---|
| Bitcoin | probabilistica | più lavoro accumulato sopra; mai assoluta | circa 10 minuti per blocco; la profondità la sceglie chi riceve |
| Ethereum | economica (Gasper) | checkpoint finalizzato da due terzi dell’ether in staking | almeno 12,8 minuti, circa 15 in pratica |
| Solana (Alpenglow Votor, dal 21 ottobre 2026) | voto deterministico | 60% dello stake vota per finalizzare o 80% vota per notarizzare | circa 150 ms di mediana, obiettivo di Anza; non una misura su mainnet |
| Catene Cosmos (CometBFT) | deterministica (BFT) | più di due terzi del potere di voto firma il blocco | un blocco, pochi secondi; si ferma se più di un terzo è offline |
| Polygon PoS | milestone più checkpoint su Ethereum | due terzi del potere di voto su una milestone | Circle attende 2-3 blocchi, circa 8 secondi |
| OP Mainnet, Base, Arbitrum One | ereditata da Ethereum | Ethereum finalizza il blocco che contiene i dati del rollup | soft in circa 2 secondi o meno; definitiva in circa 15-30 minuti |
Exchange: una profondità per ogni asset
Gli exchange centralizzati pubblicano quante conferme attendono prima di accreditare un deposito, e il numero varia per asset e nel tempo. La pagina di supporto di Kraken sui tempi di deposito, letta il 7 novembre 2026, porta Bitcoin come esempio: i depositi vengono accreditati dopo tre conferme, che secondo l’exchange richiedono circa 45 minuti. L’exchange si assume il rischio di un reorg più profondo: se il deposito sparisce dopo che hai venduto le monete, a rimetterci è l’exchange. Controlla sempre la pagina dei depositi dell’exchange per l’asset e la rete che usi, invece di fidarti di una cifra letta su un forum; la nostra guida a come funzionano gli exchange centralizzati spiega il flusso dei depositi.
Bridge: pagare prima che la catena di origine sia definitiva
I bridge portano il rischio di reorg più alto, perché rilasciano fondi su una catena a fronte di un evento su un’altra. Se la catena di origine si riorganizza dopo che quella di destinazione ha pagato, il bridge ha dato denaro per un deposito che non esiste più. La documentazione del Cross-Chain Transfer Protocol di Circle, letta il 7 novembre 2026, mostra il compromesso tra le sue due modalità.
| Catena di origine | Fast Transfer | Standard Transfer (finalità definitiva) |
|---|---|---|
| Ethereum | 2 blocchi, circa 20 secondi | circa 65 blocchi, circa 15-19 minuti |
| Arbitrum, Base, OP Mainnet | 1 blocco, circa 8 secondi | circa 65 blocchi di Ethereum, circa 15-19 minuti |
| Solana | 2-3 blocchi, circa 0,4-0,6 secondi | 32 blocchi, circa 17 secondi |
| Polygon PoS | non offerto | 2-3 blocchi, circa 8 secondi |
| Avalanche | non offerto | 1 blocco, circa 8 secondi |
Un trasferimento veloce paga prima che la catena di origine sia definitiva, quindi chi lo offre si assume il rischio di una riorganizzazione e di solito lo fa pagare. Dove non esiste una modalità veloce, la spiegazione di Circle è che l’attesa standard su quelle catene è già breve. La riga di Solana riporta ancora 32 blocchi, la regola di Tower BFT, due settimane dopo l’avvio di Alpenglow: i servizi non aggiornano tutti le loro attese il giorno in cui una catena cambia consenso. La nostra guida a bridge e intent cross-chain approfondisce i modelli e i loro rischi.
Commercianti e privati: l’attesa va commisurata all’importo
Per un caffè pagato in bitcoin, un pagamento non confermato o con una sola conferma è un rischio piccolo. Per un’auto, no. Gli attacchi race, Finney e di reorg descritti nella nostra lezione sulla doppia spesa sfruttano tutti chi considera definitivo un blocco superficiale. Dalle sezioni precedenti discendono alcune regole pratiche: su Bitcoin, aspetta più blocchi al crescere dell’importo; su Ethereum e sui rollup, considera «finalized» la soglia per le somme grandi e «latest» un dato provvisorio; sulle catene BFT un blocco confermato è definitivo, ma verifica che la catena stia producendo blocchi. Soprattutto, scopri quale livello ti sta mostrando davvero il tuo wallet o il tuo servizio.
La finalità giuridica non è la finalità on chain
Banche e infrastrutture di mercato usano la stessa parola con un significato giuridico. Nell’Unione europea la direttiva 98/26/CE sulla definitività del regolamento rende gli ordini di trasferimento immessi in un sistema designato di pagamento o di regolamento titoli giuridicamente vincolanti anche nei confronti dei terzi, pure se un partecipante diventa insolvente. Il Regno Unito ha un proprio equivalente, i Financial Markets and Insolvency (Settlement Finality) Regulations 1999. Quella finalità è una regola che un giudice fa rispettare.
La direttiva è stata scritta per sistemi designati gestiti da operatori identificabili, e su una catena pubblica nulla è definitivo per legge. La finalità di Bitcoin è una probabilità, quella di Ethereum una penalità, quella di una catena BFT una regola di voto. Il rapporto BIS citato prima trae la conseguenza pratica per il proof of work: «the more times the transaction is confirmed in the ledger, the less likely it will be revoked», cioè più volte la transazione è confermata nel registro, meno probabile è che venga revocata. Ogni modello ha avuto il suo giorno storto: Bitcoin un reorg di 53 blocchi nel 2010, Ethereum un’ora senza finalità nel 2023, Polygon, prima delle milestone, un reorg di 157 blocchi lo stesso anno.
La tabella qui sotto raccoglie gli incidenti datati trattati in questa lezione.
| Data (UTC) | Catena | Evento | Profondità o durata |
|---|---|---|---|
| 15-16 agosto 2010 | Bitcoin | bug di overflow dei valori, blocco 74.638 | circa 53 blocchi |
| 11-12 marzo 2013 | Bitcoin | divisione di database 0.7 / 0.8, dal blocco 225.430 | 24 blocchi, circa 6 ore |
| 25 maggio 2022 | Beacon chain di Ethereum (prima del Merge) | introduzione parziale del proposer boost | 7 blocchi; finalità non ritardata |
| 22 febbraio 2023 | Polygon PoS | reorg al blocco 39.599.624 dopo un’interruzione parziale | 157 blocchi, circa 5 minuti |
| 8 maggio 2023 | Bitcoin | catena stale di due blocchi | 2 blocchi |
| 11 maggio 2023 | Ethereum | perdita di finalità, bug di Prysm | circa 4 epoche, circa 25 minuti |
| 12 maggio 2023 | Ethereum | perdita di finalità, partecipazione al 30,7% | circa 9 epoche, poco più di un’ora |
| 10 settembre 2025 | Polygon PoS | milestone in ritardo, hard fork d’emergenza | finalità ritardata di 10-15 minuti, nessun reorg |
| 14 settembre 2025 | Monero | catena alternativa dal blocco 3.499.659, origine non accertata | 18 blocchi |
| 4 dicembre 2025 | Ethereum | bug di Prysm dopo Fusaka, partecipazione fino al 75% | 42 epoche degradate, 248 slot senza blocco |
| 23 marzo 2026 | Bitcoin | ramo di Foundry sostituisce i blocchi di AntPool e ViaBTC | 2 blocchi, pochi minuti |
La prossima lezione di questo percorso guarda ai fork: i cambi di regole pianificati, soft e hard, che dividono una catena di proposito, e il vocabolario stale contro orfano che questa lezione ha preso in prestito. Prima, il controllo più rapido che puoi fare è aprire il tuo wallet o il tuo exchange e scoprire se ti sta mostrando latest, safe o finalized.
