Vai al contenuto

Attacchi di stake grinding: distorcere la casualità proof-of-stake

Uno stake-grinding attack cerca tra chiavi, blocchi o contributi casuali ammessi l'esito che migliora la futura selezione. Esamina percorsi, vantaggio di ricerca e difese specifiche.

Aggiornato

Analisi didattica della sicurezza dei protocolli. Casualità, selezione dei leader, penalità e costi dipendono da protocollo e versione; verificare specifica e implementazione attive prima di conclusioni su sicurezza o staking.

Risposta diretta

Uno stake-grinding attack sfrutta scelte disponibili prima che la casualità PoS sia fissata. Il partecipante valuta più chiavi, blocchi candidati o contributi validi e conserva o rivela l’opzione che favorisce un futuro proponente, comitato o fork. La ricerca trasforma un’estrazione in più candidati e può dare influenza oltre la quota nominale di stake.

È una famiglia di attacchi. Nel grinding di blocco o seed, il produttore varia contenuti o antenati ammessi se l’hash alimenta la casualità futura. Nel key grinding genera molte chiavi prima della registrazione e tiene le identità favorevoli. Nella rivelazione selettiva trattiene o pubblica commitment, reveal, firma o blocco dopo averne appreso l’effetto sul seed.

Hash, funzione casuale verificabile (VRF) o commit-reveal non rendono da soli imparziale l’intero processo. Contano chi sceglie gli input, quando conosce l’idoneità, quante alternative prova, se l’abbandono offre una scelta e quanto il seed è separato dai leader scelti. La verifica deve usare l’esatta versione del protocollo.

Percorso di attacco e analisi

  1. Fissare la regola. Registrare rete, versione, epoca o round, snapshot dello stake, derivazione del seed, test, fork choice, premi e penalità.
  2. Mappare le scelte avverse. Includere chiavi pre-registrazione, ordini validi, campi opzionali, parent candidati, pubblicazione, reveal e aborti; conta solo ciò che cambia stato o seed accettati.
  3. Misurare il budget. Stimare candidati entro la scadenza, indipendenza e costi di calcolo, premi persi, depositi, ritardi o azioni slashable.
  4. Collegare seed e potere. Stabilire l’anticipo della selezione, se l’attaccante vede l’esito prima dell’impegno e se una vittoria abilita altro grinding.
  5. Valutare accettazione e accumulo. Il candidato deve rispettare transizione, tempo, firma e fork choice. Modellare il processo con stato, senza falsa indipendenza tra round.
  6. Provare ogni difesa. Seed ritardati, VRF, registrazione, penalità, beacon a soglia e funzioni di ritardo verificabile coprono capacità e ipotesi diverse.

Conservare blocchi o commitment candidati, hash e domini, tempi, snapshot, calcolo implementato e risultati controfattuali. Una serie di proposte non basta: lotterie oneste producono concentrazioni.

Esempio svolto

Un protocollo semplificato assegna all’attaccante 10% di probabilità di essere il prossimo proponente. Con un seed fisso è 0.10. Un difetto gli consente di valutare quasi gratis 20 seed indipendenti e validi e pubblicarne uno.

La probabilità che almeno uno lo selezioni è 1 - (1 - 0.10)^20, circa 87.8%. Non possiede 87.8% dello stake: il protocollo gli ha concesso per errore 20 estrazioni e la scelta dopo averle viste.

È un esempio, non una previsione. Correlazione, scadenze, costi, premi persi, penalità e limitato potere del proponente possono ridurre l’effetto. Vanno misurati prima dell’impatto economico o di consenso.

Difese e checklist

Costruzione della casualità

  • Derivare la casualità da input impegnati prima che i partecipanti conoscano o controllino le assegnazioni.
  • Separare contributo, commitment, reveal e uso affinché il leader non cerchi a basso costo il seed del successore.
  • Considerare l’ultimo rivelatore: commit-reveal resta distorcibile se trattenere permette di scegliere tra esiti.
  • Usare beacon a soglia o distribuiti con ipotesi esplicite su onestà, liveness, recupero e membri.

Idoneità e identità

  • Vincolare chiavi VRF e stake a uno snapshot anteriore al seed, altrimenti la generazione offline diventa key grinding.
  • Separare i domini per chain, versione, round, ruolo e scopo per impedire il riuso delle prove.
  • Usare idoneità privata ove adatto, sapendo che riduce il targeting ma non corregge seed distorti.
  • Limitare il ricambio economico di identità e definire stake delegato, pool e validator set variabili.

Economia e operazioni

  • Valutare blocchi e premi persi, capitale bloccato, equivocation rilevabile e penalità correlate; non ogni scelta legale è slashable.
  • Monitorare contributi, reveal mancati, candidati anomali, frequenze e diversità software su finestre significative.
  • Isolare la casualità critica da builder, relay e ordinamento discrezionali salvo prova di innocuità.
  • Provare il fallback: un meccanismo imparziale solo se tutti rispondono può sacrificare la liveness.

Idee errate comuni

  • Gli hash sono casuali, quindi niente grinding. Un hash imprevedibile su un input fisso può essere selezionato tra molti input e quindi distorto.
  • Una VRF elimina ogni grinding. Prova un output; chiavi, seed, registrazione e pubblicazione selettiva restano problemi distinti.
  • Commit-reveal è automaticamente imparziale. L’ultimo partecipante può scegliere reveal o abbandono se l’opzione non è neutralizzata.
  • Serve la maggioranza dello stake. Una minoranza con prove economiche può guadagnare probabilità; un guasto di sicurezza richiede altre condizioni.
  • Proposte consecutive provano la manipolazione. Il caso crea serie; servono modello statistico ed evidenze tecniche.
  • Grinding e nothing at stake coincidono. Il primo distorce casualità o idoneità, il secondo gli incentivi a sostenere storie concorrenti.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...