Antes pensaba que un epoch era principalmente una forma conveniente de agrupar bloques. Al observar el ciclo de vida del provisioner de Dusk, esa idea se siente demasiado superficial.
Me di cuenta de que 2.160 bloques no es solo un número en la especificación de la red. Se convierte en una unidad de tiempo discreta que determina cuándo un provisioner recién apostado puede realmente entrar en consenso.
Volví a la documentación porque lo interesante está en la lógica de los límites. Una nueva apuesta no se vuelve activa de inmediato. Su activación ocurre en el límite de epoch después del siguiente, lo que significa que el bloque exacto en el que se envía la apuesta afecta cuánto tiempo espera el operador.
Eso crea un equilibrio útil de ingeniería: transiciones de ciclo de vida predecibles frente a participación inmediata.
El mecanismo es esencialmente:
transacción de apuesta → epoch actual → límite del siguiente epoch → límite del epoch siguiente → apuesta activa.
Así, la duración del epoch convierte el tiempo continuo en puntos de control definidos por el protocolo. En lugar de que cada bloque potencialmente cambie el conjunto activo de provisioners, los cambios de ciclo de vida se sincronizan alrededor de límites fijos.
La consecuencia es sutil. Dos apuestas idénticas enviadas en distintos momentos dentro del mismo epoch pueden experimentar diferentes demoras de activación, aunque la regla del protocolo en sí sea determinista.
Esa previsibilidad hace que las transiciones del conjunto de validadores sean más fáciles de razonar, pero el costo es la latencia: entrar en consenso no es una operación instantánea.
Lo que me sorprendió es que 2.160 bloques, por lo tanto, actúa menos como un intervalo de calendario y más como un reloj de transición de estado para los provisioners.
La pregunta a la que sigo volviendo es: ¿cuánto de la simplicidad operativa de Dusk proviene específicamente de obligar a que los cambios de ciclo de vida se produzcan en estos límites discretos de epoch?
@Dusk_Foundation $DUSK #dusk
Me di cuenta de que 2.160 bloques no es solo un número en la especificación de la red. Se convierte en una unidad de tiempo discreta que determina cuándo un provisioner recién apostado puede realmente entrar en consenso.
Volví a la documentación porque lo interesante está en la lógica de los límites. Una nueva apuesta no se vuelve activa de inmediato. Su activación ocurre en el límite de epoch después del siguiente, lo que significa que el bloque exacto en el que se envía la apuesta afecta cuánto tiempo espera el operador.
Eso crea un equilibrio útil de ingeniería: transiciones de ciclo de vida predecibles frente a participación inmediata.
El mecanismo es esencialmente:
transacción de apuesta → epoch actual → límite del siguiente epoch → límite del epoch siguiente → apuesta activa.
Así, la duración del epoch convierte el tiempo continuo en puntos de control definidos por el protocolo. En lugar de que cada bloque potencialmente cambie el conjunto activo de provisioners, los cambios de ciclo de vida se sincronizan alrededor de límites fijos.
La consecuencia es sutil. Dos apuestas idénticas enviadas en distintos momentos dentro del mismo epoch pueden experimentar diferentes demoras de activación, aunque la regla del protocolo en sí sea determinista.
Esa previsibilidad hace que las transiciones del conjunto de validadores sean más fáciles de razonar, pero el costo es la latencia: entrar en consenso no es una operación instantánea.
Lo que me sorprendió es que 2.160 bloques, por lo tanto, actúa menos como un intervalo de calendario y más como un reloj de transición de estado para los provisioners.
La pregunta a la que sigo volviendo es: ¿cuánto de la simplicidad operativa de Dusk proviene específicamente de obligar a que los cambios de ciclo de vida se produzcan en estos límites discretos de epoch?
@Dusk_Foundation $DUSK #dusk