Empecé a mirar el Modo de Emergencia de Dusk después de hacerme una pregunta sencilla: ¿qué pasa si de pronto la mayoría de los participantes responsables del consenso se desconectan?
Sin ataque. Sin bloqueo malicioso.
Solo falta suficiente participación de stake para llegar a un acuerdo.
Eso es lo que hizo interesante para mí el Modo de Emergencia de @Dusk .
Al principio, asumí que el Modo de Emergencia se trataba principalmente de producir un bloque de emergencia. Al mirar más de cerca, en realidad ese no es el punto.
Cuando falla una iteración del consenso, Dusk no cierra la puerta de inmediato. Las iteraciones anteriores pueden permanecer abiertas mientras comienzan otras nuevas, dándole a los provisioners restantes más oportunidades de llegar a un acuerdo.
Pero eso crea un compromiso: mantener vivas múltiples iteraciones también crea la posibilidad de bloques en competencia.
Por eso Dusk prioriza la iteración con éxito más bajo.
Y si la participación sigue siendo insuficiente, la Solicitud de Bloque de Emergencia (EBR) ofrece otra ruta de recuperación. Una vez que se recopilan EBR que representan la mayoría del stake de la red, se puede producir un bloque de emergencia vacío.
Ese bloque no está ahí para procesar transacciones. Su propósito es mantener la cadena en movimiento y establecer una semilla fresca para otro intento de consenso.
Así que el Modo de Emergencia no trata realmente de qué sucede cuando el consenso tiene éxito. Trata de lo que hace el protocolo cuando dejan de cumplirse las suposiciones que sustentan el consenso.
Ese es el compromiso más profundo: preservar la vivacidad es útil, pero la ruta de recuperación tiene que seguir siendo determinista cuando son posibles múltiples resultados.
La pregunta que me queda es qué tan bien se sostiene esta ruta de recuperación si la participación degradada no es temporal, sino persistente.
@Dusk $DUSK #dusk
Sin ataque. Sin bloqueo malicioso.
Solo falta suficiente participación de stake para llegar a un acuerdo.
Eso es lo que hizo interesante para mí el Modo de Emergencia de @Dusk .
Al principio, asumí que el Modo de Emergencia se trataba principalmente de producir un bloque de emergencia. Al mirar más de cerca, en realidad ese no es el punto.
Cuando falla una iteración del consenso, Dusk no cierra la puerta de inmediato. Las iteraciones anteriores pueden permanecer abiertas mientras comienzan otras nuevas, dándole a los provisioners restantes más oportunidades de llegar a un acuerdo.
Pero eso crea un compromiso: mantener vivas múltiples iteraciones también crea la posibilidad de bloques en competencia.
Por eso Dusk prioriza la iteración con éxito más bajo.
Y si la participación sigue siendo insuficiente, la Solicitud de Bloque de Emergencia (EBR) ofrece otra ruta de recuperación. Una vez que se recopilan EBR que representan la mayoría del stake de la red, se puede producir un bloque de emergencia vacío.
Ese bloque no está ahí para procesar transacciones. Su propósito es mantener la cadena en movimiento y establecer una semilla fresca para otro intento de consenso.
Así que el Modo de Emergencia no trata realmente de qué sucede cuando el consenso tiene éxito. Trata de lo que hace el protocolo cuando dejan de cumplirse las suposiciones que sustentan el consenso.
Ese es el compromiso más profundo: preservar la vivacidad es útil, pero la ruta de recuperación tiene que seguir siendo determinista cuando son posibles múltiples resultados.
La pregunta que me queda es qué tan bien se sostiene esta ruta de recuperación si la participación degradada no es temporal, sino persistente.
@Dusk $DUSK #dusk
