Solía pensar que un límite de época en Dusk era, en su mayor parte, un evento de temporización: una época termina y otra comienza.
Al mirar más de cerca, creo que esa formulación no capta una restricción importante del sistema.
Una época cambia el estado desde el que se evalúa la elegibilidad del provisioner, mientras que el consenso todavía tiene que operar dentro de una cantidad acotada de cómputo. Eso hace que el límite sea más que una marca de calendario: es un punto en el que el estado de participación puede cambiar sin permitir que el trabajo de consenso crezca indefinidamente.
La cadena de ingeniería que me resulta interesante es:
transición de época → cambia el estado de elegibilidad → el consenso evalúa el nuevo estado → el cómputo permanece acotado.
Eso crea un equilibrio sutil.
Si los cambios en la participación o en la elegibilidad pudieran afectar al consenso de forma inmediata y sin límites claros, los nodos podrían enfrentar transiciones de estado más complicadas. Si los cambios se restringen mediante condiciones de época, el protocolo obtiene un modelo de estado más limpio, pero los cambios de participación se vuelven menos instantáneos.
Lo que me sorprendió es que la segmentación temporal y los límites computacionales pueden resolver problemas distintos mientras se refuerzan entre sí.
Una época responde a cuándo puede cambiar el estado del consenso.
Un proceso iterativo acotado responde a cuánto trabajo se le permite hacer al consenso.
La pregunta abierta es: a medida que el conjunto de provisioners de una red cambia con más rapidez, ¿cómo debería equilibrarse la duración de la época entre la estabilidad del estado y la capacidad de respuesta?
@Dusk_Foundation $DUSK #dusk
Al mirar más de cerca, creo que esa formulación no capta una restricción importante del sistema.
Una época cambia el estado desde el que se evalúa la elegibilidad del provisioner, mientras que el consenso todavía tiene que operar dentro de una cantidad acotada de cómputo. Eso hace que el límite sea más que una marca de calendario: es un punto en el que el estado de participación puede cambiar sin permitir que el trabajo de consenso crezca indefinidamente.
La cadena de ingeniería que me resulta interesante es:
transición de época → cambia el estado de elegibilidad → el consenso evalúa el nuevo estado → el cómputo permanece acotado.
Eso crea un equilibrio sutil.
Si los cambios en la participación o en la elegibilidad pudieran afectar al consenso de forma inmediata y sin límites claros, los nodos podrían enfrentar transiciones de estado más complicadas. Si los cambios se restringen mediante condiciones de época, el protocolo obtiene un modelo de estado más limpio, pero los cambios de participación se vuelven menos instantáneos.
Lo que me sorprendió es que la segmentación temporal y los límites computacionales pueden resolver problemas distintos mientras se refuerzan entre sí.
Una época responde a cuándo puede cambiar el estado del consenso.
Un proceso iterativo acotado responde a cuánto trabajo se le permite hacer al consenso.
La pregunta abierta es: a medida que el conjunto de provisioners de una red cambia con más rapidez, ¿cómo debería equilibrarse la duración de la época entre la estabilidad del estado y la capacidad de respuesta?
@Dusk_Foundation $DUSK #dusk