Nodo de Archivo de Ethereum y RPC Histórico: Consultando Saldos, Registros y Estado Pasados

Respuesta Directa: Lo Que Necesitas para Consultar Datos Históricos de Ethereum

Para consultar saldos, código, almacenamiento o registros históricos de Ethereum, necesitas un endpoint RPC respaldado por un nodo de archivo—o un nodo que exponga el historial de estado mediante los métodos debug/ots_ de Erigon. Un nodo completo estándar solo mantiene el estado más reciente y solo puede responder eth_getBalance en el último bloque. Los nodos de archivo retienen todo el estado histórico, permitiendo consultas como eth_getBalance en el bloque 1,000,000. Esta guía explica los mecanismos, te muestra cómo probar cualquier endpoint y proporciona un script reproducible.

• Nodo de archivo: almacena todo el historial de estado, permitiendo consultas en cualquier bloque pasado.
• Nodo completo: poda el estado histórico, solo sirve el estado más reciente.
• Etiquetas de bloque: 'latest', 'earliest', 'pending' o un número de bloque hexadecimal.
• Los nodos de archivo de Erigon también exponen métodos RPC de historial de estado (debug_ y ots_).

Nodo de Archivo de Ethereum vs Nodo Completo: Qué Datos se Conservan

Los clientes de ejecución de Ethereum (geth, Erigon, Nethermind, Besu) exponen la misma superficie JSON-RPC, pero los datos que pueden servir dependen del modo de sincronización del nodo. Un nodo completo (por defecto en geth) descarga y valida todos los bloques pero poda los nodos del trie de estado histórico, conservando solo el estado más reciente. Un nodo de archivo (geth --syncmode full --gcmode archive) retiene cada nodo del trie de estado, permitiendo consultas en cualquier bloque histórico.

El modo de archivo de Erigon es más granular: almacena el historial de estado como una serie de diferencias de estado, permitiendo no solo eth_getBalance en bloques antiguos sino también métodos especializados como debug_traceTransaction y ots_getTransactionOutput. La documentación de la Fundación Ethereum sobre nodos de archivo y la especificación JSON-RPC son las referencias principales del protocolo; los documentos de Erigon y tutoriales independientes (por ejemplo, la guía de Erigon de M. Hansson) proporcionan detalles orientados al lector.

• Nodo completo de geth: poda el estado, solo sirve el estado más reciente.
• Nodo de archivo de geth: conserva todo el estado, sirve cualquier bloque.
• Archivo de Erigon: almacena el historial de estado, soporta métodos adicionales debug/ots.
• El modo de archivo es una configuración de inicio, no un parámetro RPC.

Métodos RPC para Leer Datos Históricos

Los métodos JSON-RPC principales para consultas históricas son eth_getBlockByNumber, eth_getBalance, eth_getCode, eth_getStorageAt, eth_getTransactionCount, eth_getProof y eth_getLogs. Cada uno acepta un parámetro de bloque que puede ser un número de bloque, hash o etiqueta. Por ejemplo, eth_getBalance con la etiqueta de bloque '0x0' devuelve el saldo en el génesis. El conjunto de métodos y sus semánticas están documentados en la especificación JSON-RPC de Ethereum, y la profundidad de datos detrás de ellos se explica en la guía oficial de nodos de archivo de Ethereum.

eth_getProof (EIP-1186) devuelve el saldo de una cuenta, el hash del código, la raíz de almacenamiento y la prueba de Merkle en un bloque dado, útil para verificar el estado histórico. eth_getLogs filtra registros por dirección y temas en un rango de bloques, lo cual es esencial para indexar eventos históricos.

Los nodos de archivo de Erigon además exponen métodos debug_ y ots_ (por ejemplo, ots_getTransactionOutput, debug_traceBlockByNumber) que reconstruyen el estado o rastrean transacciones históricamente. Estos no forman parte del JSON-RPC estándar de Ethereum pero están documentados por Erigon.

• eth_getBlockByNumber: obtener el encabezado del bloque y las transacciones.
• eth_getBalance / eth_getCode / eth_getStorageAt / eth_getTransactionCount: leer el estado en un bloque.
• eth_getProof: obtener la prueba de Merkle en un bloque (EIP-1186).
• eth_getLogs: consultar registros en un rango de bloques.
• Erigon debug_/ots_: historial de estado y rastreo.

Detalle Clave: El Archivo es un Modo de Nodo, No un Parámetro RPC

Una idea errónea común es que puedes solicitar datos históricos de cualquier nodo especificando un número de bloque. En realidad, el nodo debe tener almacenado el estado histórico. Si llamas a eth_getBalance con un bloque antiguo en un nodo completo, devuelve un error como 'missing trie node' o 'historical state not available'. El modo de archivo se establece al iniciar el nodo; no puedes cambiarlo sobre la marcha.

Por lo tanto, al elegir un proveedor de RPC, debes verificar que el endpoint esté respaldado por un nodo de archivo. Proveedores como Chainstack, Infura, QuickNode y OnFinality ofrecen endpoints de archivo, pero la retención y disponibilidad varían. Siempre consulta la documentación del proveedor para conocer el soporte de archivo y el rango de bloques.

• Nodo completo: eth_getBalance en un bloque antiguo → error.
• Nodo de archivo: eth_getBalance en un bloque antiguo → valor correcto.
• Endpoints de archivo del proveedor: documentados, pero la retención varía.
• Siempre verifica con una consulta de prueba.

