Estaba trazando cómo el consenso de Dusk llega realmente a la finalización, y el enfoque de “un bloque, una confirmación” empezó a sentirse incompleto.

La Attestation Succinct funciona en rondas, y cada ronda puede ejecutarse a través de múltiples iteraciones si un comité no logra producir o validar un bloque a tiempo. A simple vista, eso es solo un mecanismo de reintento; está bien, la red se corrige a sí misma. Pero cuando seguí lo que en realidad cuesta una iteración fallida, no es solo un reintento abstracto. Cada iteración fallida reordena el comité, reinicia la ventana de votación y empuja la marca de tiempo de la finalización más hacia adelante. Ese retraso no aparece en ninguna parte como un solo número: se distribuye entre quienes están esperando ese bloque, ya sea un contraparte de liquidación, un relé de puente o una aplicación que comprueba el estado de la confirmación.

Así que el “tiempo de finalización” que la gente cita es en realidad una cifra de mejor caso. El costo real es condicional: se acumula con las condiciones de la red, la capacidad de respuesta de los validadores y la frecuencia con la que los comités terminan su trabajo en el primer intento. Nadie asume ese riesgo de manera uniforme; la persona que espera la transacción lo absorbe, no el protocolo.

Todavía no estoy seguro de cómo se comporta esa tasa de fallos cuando tanto el volumen de transacciones como la rotación de comités escalan al mismo tiempo.
#dusk $DUSK @Dusk