Ir para o conteúdo
Financial Context Wiki

Ataques de stake grinding: viés na aleatoriedade do proof of stake

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.

Atualizado

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

Fontes

Navegação

Pesquisar na wiki...