Una gestión aduanera que estaba siguiendo en el puerto de Karachi se quedó en "bajo revisión" durante tres días antes de pasar directamente a "despachado" sin mostrar etapas intermedias en el portal. Esperaba que la finalización por bloques de Dusk funcionara de la misma manera: pendiente y luego final, un solo salto. Pero así no funciona la finalización progresiva.
Hay cuatro estados distintos por los que pasa un bloque, y el salto entre ellos depende por completo de lo que haya ocurrido en las iteraciones anteriores. Un bloque comienza como atestiguado si en esa ronda no falló ninguna iteración previa, lo que significa que ningún otro candidato pudo haberlo superado hasta alcanzar el consenso. Si alguna iteración previa sí falló sin una atestación de fallo, entonces comienza como aceptado; es decir, que un bloque de una iteración inferior todavía podría reemplazarlo teóricamente.
La parte que realmente remodeló mi forma de pensar es que confirmado y final no tratan realmente del bloque en sí. Un bloque atestiguado se vuelve confirmado cuando se atestigua o confirma un único sucesor. Pero un bloque aceptado necesita 2 veces n bloques consecutivos atestiguados o confirmados apilados sobre él, donde n es el número de iteraciones previas que no están atestiguadas. Así, dos bloques de edad similar pueden tardar cantidades totalmente distintas de tiempo en llegar al mismo nivel de confianza, dependiendo únicamente de qué tan limpio haya sido su historial de iteraciones.
Lo que el whitepaper no me da es un plazo promedio real, en segundos o en bloques, para que algo pase de aceptado a final en la infraestructura en vivo de Dusk. No puedo inventar ese número.
La prueba real para DUSK es si esta ruta variable hacia la finalización sigue sintiéndose lo bastante rápida para los usuarios cotidianos que mueven fondos.
¿Alguien ha rastreado cuánto tardó una transacción real en alcanzar el estado final en Dusk?
#dusk $DUSK @Dusk
Hay cuatro estados distintos por los que pasa un bloque, y el salto entre ellos depende por completo de lo que haya ocurrido en las iteraciones anteriores. Un bloque comienza como atestiguado si en esa ronda no falló ninguna iteración previa, lo que significa que ningún otro candidato pudo haberlo superado hasta alcanzar el consenso. Si alguna iteración previa sí falló sin una atestación de fallo, entonces comienza como aceptado; es decir, que un bloque de una iteración inferior todavía podría reemplazarlo teóricamente.
La parte que realmente remodeló mi forma de pensar es que confirmado y final no tratan realmente del bloque en sí. Un bloque atestiguado se vuelve confirmado cuando se atestigua o confirma un único sucesor. Pero un bloque aceptado necesita 2 veces n bloques consecutivos atestiguados o confirmados apilados sobre él, donde n es el número de iteraciones previas que no están atestiguadas. Así, dos bloques de edad similar pueden tardar cantidades totalmente distintas de tiempo en llegar al mismo nivel de confianza, dependiendo únicamente de qué tan limpio haya sido su historial de iteraciones.
Lo que el whitepaper no me da es un plazo promedio real, en segundos o en bloques, para que algo pase de aceptado a final en la infraestructura en vivo de Dusk. No puedo inventar ese número.
La prueba real para DUSK es si esta ruta variable hacia la finalización sigue sintiéndose lo bastante rápida para los usuarios cotidianos que mueven fondos.
¿Alguien ha rastreado cuánto tardó una transacción real en alcanzar el estado final en Dusk?
#dusk $DUSK @Dusk
