Cómo obtener el número de bloque actual desde un RPC de EVM o Solana

Qué representa el número de bloque y por qué importa

Un número de bloque es un entero que aumenta monotónicamente e identifica la posición de un bloque en una cadena. En redes EVM el bloque génesis es el bloque 0, y cada bloque posterior incrementa el número en uno. Por lo tanto, el número de bloque más reciente es un proxy de cuánto ha avanzado la cadena y de cuán actual es tu vista del RPC.

Las aplicaciones usan el número de bloque para muchas cosas: fijar una consulta a un estado consistente con eth_call en un bloque específico, decidir si una transacción ha sido incluida, calcular la profundidad de confirmación o detectar que un indexador se ha quedado atrás. Como el número es barato de obtener, también es la verificación de estado estándar para una conexión RPC.

El matiz importante es que "número de bloque más reciente" no es una única verdad global en un instante dado. Los diferentes nodos se enteran de los nuevos bloques en momentos ligeramente distintos, y los endpoints con balanceo de carga pueden enrutar solicitudes consecutivas a backends diferentes. Trata el valor como una observación muestreada, no como un reloj exacto.

• EVM: eth_blockNumber devuelve la altura del último bloque como una cantidad hexadecimal.
• Solana: getSlot devuelve el slot actual; getBlockHeight devuelve la altura del último bloque confirmado.
• Otras cadenas: los nombres de los métodos varían, pero el concepto es una altura de cabeza o número de slot.

Requisitos previos y suposiciones

Necesitas una URL de RPC HTTP o WebSocket para la red que estás consultando. Esta guía usa el marcador de posición RPC_URL; sustituye el endpoint que se te haya asignado. Para un endpoint gestionado, consulta el servicio API de OnFinality y la lista de redes compatibles.

Los ejemplos asumen una interfaz JSON-RPC accesible por HTTPS. Los ejemplos de EVM usan métodos estándar de Ethereum JSON-RPC, que están implementados por la mayoría de las cadenas compatibles con EVM. Los ejemplos de Solana usan su API JSON-RPC. No se requiere una clave privada para leer un número de bloque; estos son métodos de lectura públicos.

Si estás eligiendo entre proveedores en lugar de escribir código, la recomendación concreta de endpoint corresponde a RPC Assistant. Este artículo se centra en el método, el procedimiento de verificación y los modos de fallo.

Obtener el número de bloque en cadenas EVM con curl

La llamada EVM más sencilla es eth_blockNumber. No toma parámetros y devuelve una cantidad codificada en hexadecimal. El siguiente comando es ejecutable una vez que reemplazas RPC_URL:

• Una respuesta exitosa se ve como {"jsonrpc":"2.0","id":1,"result":"0x..."}.
• El campo result es una cadena hexadecimal; conviértelo a decimal antes de compararlo o almacenarlo.
• Un objeto error en lugar de result generalmente significa que el método no es compatible o que la solicitud estaba mal formada.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Obtener el número de bloque en JavaScript y Python

En el código de la aplicación normalmente envolverás la llamada en un pequeño helper. El ejemplo de JavaScript a continuación usa el fetch integrado disponible en Node.js moderno y navegadores, y convierte el resultado hexadecimal a un número:

const RPC_URL = process.env.RPC_URL;

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

getBlockNumber().then(console.log).catch(console.error);

Obtener el número de bloque en Solana

Solana no usa eth_blockNumber. Los equivalentes más cercanos son getSlot, que devuelve el slot actual que el nodo está procesando, y getBlockHeight, que devuelve la altura del último bloque confirmado. Los slots y las alturas de bloque están relacionados pero no son idénticos: los slots pueden omitirse, por lo que la altura de bloque avanza más lentamente que el número de slot.

Usa getSlot cuando necesites la posición actual del clúster, y getBlockHeight cuando necesites una altura confirmada adecuada para indexación o lógica de confirmación. La llamada curl a continuación usa getSlot:

• El parámetro commitment controla qué estado del clúster observas; confirmed y finalized se comportan de manera diferente en condiciones de bifurcación.
• getBlockHeight acepta las mismas opciones de commitment y devuelve un número en lugar de un slot.
• No compares directamente un slot de Solana con un número de bloque de EVM; son unidades diferentes.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[{"commitment":"confirmed"}]}'

Verificar que el número de bloque esté actualizado

Un número devuelto solo es útil si está actualizado. La forma fiable de comprobar la frescura es muestrear el mismo endpoint dos veces con un intervalo conocido y comparar la diferencia con el tiempo de bloque esperado de la cadena. El procedimiento a continuación produce una tabla de resultados que puedes completar con tus propias observaciones; no asumas ningún valor de antemano.

Ejecuta el script de muestreo contra cada endpoint que estés evaluando, al mismo tiempo, durante la misma duración. Registra el primer número de bloque, el último número de bloque, los segundos transcurridos y la tasa calculada de bloques por segundo. Luego compara esa tasa con el tiempo de bloque objetivo documentado de la red. Una gran deficiencia indica un nodo retrasado o un endpoint limitado.

