#dusk $DUSK
La frase "modo de emergencia" seguía apareciendo en el whitepaper de Dusk y yo seguía avanzando más allá. Cuando de verdad leí la sección, el mecanismo es más específico que el nombre sugiere.
Consenso normal de Dusk: cada ronda se ejecuta hasta un máximo de 50 iteraciones. En cada paso, Propuesta, Validación, Ratificación, hay un tiempo de espera. Si no se forma quórum antes del tiempo de espera, el paso continúa y eventualmente comienza una nueva iteración. Secuencial, acotado y predecible.
El modo de emergencia es diferente. Se activa después de 16 iteraciones fallidas consecutivas — donde fallida significa que no se alcanzó quórum, normalmente porque los validadores están fuera de línea o aislados. Una vez activado: se deshabilitan los tiempos de espera de los pasos. Se inician nuevas iteraciones, pero cada iteración en curso se mantiene activa en lugar de cerrarse. Varias iteraciones abiertas permanecen ejecutándose en paralelo. Esto aumenta la probabilidad de producir un bloque. También aumenta la probabilidad de bifurcaciones.
Las bifurcaciones en el modo de emergencia se resuelven seleccionando el bloque del número de iteración más bajo. Si la red aún no puede formar un bloque, el último recurso es un bloque de emergencia: un bloque vacío, sin transacciones, firmado por Dusk como entidad usando su clave pública global. Los provisionadores que tienen la mayoría del stake lo solicitan.
Entonces, ¿por qué la red no ejecuta el modo de emergencia cada vez que quiere ser más rápida.
El modo normal intercambia algo de velocidad por una finalidad más limpia. Las iteraciones abiertas concurrentes aumentan la vivacidad bajo estrés pero introducen complejidad que el respaldo del bloque vacío es una intervención centralizada — la cadena sigue avanzando, pero la entidad Dusk es la que lo está moviendo.
En realidad, encuentro que el bloque de emergencia es la pregunta de diseño más interesante — porque significa que la garantía de vivacidad depende en última instancia de la disponibilidad y la disposición de la entidad Dusk para firmar. La seguridad del protocolo y la descentralización tiran en direcciones ligeramente diferentes.
Lo que no he visto explicado es qué sucede con las transacciones que estaban en curso cuando un bloque de emergencia reemplaza a un bloque normal — si se re-incluyen en la siguiente ronda o si se descartan. @Dusk
$DUSK #dusk
La frase "modo de emergencia" seguía apareciendo en el whitepaper de Dusk y yo seguía avanzando más allá. Cuando de verdad leí la sección, el mecanismo es más específico que el nombre sugiere.
Consenso normal de Dusk: cada ronda se ejecuta hasta un máximo de 50 iteraciones. En cada paso, Propuesta, Validación, Ratificación, hay un tiempo de espera. Si no se forma quórum antes del tiempo de espera, el paso continúa y eventualmente comienza una nueva iteración. Secuencial, acotado y predecible.
El modo de emergencia es diferente. Se activa después de 16 iteraciones fallidas consecutivas — donde fallida significa que no se alcanzó quórum, normalmente porque los validadores están fuera de línea o aislados. Una vez activado: se deshabilitan los tiempos de espera de los pasos. Se inician nuevas iteraciones, pero cada iteración en curso se mantiene activa en lugar de cerrarse. Varias iteraciones abiertas permanecen ejecutándose en paralelo. Esto aumenta la probabilidad de producir un bloque. También aumenta la probabilidad de bifurcaciones.
Las bifurcaciones en el modo de emergencia se resuelven seleccionando el bloque del número de iteración más bajo. Si la red aún no puede formar un bloque, el último recurso es un bloque de emergencia: un bloque vacío, sin transacciones, firmado por Dusk como entidad usando su clave pública global. Los provisionadores que tienen la mayoría del stake lo solicitan.
Entonces, ¿por qué la red no ejecuta el modo de emergencia cada vez que quiere ser más rápida.
El modo normal intercambia algo de velocidad por una finalidad más limpia. Las iteraciones abiertas concurrentes aumentan la vivacidad bajo estrés pero introducen complejidad que el respaldo del bloque vacío es una intervención centralizada — la cadena sigue avanzando, pero la entidad Dusk es la que lo está moviendo.
En realidad, encuentro que el bloque de emergencia es la pregunta de diseño más interesante — porque significa que la garantía de vivacidad depende en última instancia de la disponibilidad y la disposición de la entidad Dusk para firmar. La seguridad del protocolo y la descentralización tiran en direcciones ligeramente diferentes.
Lo que no he visto explicado es qué sucede con las transacciones que estaban en curso cuando un bloque de emergencia reemplaza a un bloque normal — si se re-incluyen en la siguiente ronda o si se descartan. @Dusk
$DUSK #dusk
