---
title: "Slashing"
description: "Slashing è una riduzione dello stake slashabile definita dal protocollo dopo un comportamento scorretto attribuibile a un validatore o a un operatore. Analizza l'esatto illecito, le prove, la base dello stake, la formula della penalità, i tempi, la delega e l'esposizione al ritiro invece di assumere che ogni dovere mancato o percentuale dichiarata abbia lo stesso effetto."
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.

# Slashing

> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

<a id="answer"></a>

## Risposta diretta

Lo slashing è una riduzione dello stake definita dal protocollo dopo una violazione attribuibile a un validatore, operatore o altro partecipante vincolato. Una regola completa identifica la violazione soggetta a slashing, la prova o il contatore che la dimostra, lo stake esposto, il calcolo della penalità e il periodo in cui può ancora essere applicata. Può accompagnarsi a sospensione, disabilitazione, uscita forzata, perdita di ricompense o premio di segnalazione, ma sono transizioni di stato distinte salvo che il protocollo le definisca insieme.

Non esiste una regola universale di decurtazione. Ethereum decurta le proposte e le attestazioni in conflitto, ma tratta separatamente i doveri mancati ordinari e la perdita per inattività. Una catena Cosmos SDK può configurare sia le decurtazioni per doppia firma sia quelle per inattività. Polkadot distingue tra infrazioni, decurtazioni, disabilitazioni e cambiamenti di reputazione. Un servizio di restaking può aggiungere un altro impegno soggetto a decurtazione i cui contratti, insieme di operatori e finestra di prelievo differiscono dalla catena base. Leggi le regole attive per la rete, fork, runtime o distribuzione del contratto esatti.

Slashing dimostra un predicato di protocollo, non un intento malevolo. Una chiave di validatore duplicata, un failover split-brain, un backup ripristinato, una corsa del firmatario remoto o un database di protezione contro lo slashing corrotto possono produrre due firme valide che confliggono anche quando l'operatore non intendeva un attacco. Al contrario, una scarsa disponibilità non è automaticamente punibile con lo slashing su ogni network, e un messaggio non valido o tardivo non è punibile con lo slashing a meno che non soddisfi una regola di infrazione definita.

Tieni separati questi concetti:

- **Ricompensa mancata o penalità ordinaria:** un dovere era assente, in ritardo o incorretto, ma nessun reato punibile è stato provato.
- **Meccanismo di inattività:** Le penalità aumentano o il peso di voto cambia durante una non-finalità prolungata; la perdita di inattività di Ethereum non comporta essa stessa una riduzione.
- **Slashing:** una transizione di stato riconosciuta in catena o dal protocollo riduce la posta legata a un reato provato.
- **Imprigionamento, disabilitazione, espulsione o tombstoning:** La partecipazione è sospesa o terminata; l'azione può verificarsi con o senza una riduzione aggiuntiva della quota.
- **Penale sociale o contrattuale:** La governance , un contratto di servizio, una polizza assicurativa o un fork coordinato impone una conseguenza al di fuori della funzione di slashing automatica del protocollo di base.

La parte che gestisce la chiave non è necessariamente l'unica parte a subire perdite. Le regole del protocollo e i contratti di servizio possono esporre l'autoscommessa, la scommessa delegata, la scommessa del nominatore, le allocazioni reinvestite, i prelievi in coda o le pretese collettive. Assicurazione e rimborso sono promesse di credito separate, non annullamenti dell'evento del protocollo.

<a id="mechanism"></a>

## Come analizzare lo slashing

### 1. Fissa il regolamento e il punto di osservazione

Registra lo `network`, `chain ID`, `fork version` attivo o runtime, blocco o epoca, rilascio di client/specifica e indirizzi contrattuali rilevanti. Separa le regole di consenso dai termini di un fornitore di staking e dall'interfaccia utente. Una query di parametro attuale e uno stato finalizzato sono prove più solide di una pagina di aiuto senza data.

### 2. Scrivi il predicato esatto della violazione

Nomina la regola in termini eseguibili: due proposte distinte di un validadore per lo stesso slot, un `double vote`, un `surround vote`, un voto non valido riconosciuto dal protocollo, o `missed > max_missed` all'interno di una finestra di vivacità. Non sostituire il predicato con etichette come "comportamento sbagliato", "offline" o "attacco".

