---
title: "Attacchi di stake grinding: distorcere la casualità proof-of-stake"
description: "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."
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.
# Attacchi di stake grinding: distorcere la casualità proof-of-stake
> 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
- [Proof of stake](/it/crypto/proof-of-stake/)
- [Validatori](/it/crypto/validator/)
- [Hash crittografici](/it/crypto/cryptographic-hash/)
- [Regole di fork choice](/it/crypto/fork-choice-rule/)
- [Nothing at stake](/it/crypto/nothing-at-stake/)
## Fonti
- [Criptovalute senza proof of work](https://arxiv.org/abs/1406.5694) - arXiv (consultato: 2026-08-21)
- [Ouroboros: un protocollo blockchain proof-of-stake con sicurezza dimostrabile](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (consultato: 2026-08-21)
- [Ouroboros Praos: protocollo proof-of-stake semi-sincrono e adattivamente sicuro](https://eprint.iacr.org/2017/573) - IACR Cryptology ePrint Archive (consultato: 2026-08-21)
- [Algorand: scalare gli accordi bizantini per le criptovalute](https://doi.org/10.1145/3132747.3132757) - ACM (consultato: 2026-08-21)
- [Specifiche di consenso Ethereum: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/stake-grinding-attack/index.mdx