• | Endpoint | Primer bloque | Último bloque | Transcurrido (s) | Bloques/s | Notas |
• |----------|-------------|------------|-------------|----------|-------|
• | RPC_URL A | | | | | |
• | RPC_URL B | | | | | |

import os, time, requests

RPC_URL = os.environ["RPC_URL"]
INTERVAL = 5
SAMPLES = 12

def block_number():
    p = {"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}
    r = requests.post(RPC_URL, json=p, timeout=10).json()
    return int(r["result"], 16)

first = block_number()
start = time.time()
for _ in range(SAMPLES):
    time.sleep(INTERVAL)
    last = block_number()
elapsed = time.time() - start
print({"first": first, "last": last, "elapsed_s": round(elapsed, 1),
       "blocks_per_s": round((last - first) / elapsed, 3)})

Verificación cruzada de dos endpoints para consistencia

Un solo endpoint puede ser internamente consistente pero aún incorrecto en relación con el resto de la red. Para detectar esto, consulta dos endpoints independientes en una ventana corta y compara sus números de bloque. Una pequeña diferencia es un retraso de propagación normal; una diferencia grande o creciente sugiere que un endpoint está retrasado.

Para cadenas EVM, también puedes confirmar el número de bloque contra una cabecera de bloque: llama a eth_getBlockByNumber con la etiqueta latest y verifica que el campo number devuelto coincida con lo que reportó eth_blockNumber. Si no coinciden, el endpoint puede estar balanceando la carga entre backends a diferentes alturas.

• Compara el campo number en el objeto de bloque con el resultado de eth_blockNumber.
• Revisa el timestamp del bloque para estimar la antigüedad de la cabeza.
• Repite la comparación varias veces para ver si la brecha es estable o se está ampliando.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]}'

Solución de problemas de números de bloque obsoletos, faltantes o inconsistentes

Cuando el número de bloque parece incorrecto, revisa las causas en orden de probabilidad. La mayoría de los incidentes son problemas de configuración o de límite de velocidad, no problemas de la cadena.

Si eth_blockNumber devuelve un error, confirma el nombre del método y que el endpoint sea para la red correcta. Un método que funciona en Ethereum puede no existir en una cadena no EVM. Si la llamada tiene éxito pero el número nunca cambia, el endpoint puede estar sirviendo respuestas en caché o el nodo puede estar retrasado. Si el número salta una cantidad inesperada, puede que estés llegando a un balanceador de carga que enruta a diferentes backends, o que la cadena haya tenido un período de producción rápida de bloques.

• HTTP 429 o errores específicos del proveedor por límite de velocidad: reduce la velocidad de las solicitudes o usa un endpoint dedicado.
• Tiempos de espera: agrega tiempos de espera explícitos en el cliente y reintentos con retroceso exponencial.
• Errores de análisis hexadecimal: asegúrate de convertir con base 16, no base 10.
• Confusión entre slot y altura de bloque en Solana: elige el método que coincida con tu semántica de confirmación.
• Suscripciones WebSocket: una conexión caída puede dejarte con un número en caché obsoleto; vuelve a suscribirte y a obtener el número al reconectar.

Limitaciones y compensaciones de las comprobaciones del número de bloque

El número de bloque es una señal de salud gruesa. Te dice que la cadena está avanzando, pero no que el endpoint sea correcto, completo o rápido para otros métodos. Un nodo puede reportar un número de bloque actual mientras falla eth_call o devuelve un estado inconsistente para consultas de archivo.

La frecuencia de muestreo también es una compensación. Consultar cada segundo da una resolución más fina pero consume presupuesto de límite de velocidad y puede distorsionar las mediciones en endpoints restringidos. Para monitoreo en producción, un intervalo moderado combinado con alertas por retraso sostenido suele ser más útil que el sondeo de alta frecuencia.

Por último, los números de bloque son específicos de cada cadena. Un número válido en una red no significa nada en otra, así que siempre empareja el valor con el identificador de red y el método usado para obtenerlo.

Próximos pasos para uso en producción

Una vez que puedas leer y verificar un número de bloque, el siguiente paso es integrarlo en las comprobaciones de estado y la lógica de indexación de tu aplicación. Almacena el número de bloque junto con cualquier estado que persistas, para que puedas detectar brechas y reorganizaciones más adelante. Para cargas de trabajo que necesitan acceso consistente a la cabeza de la cadena, considera un nodo dedicado en lugar de endpoints públicos compartidos.

Si estás comparando proveedores o necesitas un endpoint concreto para una red específica, usa RPC Assistant para la recomendación breve y conserva este artículo como la metodología de verificación. Para planificación de capacidad y costos, revisa los precios de RPC y la guía más amplia de endpoints RPC.

• Registra los números de bloque con marcas de tiempo para construir una línea base de retraso.
• Alerta cuando la tasa observada caiga por debajo de un umbral que derives de tus propias mediciones.
• Vuelve a verificar después de cualquier cambio de proveedor o de red.