### 3. Verifica l'attribuzione e le prove

Verifica l'identità del validatore o dell'operatore, le firme, `signing root`, la separazione dei domini, il contesto del fork, le altezze o le epoche e l'età delle prove. Per le infrazioni con messaggi conflittuali, conserva entrambi gli oggetti firmati. Per le regole di disponibilità, riproduci il contatore e la finestra del protocollo. L'inclusione delle prove può avvenire dopo l'infrazione, quindi distingui `infraction time`, `detection time` e `application time`.

### 4. Identifica ogni saldo esposto

Determina se la base è `effective balance`, lo stake vincolato all'altezza dell'infrazione, lo stake corrente, lo stake personale, lo stake delegato, un'allocazione di slot del validatore o uno stake assegnato a un `operator set`. Controlla limiti massimi, limiti minimi, incrementi di arrotondamento, denominazione, sanzioni precedenti, ristagni di delega e se i prelievi in coda restano soggetti a decurtazione.

### 5. Ricalcola ogni componente della penalità

Suddividere il risultato in `initial penalty`, `correlation penalty`, penali per obblighi continui, ricompense rinunciate, effetti di uscita forzata e ricompense per segnalazioni o whistleblower. Una semplice regola fissa può usare `slash_amount = slashable_stake * slash_fraction`; molti protocolli attivi usano invece funzioni dipendenti dallo stato. Non applicare mai una percentuale generale al saldo del portafoglio senza confermare la base.

### 6. Mappa l'intera timeline e chi sostiene la perdita

Reato tracciato, propagazione delle prove, inclusione, contabilità della sanzione, periodo di reclusione o disabilitazione, finestra di appello o cancellazione, uscita, sblocco dei vincoli e completamento del prelievo. Poi allocare la perdita tra operatore, deleganti, nominanti, detentori di token del pool e restaker secondo il protocollo e il contratto di servizio. Includere gli effetti sul prezzo del token e sulla liquidità separatamente dalle unità bruciate.

### 7. Verifica i controlli e riconcilia lo stato

Rivedere la custodia chiave, l'esclusività dei firmatari, la durabilità `slashing protection database`, il fencing di failover, il ripristino dei backup, il monitoraggio di orologio e rete, la diversità dei clienti e le procedure per gli incidenti. Ricalcolare l'evento dallo stato finalizzato, dai parametri, dalle evidenze e dai delta di bilancio; riconciliarlo con etichette dell'explorer, dichiarazioni dei fornitori, registrazioni contabili e qualsiasi pagamento assicurativo senza considerare una fonte come conclusiva.

<a id="example"></a>

## Esempi svolti

### Firme conflittuali in stile Ethereum

Supponiamo che il validatore `V` firmi l'intestazione del blocco `A` e un'intestazione diversa `B` per `slot = 8`, con firme valide nello stesso contesto di fork applicabile. La coppia soddisfa la forma di doppia proposizione Ethereum; una proposta mancata nello slot 9 non lo fa. Per le attestazioni, si considerino `A = (source = 120, target = 125)` e `B = (source = 118, target = 127)`. Poiché `B` circonda `A`, la coppia ha la forma di voto contorno. Le etichette da sole non sono sufficienti: i dati effettivamente firmati, i domini, l'indice del validatore e i controlli del periodo slashable devono rispettare la specifica attiva.

Questo esempio mostra anche perché l'intento non è un input. Due macchine che utilizzano la stessa chiave possono creare la prova. Uno screenshot che dice "doppia firma" non può; il protocollo richiede oggetti firmati validi in conflitto.

### Calcolo della perdita per quota proporzionale

Considera un protocollo illustrativo con token `slashable_stake = 12,500` e un `slash_fraction = 0.015` fisso. La perdita del protocollo è:

`12,500 * 0.015 = 187.5 tokens`.

Se la regola addebita tutta la quota di supporto pro rata, i token `2,500` dell'auto-commit dell'operatore perdono `37.5`, mentre i token delegati `10,000` perdono `150`. Se il contratto di servizio rimborsa i delegatori ma non l'operatore, quel pagamento è un credito separato ed espone a rischio di credito. Non modifica la penalità on-chain e questa allocazione non deve essere trasferita a un protocollo che protegge i delegatori o utilizza una base di stake diversa.

