Nodos de Archivo de Sui y RPC Histórico: Checkpoints, Épocas y Consulta del Estado Pasado

¿Qué es un nodo de archivo de Sui y cómo se accede al estado histórico?

Un nodo de archivo de Sui es un nodo completo que conserva todos los checkpoints y el estado histórico, lo que permite consultar el estado pasado de la red en cualquier momento. A diferencia de un nodo completo estándar, que elimina datos antiguos y solo mantiene el estado más reciente, un nodo de archivo almacena cada checkpoint desde el génesis. Puedes acceder a estos datos históricos a través de la API JSON-RPC de Sui utilizando métodos como sui_getCheckpoint y sui_getObject con versiones históricas, o ejecutando tu propio nodo de archivo. Esta guía explica el mecanismo y muestra cómo consultar el estado pasado de manera confiable.

El modelo de datos de Sui es fundamentalmente diferente al de las cadenas basadas en EVM. En lugar de bloques y transacciones, Sui utiliza objetos y checkpoints. Un checkpoint es una secuencia de transacciones que han sido acordadas por los validadores y sirve como punto de finalidad. Las épocas son períodos de tiempo durante los cuales el conjunto de validadores es fijo. Comprender estos conceptos es clave para trabajar con datos históricos.

• Objeto: La unidad básica de estado, propiedad de una dirección o compartida. Cada objeto tiene un número de versión que se incrementa cada vez que se modifica.
• Checkpoint: Un lote de transacciones que han sido certificadas y confirmadas. Los checkpoints se numeran secuencialmente desde el génesis (número de secuencia 0).
• Época: Un período de tiempo (por ejemplo, 24 horas) durante el cual el conjunto de validadores es fijo. Los límites de época están marcados por checkpoints especiales.
• Nodo completo: Almacena solo el estado más reciente y un historial limitado (por ejemplo, checkpoints recientes) para ahorrar espacio en disco.
• Nodo de archivo: Conserva todos los checkpoints y el estado histórico, lo que permite consultar cualquier checkpoint o versión de objeto pasada.

Cómo almacena Sui los datos históricos: checkpoints, épocas y versiones de objetos

El consenso de Sui produce una secuencia de checkpoints. Cada checkpoint contiene una lista de transacciones y los cambios de estado resultantes. El estado se compone de objetos, cada uno con un ID único y un número de versión. Cuando un objeto se modifica, su versión se incrementa. El nodo completo mantiene la última versión de cada objeto en su base de datos, pero puede eliminar versiones anteriores y checkpoints para gestionar el uso del disco.

Los nodos de archivo, por otro lado, almacenan cada checkpoint y cada versión de cada objeto. Esto permite consultar el estado de un objeto en una versión histórica específica o recuperar eventos que ocurrieron en un rango de checkpoints específico. La documentación de Sui sobre Datos de Archivo de Sui explica que los nodos de archivo son esenciales para aplicaciones que necesitan auditar el estado pasado o servir consultas históricas.

Los límites de época son importantes porque afectan los conjuntos de validadores y los parámetros de gas. Puedes consultar checkpoints por número de secuencia o por época. Por ejemplo, sui_getCheckpoint acepta un ID de checkpoint o número de secuencia, y también puedes usar sui_getCheckpoints para paginar a través de checkpoints en un rango.

• Los números de secuencia de checkpoint son enteros monótonamente crecientes que comienzan en 0.
• Cada época tiene un checkpoint de inicio y fin. El primer checkpoint de una época se usa a menudo para marcar el cambio de época.
• Las versiones de objeto son por objeto y se incrementan en cada escritura. Puedes consultar una versión específica usando sui_getObject con el parámetro version.
• Los eventos se indexan por checkpoint y se pueden consultar usando suix_queryEvents con un filtro de rango de checkpoints.

Nodo completo vs nodo de archivo: ¿qué métodos RPC puedes usar?

La diferencia clave entre un nodo completo y un nodo de archivo es el horizonte de retención. Un nodo completo típicamente mantiene solo el último checkpoint y algunos recientes, mientras que un nodo de archivo conserva todos. Esto afecta qué llamadas RPC tienen éxito. Por ejemplo, llamar a sui_getCheckpoint con un número de secuencia antiguo en un nodo completo puede devolver un error si ese checkpoint ha sido eliminado. De manera similar, consultar un objeto en una versión antigua puede fallar si el nodo completo ya no tiene esa versión.

La documentación de Sui sobre Configuración de Nodo Completo de Sui describe las opciones de configuración checkpoint-pruning y object-pruning. Por defecto, los nodos completos eliminan datos antiguos, pero puedes configurarlos para retener más o ejecutar un nodo de archivo deshabilitando la poda.

