Requisitos, almacenamiento y configuración RPC de un nodo completo de Aptos

Panorama de roles de nodo en Aptos: validador, nodo completo y nodo completo que sirve API

Un nodo de Aptos puede ejecutarse en varias configuraciones, y los requisitos difieren drásticamente entre ellas. Un nodo validador participa en el consenso, lo que significa que debe gestionar claves de identidad, cumplir reglas de elegibilidad de la comunidad y del stake, y mantener un tiempo de actividad estricto. Un nodo completo sincroniza el ledger y puede servir la API REST, pero no vota sobre bloques. La documentación de Aptos sobre tipos de nodo separa estos roles con claridad, y la distinción importa porque la mayoría de los equipos de infraestructura no necesitan un validador.

La configuración que la mayoría de los equipos realmente quiere es un nodo completo ejecutando la API REST/JSON-RPC. Este nodo responde consultas de cuentas, bloques, transacciones y eventos por HTTP. La documentación del nodo completo de Aptos describe la ruta de configuración, y la documentación de las API de Aptos describe la superficie REST que expone el nodo. Si tu objetivo es servir tráfico de lectura para una dapp, un indexador o una billetera, estás dimensionando un nodo completo, no un validador.

• Validador: participación en consenso, claves de identidad, elegibilidad de stake, tiempo de actividad estricto.
• Nodo completo: sincroniza el ledger, sirve la API REST, no vota.
• Nodo completo que sirve API: la configuración que necesitan la mayoría de los equipos con cargas de lectura intensiva.
• RPC gestionado: una alternativa cuando la sobrecarga del autohospedaje supera el control.

Cuatro dimensiones de recursos que deciden el dimensionamiento de un nodo Aptos

La ejecución de Aptos y su motor de ejecución paralela están limitados por CPU, por lo que el número de núcleos y la velocidad de un solo hilo impulsan tanto el progreso de sincronización como la latencia de consulta. La RAM debe contener el estado en memoria y las estructuras de índices; si no caben, el nodo recurre al swap y se retrasa respecto a la cabeza de la cadena. El almacenamiento debe acomodar el ledger más el snapshot de estado, que crecen continuamente y requieren NVMe rápido con alta resistencia. El rendimiento de red importa tanto para la sincronización como para el tráfico de API, por lo que el ancho de banda y el peering de baja latencia con la red forman parte de la ecuación de dimensionamiento.

La documentación oficial de Aptos publica una tabla de hardware que debe tratarse como una línea base móvil. Se desplaza hacia arriba con la carga de la red y los cambios de versión, así que siempre reconcilia tu plan con los documentos actuales en lugar de una copia en caché. Para una comparación más amplia de cómo estas dimensiones se asignan a otras cadenas, consulta Requisitos de nodo RPC de Solana y dimensionamiento de hardware.

• CPU: número de núcleos y velocidad de un solo hilo para ejecución y latencia de consulta.
• RAM: debe contener el estado en memoria y los índices para evitar el swap.
• Almacenamiento: NVMe rápido con alta resistencia; el archivo de snapshots multiplica la capacidad.
• Red: rendimiento y peering de baja latencia para sincronización y tráfico de API.

Línea base de hardware mínima documentada vs recomendada

La documentación de Aptos presenta la guía de hardware como niveles mínimo y recomendado. El nivel mínimo es un piso para la operación básica, mientras que el nivel recomendado apunta a tráfico RPC de producción y una sincronización más rápida. Debido a que la red crece, el nivel recomendado es un objetivo móvil. Trata la tabla publicada como una línea base a verificar, no como una especificación permanente.

Al planificar la capacidad, mide tu propio nodo contra los valores documentados actuales. La siguiente tabla es una plantilla que puedes completar con tus valores medidos y los valores mínimo y recomendado documentados en los documentos actuales de Aptos. Esto mantiene tu decisión de dimensionamiento reproducible y auditable.

• Mínimo: operación básica, sincronización más lenta, no ideal para RPC de producción.
• Recomendado: RPC de producción, sincronización más rápida, mayor margen.
• Línea base móvil: reconcilia con los documentos actuales de Aptos por versión.
• Mide tu nodo: CPU, RAM, IOPS de almacenamiento, rendimiento de red.

Estrategia de sincronización: snapshot de estado vs arranque desde génesis

Los nodos completos de Aptos pueden arrancar desde un snapshot de estado, lo que es mucho más rápido que sincronizar desde génesis. El compromiso es la confianza: un snapshot debe obtenerse de una fuente en la que confíes, y su frescura determina cuánta sincronización adicional queda. La sincronización desde génesis es lenta pero verifica todo el historial de la cadena desde el inicio. La documentación del nodo completo de Aptos describe ambas rutas.