### Finestra di attività in stile Cosmos

Supponiamo che una catena basata su Cosmos SDK abbia interrogato i parametri `window = 1,000` e `min_signed = 0.95`. I suoi errori massimi consentiti sono:

`max_missed = 1,000 - (0.95 * 1,000) = 50`.

Se la regola attiva scatta quando `missed > max_missed`, esattamente `50` assenze non superano la soglia, mentre `51` sì. La frazione di slashing, la durata della sospensione, l'azzeramento del contatore e la possibilità di rientrare dipendono dai parametri attivi della catena e dalla versione del modulo. È un esempio di catena configurata, non una regola proof-of-stake universale né il trattamento dell'inattività di Ethereum.

### Formula delle violazioni correlate

La documentazione revisionata di Polkadot fornisce la frazione di equivocazione `min((3 * x / n)^2, 1)`, dove `x` è il numero di trasgressori e `n` il conteggio dei validatori attivi. Con `x = 5` e `n = 100`:

`min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%`.

Applicato alle unità `40,000` di stake nello slot del validatore, cioè `900` unità. Con `x = 20`, la stessa formula dà `36%`, non quattro volte `2.25%`. Questo dimostra il rischio di correlazione; non autorizza l'uso di quella formula su Ethereum, una catena Cosmos, una parachain o un diverso runtime Polkadot senza verificare le regole attuali.

<a id="risks"></a>

## Rischi e fallimenti della revisione

- **Regolamento sbagliato:** un'altra catena, fork, runtime, testnet o distribuzione di contratti può avere reati e penalità diversi.
- **Confluenza tra reato e sanzione:** Le ricompense perse, le penalità per inattività, l'incarcerazione, la disabilitazione, l'espulsione e la decurtazione di non sono etichette intercambiabili.
- **Parametri obsoleti:** La governance e gli aggiornamenti di possono modificare finestre, frazioni, limiti, ritardi e saldi protetti.
- **Confusione di dominio:** Le firme provenienti da contesti di fork o domini diversi potrebbero non costituire prove punibili.
- **Prova non valida:** Le prove malformate, duplicate, scadute, indicizzate in modo errato o non autenticate possono essere rifiutate.
- **Scoperta ritardata:** Le prove possono arrivare dopo la riassegnazione o l'inizio dell'uscita, quindi gli stati di infrazione e applicazione differiscono.
- **Snapshot della quota errata:** Il saldo corrente potrebbe non essere il saldo, il potere di voto o la quota effettiva utilizzata dalla regola.
- **Amplificazione della correlazione:** un cliente condiviso, cloud, firmatario o procedimento può trasformare un errore in una penalità di massa dipendente dallo stato.
- **Chiavi duplicate:** ha copiato i keystore e i backup attivi simultanei possono generare firme contrastanti.
- **Errore del firmatario remoto:** ritenta, blocchi obsoleti, database incoerenti o riconoscimenti ambigui possono causare doppia firma.
- **Failover del cervello diviso:** due siti potrebbero entrambi credere di essere primari a meno che il failover non sia criptograficamente delimitato.
- **Perdita del database di protezione:** Il ripristino delle chiavi senza una cronologia completa delle firme può rendere un validatore apparentemente pulito non sicuro.
- **Concentrazione dell'operatore:** molti validatori sotto un unico piano di controllo condividono esposizione operativa e di correlazione.
- **Trasferimento della delega:** I deleganti o i nominatori possono subire perdite causate da un operatore che non possono controllare direttamente.
- **Sovrapposizione del restaking:** un asset può supportare più impegni con autorità di penalizzazione e regole di allocazione distinte.
- **Esposizione al ritiro:** lo sblocco o il prelievo in coda potrebbero rimanere soggetti a decurtazione per reati precedenti o recentemente attribuibili.
- **Incertezza nella governance:** Gli appelli , i periodi di cancellazione, gli aggiornamenti o il recupero sociale possono modificare i tempi, ma non sono rimedi garantiti.
- **Contabilità e arrotondamento:** Gli incrementi del saldo effettivo , le conversioni delle quote, i limiti e i decimali dei token possono sconfiggere la moltiplicazione del saldo del portafoglio.
- **Lacune di osservabilità:** Le etichette dell'esploratore possono omettere la coppia di prove, l'istantanea dei parametri, le deleghe interessate o le sanzioni successive.
- **Rischio di contratto e di controparte:** Le promesse di pool, custodia, assicurazione e rimborso di possono fallire indipendentemente dalla correttezza del consenso.

