Vai al contenuto
Financial Context Wiki

Slashing

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.

Aggiornato

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

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.

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.

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.

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.

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.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...