Cuando usas un proveedor de RPC, la disponibilidad de datos históricos depende de si ejecutan nodos de archivo. Algunos proveedores ofrecen endpoints de archivo con datos históricos completos, mientras que otros solo proporcionan acceso a nodos completos. Siempre verifica la documentación del proveedor para conocer las políticas de retención.

• RPC de nodo completo: Adecuado para consultas de estado actual, transacciones recientes y suscripciones en vivo. Las consultas históricas están limitadas a una ventana corta (por ejemplo, últimos 100 checkpoints).
• RPC de nodo de archivo: Admite consultas a cualquier checkpoint, versión de objeto o evento en la historia. Ideal para análisis, auditorías y relleno de datos.
• Soporte del proveedor: Varía según el proveedor. Algunos ofrecen endpoints de archivo como característica premium. Consulta la guía de RPC de Sui para seleccionar un endpoint.

Ejecutar tu propio nodo de archivo de Sui: almacenamiento y configuración

Si prefieres ejecutar tu propio nodo de archivo, necesitas configurar tu nodo completo de Sui para deshabilitar la poda. La documentación de Sui proporciona un archivo de configuración fullnode.yaml donde puedes establecer checkpoint-pruning y object-pruning en false. Esto hará que el nodo conserve todos los datos históricos.

Las necesidades de almacenamiento son significativas: un nodo de archivo almacena todos los checkpoints históricos y versiones de objetos, y el conjunto de datos crece continuamente con la actividad de la red. El tamaño exacto varía según el proveedor, la política de retención y el punto en el tiempo, por lo que trata cualquier cifra como documentada por el proveedor en lugar de una constante fija, y verifica contra fuentes oficiales o el uso de disco de tu propio nodo.

Ejecutar un nodo de archivo también requiere más CPU y memoria para manejar consultas sobre datos históricos. Debes asegurarte de que tu infraestructura cumpla con las especificaciones recomendadas, que están documentadas en la guía de Configuración de Nodo Completo de Sui.

• Establece checkpoint-pruning y object-pruning en false en la configuración de tu nodo.
• Monitorea el uso del disco regularmente; los nodos de archivo crecen continuamente.
• Considera usar snapshots para arrancar tu nodo más rápido, pero ten en cuenta que los snapshots pueden no incluir el historial completo a menos que sean snapshots de archivo.
• Para opciones gestionadas, consulta el servicio API de OnFinality u otros proveedores que ofrezcan nodos de archivo.

Consultar el estado histórico con @mysten/sui.js: un ejemplo ejecutable

El siguiente script de Node.js demuestra cómo consultar datos históricos usando el SDK oficial @mysten/sui.js. Se conecta a un endpoint RPC de Sui (reemplázalo con tu endpoint de archivo), obtiene un checkpoint por número de secuencia, recupera un objeto en una versión específica y consulta eventos en un rango de checkpoints.

Antes de ejecutar, instala el SDK: npm install @mysten/sui.js. El script asume que tienes un endpoint con capacidad de archivo. Si no tienes uno, puedes usar un endpoint público que admita datos de archivo (por ejemplo, de un proveedor que ofrezca acceso de archivo).

El script muestra los detalles del checkpoint, el contenido del objeto y los eventos. Este es un método reproducible para verificar que tu endpoint proporciona datos históricos.

// queryHistorical.js
import { SuiClient, getFullnodeUrl } from '@mysten/sui.js/client';

// Reemplaza con la URL de tu endpoint de archivo
const RPC_URL = 'https://your-archive-endpoint.example.com';
const client = new SuiClient({ url: RPC_URL });

async function main() {
  // 1. Obtener un checkpoint por número de secuencia (ej., 1000)
  const checkpointSeq = 1000;
  const checkpoint = await client.getCheckpoint({ id: checkpointSeq });
  console.log('Checkpoint:', checkpoint);

  // 2. Obtener un objeto en una versión específica (reemplaza con un ID de objeto y versión reales)
  const objectId = '0x...';
  const version = 1;
  try {
    const object = await client.getObject({
      id: objectId,
      options: { showContent: true },
      version: version
    });
    console.log('Objeto en versión', version, ':', object);
  } catch (e) {
    console.error('La consulta del objeto falló (puede estar podado):', e.message);
  }

  // 3. Consultar eventos en un rango de checkpoints (ej., de 1000 a 1010)
  const events = await client.queryEvents({
    query: { Checkpoint: { checkpoint: checkpointSeq } },
    limit: 10
  });
  console.log('Eventos:', events.data);
}

main().catch(console.error);

Salida esperada y verificación

