Saltar al contenido
Financial Context Wiki

Ataques de stake grinding: sesgo de la aleatoriedad en prueba de participación

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.

Actualizado

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

Fuentes

Navegación

Buscar en la wiki...