Cómo consultar datos históricos de blockchain a través de RPC

La respuesta corta: nodos completos vs de archivo vs de rastreo

Cuando necesitas datos históricos de blockchain a través de RPC, la primera decisión es qué tipo de nodo usar. Un nodo completo almacena cada bloque y transacción, pero solo el estado más reciente (saldos de cuentas, almacenamiento de contratos). Un nodo de archivo almacena todas las instantáneas de estado históricas, lo que permite consultas como "¿cuál era el saldo de esta dirección en el bloque 10,000,000?". Un nodo de rastreo además almacena los rastros de ejecución, lo que permite la reproducción profunda de transacciones y los cambios de estado. Para la mayoría de las consultas históricas, necesitas un nodo de archivo; para datos de bloques y registros, un nodo completo es suficiente.

Esta distinción es crítica porque los métodos RPC como eth_getBalance y eth_call aceptan un parámetro de bloque. En un nodo completo, pasar un bloque pasado devuelve un error o datos incorrectos porque el estado se ha podado. En un nodo de archivo, la misma llamada devuelve el valor histórico exacto. Consulta nuestra guía de nodos de archivo vs nodos completos para una explicación más detallada.

• Nodo completo: almacena todos los bloques, transacciones, recibos y solo el estado más reciente.
• Nodo de archivo: almacena todas las instantáneas de estado históricas, lo que permite consultas de estado en cualquier bloque.
• Nodo de rastreo: almacena rastros de ejecución, lo que permite la reproducción y el análisis profundo (por ejemplo, el módulo de rastreo de Parity).

Entendiendo la poda de nodos y la disponibilidad del estado

Los clientes de Ethereum como Geth y Nethermind podan el estado histórico por defecto. Solo mantienen el trie de estado más reciente y un conjunto limitado de estados recientes (por ejemplo, 128 bloques). Esto significa que eth_getBalance con un parámetro de bloque pasado fallará en un nodo completo. El error exacto varía: Geth devuelve "missing trie node" o "header not found", mientras que Nethermind puede devolver "Cannot read state at block ...".

Los nodos de archivo desactivan la poda, almacenando cada instantánea de estado. Esto requiere significativamente más espacio en disco: cientos de gigabytes a terabytes. Por ejemplo, los nodos de archivo de Ethereum pueden superar los 2 TB a partir de 2026. Proveedores como el servicio RPC de OnFinality ofrecen endpoints de archivo para Ethereum y otras redes, para que no tengas que ejecutar el tuyo propio.

Cuando consultas un endpoint RPC público, no sabes si es de archivo o completo. Siempre revisa la documentación o prueba con un estado histórico conocido. Por ejemplo, consulta el saldo de una dirección conocida en un bloque antiguo y compáralo con un explorador de bloques.

curl -X POST https://eth-mainnet.public.blastapi.io -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x742d35Cc6634C0532925a3b844Bc454e4438f44e", "0x5F5E100"],"id":1}'

Consultando bloques y transacciones históricas

Los datos de bloques y transacciones históricas están disponibles en cualquier nodo completo. eth_getBlockByNumber devuelve el encabezado del bloque, las transacciones y, opcionalmente, los objetos de transacción completos. eth_getTransactionByHash y eth_getTransactionReceipt funcionan para cualquier transacción pasada. Estos métodos no requieren estado de archivo.

Por ejemplo, para obtener el bloque 15,000,000 (0xE4E1C0) con transacciones completas:

Esto es útil para auditorías, análisis y aplicaciones de sincronización. Sin embargo, para escaneos a gran escala (por ejemplo, todas las transferencias de un token), usar eth_getLogs es más eficiente que iterar sobre bloques.

curl -X POST https://eth-mainnet.public.blastapi.io -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xE4E1C0", true],"id":1}'

Consultando el estado histórico: eth_call, eth_getBalance, eth_getCode, eth_getStorageAt

Para consultar el estado en un bloque pasado, necesitas un nodo de archivo. Los métodos clave son:

• eth_getBalance(address, block) – saldo en un bloque dado.

• eth_getCode(address, block) – código de bytes del contrato en un bloque dado.

• eth_getStorageAt(address, slot, block) – valor de almacenamiento en un slot dado.

• eth_call({to, data}, block) – simula una llamada en un bloque pasado, útil para lecturas históricas de contratos.

Estos métodos aceptan un parámetro de bloque como número hexadecimal, etiqueta ("latest", "earliest", "pending") o hash de bloque. En un nodo de archivo, devuelven el valor histórico exacto.

Ejemplo: Obtén el saldo de la billetera de la Fundación Ethereum en el bloque 10,000,000 (0x989680):

Si obtienes un error como "missing trie node", el nodo no es de archivo. Necesitas cambiar a un endpoint de archivo. OnFinality proporciona endpoints de archivo para Ethereum y otras redes; consulta nuestra página de red de Ethereum para más detalles.