Ejemplo Ejecutable: Prueba tu Endpoint para Soporte de Archivo

El siguiente script de Node.js usa ethers v6 para (a) resolver un bloque histórico, (b) leer eth_getBalance en ese bloque y en el último, y (c) paginar eth_getLogs en una ventana acotada con retroceso. Reemplaza RPC_URL con tu endpoint. El script imprime resultados y un veredicto sobre si el endpoint sirve estado histórico.

Salida esperada: si el endpoint es de archivo, el saldo en el bloque 1,000,000 será un número (posiblemente 0), y el saldo más reciente diferirá. Si no es de archivo, la llamada histórica lanzará un error.

const { ethers } = require('ethers');

const RPC_URL = 'https://your-rpc-endpoint.example';
const provider = new ethers.JsonRpcProvider(RPC_URL);

async function testArchive() {
  const address = '0x0000000000000000000000000000000000000000'; // dirección cero
  const historicalBlock = 1000000; // bloque 1,000,000

  try {
    const historicalBalance = await provider.getBalance(address, historicalBlock);
    console.log(`Saldo en el bloque ${historicalBlock}: ${historicalBalance.toString()}`);
  } catch (e) {
    console.log('El saldo histórico falló:', e.message);
    console.log('El endpoint probablemente NO es de archivo.');
    return;
  }

  const latestBalance = await provider.getBalance(address, 'latest');
  console.log(`Saldo en el último bloque: ${latestBalance.toString()}`);

  // Ejemplo de paginación de eth_getLogs
  const filter = {
    address: '0x0000000000000000000000000000000000000000',
    fromBlock: 1000000,
    toBlock: 1000100
  };
  try {
    const logs = await provider.getLogs(filter);
    console.log(`Registros en el rango: ${logs.length}`);
  } catch (e) {
    console.log('getLogs falló:', e.message);
  }
}

testArchive();

Tabla de Resultados y Lista de Verificación de Archivo

Ejecuta el script contra tu endpoint y completa la tabla a continuación. La columna '¿Archivo?' debe ser 'Sí' si la llamada de saldo histórico tiene éxito, 'No' si lanza un error, y 'Desconocido' si el error es ambiguo (por ejemplo, límite de velocidad).

• URL del endpoint: ______
• Saldo histórico (bloque 1,000,000): ______
• Saldo más reciente: ______
• ¿La llamada histórica tuvo éxito? Sí/No
• ¿Se devolvieron registros? Sí/No
• ¿Archivo? Sí/No/Desconocido

Fallos Comunes y Soluciones

Al consultar datos históricos, puedes encontrar errores. Aquí hay algunos comunes y cómo solucionarlos.

El error 'missing trie node' o 'historical state not available' significa que el nodo no es de archivo. Cambia a un endpoint de archivo. El error 'block not found' puede significar que el número de bloque es inválido o que el nodo no está completamente sincronizado. El error 'rate limit exceeded' significa que alcanzaste el límite de velocidad del proveedor; implementa retroceso o usa un plan de nivel superior.

• Falta nodo trie → usa un endpoint de archivo.
• Bloque no encontrado → verifica el número de bloque y el estado de sincronización.
• Límite de velocidad → agrega reintentos con retroceso exponencial.
• Tiempo de espera de eth_getLogs → reduce el rango de bloques y pagina.

Compensaciones y Limitaciones

Los nodos de archivo requieren significativamente más espacio en disco y memoria que los nodos completos. Los tamaños exactos varían según el cliente y el tiempo; a partir de 2026, un nodo de archivo de Ethereum puede requerir varios terabytes, pero esto está documentado como 'varía según el proveedor' y cambia con el tiempo. Los proveedores a menudo cobran más por el acceso de archivo debido a los costos de infraestructura.

Las consultas históricas son más lentas que las consultas de estado más reciente porque requieren recorrer tries de estado más antiguos. La latencia varía según el proveedor y las condiciones de red; no afirmamos números específicos. Además, eth_getLogs en rangos grandes puede ser intensivo en recursos; los proveedores pueden limitar el tamaño del rango o requerir paginación.

• Espacio en disco: los nodos de archivo necesitan más almacenamiento (varía según el proveedor).
• Costo: los endpoints de archivo suelen ser más caros.
• Rendimiento: las consultas históricas son más lentas.
• Límites del proveedor: los rangos de registros y los límites de velocidad varían.

Próximos Pasos y Lecturas Adicionales

Ahora que entiendes los nodos de archivo de Ethereum y el RPC histórico, explora guías relacionadas para profundizar tu conocimiento. Para detalles específicos de la red, consulta la página de la red Ethereum. Para técnicas generales de datos históricos, lee el recetario de datos históricos de EVM y la comparación entre nodo de archivo y nodo completo.

Si estás eligiendo un proveedor de RPC, revisa tipos de nodos RPC de Ethereum y precios de RPC. Para consideraciones de rendimiento, consulta la guía de latencia de RPC de Ethereum y límites de velocidad y errores 429. Finalmente, explora el servicio de API para endpoints gestionados.

• Página de la red Ethereum
• Centro de aprendizaje de OnFinality
• Precios de RPC
• Servicio de API
• Tipos de nodos RPC de Ethereum (Asistente de RPC)
• Consultando datos históricos de blockchain (recetario EVM)
• Nodo de archivo vs nodo completo
• Guía de latencia de RPC de Ethereum
• Límites de velocidad de RPC de Ethereum y errores 429