Chicos, la mayoría de las blockchains asumen que el consenso sigue avanzando. $DUSK realmente tiene un plan para cuando no lo hace.
En su consenso SA, cada bloque lleva una semilla derivada de la firma del generador del bloque anterior. Eso cambia constantemente la aleatoriedad, haciendo difícil predecir con antelación a los futuros generadores de bloques y comités.
Pero lo más interesante es lo que sucede cuando las cosas salen mal.
Si suficientes provisionadores se desconectan y fallan 16 iteraciones consecutivas, Dusk entra en modo de emergencia. En lugar de simplemente rendirse, la red sigue intentando hasta que un bloque candidato alcanza el quórum.
Varias iteraciones incluso pueden permanecer abiertas al mismo tiempo, aumentando la probabilidad de que una tenga éxito. ¿El costo? Más intentos concurrentes también pueden crear bifurcaciones (forks), que Dusk resuelve seleccionando el candidato de la iteración más baja.
Y si la red llega a la iteración final sin avances, los provisionadores que tengan la mayoría del stake pueden solicitar un bloque de emergencia. Ese bloque no contiene transacciones, pero le da a la red una nueva semilla para que pueda pasar a la siguiente ronda.
En realidad, me parece más interesante que el habitual argumento de “consenso rápido”. Muestra lo que hace el protocolo cuando la red se comporta mal, no solo cuando todo funciona perfectamente.
Pero sigo preguntándome: ¿tener una ruta de emergencia elaborada hace a Dusk más resiliente, o la complejidad añadida introduce nuevos casos límite?
¿Preferirías usar una blockchain con un mecanismo detallado de recuperación ante fallos, o una con un diseño de consenso más simple?
#dusk $DUSK @Dusk
En su consenso SA, cada bloque lleva una semilla derivada de la firma del generador del bloque anterior. Eso cambia constantemente la aleatoriedad, haciendo difícil predecir con antelación a los futuros generadores de bloques y comités.
Pero lo más interesante es lo que sucede cuando las cosas salen mal.
Si suficientes provisionadores se desconectan y fallan 16 iteraciones consecutivas, Dusk entra en modo de emergencia. En lugar de simplemente rendirse, la red sigue intentando hasta que un bloque candidato alcanza el quórum.
Varias iteraciones incluso pueden permanecer abiertas al mismo tiempo, aumentando la probabilidad de que una tenga éxito. ¿El costo? Más intentos concurrentes también pueden crear bifurcaciones (forks), que Dusk resuelve seleccionando el candidato de la iteración más baja.
Y si la red llega a la iteración final sin avances, los provisionadores que tengan la mayoría del stake pueden solicitar un bloque de emergencia. Ese bloque no contiene transacciones, pero le da a la red una nueva semilla para que pueda pasar a la siguiente ronda.
En realidad, me parece más interesante que el habitual argumento de “consenso rápido”. Muestra lo que hace el protocolo cuando la red se comporta mal, no solo cuando todo funciona perfectamente.
Pero sigo preguntándome: ¿tener una ruta de emergencia elaborada hace a Dusk más resiliente, o la complejidad añadida introduce nuevos casos límite?
¿Preferirías usar una blockchain con un mecanismo detallado de recuperación ante fallos, o una con un diseño de consenso más simple?
#dusk $DUSK @Dusk