Para RPC de producción, la sincronización por snapshot suele ser la opción pragmática porque lleva el nodo a un estado reciente rápidamente. Sin embargo, si tu caso de uso requiere verificación histórica o datos a nivel de archivo, revisa Nodo de archivo vs nodo completo y Acceso a datos históricos de blockchain antes de comprometerte con una estrategia de sincronización.

• Sincronización por snapshot: rápida, requiere fuente confiable, puede necesitar sincronización adicional.
• Sincronización desde génesis: lenta, verifica todo el historial, alto costo de tiempo.
• Necesidades de archivo: considera patrones de nodo de archivo para consultas históricas.
• Frescura: verifica la antigüedad del snapshot antes de iniciar la sincronización.

Exponer y verificar la API REST de Aptos

El nodo sirve la API REST en su puerto HTTP. Antes de enrutar tráfico, confirma que responde a endpoints estándar: una llamada de node-info o ledger-info, una consulta de cuenta y una consulta de bloque por altura. La documentación de las API de Aptos enumera los endpoints disponibles, aunque la superficie exacta varía según la versión y configuración del nodo.

La verificación debe ser scriptada para que sea repetible. El siguiente ejemplo de curl sondea la API REST de un nodo Aptos en ejecución para obtener información del ledger, un recurso de cuenta y un bloque por altura. Reemplaza la URL base con el endpoint HTTP de tu nodo.

#!/usr/bin/env bash
# Probe an Aptos full node REST API
BASE_URL="http://localhost:8080"

# 1. Ledger info: synced version and chain id
curl -s "$BASE_URL/v1" | jq '{chain_id, ledger_version, ledger_timestamp}'

# 2. Account resource (replace with a known account address)
curl -s "$BASE_URL/v1/accounts/0x1/resource/0x1::account::Account" | jq .

# 3. Block by height (replace with a recent height)
curl -s "$BASE_URL/v1/blocks/by_height/1000000?with_transactions=false" | jq '{block_height, block_hash}'

Sonda Node.js ejecutable para la salud de la API REST de Aptos

Una sonda Node.js puede integrarse en el monitoreo. El siguiente ejemplo obtiene información del ledger, un recurso de cuenta y un bloque por altura, luego imprime la versión sincronizada, el id de cadena y si la API respondió. Utiliza la API fetch integrada disponible en Node.js moderno.

Ejecuta esto contra el endpoint HTTP de tu nodo. Si alguna llamada falla, el nodo puede seguir sincronizando, el endpoint puede estar mal configurado o la superficie de la API puede diferir según la versión. Usa la salida para decidir si enrutar tráfico.

// aptos-probe.js
const BASE_URL = process.env.APTOS_NODE_URL || 'http://localhost:8080';

async function probe() {
  const results = {};
  try {
    const ledgerRes = await fetch(`${BASE_URL}/v1`);
    const ledger = await ledgerRes.json();
    results.chainId = ledger.chain_id;
    results.syncedVersion = ledger.ledger_version;
    results.ledgerTimestamp = ledger.ledger_timestamp;
  } catch (e) {
    results.ledgerError = e.message;
  }

  try {
    const accountRes = await fetch(`${BASE_URL}/v1/accounts/0x1/resource/0x1::account::Account`);
    results.accountStatus = accountRes.status;
  } catch (e) {
    results.accountError = e.message;
  }

  try {
    const blockRes = await fetch(`${BASE_URL}/v1/blocks/by_height/1000000?with_transactions=false`);
    results.blockStatus = blockRes.status;
  } catch (e) {
    results.blockError = e.message;
  }

  console.log(JSON.stringify(results, null, 2));
  const answered = results.chainId !== undefined && results.accountStatus === 200;
  console.log(`API answered: ${answered}`);
}

probe();

Tabla de resultados reproducible para dimensionamiento de nodo y sondas de API

Usa las siguientes tablas para registrar tus mediciones y compararlas con los valores documentados. La primera tabla cubre dimensiones de recursos; la segunda cubre sondas de API. Complétalas con tus propias observaciones para crear un registro reproducible.

Para la tabla de dimensionamiento, mide núcleos de CPU, RAM, IOPS de almacenamiento y rendimiento de red en tu nodo. Compara con los valores mínimo y recomendado de la documentación actual de Aptos. La columna de veredicto debe indicar si tu nodo cumple, supera o no alcanza la línea base. La columna de acción debe registrar el siguiente paso, como actualizar el almacenamiento o agregar RAM.

• Dimensión: CPU, RAM, almacenamiento, red.
• Valor medido: tu métrica observada.
• Mínimo documentado: de los documentos actuales de Aptos.
• Recomendado documentado: de los documentos actuales de Aptos.
• Veredicto: cumple, supera o no alcanza.
• Acción: actualizar, monitorear o aceptar.