<a id="misconceptions"></a>

## Comuni idee sbagliate

### Ogni validatore offline viene punito?

No. Ethereum applica penalità per doveri mancati e inattività, ma non classifica i periodi di inattività ordinari come un reato punibile. Le catene Cosmos SDK possono configurare la penalizzazione per inattività. Altri protocolli possono disabilitare, mettere in stato di blocco, ridurre le ricompense o non fare nulla. Interroga la regola esatta invece di generalizzare da una rete.

### Lo slashing richiede la prova dell'intento malevolo?

Di solito la regola automatica valuta messaggi firmati, prove, contatori e stato, non il motivo. Un incidente operativo può soddisfare lo stesso predicato di un'ambiguità deliberata. L'intento può essere importante per la governance, l'assicurazione, il contenzioso o un contratto di servizio, ma non per la transizione di stato deterministica.

### La perdita massima è la percentuale di slashing dichiarata?

Non necessariamente. La percentuale può applicarsi a staking effettivo, vincolato, allocato, delegato o storico; la correlazione e le penalità continue possono aumentare la perdita; l'uscita forzata comporta la perdita delle ricompense future; e il prezzo del token o gli sconti sul liquid-staking possono modificare il valore economico. Al contrario, un tetto o un saldo protetto possono ridurre la base da addebitare.

### L'avvio di un'uscita termina immediatamente l'esposizione allo slashing?

Non esiste alcuna regola universale che lo dica. Le prove possono essere ritardate, l'unbonding esiste in parte per preservare la responsabilità, e alcuni prelievi da restaking rimangono punibili durante una coda. Verifica l'ultimo momento punibile per ogni impegno, non solo la transazione che ha richiesto l'uscita.

### La delega, l'assicurazione o il recupero sociale eliminano il rischio di slash?

No. Ridistribuiscono la perdita o promettono di rimborsarla secondo regole aggiuntive. La copertura può escludere guasti correlati, scadere, limitare i reclami, dipendere dalla governance o creare rischio di controparte. Lo slashing del protocollo rimane un evento separato da riconciliare in modo indipendente.

<a id="related"></a>

## Argomenti correlati

- [Prova di partecipazione](/it/crypto/proof-of-stake/)
- [Validatore](/it/crypto/validator/)
- [Staking](/it/crypto/staking/)
- [Reinvestimento](/it/crypto/restaking/)
- [Coda di Uscita e di Ritiro del Validatore](/it/crypto/validator-exit-withdrawal-queue/)

<a id="sources"></a>

## Fonti

- [Ricompense e Penalità del Proof-of-Stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (accesso: 2026-08-19)
- [Specifiche di Consenso Ethereum: Validatore Onesto](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (accesso: 2026-08-19)
- [Specifiche di Consenso Ethereum: Catena del Faro](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (accesso: 2026-08-19)
- [Cosmos SDK modulo x/slashing](https://docs.cosmos.network/sdk/v0.53/build/modules/slashing/README) - Cosmos SDK (accesso: 2026-08-19)
- [Cosmos SDK modulo x/evidence](https://docs.cosmos.network/sdk/latest/modules/evidence/README) - Cosmos SDK (accesso: 2026-08-19)
- [Violazioni e slashing](https://docs.polkadot.com/infrastructure/staking-mechanics/offenses-and-slashes/) - Polkadot Developer Docs (accesso: 2026-08-19)
- [Casper Friendly Finality Gadget](https://arxiv.org/abs/1710.09437) - Buterin e Griffith (consultato: 2026-08-19)
- [EigenLayer DelegationManager](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - Eigen Labs (accesso: 2026-08-19)

Source: https://wiki.fcontext.com/it/crypto/slashing/index.mdx