Sepolia Scan: leer datos de la testnet con exploradores y RPC

Qué recupera realmente un Sepolia scan

Sepolia es la testnet pública de prueba de participación de Ethereum. Un Sepolia scan es cualquier consulta de datos on-chain de la testnet: un hash de transacción, un número de bloque, el saldo de una dirección, una transferencia de tokens o el almacenamiento de un contrato. Los datos son idénticos ya sea que los veas en un explorador basado en navegador o los obtengas con una llamada RPC; ambos leen de nodos de Sepolia que han indexado o sincronizado la cadena.

La distinción importante es entre vistas indexadas y vistas de nodo sin procesar. Exploradores como Etherscan, Blockscout e interfaces estilo Arbiscan mantienen bases de datos que decodifican logs, etiquetan direcciones y agregan estadísticas. El RPC sin procesar devuelve los datos canónicos de la cadena: bloques, recibos, trazas y estado. Cuando un explorador y tu aplicación no coinciden, la respuesta RPC suele ser la fuente de verdad sobre lo que el nodo aceptó.

• Consulta de transacción: estado, gas usado, logs y motivo de reversión.
• Consulta de bloque: marca de tiempo, tarifa base, número de transacciones y validador.
• Consulta de dirección: saldo, nonce y bytecode del contrato.
• Consulta de tokens y logs: transferencias ERC-20 y decodificación de eventos.

Supuestos y requisitos previos

Esta guía asume que tienes una URL RPC de Sepolia de un proveedor o tu propio nodo, una dirección de billetera o un hash de transacción para inspeccionar, y familiaridad básica con JSON-RPC. No necesitas ETH de mainnet para escaneos de solo lectura, pero sí necesitas ETH de Sepolia para enviar transacciones de prueba. Los faucets distribuyen pequeñas cantidades y normalmente imponen límites diarios o requisitos de actividad en mainnet.

Si estás eligiendo un endpoint en lugar de ejecutar un nodo, la decisión concreta del proveedor corresponde al Asistente de RPC y no a este artículo. Para una comparación más amplia de opciones de endpoints, consulta la guía de API RPC de Ethereum y la guía de endpoints RPC multicadena.

En qué se diferencian los exploradores y RPC en lo que muestran

Un explorador es una capa de indexación. Escucha nuevos bloques, decodifica transacciones y logs, y almacena datos derivados como saldos de tokens y etiquetas de contratos. Eso lo hace rápido para humanos pero dependiente del estado de sincronización del indexador. Un endpoint RPC sin procesar responde desde la vista actual del nodo sobre la cadena, que puede retrasarse uno o dos bloques según el modo de sincronización del nodo.

Esto importa durante la depuración. Una transacción puede aparecer como pendiente en una billetera, confirmada en un explorador, y aún así devolver un recibo nulo desde un nodo RPC que todavía no ha importado el bloque. Siempre compara lo comparable: verifica el número de bloque en el explorador contra el número de bloque que reporta tu RPC antes de concluir que faltan datos.

• Explorador: decodificado, etiquetado y agregado; útil para humanos.
• RPC: canónico y programático; útil para automatización y verificación.
• Retraso del indexador: los exploradores pueden ir por detrás de la cabeza de la cadena por segundos.
• Retraso del nodo: tu RPC puede ir por detrás de la cabeza de la cadena si está poniéndose al día.

Escanear una transacción con curl

El Sepolia scan más directo es una consulta de recibo de transacción. Reemplaza RPC_URL con tu endpoint y TX_HASH con el hash que quieres inspeccionar. El recibo te indica si la transacción tuvo éxito, cuánto gas usó y qué logs emitió.

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

Verificar el resultado contra la cabeza de la cadena

Un recibo por sí solo no te dice si el nodo está actualizado. Obtén el número de bloque más reciente y compáralo con el número de bloque del recibo. Si el bloque del recibo está dentro de unos pocos bloques de la cabeza, el escaneo es reciente. Si la cabeza está muy por detrás de un explorador público, es probable que tu endpoint esté sincronizando o tenga límite de tasa.

Ejecuta la misma solicitud dos veces con un breve retraso y registra los números de bloque. Un endpoint saludable avanza su cabeza entre llamadas. Un endpoint estancado devuelve el mismo número de bloque repetidamente.

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

Un escaneo en JavaScript para actividad de direcciones

