En la liquidación de valores, “el pedido ya fue emparejado”, “los fondos ya están congelados” y “la entrega se completó legalmente” no son lo mismo. La confirmación en blockchain también es así. <@Dusk > el sitio web oficial enfatiza la liquidación determinista, pero el whitepaper no simplifica la finality a “dinero en segundos”; en cambio, sigue analizando si, en circunstancias anómalas, un bloque podría llegar a ser reemplazado.
Primero, veamos el fallback. Dentro de la misma ronda de consenso, si varios bloques candidatos logran resultados, los nodos darán prioridad al que tenga una iteración más baja, y revertirán la rama con una iteración más alta. Aunque un bloque haya sido aceptado por la red, no significa que sea absolutamente estable en todos los estados posteriores.
El whitepaper también diseña un modo de emergencia: después de 16 fallos consecutivos de iteración, el paso por tiempo de espera se cancela; varias iteraciones abiertas pueden avanzar en paralelo, hasta que algún bloque candidato complete la verificación y la aprobación. Si aun así no se puede continuar, los provisioners que poseen la mayoría total apostada pueden solicitar la generación de un bloque de emergencia. Este no incluye transacciones; principalmente escribe una nueva seed para que la red pueda retomar el avance. <#dusk >
Por eso, la rolling finality de <$DUSK > distingue cuatro estados: accepted indica que el bloque tiene pruebas de éxito, pero aún podría ser reemplazado por una iteración más baja; attested significa que las iteraciones anteriores fallaron y que el bloque actual ya no puede ser reemplazado por una iteración más baja; confirmed indica que cuenta con el respaldo de bloques posteriores; y final exige que el bloque padre también ya esté final. Si antes hubo n iteraciones no attestadas, un bloque accepted todavía debe atravesar 2×n bloques consecutivos attested o confirmed, para entrar en confirmed.
Así que, a mi juicio, si se mira de esa manera, es más honesto decir “finalidad en segundos”: separa la velocidad de la ruta normal de la estabilidad de la ruta anómala, y también admite que pueden ocurrir demoras, estar offline y bifurcaciones.
Primero, veamos el fallback. Dentro de la misma ronda de consenso, si varios bloques candidatos logran resultados, los nodos darán prioridad al que tenga una iteración más baja, y revertirán la rama con una iteración más alta. Aunque un bloque haya sido aceptado por la red, no significa que sea absolutamente estable en todos los estados posteriores.
El whitepaper también diseña un modo de emergencia: después de 16 fallos consecutivos de iteración, el paso por tiempo de espera se cancela; varias iteraciones abiertas pueden avanzar en paralelo, hasta que algún bloque candidato complete la verificación y la aprobación. Si aun así no se puede continuar, los provisioners que poseen la mayoría total apostada pueden solicitar la generación de un bloque de emergencia. Este no incluye transacciones; principalmente escribe una nueva seed para que la red pueda retomar el avance. <#dusk >
Por eso, la rolling finality de <$DUSK > distingue cuatro estados: accepted indica que el bloque tiene pruebas de éxito, pero aún podría ser reemplazado por una iteración más baja; attested significa que las iteraciones anteriores fallaron y que el bloque actual ya no puede ser reemplazado por una iteración más baja; confirmed indica que cuenta con el respaldo de bloques posteriores; y final exige que el bloque padre también ya esté final. Si antes hubo n iteraciones no attestadas, un bloque accepted todavía debe atravesar 2×n bloques consecutivos attested o confirmed, para entrar en confirmed.
Así que, a mi juicio, si se mira de esa manera, es más honesto decir “finalidad en segundos”: separa la velocidad de la ruta normal de la estabilidad de la ruta anómala, y también admite que pueden ocurrir demoras, estar offline y bifurcaciones.