@Dusk_Foundation La Distancia de Recuperación que Realmente Observo en un Nodo DUSK
A las 03:17, el nodo ya estaba de vuelta en la caja, pero aún en ninguna parte cercano a ser útil. Rusk estaba instalado, la configuración estaba donde la esperaba y las claves no habían sido tocadas. Lo que resultaba molesto era el estado. La red había seguido avanzando mientras esta máquina no.
Ahí es donde para mí el fast-sync de DUSK se vuelve interesante. No porque de alguna manera haga que desaparezcan bloques antiguos. Hace algo más práctico: reemplaza el estado local de Rusk y la base de datos de la cadena con un estado publicado, y luego deja el nodo continuar desde ahí hacia el tip en vivo.
Empecé a pensar en el hueco como distancia de recuperación. Si el snapshot se encuentra en la altura S y la red ya está en T, entonces T menos S es el trabajo que todavía queda delante del nodo. Un snapshot más nuevo puede reducir esa distancia, pero no elimina el resto del camino de recuperación. Descargar es una parte. Reiniciar, encontrar pares, avanzar la altura y comprobar que sigue avanzando son otras.
También hay un borde incómodo aquí. El fast-sync no reconstruye los índices de archivo desde antes del snapshot, así que “recuperado” significa cosas distintas para un nodo ordinario y para un servicio de archivo.
Lo que quiero observar a continuación no es el tamaño del snapshot. Es cómo se comporta la distancia de recuperación durante una falla caótica, cuando la red sigue moviéndose mientras el operador todavía está arreglando cosas.#dusk $DUSK
A las 03:17, el nodo ya estaba de vuelta en la caja, pero aún en ninguna parte cercano a ser útil. Rusk estaba instalado, la configuración estaba donde la esperaba y las claves no habían sido tocadas. Lo que resultaba molesto era el estado. La red había seguido avanzando mientras esta máquina no.
Ahí es donde para mí el fast-sync de DUSK se vuelve interesante. No porque de alguna manera haga que desaparezcan bloques antiguos. Hace algo más práctico: reemplaza el estado local de Rusk y la base de datos de la cadena con un estado publicado, y luego deja el nodo continuar desde ahí hacia el tip en vivo.
Empecé a pensar en el hueco como distancia de recuperación. Si el snapshot se encuentra en la altura S y la red ya está en T, entonces T menos S es el trabajo que todavía queda delante del nodo. Un snapshot más nuevo puede reducir esa distancia, pero no elimina el resto del camino de recuperación. Descargar es una parte. Reiniciar, encontrar pares, avanzar la altura y comprobar que sigue avanzando son otras.
También hay un borde incómodo aquí. El fast-sync no reconstruye los índices de archivo desde antes del snapshot, así que “recuperado” significa cosas distintas para un nodo ordinario y para un servicio de archivo.
Lo que quiero observar a continuación no es el tamaño del snapshot. Es cómo se comporta la distancia de recuperación durante una falla caótica, cuando la red sigue moviéndose mientras el operador todavía está arreglando cosas.#dusk $DUSK