Para escaneos a nivel de dirección, necesitas el saldo, el nonce y el bytecode del contrato. El nonce es especialmente útil: te dice cuántas transacciones ha enviado la dirección, lo que ayuda a distinguir una transacción atascada de una nueva. El siguiente script usa fetch y funciona en Node.js 18 o posterior.

const RPC_URL = process.env.RPC_URL;
const ADDRESS = process.env.ADDRESS;

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    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;
}

const [balance, nonce, code] = await Promise.all([
  rpc('eth_getBalance', [ADDRESS, 'latest']),
  rpc('eth_getTransactionCount', [ADDRESS, 'latest']),
  rpc('eth_getCode', [ADDRESS, 'latest'])
]);

console.log({ balance, nonce, isContract: code !== '0x' });

Procedimiento de medición reproducible para la latencia de escaneo

Si quieres comparar endpoints en lugar de solo leer datos, mide el tiempo desde el envío de una transacción hasta ver un recibo confirmado. No inventes números; ejecuta el procedimiento y registra los tuyos. Usa una billetera nueva, un precio de gas fijo y la misma carga útil de transacción para cada endpoint.

Registra lo siguiente en una tabla: etiqueta del endpoint, marca de tiempo de envío, marca de tiempo de primera aparición como pendiente, marca de tiempo de confirmación, número de bloque y estado del recibo. Repite al menos diez veces por endpoint e informa la mediana y el máximo. Esto separa la varianza de la red del comportamiento del endpoint.

• Usa una billetera de prueba dedicada con una secuencia de nonce conocida.
• Envía cargas útiles idénticas de valor y datos a cada endpoint.
• Registra marcas de tiempo en UTC e incluye el número de bloque.
• Descarta las ejecuciones en las que la transacción fue reemplazada o descartada.

Solución de discrepancias comunes en Sepolia scan

La discrepancia más común es una transacción que aparece confirmada en un explorador pero devuelve nulo desde tu RPC. Esto generalmente significa que tu nodo aún no ha importado el bloque, o que consultaste una red diferente. Confirma el ID de cadena con eth_chainId y compáralo con la etiqueta de red del explorador.

Un segundo problema común es una transacción fallida sin motivo visible. Los recibos incluyen un campo de estado pero no siempre una cadena de reversión. Usa eth_call en el bloque fallido para reproducir la llamada y revelar el motivo de la reversión, o inspecciona la traza de la transacción si tu proveedor admite debug_traceTransaction.

• Recibo nulo: verifica el ID de cadena, el número de bloque y el estado de sincronización del nodo.
• Transacción revertida: reproduce con eth_call en el mismo bloque.
• Logs faltantes: confirma que la transacción realmente emitió eventos.
• Saldo incorrecto: recuerda que pending y latest son etiquetas diferentes.

Limitaciones del escaneo basado en exploradores

Los exploradores son convenientes pero no son autoritativos para la automatización. Pueden retrasarse, limitar la tasa o decodificar contratos de manera diferente a tu aplicación. Tampoco pueden responder preguntas sobre el estado pendiente ni simular llamadas futuras. Para flujos de trabajo en producción, trata al explorador como una ayuda de depuración y al RPC como la superficie de integración.

Sepolia en sí es una testnet. Su estado puede ser reiniciado o podado por los operadores, y la disponibilidad de faucets cambia. No construyas monitoreo que asuma que el historial de Sepolia es permanente. Para acceso a nodos de nivel producción, revisa opciones de nodos dedicados y precios de RPC antes de comprometerte con una arquitectura.

Próximos pasos para flujos de trabajo confiables en Sepolia

Una vez que puedas escanear una transacción y verificar la cabeza de la cadena, pasa a comprobaciones automatizadas: sondea recibos con retroceso exponencial, verifica el ID de cadena antes de cada escritura y registra los números de bloque junto con los resultados. Si necesitas una recomendación concreta de endpoint, usa el Asistente de RPC. Para contexto a nivel de red, explora las redes compatibles y la descripción general del servicio API.

• Añade aserciones de ID de cadena y número de bloque a tus scripts.
• Almacena en caché los recibos solo después de una profundidad de confirmación configurable.
• Dirige los escaneos con muchas lecturas a endpoints con límites de tasa suficientes.
• Mantén un endpoint de respaldo para fallos de escaneo.