Recuperabilidad de datos y poda

El propósito de las capas de disponibilidad de datos como Celestia es garantizar que los datos de bloque se publiquen de manera comprobable, para que las aplicaciones y las implementaciones puedan saber cuál es el estado de su cadena, y almacenar esos datos. Una vez que se publican los datos, la disponibilidad de los datos se ajusta a las capas no garantice inherentemente que los datos históricos se almacenarán permanentemente y permanecer recuperable.

En este documento, discutimos el estado de la recuperación de datos y la poda en Celestia, así como algunos consejos para los desarrolladores de rollup para garantizar que sea posible sincronizar nuevos nodos de rollup.

Recuperación de datos y poda en celestia-nodo​

A partir de la versión v0.13.0, celestia-nodo ha implementado una ventana de muestreo de nodo ligero de 30 días, como se especifica en CIP-4. Esto significa que una vez que se implemente la poda, los nodos de luz ahora solo muestrearán bloques dentro de una ventana de 30 días en lugar de muestrear todos los bloques de la génesis. Este cambio introduce el concepto de poda en el nodo celestial, donde los datos fuera de la ventana de 30 días no pueden almacenarse mediante nodos de luz, marcando una actualización significativa en cómo se gestionan la capacidad de recuperación y el almacenamiento de datos dentro de la red (notas de la versión v0.13.0).

Los blobs de datos más antiguos que la ventana de recencia se podarán de forma predeterminada en los nodos ligeros, después de que la poda se implemente por completo, pero continuarán siendo almacenados por nodos de archivo que no podan datos. Los nodos de luz podrán consultar datos de blob históricos en espacios de nombres de nodos de archivo, siempre que existan nodos de archivo en la red pública.

Una vez que la poda esté completamente implementada, los nodos de luz solo realizarán el muestreo de disponibilidad de datos para bloques dentro de la ventana de recencia de datos de 30 días.

Prácticas sugeridas para rollups​

Es posible que los rollups necesiten acceder a datos históricos para permitir que los nuevos nodos de rollup reconstruyan el último estado reproduciendo bloques históricos. Una vez que los datos se han publicado en Celestia y se garantiza que se han puesto a disposición, los rollups y las aplicaciones son responsables de almacenar sus datos históricos.

Si bien es posible continuar haciendo esto usando el GetAll Método API en celestia-node en bloques históricos siempre que existan nodos de archivo en la red pública de Celestia, los desarrolladores de rollup no deben confiar en esto como el único método para acceder a datos históricos, como nodos de archivo que sirven solicitudes de datos históricos de forma gratuita no está garantizado. A continuación se presentan algunos otros métodos sugeridos para acceder a los datos históricos.

• Utilice nodos de archivo profesionales o proveedores de datos. Se espera que los proveedores de infraestructura profesional proporcionen acceso pagado a los nodos de archivo, donde se pueden recuperar datos históricos, por ejemplo, utilizando el GetAll Método API. Esto proporciona mejores garantías que confiar únicamente en nodos de archivo gratuitos en la red pública de Celestia.

• Compartir instantáneas de nodos de rollup. Los rollups podrían compartir instantáneas de sus directorios de datos que los usuarios pueden descargar manualmente al iniciar nuevos nodos. Estas instantáneas podrían contener el último estado de la implementación y/o todos los bloques históricos.

• Agregue soporte peer-to-peer para la sincronización histórica de bloques. Una versión menos manual de compartir instantáneas, donde los nodos de implementación podrían implementar soporte incorporado para la sincronización de bloques, donde los nodos de despliegue descargan datos de bloques históricos entre sí a través de una red peer-to-peer.

  • Anclaje de espacio de nombres. En el futuro, se espera que celestia-node permita a los nodos elegir "pin" datos de espacios de nombres seleccionados que desean almacenar y poner a disposición de otros nodos. Esto permitirá que los nodos de despliegue sean responsables de almacenar sus datos, sin necesidad de implementar su propio mecanismo de sincronización de bloques históricos entre pares.