¿Cómo monitoreo el uptime de un validador de Solana con un endpoint de API?

Solana no publica un único endpoint REST de "uptime de validador". Si buscaste uno, la respuesta práctica es que el uptime es una métrica derivada: se calcula consultando un pequeño conjunto de métodos JSON-RPC estándar contra un endpoint RPC de Solana y rastreando cómo cambia la actividad de voto y slots de un validador a lo largo del tiempo. Esta página cubre los métodos exactos, las formas de las solicitudes y el bucle de monitoreo que puedes ejecutar hoy.

Qué puedes y qué no puedes obtener de un endpoint

No existe un método getValidatorUptime. Lo que Solana expone es el estado bruto de la cadena que te permite inferir actividad:

• getVoteAccounts devuelve las cuentas de voto actuales y morosas, incluyendo lastVote, rootSlot y epochCredits.
• getSlot y getBlockHeight te indican cuánto ha progresado el clúster.
• getEpochInfo proporciona la época actual, el índice de slot y el rango de slots.
• getBlockProduction informa la producción de slots de líder por identidad.
• getClusterNodes devuelve los nodos visibles por gossip con sus versiones y características.

El uptime es lo que construyes sobre estos. Un validador que deja de votar, se queda atrás del slot del clúster o deja de aparecer en las cuentas de voto está efectivamente caído para fines de monitoreo, incluso si el proceso sigue en ejecución.

Guía de decisión: endpoint compartido o nodo dedicado para monitoreo

Antes de escribir código de sondeo, decide qué necesita tu bucle de monitoreo. El monitoreo de validadores es una carga de trabajo constante, de bajo volumen y siempre activa, y eso cambia qué tipo de endpoint encaja.

Si estás revisando un validador unas pocas veces al día, un endpoint compartido es razonable. Si ejecutas alertas que deben dispararse cuando un validador se vuelve moroso, un nodo dedicado elimina una clase de falsos positivos causados por la contención del endpoint compartido. OnFinality ofrece tanto acceso compartido a la API RPC como nodos dedicados de Solana, para que puedas comenzar con compartido y pasar a dedicado a medida que madura tu monitoreo.

Los métodos que realmente indican la actividad del validador

getVoteAccounts

Esta es la llamada principal. Devuelve dos arreglos: current (votando normalmente) y delinquent (sin votar). Cada entrada incluye la pubkey de la cuenta de voto, la identidad del nodo, activatedStake, lastVote, rootSlot y epochCredits.

curl -s https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getVoteAccounts",
    "params": [{"votePubkey": "YOUR_VOTE_ACCOUNT"}]
  }'

Si tu validador aparece en delinquent, ha dejado de votar. Si está ausente de ambos arreglos, la cuenta de voto puede ser nueva o la solicitud puede haber fallado, así que siempre verifica la forma de la respuesta antes de alertar.

getSlot y getEpochInfo

Compara el lastVote del validador con el slot actual. Una brecha creciente significa que el validador se está quedando atrás. getEpochInfo te da el índice de slot dentro de la época para que puedas normalizar la brecha.

curl -s https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getEpochInfo"}'

getBlockProduction

Esto devuelve la producción de slots de líder. Filtrar por identidad muestra cuántos slots se esperaba que produjera un validador y cuántos produjo realmente, lo cual es una señal secundaria útil junto con la actividad de voto.

Construyendo un bucle de sondeo en JavaScript

Un monitor mínimo consulta getVoteAccounts en un intervalo, registra lastVote y epochCredits, y marca un validador cuando los valores dejan de avanzar. El ejemplo a continuación usa el endpoint público de Solana de OnFinality y un enfoque de sondeo sin WebSocket para que funcione en cualquier lugar.

const RPC = "https://solana.api.onfinality.io/public";
const VOTE_ACCOUNT = "YOUR_VOTE_ACCOUNT";

