---
title: "Ataques de stake grinding: viés na aleatoriedade do proof of stake"
description: "Um ataque de stake grinding procura, entre chaves, blocos ou contribuições aleatórias permitidas, o resultado que melhora a seleção futura. Entenda os caminhos, a vantagem e as defesas específicas."
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.
# Ataques de stake grinding: viés na aleatoriedade do proof of stake
> Análise educacional de segurança de protocolos. Aleatoriedade, seleção de líderes, penalidades e custos dependem do protocolo e da versão; confira a especificação e a implementação ativas antes de conclusões sobre segurança ou staking.
## Resposta direta
Um ataque de stake grinding explora escolhas disponíveis antes de a aleatoriedade PoS ser fixada. O participante avalia várias chaves, blocos candidatos ou contribuições válidas e mantém ou revela a opção que favorece um proponente, comitê ou fork futuro. A busca transforma um sorteio em vários candidatos e pode dar influência acima da parcela nominal de stake.
Grinding é uma família de ataques. No grinding de bloco ou semente, o produtor varia conteúdo ou ancestrais permitidos quando o hash alimenta aleatoriedade futura. No de chaves, gera muitas antes do registro e retém identidades favoráveis. Na revelação seletiva, retém ou publica compromisso, revelação, assinatura ou bloco depois de saber o efeito de cada opção na semente.
Hash, função aleatória verificável (VRF) ou commit-reveal não tornam todo o processo imparcial sozinhos. Importam quem escolhe entradas, quando conhece a elegibilidade, quantas alternativas testa, se abortar cria uma escolha e por quanto tempo a semente fica isolada dos líderes selecionados. A análise deve usar a versão exata do protocolo.
## Caminho de ataque e análise
1. **Fixe a regra.** Registre rede, versão, época ou rodada, snapshot do stake, derivação da semente, teste, fork choice, recompensas e penalidades.
2. **Mapeie escolhas adversárias.** Inclua chaves pré-registro, ordens válidas, campos opcionais, pais candidatos, publicação, revelações e abortos; só importa o que altera estado ou semente aceitos.
3. **Meça o orçamento.** Estime candidatos até o prazo, independência e custos de computação, recompensas perdidas, depósitos, atrasos ou atos puníveis.
4. **Ligue semente e poder.** Determine a antecedência da seleção, se o atacante vê o resultado antes do compromisso e se um acerto permite novo grinding.
5. **Avalie aceitação e acúmulo.** O candidato deve cumprir transição, tempo, assinatura e fork choice. Modele repetição com estado, sem presumir independência.
6. **Teste cada defesa.** Sementes atrasadas, VRF, registro, penalidades, beacons de limiar e funções de atraso verificável cobrem capacidades e hipóteses diferentes.
Preserve blocos ou compromissos candidatos, hashes e domínios, horários, snapshots, cálculo implementado e resultados contrafactuais. Uma sequência de propostas não basta: loterias honestas criam agrupamentos.
## Exemplo completo
Um protocolo simplificado dá ao atacante `10%` de chance de ser o próximo proponente. Com uma semente fixa, é `0.10`. Uma falha permite avaliar quase sem custo `20` sementes independentes e válidas e publicar qualquer uma.
A chance de ao menos uma selecioná-lo é `1 - (1 - 0.10)^20`, cerca de `87.8%`. Ele não possui `87.8%` do stake: o protocolo concedeu por engano `20` sorteios e escolha após observar os resultados.
É uma ilustração, não previsão. Correlação, prazos, custos, recompensas perdidas, punição por retenção e poder limitado do proponente podem reduzir o efeito. Meça tudo antes de atribuir impacto econômico ou de consenso.
## Defesas e checklist
### Construção da aleatoriedade
- Derive a aleatoriedade de entradas comprometidas antes de os afetados conhecerem ou controlarem as atribuições.
- Separe contribuição, compromisso, revelação e uso para o líder não buscar barato a semente do sucessor.
- Considere o último revelador: commit-reveal continua enviesável se reter permite escolher entre resultados.
- Use beacons de limiar ou distribuídos com hipóteses explícitas de honestidade, vivacidade, recuperação e membros.
### Elegibilidade e identidade
- Vincule chaves VRF e stake a um snapshot anterior à semente; caso contrário, geração offline vira grinding de chaves.
- Separe domínios por chain, versão, rodada, função e propósito para impedir reutilização de provas.
- Use elegibilidade privada quando apropriado, sabendo que reduz ataques antecipados, mas não corrige semente enviesada.
- Limite rotação barata de identidades e defina stake delegado, pools e conjuntos variáveis.
### Economia e operações
- Precifique blocos e recompensas perdidos, capital preso, equivocation detectável e penalidades correlacionadas; nem toda escolha legal é punível.
- Monitore contribuições, falhas de revelação, candidatos anormais, frequência e diversidade de software em janelas significativas.
- Isole aleatoriedade crítica de builder, relay ou ordenação discricionários, salvo prova de que são inofensivos.
- Teste fallback: um mecanismo imparcial só quando todos respondem pode sacrificar vivacidade.
## Erros comuns
- **Hashes são aleatórios, então não há grinding.** Um hash imprevisível para entrada fixa pode ser selecionado entre muitas entradas e ficar enviesado.
- **Uma VRF elimina todo grinding.** Ela prova uma saída; chaves, semente, registro e publicação seletiva continuam questões distintas.
- **Commit-reveal é automaticamente imparcial.** O último participante pode escolher revelar ou abortar se a opção não for neutralizada.
- **É preciso stake majoritário.** Uma minoria com tentativas baratas pode aumentar a chance; uma falha de segurança exige outras condições.
- **Propostas consecutivas provam manipulação.** O acaso cria sequências; detecção exige modelo estatístico e evidência técnica.
- **Grinding e nothing at stake são iguais.** Um enviesa aleatoriedade ou elegibilidade; o outro trata do incentivo a apoiar históricos rivais.
## Tópicos relacionados
- [Proof of stake](/pt-br/crypto/proof-of-stake/)
- [Validadores](/pt-br/crypto/validator/)
- [Hashes criptográficos](/pt-br/crypto/cryptographic-hash/)
- [Regras de fork choice](/pt-br/crypto/fork-choice-rule/)
- [Nothing at stake](/pt-br/crypto/nothing-at-stake/)
## Fontes
- [Criptomoedas sem prova de trabalho](https://arxiv.org/abs/1406.5694) - arXiv (acesso: 2026-08-21)
- [Ouroboros: um protocolo blockchain proof-of-stake com segurança demonstrável](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (acesso: 2026-08-21)
- [Ouroboros Praos: protocolo proof-of-stake semissíncrono e adaptativamente seguro](https://eprint.iacr.org/2017/573) - IACR Cryptology ePrint Archive (acesso: 2026-08-21)
- [Algorand: escalando acordos bizantinos para criptomoedas](https://doi.org/10.1145/3132747.3132757) - ACM (acesso: 2026-08-21)
- [Especificações de consenso do Ethereum: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (acesso: 2026-08-21)
Source: https://wiki.fcontext.com/pt-br/crypto/stake-grinding-attack/index.mdx