#dusk $DUSK @Dusk Pasé el tiempo investigando el consenso de Dusk en vez de solo echar un vistazo a la documentación. Volvía una y otra vez a un detalle que no me dejaba en paz.
El modo de emergencia solo se activa después de 16 iteraciones fallidas. Antes de eso, la attestation Succinct se ejecuta normalmente con timeouts de paso fijos. El candidato no aparece o no logra alcanzar el quórum, termina la iteración y comienza la siguiente. Limpio y secuencial.
Después de 16 fallos seguidos, los timeouts desaparecen. Las iteraciones permanecen abiertas. Se desactivan los votos de NoCandidate y NoQuorum. A propósito se permite ejecutar varias iteraciones abiertas al mismo tiempo. Esto aumenta las probabilidades de que al menos una genere un bloque válido. El costo es un mayor riesgo de forks. Cuando aparecen forks, la regla queda fija: gana el número de iteración más bajo que alcanzó consenso. Todo lo demás se cierra en cuanto se acepta un bloque.
Aún queda una última protección. Si incluso la iteración final se queda bloqueada, los provisioners que tienen una mayoría del stake pueden solicitar un bloque de emergencia. Vacío, sin transacciones, firmado por Dusk, lo justo para mantener el turno en movimiento. Aún puede reemplazarse más tarde por un bloque con una iteración menor que alcance un quórum normal.
El whitepaper y los issues de rusk lo describen con claridad. Lo que aún no es público es con qué frecuencia realmente se ha activado este camino en el mainnet en vivo. La frecuencia parece ser la prueba real una vez que la red soporta una carga sostenida.
Me hace preguntarme si 16 es lo suficientemente alto como para que la mayoría de los días ni siquiera se llegue a él, o si los periodos silenciosos ya esconden más bloques de emergencia de los que muestra el explorador.
El modo de emergencia solo se activa después de 16 iteraciones fallidas. Antes de eso, la attestation Succinct se ejecuta normalmente con timeouts de paso fijos. El candidato no aparece o no logra alcanzar el quórum, termina la iteración y comienza la siguiente. Limpio y secuencial.
Después de 16 fallos seguidos, los timeouts desaparecen. Las iteraciones permanecen abiertas. Se desactivan los votos de NoCandidate y NoQuorum. A propósito se permite ejecutar varias iteraciones abiertas al mismo tiempo. Esto aumenta las probabilidades de que al menos una genere un bloque válido. El costo es un mayor riesgo de forks. Cuando aparecen forks, la regla queda fija: gana el número de iteración más bajo que alcanzó consenso. Todo lo demás se cierra en cuanto se acepta un bloque.
Aún queda una última protección. Si incluso la iteración final se queda bloqueada, los provisioners que tienen una mayoría del stake pueden solicitar un bloque de emergencia. Vacío, sin transacciones, firmado por Dusk, lo justo para mantener el turno en movimiento. Aún puede reemplazarse más tarde por un bloque con una iteración menor que alcance un quórum normal.
El whitepaper y los issues de rusk lo describen con claridad. Lo que aún no es público es con qué frecuencia realmente se ha activado este camino en el mainnet en vivo. La frecuencia parece ser la prueba real una vez que la red soporta una carga sostenida.
Me hace preguntarme si 16 es lo suficientemente alto como para que la mayoría de los días ni siquiera se llegue a él, o si los periodos silenciosos ya esconden más bloques de emergencia de los que muestra el explorador.