#dusk $DUSK @Dusk Pasé por la sección de incentivos de consenso esta semana porque quería entender si un participante con más stake podría manipular el momento de la generación de bloques.
Hallazgo inesperado: el whitepaper nombra este problema exacto por sí mismo. “Future-generator incentive problem” — los generadores con más iteraciones pueden beneficiarse si fallan las iteraciones anteriores, ya que entonces ganan la recompensa del bloque. Es una vulnerabilidad nombrada, no oculta.
La actualización del protocolo Aegis en la red principal (3 de marzo de 2026) se centró en la resiliencia de la red. Parte de por qué la resiliencia importa aquí: este incentivo exacto puede hacer que los generadores de iteraciones anteriores rindan por debajo.
Tres mecanismos lo abordan: recompensas para votantes (los provisioners ganan por votar, no solo por generar); recompensas por créditos adicionales (el generador pierde el extra del 10% si excluye votos — así que el sabotaje también les cuesta); exclusión de los generadores de la siguiente iteración del paso de votación actual.
La mayoría de los sistemas PoS no tienen este problema: no existe una estructura secuencial de iteración, por lo que no hay un sucesor esperando beneficiarse del fallo de un predecesor. El diseño de Dusk crea esta vulnerabilidad y luego la corrige.
Un protocolo que nombra explícitamente su propia falla en teoría de juegos está haciendo algo inusual. Si los tres parches resisten bajo el estrés real de la red con stake concentrado es la pregunta abierta honesta. @Dusk
$DUSK #dusk
Hallazgo inesperado: el whitepaper nombra este problema exacto por sí mismo. “Future-generator incentive problem” — los generadores con más iteraciones pueden beneficiarse si fallan las iteraciones anteriores, ya que entonces ganan la recompensa del bloque. Es una vulnerabilidad nombrada, no oculta.
La actualización del protocolo Aegis en la red principal (3 de marzo de 2026) se centró en la resiliencia de la red. Parte de por qué la resiliencia importa aquí: este incentivo exacto puede hacer que los generadores de iteraciones anteriores rindan por debajo.
Tres mecanismos lo abordan: recompensas para votantes (los provisioners ganan por votar, no solo por generar); recompensas por créditos adicionales (el generador pierde el extra del 10% si excluye votos — así que el sabotaje también les cuesta); exclusión de los generadores de la siguiente iteración del paso de votación actual.
La mayoría de los sistemas PoS no tienen este problema: no existe una estructura secuencial de iteración, por lo que no hay un sucesor esperando beneficiarse del fallo de un predecesor. El diseño de Dusk crea esta vulnerabilidad y luego la corrige.
Un protocolo que nombra explícitamente su propia falla en teoría de juegos está haciendo algo inusual. Si los tres parches resisten bajo el estrés real de la red con stake concentrado es la pregunta abierta honesta. @Dusk
$DUSK #dusk
