---
title: "Attacchi a lungo raggio nelle PoS: chiavi storiche, rischio di bootstrap e checkpoint"
description: "Un attacco a lungo raggio in una PoS presenta una storia alternativa firmata con l'autorità storica dei validatori. Scopri quali nodi sono esposti, cosa deve riprodurre l'attaccante e come i checkpoint di soggettività debole e le regole di sincronizzazione specifiche del protocollo limitano il rischio."
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.
# Attacchi a lungo raggio nelle PoS: chiavi storiche, rischio di bootstrap e checkpoint
> Analisi educativa sulla sicurezza dei protocolli. La resistenza agli attacchi a lungo raggio dipende dal protocollo e dalla versione; ottieni i dati di bootstrap da fonti autenticate e verificate in modo indipendente prima di affidarti a un nodo appena sincronizzato o rimasto offline a lungo.
## Risposta diretta
Un attacco a lungo raggio contro un sistema proof of stake tenta di rendere credibile una storia in conflitto usando un'autorità di validazione che era valida molto tempo prima. Una forma comune, spesso detta corruzione posteriore, acquisisce o compromette le chiavi dei validatori dopo la loro uscita, quando la garanzia non è più soggetta a slashing. Poiché produrre vecchie firme non richiede di ripetere il consumo energetico della proof of work, l'avversario può costruire un fork internamente coerente a basso costo rispetto al costo storico della catena onesta.
Il bersaglio è di solito un nodo privo di una vista recente autenticata: un nodo avviato per la prima volta, ripristinato da un vecchio backup oppure rimasto offline oltre l'orizzonte di sincronizzazione sicura del protocollo. Un nodo che osserva continuamente la rete conosce già un antenato finalizzato o altrimenti protetto e dovrebbe respingere un fork in conflitto. Un attacco eclipse o una fonte dati compromessa può quindi amplificare l'attacco nascondendo la vista onesta al nodo in sincronizzazione.
Le chiavi storiche da sole non sono uno strumento universale di falsificazione. La storia alternativa deve rispettare domini di firma, transizioni di stato, evoluzione dell'insieme dei validatori, regole temporali, prove di finalità o selezione della catena e ogni vincolo su evoluzione delle chiavi o checkpoint del protocollo bersaglio. Alcuni protocolli PoS richiedono un checkpoint recente di soggettività debole; altri definiscono un bootstrap orientato alla genesi o diverse ipotesi di fiducia e disponibilità. Occorre analizzare la specifica catena, rete, versione del fork, client e modalità di sincronizzazione, senza trattare “PoS” come un unico meccanismo.
Un checkpoint non è soltanto un numero di blocco comodo. Lega una rete e uno stato di consenso specifici a una radice o un hash presso un'epoca, uno slot o un'altezza. Una volta autenticato, limita le storie che il nodo prenderà in considerazione. La catena rimanente può quindi essere verificata secondo le regole del protocollo a partire da quell'ancora. Questa è la soggettività debole: input esterno limitato al bootstrap, seguito da validazione oggettiva entro il periodo assunto, non fiducia permanente nell'ultima testa annunciata da un peer.
## Percorso di attacco e verifica
1. **Scegliere un vecchio punto di fork.** L'avversario individua uno stato storico la cui autorità di validazione è poi cambiata o che un nuovo nodo fatica ad autenticare autonomamente.
2. **Ottenere sufficiente potere storico di firma.** Le chiavi possono essere comprate, rubate, conservate, recuperate da backup o esposte da sistemi di firma compromessi dopo l'uscita dei validatori. Peso e tipi di messaggio richiesti dipendono dal protocollo; una singola vecchia chiave di proponente non basta automaticamente.
3. **Costruire un'alternativa valida per il protocollo.** L'avversario produce blocchi, voti, certificati e variazioni dell'insieme dei validatori che superano i controlli storici del client della vittima. Una transizione di stato non valida, un dominio errato, tempi impossibili o una prova mancante possono ancora invalidare il fork.
4. **Estendere e presentare il fork.** La produzione economica di firme può consentire una lunga storia, ma il numero grezzo di blocchi non è decisivo. Il ramo deve vincere o aggirare l'esatta procedura di selezione usata dalla modalità di sincronizzazione.
5. **Controllare la vista di bootstrap.** La vittima viene isolata da un checkpoint recente autenticato o dalle prove di peer onesti e vede la storia alternativa come unico candidato o candidato preferito.
6. **Indurre affidamento a valle.** Se il nodo accetta lo stato errato, RPC, wallet, indicizzatore, monitor del bridge o applicazione possono riportare saldi, eventi e membri dei validatori validi sul fork dell'attaccante, anche se la rete attiva segue un'altra catena.
Il difensore deve ripercorrere il percorso al contrario: autenticare un'ancora, confermarne l'identità di catena e rete, verificare che il candidato ne discenda, eseguire tutti i controlli di consenso e transizione di stato e confrontare lo stato finalizzato o selezionato su infrastrutture indipendenti. Un download riuscito non prova che la storia selezionata sia canonica.
## Esempio pratico
Supponiamo che l'insieme di validatori `V_old` controllasse una catena PoS ipotetica all'epoca `120,000`. Anni dopo, oltre `2/3` di quel peso storico è uscito e non è più esposto a sanzioni del protocollo. Un avversario ottiene quelle vecchie chiavi e avvia una storia in conflitto subito dopo il checkpoint `C_old`.
Sul ramo fabbricato, l'avversario firma i voti richiesti dal protocollo ipotetico, modifica in seguito i validatori e prosegue fino all'epoca `420,000`. Anche la rete onesta ha raggiunto l'epoca `420,000`, quindi epoche uguali o un file più lungo non indicano a un nodo in bootstrap quale ramo sia socialmente e operativamente canonico. L'ammissibilità del ramo fabbricato dipende da tutte le regole storiche del protocollo.
Il nodo `N_live` ha osservato il checkpoint finalizzato autentico `C_recent` all'epoca `419,936`. Poiché il fork di attacco non discende da `C_recent`, `N_live` lo respinge. Il nodo `N_new`, invece, parte dalla genesi, si connette soltanto a peer avversari e non dispone di un'ancora recente autenticata. Se protocollo e modalità di sincronizzazione non distinguono le storie usando solo le prove interne, potrebbe accettare il ramo di attacco.
Fornire a `N_new` la coppia autenticata `C_recent = (root, 419,936)` cambia la soglia decisionale. Il client deve esigere che il percorso di sincronizzazione contenga esattamente quel checkpoint e fallire in modo chiuso se non può farlo. Le epoche e la soglia `2/3` dell'esempio illustrano un progetto basato sulla finalità; non sono parametri PoS universali né impostazioni attuali di una rete specifica.
## Controlli e checklist di revisione
### Progettazione del protocollo
- Documenta l'esatto modello di sicurezza a lungo raggio: corruzione posteriore, ricambio dei validatori, compromissione adattiva delle chiavi, isolamento della rete e disponibilità dei dati.
- Definisci quali stati finalizzati non possono mai essere annullati e come la fork choice gestisce un conflitto con un'ancora considerata affidabile localmente.
- Limita uscite, prelievi e ricambio dei validatori affinché le ipotesi di sicurezza restino significative mentre le firme in conflitto sono ancora rilevabili e sanzionabili.
- Specifica il periodo di soggettività debole o un'ipotesi alternativa di sincronizzazione sicura come derivazione dello stato corrente e delle costanti del protocollo, non come valore di calendario eterno.
- Valuta firme a evoluzione di chiave o forward-secure se supportate dal progetto; eliminare normalmente le chiavi è buona igiene, ma non una difesa completa del consenso.
- Verifica separatamente prima sincronizzazione, sincronizzazione da checkpoint, ripristino di snapshot e recupero dopo un lungo periodo offline. Una fork choice sicura durante l'operatività non rende automaticamente sicuro il bootstrap.
### Bootstrap e operatività del nodo
- Registra prima della sincronizzazione radice del checkpoint o hash del blocco, epoca o altezza, ID della catena, rete, versione del fork, ora di acquisizione e fornitore.
- Ottieni le ancore tramite canali autenticati e confronta fonti davvero indipendenti. Più siti basati sullo stesso nodo o operatore non sono indipendenti.
- Respingi checkpoint obsoleti, malformati, della rete errata o in conflitto. Non ripiegare silenziosamente su una sincronizzazione senza ancora dopo un errore di validazione.
- Esigi che la catena sincronizzata contenga l'ancora esatta e verifica tutti i discendenti con i client di consenso ed esecuzione previsti.
- Diversifica peer, client, operatori e RPC; monitora condizioni di eclipse, divergenze delle radici finalizzate, rollback insoliti e prolungata assenza di finalità.
- Ricontrolla l'ancora dopo il ripristino di un vecchio database o backup e aggiornala entro il periodo sicuro documentato dal protocollo.
### Affidamento delle applicazioni
- Non sbloccare depositi, messaggi bridge o operazioni irreversibili solo perché un RPC appena sincronizzato segnala il successo.
- Concilia identità della catena, checkpoint finalizzato e ascendenza degli eventi tra nodi indipendenti prima di azioni ad alto impatto.
- Separa la storia del consenso dalla verità applicativa: una catena canonica non prova correttezza dell'oracolo, sicurezza del contratto, disponibilità dei dati esterni o solvibilità del custode.
- Prepara una politica di arresto per checkpoint finalizzati o ancore affidabili in conflitto. La condizione può indicare fallimento del consenso, dati di bootstrap corrotti o rete errata e non va risolta automaticamente scegliendo il ramo più lungo.
## Errori comuni
- **Ogni catena PoS è vulnerabile allo stesso modo.** La resistenza dipende da evoluzione dei validatori, firme, finalità, fork choice, checkpoint e ipotesi di sincronizzazione del protocollo.
- **Le vecchie chiavi possono riscrivere qualsiasi transazione senza vincoli.** L'attaccante deve comunque produrre una storia accettata da tutte le regole di validazione della vittima; l'autorità storica serve solo in alcuni attacchi e può non bastare.
- **La catena con più blocchi, epoche o firme è autentica.** La selezione usa validità, peso, certificati e ancore specifici del protocollo, non un confronto universale della lunghezza.
- **La finalità da sola permette a un nodo partito dalla genesi di riconoscere la catena sociale.** Due storie finalizzate e internamente valide possono essere ambigue senza una vista recente autenticata; la finalità protegge il nodo che conosce già il checkpoint pertinente.
- **Lo slashing scoraggia sempre l'attacco.** I validatori che hanno ritirato tutto possono non avere garanzie da sanzionare, e le prove devono essere attribuibili ed elaborate mentre le sanzioni sono ancora applicabili.
- **Un checkpoint significa fidarsi per sempre di un'azienda.** La fiducia può limitarsi a una specifica ancora recente ed essere ridotta con distribuzione autenticata, verifiche indipendenti e successiva verifica locale.
- **Eliminare le chiavi ritirate risolve il problema del protocollo.** La cancellazione sicura riduce il rischio, ma regole robuste di consenso e bootstrap devono tollerare la disponibilità di alcune chiavi storiche.
## Argomenti correlati
- [Finalità](/it/crypto/finality/)
- [Regole di fork choice](/it/crypto/fork-choice-rule/)
- [Proof of stake](/it/crypto/proof-of-stake/)
- [Code di uscita e prelievo dei validatori](/it/crypto/validator-exit-withdrawal-queue/)
- [Soggettività debole](/it/crypto/weak-subjectivity/)
## Fonti
- [Soggettività debole in Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consultato: 2026-08-21)
- [Specifiche di consenso di Ethereum: guida alla soggettività debole](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/weak-subjectivity.md) - Ethereum Foundation (consultato: 2026-08-21)
- [Attacchi e difese nella proof of stake di Ethereum](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consultato: 2026-08-21)
- [Casper, il dispositivo amichevole di finalità](https://arxiv.org/abs/1710.09437) - arXiv (consultato: 2026-08-21)
- [Ouroboros Genesis: blockchain proof of stake componibili con disponibilità dinamica](https://eprint.iacr.org/2018/378) - IACR Cryptology ePrint Archive (consultato: 2026-08-21)
- [Progetto di Ouroboros Genesis](https://ouroboros-consensus.cardano.intersectmbo.org/docs/references/miscellaneous/genesis_design/) - Intersect (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/long-range-attack/index.mdx