Ayer estaba mirando las reglas de finalidad de Dusk y una pequeña fórmula me hizo detenerme: 2 × n.

Al principio pensé que la finalidad rodante solo se trataba de esperar una cantidad fija de bloques. Pero así no es como Dusk lo maneja.

Aquí, n = la cantidad de iteraciones previas no atestiguadas de un bloque en la misma ronda. Si n = 0, el bloque nuevo se marca como atestiguado. Un bloque atestiguado se vuelve confirmado cuando su sucesor está atestiguado o confirmado.

Pero cuando n > 0, las cosas cambian.

El bloque se vuelve aceptado y necesita 2 × n bloques consecutivos atestiguados o confirmados antes de volverse confirmado.

Así que si n = 1 - 2 bloques.
Si n = 2 - 4 bloques.
Si n = 3 - 6 bloques.
Si n = 4 - 8 bloques.

El whitepaper da un ejemplo sencillo: si un bloque está en la iteración 5 y dos iteraciones anteriores fallaron al atestiguar, necesita 4 bloques más (2 × 2) que estén atestiguados o confirmados antes de la confirmación. Después de eso, se vuelve final cuando su padre ya es final.

Lo que encuentro interesante es que Dusk no está tratando a cada bloque por igual.

Un bloque que llega después de iteraciones inferiores fallidas lleva más incertidumbre, así que el protocolo pide más evidencia.

Para mí, 2×n es básicamente un búfer de seguridad adaptable.

Más rutas fallidas → más confirmación requerida.

Esa es la parte de Finalidad Rodante que ahora entiendo mucho mejor.

#dusk @Dusk $DUSK
Fixed Finality
100%
Adaptive Finality
0%
Stronger Security
0%
2 Votos • Votación cerrada