async function rpc(method, params = []) {
  const res = await fetch(RPC, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

let lastSeenVote = null;
let stalledPolls = 0;

async function poll() {
  const { current, delinquent } = await rpc("getVoteAccounts", [
    { votePubkey: VOTE_ACCOUNT },
  ]);

  const entry = current.find((v) => v.votePubkey === VOTE_ACCOUNT);
  const isDelinquent = delinquent.some((v) => v.votePubkey === VOTE_ACCOUNT);

  if (isDelinquent) {
    console.warn("validator delinquent");
  }

  if (entry) {
    if (lastSeenVote !== null && entry.lastVote === lastSeenVote) {
      stalledPolls += 1;
    } else {
      stalledPolls = 0;
    }
    lastSeenVote = entry.lastVote;
    console.log({ lastVote: entry.lastVote, epochCredits: entry.epochCredits });
  }
}

setInterval(poll, 15000);

Dos detalles importan aquí. Primero, epochCredits es un arreglo de [epoch, credits, previousCredits]; el delta entre las dos últimas entradas es una señal de actividad más limpia que lastVote por sí solo. Segundo, sondea en un intervalo fijo que sea cómodamente más largo que un slot (aproximadamente 400 ms) para no perseguir ruido. Quince a treinta segundos es un valor predeterminado práctico.

Convirtiendo respuestas brutas en un número de uptime

El uptime es una proporción que tú defines. Un enfoque común:

1. Sondea cada N segundos y registra si el validador avanzó su voto o créditos.
2. Cuenta los avances exitosos como muestras "activo" y los estados estancados o morosos como muestras "caído".
3. Divide las muestras activas entre el total de muestras en una ventana móvil (por ejemplo, 24 horas).

Esto te da una cifra defendible que coincide con tu propia cadencia de monitoreo en lugar de un número externo que no puedes verificar. Documenta la cadencia y la ventana junto con el porcentaje, porque el mismo validador puede mostrar diferentes uptimes según con qué frecuencia muestrees.

La confiabilidad del endpoint es parte de la medición

Si tu endpoint RPC pierde solicitudes, tu monitor registra falsas caídas. Esa es la fuente más común de datos incorrectos de uptime de validadores. Protégete contra esto:

• Distingue fallos de transporte del estado de la cadena. Un timeout no es lo mismo que un validador moroso.
• Reintenta solicitudes fallidas antes de contar una muestra de caída.
• Usa un segundo endpoint como verificación cruzada para decisiones de alerta.
• Prefiere un endpoint con soporte de WebSocket si luego quieres suscripciones de slots en lugar de sondeo.

El endpoint de Solana de OnFinality admite transportes HTTP y WebSocket, por lo que puedes sondear con JSON-RPC ahora y agregar suscripciones después sin cambiar de proveedor. Consulta la página de la red Solana para detalles de conexión.

Configuración de la cadena y referencia de conexión

Para probar tu código de monitoreo antes de apuntarlo a mainnet, usa un endpoint de Solana Devnet para no contaminar las métricas de producción con datos de prueba.

Modos de fallo comunes y cómo interpretarlos

Puntos clave

• Solana no tiene un endpoint dedicado de uptime de validadores; el uptime se deriva de getVoteAccounts, getSlot, getEpochInfo y getBlockProduction.
• getVoteAccounts es la señal principal de actividad, con los deltas de epochCredits más confiables que lastVote por sí solo.
• Sondea en un intervalo fijo y define tu propia ventana de uptime para que el número sea reproducible.
• La confiabilidad del endpoint afecta directamente el uptime medido; los reintentos y un segundo endpoint reducen las falsas caídas.
• Un endpoint compartido sirve para comprobaciones ocasionales, mientras que un nodo dedicado sirve para alertas continuas.

Preguntas frecuentes

¿Existe una API directa de uptime de validadores de Solana?

No. Solana expone el estado de la cadena a través de JSON-RPC, y el uptime es una métrica que calculas a partir de la actividad de votos y slots a lo largo del tiempo.

¿Qué método es mejor para verificar si un validador está caído?

getVoteAccounts es el más directo. Un validador en el arreglo delinquent ha dejado de votar, que es la señal más clara de caída.

¿Con qué frecuencia debo sondear?

Cada 15 a 30 segundos es un valor predeterminado práctico. Sondear más rápido que un slot agrega ruido sin mejorar la precisión.

¿Puedo usar WebSockets en lugar de sondeo?

Sí. Las suscripciones de slot y root pueden reemplazar el sondeo, pero aún derivas el uptime de las mismas señales subyacentes. El endpoint de Solana de OnFinality admite transporte WebSocket.

¿Necesito un nodo dedicado para el monitoreo de validadores?

Solo si ejecutas alertas continuas o rastreas muchos validadores. Para comprobaciones ocasionales, un endpoint compartido suele ser suficiente. Compara opciones en la página de precios de RPC y la lista de redes RPC compatibles.