Cuando ejecutes el script, deberías ver el objeto checkpoint impreso, que incluye campos como sequenceNumber, timestampMs, epoch y transactions. La consulta de objeto devolverá el contenido del objeto si la versión existe; si no, lanzará un error indicando que la versión del objeto no está disponible. La consulta de eventos devolverá una lista de eventos que ocurrieron en ese checkpoint.

Para verificar que tu endpoint es realmente un nodo de archivo, intenta consultar un checkpoint de hace mucho tiempo (por ejemplo, número de secuencia 1) y una versión de objeto que no sea la más reciente. Si estas consultas tienen éxito, tu endpoint tiene datos históricos. Si fallan con un error como Checkpoint not found o Object version not found, el endpoint es probablemente un nodo completo con historial limitado.

La forma exacta de la salida sigue el esquema JSON-RPC de Sui. Por ejemplo, un objeto checkpoint se ve así: { sequenceNumber: 1000, timestampMs: 1690000000000, epoch: 5, transactions: [...], ... }.

• Los números de secuencia de checkpoint son enteros; usa sui_getCheckpoint con el número de secuencia.
• Las versiones de objeto son enteros; usa sui_getObject con el parámetro version.
• Los eventos se devuelven como una matriz de objetos Event con campos id, type y data.

Fallos comunes y soluciones al consultar datos históricos

Al trabajar con RPC histórico, puedes encontrar errores debido a la poda o al uso incorrecto. Aquí hay problemas comunes y cómo resolverlos.

Error: 'Checkpoint not found' – Esto significa que el número de secuencia del checkpoint está más allá del horizonte de retención del nodo. Si estás usando un nodo completo, cambia a un endpoint de archivo. Si estás ejecutando tu propio nodo, asegúrate de que la poda esté deshabilitada.

Error: 'Object version not found' – Similar al anterior, el nodo puede no tener la versión histórica. Usa un nodo de archivo o consulta la última versión.

Error: 'Rate limit exceeded' – Las consultas históricas pueden ser pesadas. Verifica los límites de tasa de tu proveedor y considera agrupar solicitudes. Consulta Límites de tasa y unidades de cómputo de RPC de Sui para obtener orientación.

Error: 'Timeout' – Las consultas grandes pueden llevar tiempo. Aumenta el tiempo de espera de tu cliente o pagina los resultados. Consulta Tiempos de espera y reintentos de RPC de Sui.

• Siempre verifica la documentación del proveedor para conocer las políticas de retención.
• Usa sui_getCheckpoints para paginar a través de checkpoints si necesitas un rango.
• Para consultas de eventos, usa suix_queryEvents con un filtro de rango de checkpoints para evitar tiempos de espera.

Guía de decisión: RPC de nodo completo vs RPC de archivo

Elegir entre un nodo completo y un nodo de archivo depende de tu caso de uso. Si solo necesitas el estado actual, transacciones recientes o suscripciones en vivo, un nodo completo es suficiente y más rentable. Si necesitas analizar tendencias históricas, auditar el estado pasado o servir datos históricos a los usuarios, necesitas un nodo de archivo.

La tabla a continuación resume las compensaciones. Ten en cuenta que la disponibilidad y los costos específicos del proveedor varían; siempre verifica con tu proveedor.

• Usa RPC de nodo completo para: dApps en vivo, saldos de billeteras, actividad reciente y suscripciones de eventos.
• Usa RPC de archivo para: análisis históricos, backtesting, cumplimiento y servicios de datos.
• Costo: Los nodos de archivo son más caros debido al almacenamiento y cómputo. Los precios varían según el proveedor; consulta Precios de RPC para el modelo de OnFinality.
• Retención: Los nodos completos pueden retener solo los últimos checkpoints; los nodos de archivo retienen todos.

Próximos pasos y lecturas adicionales

Ahora que comprendes los nodos de archivo de Sui y el RPC histórico, puedes explorar temas más avanzados. Para la selección de endpoints, consulta la guía de RPC de Sui. Para optimizar tus consultas, lee sobre Latencia y rendimiento de RPC de Sui y Tiempos de espera y reintentos de RPC de Sui. Si estás construyendo en Sui, consulta la descripción general de la red Sui y el centro de aprendizaje de OnFinality para más tutoriales.

Para una inmersión más profunda en el modelo de datos de Sui, consulta la documentación oficial de Datos de Archivo de Sui y la guía de Configuración de Nodo Completo de Sui.

• Explora Límites de tasa y unidades de cómputo de RPC de Sui para gestionar tu uso.
• Considera usar el servicio API de OnFinality para nodos de archivo gestionados.
• Consulta la página de Precios de RPC para detalles de costos.