Slashing dei validatori: come gli staker perdono denaro

Lo slashing è una penalità che distrugge parte dei fondi in stake di un validatore per comportamenti dannosi dimostrabili — soprattutto la doppia firma (equivocation) o i voti avvolgenti (surround votes). Esiste per rendere costoso attaccare la chain. L'indisponibilità ordinaria non è slashing; andare offline provoca invece piccole penalità di inattività.

Questa è la risposta breve. Il resto di questa pagina separa i due modi molto diversi in cui uno staker perde denaro, e mostra dove si trova il vero rischio.

---

Slashing contro indisponibilità: due penalità diverse

Le chain proof-of-stake puniscono i validatori in due categorie, e confonderle è il malinteso più comune.

Lo slashing è riservato alle violazioni che il protocollo può dimostrare crittograficamente come attacchi al consenso. A un validatore slashato vengono bruciati fondi, viene espulso con la forza dal set attivo e non può rientrare. Su Ethereum, le violazioni slashabili sono:

• Doppia proposta (double-proposing) — firmare due blocchi diversi per lo stesso slot.
• Doppia attestazione (equivocation) — firmare due attestazioni contraddittorie per lo stesso target.
• Voti avvolgenti (surround votes) — emettere un'attestazione il cui intervallo di voto avvolge o è avvolto da un voto precedente, uno schema prodotto solo da un validatore disonesto o mal configurato.

Tutte e tre si riducono al fatto che il validatore dice due cose contraddittorie contemporaneamente sulla storia della chain. È esattamente ciò che farebbe un attaccante che cerca di forkare o invertire la chain, quindi il protocollo lo tratta come ostile a prescindere dall'intenzione.

L'indisponibilità (downtime) non è slashing. Se il tuo validatore è offline e perde attestazioni, subisci una piccola perdita da inattività (inactivity leak) — non guadagni ricompense e perdi una cifra minima, all'incirca pari a quanto avresti guadagnato. In condizioni normali si misura in frazioni di punto percentuale al giorno. Degenera in perdite serie solo durante un evento di inactivity leak, quando la chain non finalizza a lungo e i validatori offline vengono prosciugati per ripristinare una supermaggioranza. È un'emergenza rara a livello di intera chain, non una penalità di routine.

---

La penalità di correlazione

Lo slashing non è una multa fissa. L'importo scala in base a quanti validatori vengono slashati più o meno nello stesso momento, tramite la penalità di correlazione (su Ethereum: lo slashing proporzionale).

La logica: un singolo validatore che commette equivocation è probabilmente un errore o un attore malevolo isolato e fa pochi danni. Migliaia che lo fanno insieme sembrano un attacco coordinato. Quindi più stake viene slashato nella stessa finestra, maggiore è la penalità che paga ogni trasgressore — potenzialmente l'intero saldo se la quota correlata è abbastanza alta.

Questo design scoraggia direttamente la concentrazione. Eseguire molti validatori su infrastruttura identica significa che un singolo bug può slasharli tutti simultaneamente, attivando il moltiplicatore di correlazione. È un incentivo deliberato a distribuire lo stake su client, macchine e operatori indipendenti.

---

Eventi, cause e gravità

La differenza tra la prima riga e il resto è tutto il punto: l'indisponibilità ti costa ricompense, lo slashing ti costa il capitale.

---

Chi è a rischio e come evitarlo

La stragrande maggioranza degli slashing reali ha una causa principale: le stesse chiavi di validatore in esecuzione su due macchine contemporaneamente. Qualcuno configura un nodo di backup o di failover con le stesse chiavi, entrambi vanno online, e le due istanze firmano messaggi contraddittori — uno slashing per equivocation istantaneo. Qui non c'è alcun attacco, solo una configurazione errata che il protocollo non può distinguere da un attacco.

Se gestisci validatori in proprio, le difese pratiche sono:

• Non eseguire mai chiavi identiche su due nodi contemporaneamente. Non costruire un «hot spare» che condivide le chiavi. Se migri su nuovo hardware, spegni completamente e conferma che la vecchia istanza sia morta prima di avviare quella nuova.
• Usa il database di protezione dallo slashing. I client tengono un registro locale di ogni messaggio firmato e si rifiutano di firmare qualsiasi cosa sarebbe slashabile. Importa e trasporta sempre questo database quando sposti le configurazioni; non ripartire mai da zero con chiavi esistenti.
• Diversifica client e infrastruttura in modo che un singolo bug del client non slashi l'intera flotta e non attivi la penalità di correlazione.
• Comprendi il compromesso della delega. Con un pool di staking o un provider di liquid staking, è l'operatore a gestire i validatori. Il rischio di slashing ricade su di lui, non direttamente su di te — ma erediti la sua competenza e la sua concentrazione.

---

Limiti onesti

Non esiste una versione senza rischio dello staking; c'è solo una scelta di quale rischio ti assumi.

Lo staking in solo ti dà ricompense complete e controllo totale, oltre a responsabilità totale. Un evento di indisponibilità ti costa ricompense; un errore di chiavi-su-due-macchine ti costa capitale tramite slashing. Le modalità di guasto sono operative e in gran parte nelle tue mani.

Lo staking delegato o liquido trasferisce quel carico operativo a un provider. Non sei più tu a poter firmare doppio. In cambio ti assumi il rischio del provider e di controparte: l'operatore può comunque essere slashato (e trasferirti le perdite), la piattaforma può fallire, gli accordi di custodia possono rompersi, e un token di liquid staking può sganciarsi (depeg) dallo stake sottostante. Hai scambiato un rischio che controlli con uno che non controlli.

Nessuno dei due è categoricamente più sicuro. Lo slashing è un piccolo rischio di coda evitabile per un operatore solo attento, e un rischio delegato che non puoi prevenire personalmente usando un pool.

---

FAQ

Cosa fa slashare un validatore? Violazioni di consenso dimostrabili: proporre due blocchi per lo stesso slot, o fare attestazioni contraddittorie (doppi voti e voti avvolgenti). In pratica derivano quasi sempre da chiavi duplicate in esecuzione su due macchine, non da attacchi deliberati.

Verrò slashato se vado offline? No. L'indisponibilità non è una violazione slashabile. Perdi ricompense e paghi una piccola perdita da inattività all'incirca pari a quanto avresti guadagnato. Le perdite diventano serie solo durante una non finalizzazione prolungata, cosa rara.

Quanto può costare uno slashing? Inizia con un burn iniziale e un'espulsione forzata, poi aggiunge una penalità di correlazione basata su quanto stake è stato slashato insieme al tuo. In isolamento la perdita è moderata; in uno slashing di massa correlato può scalare fino all'intero saldo in stake.

Fare staking tramite un pool mi protegge dallo slashing? Sposta il rischio operativo sull'operatore anziché eliminarlo. Non firmerai doppio personalmente, ma l'operatore può comunque essere slashato e trasferirti la perdita, e in cambio ti assumi un rischio di provider e di controparte.

---

Prima ancora di fare staking, assicurati di comprendere il meccanismo che stai proteggendo — leggi cos'è lo staking e come il proof-of-stake si confronta con il proof-of-work. Se preferisci non gestire un validatore, valuta i compromessi del liquid staking.