curl -X POST https://eth-mainnet.public.blastapi.io -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae", "0x989680"],"id":1}'

Usando eth_getLogs para datos de eventos históricos

eth_getLogs es el caballo de batalla para consultar registros de eventos históricos (por ejemplo, transferencias de tokens, operaciones DEX). Funciona en nodos completos porque los registros se almacenan en los recibos, que se conservan indefinidamente. Puedes filtrar por dirección, temas y rango de bloques.

Ejemplo: Obtén todos los eventos de Transferencia de USDT (contrato 0xdAC17F958D2ee523a2206206994597C13D831ec7) desde el bloque 15,000,000 hasta 15,000,100:

Ten en cuenta que eth_getLogs tiene limitaciones: la mayoría de los proveedores limitan el rango de bloques (por ejemplo, 10,000 bloques) y el tamaño de la respuesta. Para escaneos históricos grandes, usa un indexador como The Graph o un servicio de datos dedicado. Consulta nuestra guía de endpoints RPC multicadena para opciones de proveedores.

curl -X POST https://eth-mainnet.public.blastapi.io -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"fromBlock":"0xE4E1C0","toBlock":"0xE4E1C4","address":"0xdAC17F958D2ee523a2206206994597C13D831ec7","topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}],"id":1}'

APIs de rastreo para análisis histórico profundo

Para la reproducción a nivel de transacción, cambios de estado y llamadas internas, necesitas un nodo de rastreo con el módulo trace_ (Parity/OpenEthereum) o el módulo debug_ (Geth). Estos no son métodos JSON-RPC estándar, pero están disponibles en algunos proveedores.

Ejemplo: trace_replayTransaction devuelve todas las subllamadas y cambios de estado para una transacción. Esto es útil para reconstruir cambios de estado históricos, pero es computacionalmente costoso y a menudo limitado por tasa.

Los datos de rastreo son esenciales para indexadores y plataformas de análisis. Si necesitas esto, asegúrate de que tu proveedor de RPC admita métodos de rastreo. El servicio API de OnFinality ofrece endpoints de rastreo para redes compatibles.

curl -X POST https://rpc.trace.example.com -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"trace_replayTransaction","params":["0xhash", ["trace", "stateDiff"]],"id":1}'

Errores comunes y solución de problemas

Al consultar datos históricos, puedes encontrar errores específicos. Aquí tienes una lista de verificación:

• "missing trie node" o "header not found" – el nodo no es de archivo. Usa un endpoint de archivo.

• "block not found" – el número de bloque está fuera de rango o el nodo no está sincronizado.

• "execution reverted" – la llamada revirtió en ese bloque; verifica la lógica del contrato.

• "query returned more than 10000 results" – reduce el rango de bloques en eth_getLogs.

• "rate limit exceeded" – estás alcanzando los límites del proveedor; considera el procesamiento por lotes o usar un endpoint dedicado.

Para el rendimiento, usa las mejores prácticas de procesamiento por lotes JSON-RPC para combinar múltiples consultas en una sola solicitud.

• Siempre prueba con un valor histórico conocido para verificar el soporte de archivo.
• Usa números de bloque en lugar de marcas de tiempo para mayor precisión.
• Para escaneos grandes, usa un indexador o exporta datos a través de un servicio de datos.

Compensaciones: nodos completos vs de archivo vs indexadores

Elegir la herramienta adecuada depende de tu caso de uso:

• Nodo completo: más barato, bueno para el estado actual y la historia reciente, pero sin estado histórico.

• Nodo de archivo: costoso, requerido para consultas de estado histórico, pero limitado por los límites de tasa RPC y los límites de rango de bloques.

• Indexador (The Graph, SubQuery): mejor para consultas históricas a gran escala, pero requiere configuración y tiempo de indexación.

Para consultas históricas ocasionales, un endpoint RPC de archivo es suficiente. Para análisis de producción, considera un indexador. Consulta nuestra guía de alojamiento de nodos blockchain si quieres ejecutar tu propio nodo.

• Los nodos de archivo son de 10 a 100 veces más grandes que los nodos completos.
• Los proveedores de RPC a menudo cobran más por el acceso de archivo.
• Los indexadores proporcionan API GraphQL para consultas complejas.

Próximos pasos y lecturas adicionales

Ahora que entiendes cómo consultar datos históricos, puedes comenzar a construir. Para Ethereum, prueba con un endpoint de archivo público o usa el RPC de Ethereum de OnFinality. Para Polkadot, las consultas históricas funcionan de manera diferente; consulta nuestra página de red de Polkadot.

Si estás construyendo una aplicación que necesita datos históricos confiables, considera usar un servicio RPC administrado para evitar el mantenimiento de nodos. Consulta nuestros precios para planes de archivo.

Para más mejores prácticas de RPC, lee nuestra guía de endpoints RPC y monitoreo de endpoints RPC.