--- title: "Attacco del 51%" description: "Un attacco del 51% si verifica quando una parte controlla una potenza di consenso sufficiente a superare in modo affidabile la rete onesta e a riorganizzare la storia recente della blockchain." 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. # Attacco del 51% > Solo a scopo educativo; non costituisce consulenza d'investimento. Gli investimenti possono comportare perdite. ## Risposta diretta Un attacco del 51% si verifica quando una parte controlla una potenza di consenso sufficiente a superare in modo affidabile la rete onesta e a riorganizzare la storia recente della blockchain. In una blockchain proof-of-work (PoW), il termine indica in genere il controllo della maggioranza dell'hash rate attivo. L'attaccante può costruire un ramo concorrente con più proof of work cumulativa rispetto al ramo onesto e indurre i nodi ad adottarlo. “51%” è un'abbreviazione per indicare un vantaggio sostenuto, non un interruttore universale: un attaccante con un hash rate inferiore può talvolta riorganizzare per caso un blocco poco profondo, mentre una potenza di maggioranza temporanea non garantisce un attacco redditizio. L'etichetta non deve essere trasferita meccanicamente al proof-of-stake (PoS). Le soglie di voto, la scelta del fork, la finalità, le penalità per inattività e lo slashing sono specifici del protocollo. Per esempio, Ethereum documenta conseguenze diverse a circa il 33%, 34%, 51% e 66% dello stake. La domanda pertinente è sempre quale regola di consenso e quale obiettivo dell'attacco si stiano considerando. ## Come funziona I nodi PoW accettano solo blocchi validi e seguono il ramo valido con la maggiore proof of work cumulativa. Un attaccante di maggioranza non può rendere valida una firma non valida né creare monete al di fuori delle regole del protocollo. Può tuttavia minare in privato un ramo valido in conflitto e rivelarlo dopo che ha superato il ramo pubblico. Una tipica sequenza di doppia spesa è la seguente: 1. L'attaccante paga un commerciante o un exchange sulla blockchain pubblica mentre mina in privato un ramo che spende le stesse monete altrove. 2. Il destinatario attende le conferme e poi consegna i beni o autorizza un prelievo. 3. Se il ramo privato accumula più proof of work, l'attaccante lo pubblica. I nodi si riorganizzano su quel ramo e il pagamento originale scompare dalla storia accettata. Ogni conferma aggiuntiva aumenta il vantaggio del ramo onesto. Quando l'attaccante ha un hash rate inferiore a quello della rete onesta, la probabilità di recuperare diminuisce con l'aumentare di tale vantaggio; con una maggioranza sostenuta, nel tempo l'attaccante può superare in modo affidabile il ramo onesto. Le conferme riducono il rischio, ma non creano una finalità assoluta. Lo stesso controllo può essere usato per censurare o ritardare determinate transazioni, riordinare transazioni recenti e compromettere le conferme. Non consente di rubare monete protette dalla chiave privata di qualcun altro, spendere monete che non appartengono all'attaccante o costringere i full node ad accettare blocchi che violano le regole del consenso. ## Esempio Supponiamo che una piccola rete PoW illustrativa abbia 1 TH/s di hash rate onesto. Un attaccante può noleggiare 1.2 TH/s per $20,000 l'ora, ottenendo circa il 54.5% dei 2.2 TH/s complessivi finché il noleggio è attivo. L'attaccante deposita token del valore di $200,000 presso un exchange e contemporaneamente mina un ramo privato contenente una spesa in conflitto. Se l'exchange accredita il deposito dopo 10 blocchi, ossia circa 20 minuti su questa ipotetica blockchain, l'attaccante può prelevare un altro asset prima di pubblicare il ramo privato. Un noleggio di due ore costa $40,000, ma questa cifra non è il profitto dell'attaccante. Commissioni di negoziazione, slippage, mancata esecuzione, blocchi dei prelievi, rilevamento e un calo del prezzo dell'asset attaccato possono rendere il tentativo non redditizio. Se l'exchange aumenta il requisito a 200 blocchi, l'attaccante deve mantenere il ramo concorrente molto più a lungo. Con l'intervallo ipotizzato di due minuti per blocco, si tratta di circa 6 ore e 40 minuti di conferme. L'attacco diventa più costoso e più facile da rilevare, mentre anche i clienti legittimi devono attendere più a lungo. Una politica di conferma bilancia quindi la velocità di regolamento con il rischio di riorganizzazione. ## Rischi e misure di controllo Gli obiettivi più esposti sono i pagamenti recenti e di valore elevato che possono essere convertiti o prelevati prima che un operatore reagisca. Riscrivere la storia a partire da migliaia di blocchi prima richiederebbe di ricostruire tutta la proof of work successiva e superare la blockchain attiva; per questo gli attacchi pratici si concentrano di solito su una finestra breve e di grande valore. La sicurezza economica dipende da fattori ulteriori rispetto alla capitalizzazione di mercato di un token. Tra i fattori rilevanti vi sono l'hash rate noleggiabile, la disponibilità di hardware specializzato, i costi dell'elettricità e del coordinamento, la concentrazione dei mining pool, le ricompense dei blocchi, la liquidità del mercato e il valore che un destinatario rende disponibile dopo la conferma. La concentrazione dei pool è un segnale d'allarme, ma gli operatori dei pool non possiedono necessariamente le apparecchiature dei miner, che possono reindirizzare il proprio hash rate. I destinatari e gli operatori dell'infrastruttura possono ridurre l'esposizione: - stabilendo requisiti di conferma in base al valore della transazione e alle condizioni attuali della rete; - monitorando i rami concorrenti, le variazioni insolite dell'hash rate e le riorganizzazioni profonde; - sospendendo depositi o prelievi quando aumenta il rischio di riorganizzazione; e - limitando la quantità di valore irreversibile che può uscire durante una singola finestra di conferma. Queste misure riducono la perdita attesa; nessuna rende matematicamente irreversibile un regolamento PoW probabilistico. ## Idee sbagliate comuni ### Mito 1: un attaccante ha bisogno esattamente del 51.0% No. Al di sotto del 50%, un attaccante può comunque recuperare per caso, soprattutto partendo da uno svantaggio ridotto, ma la probabilità diminuisce con l'accumularsi delle conferme. Al di sopra del 50%, il controllo sostenuto dell'hash rate conferisce all'attaccante un vantaggio atteso nel lungo periodo. Durata, condizioni della rete, costo e obiettivo scelto rimangono comunque importanti. ### Mito 2: la potenza di hash di maggioranza può rubare ogni moneta No. La potenza di consenso influisce sulla scelta della storia valida; non rivela chiavi private né autorizza spese non valide. Un attaccante di maggioranza ottiene principalmente la capacità di annullare i propri pagamenti recenti, censurare transazioni e riordinare blocchi recenti. ### Mito 3: un numero fisso di conferme è sempre sicuro Nessun numero fisso è adatto a ogni blockchain o pagamento. Il rischio dipende dall'hash rate disponibile per l'attaccante, dal budget di sicurezza della rete onesta, dal valore della transazione, dai tempi di rilevamento e risposta e dalla rapidità con cui l'asset ricevuto può essere prelevato o convertito. ## Argomenti correlati - [Riorganizzazione della blockchain (reorg)](/it/crypto/chain-reorg/) - [La firma di una delega di governance è sicura?](/it/crypto/governance-delegation-signature-risk/) - [Hash rate](/it/crypto/hashrate/) - [Liquid staking](/it/crypto/liquid-staking/) - [Proof of work (PoW)](/it/crypto/proof-of-work/) ## Fonti - [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consultato il: 2026-08-20) - [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Developer Guide (consultato il: 2026-08-20) - [Proof-of-stake attack and defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consultato il: 2026-08-20) Source: https://wiki.fcontext.com/it/crypto/fifty-one-percent-attack/index.mdx