Plantilla de tabla de resultados de sondas de API

La tabla de sondas de API te ayuda a verificar que el nodo está sirviendo los endpoints esperados. Registra el endpoint, la respuesta esperada, la respuesta observada y cualquier nota. Esto es útil al comparar versiones o configuraciones de nodo.

Por ejemplo, el endpoint de ledger-info debe devolver un chain_id y un ledger_version. El endpoint de recurso de cuenta debe devolver un estado 200 para una cuenta conocida. El endpoint de bloque por altura debe devolver un bloque para una altura reciente. Si algún endpoint falla, anota el error y revisa los registros del nodo.

• Endpoint: /v1, /v1/accounts/{address}/resource/{resource}, /v1/blocks/by_height/{height}.
• Esperado: chain_id, ledger_version, estado 200, datos del bloque.
• Observado: tu respuesta real.
• Notas: diferencias de versión, estado de sincronización, configuración.

Limitaciones y compromisos del autohospedaje de un nodo completo de Aptos

La guía de hardware de Aptos cambia por versión, así que siempre reconcilia con los documentos actuales. Una sincronización desde génesis toma mucho tiempo, mientras que una sincronización por snapshot es más rápida pero debe ser confiable desde su fuente. La superficie de la API REST y los endpoints disponibles varían según la versión y configuración del nodo, por lo que lo que funciona en un nodo puede no funcionar en otro.

Los proveedores RPC gestionados siguen siendo más rentables que el autohospedaje para muchos equipos con cargas de lectura intensiva. Si tu carga de trabajo es principalmente de lectura, compara el costo total de propiedad con Precios de RPC y la página de Endpoints RPC de Aptos (RPC Assistant). El autohospedaje aún requiere actualizaciones continuas, monitoreo de disco y endurecimiento de la API. Para equipos que necesitan control sobre la localidad de los datos o indexación personalizada, el autohospedaje puede seguir justificándose.

• La guía de hardware cambia por versión; verifica con los documentos actuales.
• Confianza en la sincronización por snapshot: la fuente debe ser reputada.
• La superficie de la API varía según versión y configuración.
• El RPC gestionado suele ser más rentable para cargas de lectura intensiva.
• El autohospedaje requiere actualizaciones, monitoreo de disco y endurecimiento de la API.

Solución de problemas comunes de un nodo completo de Aptos

Si el nodo no está sincronizando, revisa primero el espacio en disco. El ledger y el snapshot de estado crecen continuamente, y un disco lleno detendrá la sincronización. Luego, verifica la conectividad de red y el número de pares. Si el nodo está sincronizando pero la API REST no responde, confirma que el puerto HTTP esté abierto y que el servicio de API esté habilitado en la configuración del nodo.

Si las llamadas a la API devuelven errores, revisa la versión del nodo y la ruta del endpoint. Algunos endpoints pueden estar obsoletos o renombrados. Si el nodo está detrás de la cabeza de la cadena, el ledger_version se retrasará. Usa los scripts de sonda anteriores para identificar qué componente está fallando. Para patrones de infraestructura más amplios, consulta el centro de aprendizaje de OnFinality y la descripción general del servicio de API.

• Disco lleno: amplía el almacenamiento o poda si es compatible.
• Sin pares: revisa la red y las reglas del firewall.
• API sin respuesta: verifica el puerto HTTP y la configuración del servicio.
• Desajuste de versión: revisa las rutas de los endpoints con los documentos actuales.
• ledger_version retrasado: el nodo sigue sincronizando o tiene recursos insuficientes.

Próximos pasos: del nodo local al RPC de producción

Una vez que tu nodo esté sincronizado y la API REST verificada, puedes enrutar tráfico hacia él. Para producción, considera el balanceo de carga entre múltiples nodos, el monitoreo de disco y CPU, y la automatización de actualizaciones. Si prefieres evitar la sobrecarga operativa, evalúa proveedores RPC gestionados. La página de Endpoints RPC de Aptos (RPC Assistant) enumera opciones de proveedores, y Precios de RPC ayuda a comparar costos.

Para equipos que construyen sobre Aptos, la página de la red Aptos proporciona una descripción general de la red y los servicios disponibles. Si también ejecutas otras cadenas, la guía de Configuración del endpoint RPC de un nodo completo de Sui sigue un patrón similar. Mantén siempre actualizado el software de tu nodo y vuelve a medir contra la documentación actual de Aptos.

• Enruta tráfico después de verificar la salud de la API.
• Balancea la carga entre múltiples nodos para producción.
• Monitorea disco, CPU y red continuamente.
• Automatiza las actualizaciones para coincidir con las versiones de la red.
• Compara los costos de RPC gestionado con el autohospedaje.