---
title: "Ataques de stake grinding: sesgo de la aleatoriedad en prueba de participación"
description: "Un ataque de stake grinding busca entre claves, bloques o aportes aleatorios permitidos el resultado que mejora una selección futura. Conozca sus vías, cuantifique la ventaja y revise las defensas del protocolo."
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: sesgo de la aleatoriedad en prueba de participación
> Análisis educativo de seguridad de protocolos. La aleatoriedad, la selección de líderes, las penalizaciones y los costes dependen del protocolo y la versión; verifique la especificación y la implementación activas antes de extraer conclusiones de seguridad o staking.
## Respuesta directa
Un ataque de stake grinding aprovecha decisiones que un participante de prueba de participación puede tomar antes de fijarse la aleatoriedad. Evalúa varias claves, bloques candidatos o contribuciones válidas y conserva o revela la opción que favorece a un futuro proponente, comité o bifurcación. La búsqueda convierte un sorteo en varios candidatos y puede otorgar influencia superior a la participación nominal.
Grinding es una familia de ataques. En el grinding de bloque o semilla, un productor varía contenido o ancestros permitidos cuando el hash resultante alimenta aleatoriedad futura. En el de claves genera muchas antes del registro y conserva identidades con elegibilidad favorable. En la revelación selectiva retiene o publica un compromiso, revelación, firma o bloque tras conocer cómo cambia la semilla cada opción permitida.
Un hash, una función aleatoria verificable (VRF) o commit-reveal no hacen imparcial todo el proceso por sí solos. Importan quién elige cada entrada, cuándo conoce la elegibilidad, cuántas alternativas prueba, si abortar añade otra opción y cuánto se separa la semilla de los líderes que selecciona. Debe revisarse la versión exacta, no inferir seguridad del nombre de una primitiva.
## Ruta de ataque y análisis
1. **Fije la regla de selección.** Registre red, versión, época o ronda, instantánea del stake activo, derivación de semilla, prueba de elegibilidad, elección de bifurcación, recompensas y penalizaciones.
2. **Mapee cada decisión adversaria.** Incluya claves previas al registro, órdenes válidos, campos opcionales, padres candidatos, publicación, revelaciones y abortos. Un campo importa solo si cambia un estado o semilla futuros aceptados.
3. **Mida el presupuesto de búsqueda.** Estime candidatos antes del plazo, independencia y coste de cómputo, recompensas perdidas, depósitos, retrasos o actos sancionables por intento.
4. **Conecte semilla y poder futuro.** Determine con cuánto anticipo selecciona proponentes o comités, si el atacante ve resultados antes de comprometerse y si un acierto permite otro grinding.
5. **Evalúe aceptación y acumulación.** El candidato debe cumplir transición de estado, tiempo, firma y fork choice. Modele la repetición con estado; no extrapole una ronda suponiendo independencia.
6. **Pruebe cada defensa frente a cada elección.** Semillas diferidas, VRF, registro, penalizaciones, balizas de umbral y funciones de demora verificable cubren capacidades distintas y añaden supuestos propios.
Conserve bloques o compromisos candidatos, hashes y dominios exactos, tiempos, instantáneas de stake, cálculo implementado y resultados contrafactuales. Una racha no es prueba: los sorteos honestos ponderados por stake producen agrupaciones.
## Ejemplo desarrollado
Suponga que un protocolo simplificado da al atacante `10%` de probabilidad de ser el próximo proponente. Con una semilla fija es `0.10`. Un fallo le permite evaluar casi gratis `20` semillas independientes e igualmente válidas y publicar cualquiera.
La probabilidad de que al menos una lo seleccione es `1 - (1 - 0.10)^20`, aproximadamente `87.8%`. No posee `87.8%` del stake: el protocolo le concedió por error `20` sorteos y elegir después de verlos.
Es una ilustración, no un pronóstico. Puede haber correlación, plazos, pérdida de comisiones o recompensas, castigo por retención, y ser el siguiente proponente quizá no dé influencia duradera. Mida esas restricciones antes del impacto económico o de consenso.
## Defensas y lista de revisión
### Construcción de aleatoriedad
- Derive la aleatoriedad de entradas comprometidas antes de que los afectados conozcan o controlen las asignaciones.
- Separe contribución, compromiso, revelación y uso para impedir que el líder busque barato la semilla de su sucesor inmediato.
- Considere al último revelador: commit-reveal conserva sesgo si retener permite elegir entre resultados.
- Use balizas de umbral o distribuidas con supuestos explícitos de honestidad, vivacidad, recuperación y membresía.
### Elegibilidad e identidad
- Vincule claves VRF y stake a una instantánea anterior a conocer la semilla; de otro modo, generar claves offline permite grinding.
- Separe dominios por cadena, versión, ronda, rol y propósito para evitar reutilizar pruebas entre contextos.
- Use elegibilidad privada cuando proceda, sabiendo que reduce ataques anticipados pero no corrige una semilla sesgada.
- Limite la rotación barata de identidades y defina cómo entran stake delegado, pools y conjuntos cambiantes.
### Economía y operaciones
- Cuantifique bloques y recompensas perdidos, capital bloqueado, equivocación detectable y penalizaciones correlacionadas; no toda elección legal es sancionable.
- Vigile aportes, fallos de revelación, candidatos anómalos, frecuencia de proponentes y diversidad de software en ventanas significativas.
- Aísle la aleatoriedad crítica de interfaces discrecionales de builders, relays u ordenación salvo que la especificación pruebe su inocuidad.
- Pruebe el fallback. Un mecanismo imparcial solo si todos responden puede cambiar resistencia al sesgo por fallo de vivacidad.
## Errores comunes
- **Los hashes son aleatorios, así que no hay grinding.** Un hash impredecible para una entrada fija puede sesgarse al elegir entre muchas entradas.
- **Una VRF elimina todo grinding.** Prueba una salida para clave y entrada; generación de claves, control de semilla, registro y publicación selectiva son cuestiones aparte.
- **Commit-reveal es automáticamente imparcial.** El último participante puede elegir revelar o abortar si esa opción no se neutraliza o cobra.
- **Hace falta stake mayoritario.** Una minoría con varios intentos baratos puede aumentar su probabilidad; causar un fallo de seguridad exige otras condiciones.
- **Una racha de propuestas demuestra manipulación.** El azar produce rachas; detectar exige un modelo estadístico previo y evidencia técnica.
- **Grinding y nothing at stake son iguales.** Uno sesga aleatoriedad o elegibilidad; el otro trata incentivos para apoyar historias rivales.
## Temas relacionados
- [Prueba de participación](/es/crypto/proof-of-stake/)
- [Validadores](/es/crypto/validator/)
- [Hashes criptográficos](/es/crypto/cryptographic-hash/)
- [Reglas de elección de bifurcación](/es/crypto/fork-choice-rule/)
- [Nothing at stake](/es/crypto/nothing-at-stake/)
## Fuentes
- [Criptomonedas sin prueba de trabajo](https://arxiv.org/abs/1406.5694) - arXiv (consulta: 2026-08-21)
- [Ouroboros: un protocolo blockchain de prueba de participación con seguridad demostrable](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (consulta: 2026-08-21)
- [Ouroboros Praos: protocolo de prueba de participación semisíncrono y adaptativamente seguro](https://eprint.iacr.org/2017/573) - IACR Cryptology ePrint Archive (consulta: 2026-08-21)
- [Algorand: escalado de acuerdos bizantinos para criptomonedas](https://doi.org/10.1145/3132747.3132757) - ACM (consulta: 2026-08-21)
- [Especificaciones de consenso de Ethereum: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consulta: 2026-08-21)
Source: https://wiki.fcontext.com/es/crypto/stake-grinding-attack/index.mdx