RPC Histórico de Nodo de Archivo de Base: Consultando Estado y Registros Pasados de Base

Respuesta Directa: Cómo Consultar el Estado y los Registros Históricos de Base

Para consultar el estado y los registros históricos de Base, necesitas un nodo de archivo o un proveedor de RPC que ofrezca datos de archivo. Base es un L2 optimista de OP-Stack, y su capa de ejecución (op-geth u op-reth) sirve JSON-RPC de Ethereum. Las lecturas históricas como eth_getBalance en un bloque antiguo, eth_call en un bloque pasado, eth_getLogs en un rango pasado y eth_getProof para pruebas de estado requieren que el cliente de ejecución haya retenido el estado para ese bloque. Un nodo completo (podado) solo mantiene el estado reciente, mientras que un nodo de archivo almacena todo el estado histórico. Esta guía explica la mecánica y proporciona un script para probar el soporte de archivo de cualquier endpoint RPC de Base.

Si buscas un endpoint de archivo administrado de Base, consulta la página de infraestructura de nodos de Base (Asistente de RPC). Para información general sobre nodos de archivo vs. completos, consulta Nodo de archivo vs. nodo completo.

• Base es un L2 de OP-Stack: op-node (consenso/derivación) + cliente de ejecución (op-geth/op-reth).
• La disponibilidad del estado histórico depende del modo del cliente de ejecución (completo vs. archivo) y de la disponibilidad de instantáneas.
• Métodos JSON-RPC clave: eth_getBlockByNumber, eth_getBalance, eth_call, eth_getCode, eth_getStorageAt, eth_getLogs, eth_getProof.

Cómo Funcionan los Nodos de Archivo de Base en OP-Stack

Base es un rollup optimista de OP-Stack. La red consiste en un op-node (el cliente de consenso que deriva bloques L2 de datos L1) y un cliente de ejecución (op-geth u op-reth) que almacena el estado L2 y sirve JSON-RPC de Ethereum. Cuando consultas un bloque histórico, el cliente de ejecución debe tener el trie de estado para ese bloque. Un nodo completo poda el estado más antiguo que una cierta ventana reciente (por ejemplo, 128 bloques para el valor predeterminado de op-geth), mientras que un nodo de archivo retiene todas las instantáneas de estado.

Base se lanzó en 2023, por lo que la profundidad de su cadena es modesta en comparación con Ethereum L1. Sin embargo, se aplica la misma mecánica de archivo. Para ejecutar un nodo de archivo, normalmente necesitas comenzar con una instantánea de archivo o sincronizar desde génesis con el modo de archivo habilitado. La configuración exacta varía según el cliente y la implementación; consulta la documentación del nodo de Base para obtener detalles.

Para una inmersión más profunda en la arquitectura de OP-Stack, consulta la documentación de OP-Stack.

• op-geth: usa --gcmode=archive para retener el estado completo.
• op-reth: usa --full (predeterminado) o --debug.tip? En realidad, reth usa --full para nodo completo y --archive para archivo? Consulta los documentos.
• Los proveedores de instantáneas ofrecen instantáneas de archivo; los tamaños varían según el proveedor y la fecha.

Métodos de Lectura Histórica en Base

La API JSON-RPC de Ethereum en Base admite métodos estándar para consultas históricas. Así es como funciona cada uno:

eth_getBlockByNumber con un número de bloque o etiqueta devuelve el encabezado del bloque y las transacciones. Para bloques históricos, esto funciona incluso en un nodo completo si el bloque está dentro del rango retenido, pero para bloques más antiguos necesitas archivo.

eth_getBalance, eth_call, eth_getCode, eth_getStorageAt aceptan un parámetro de bloque. En un nodo completo, solo funcionan para bloques recientes; en un nodo de archivo, funcionan para cualquier bloque histórico.

eth_getLogs filtra registros por dirección y temas en un rango de bloques. Esto requiere que el nodo tenga los registros para ese rango, lo que generalmente está disponible incluso en nodos completos para rangos recientes, pero para rangos más antiguos necesitas archivo.

eth_getProof (EIP-1186) devuelve las pruebas de cuenta y almacenamiento para una dirección y claves de almacenamiento dadas en un bloque específico. Esto es crucial para verificar afirmaciones de estado y para pruebas de retiro de OP-Stack. Requiere estado de archivo.

• Etiquetas de bloque: latest, earliest, pending o un número de bloque hexadecimal.
• Para eth_call, puedes simular una transacción en un bloque histórico.
• eth_getProof se usa para probar depósitos y retiros L1->L2.

Ejemplo Ejecutable: Probando el Soporte de Archivo en un Endpoint RPC de Base

El siguiente script de Node.js usa ethers v6 para consultar un endpoint RPC de Base. Resuelve un bloque pasado (por ejemplo, el bloque 1000000), lee el saldo de una cuenta conocida en ese bloque y en el último, e intenta paginar eth_getLogs en una ventana limitada. También intenta eth_getProof para ver si el endpoint admite pruebas. El script imprime resultados y una tabla para que la completes.

Suposiciones: Node.js 18+, ethers v6 y una URL RPC de mainnet de Base. Reemplaza YOUR_RPC_URL con tu endpoint. El script usa un número de bloque fijo y una dirección conocida (por ejemplo, el contrato del puente de Base). Ejecútalo para ver si tu endpoint devuelve datos de archivo o errores.

// test-archive.js
const { ethers } = require('ethers');

const RPC_URL = process.env.RPC_URL || 'YOUR_RPC_URL';
const provider = new ethers.JsonRpcProvider(RPC_URL);

const ADDRESS = '0x4200000000000000000000000000000000000016'; // Ejemplo: puente estándar L2
const BLOCK_NUMBER = 1000000; // Bloque pasado

async function main() {
  console.log('Probando soporte de archivo en RPC de Base');
  console.log('URL RPC:', RPC_URL);

  // 1. Obtener bloque por número
  const block = await provider.getBlock(BLOCK_NUMBER);
  console.log('Bloque', BLOCK_NUMBER, 'existe:', !!block);

  // 2. Obtener saldo en bloque histórico
  try {
    const balance = await provider.getBalance(ADDRESS, BLOCK_NUMBER);
    console.log('Saldo en bloque', BLOCK_NUMBER, ':', balance.toString());
  } catch (e) {
    console.log('Fallo al obtener saldo en bloque:', e.message);
  }

  // 3. Obtener saldo en el último bloque
  const latestBalance = await provider.getBalance(ADDRESS, 'latest');
  console.log('Saldo en el último bloque:', latestBalance.toString());

  // 4. Paginación de eth_getLogs (ejemplo: eventos Transfer del puente)
  const filter = {
    address: ADDRESS,
    fromBlock: BLOCK_NUMBER,
    toBlock: BLOCK_NUMBER + 1000,
    topics: [ethers.id('Transfer(address,address,uint256)')]
  };
  try {
    const logs = await provider.getLogs(filter);
    console.log('Registros en el rango:', logs.length);
  } catch (e) {
    console.log('Fallo en getLogs:', e.message);
  }

  // 5. eth_getProof (EIP-1186)
  try {
    const proof = await provider.send('eth_getProof', [ADDRESS, [], '0x' + BLOCK_NUMBER.toString(16)]);
    console.log('eth_getProof exitoso. Longitud de prueba de cuenta:', proof.accountProof.length);
  } catch (e) {
    console.log('Fallo en eth_getProof:', e.message);
  }
}

main().catch(console.error);

// Forma esperada de salida:
// Probando soporte de archivo en RPC de Base
// URL RPC: ...
// Bloque 1000000 existe: true
// Saldo en bloque 1000000 : 123456789
// Saldo en el último bloque: 987654321
// Registros en el rango: 5
// eth_getProof exitoso. Longitud de prueba de cuenta: 7
// Si el archivo no es compatible, es posible que veas errores como "nodo trie faltante" o "encabezado no encontrado".

Tabla de Resultados y Lista de Verificación de Decisiones

Completa la siguiente tabla con los resultados de tu prueba para determinar si tu endpoint es capaz de archivo.

• | Prueba | Resultado (Éxito/Error) | Notas |
• |------|------------------------|-------|
• | getBlock en bloque antiguo | | |
• | getBalance en bloque antiguo | | |
• | getBalance en el último bloque | | |
• | getLogs en rango pasado | | |
• | eth_getProof | | |

Fallos Comunes y Soluciones

Al consultar datos históricos en Base, es posible que encuentres errores. Aquí hay algunos comunes y cómo solucionarlos.

Error: 'nodo trie faltante' – Esto indica que el nodo no tiene el estado para ese bloque. Solución: usa un nodo de archivo o un proveedor con datos de archivo.

Error: 'encabezado no encontrado' – El número de bloque está más allá del límite de sincronización del nodo. Solución: asegúrate de que el nodo esté completamente sincronizado o usa un endpoint diferente.

Error: 'rango demasiado grande' para eth_getLogs – El rango de bloques excede el límite del nodo. Solución: pagina en rangos más pequeños (por ejemplo, 1000 bloques a la vez).

eth_getProof no compatible – Algunos proveedores deshabilitan este método. Solución: usa un proveedor que admita EIP-1186 o ejecuta tu propio nodo de archivo.

• Siempre verifica que el número de bloque esté dentro del rango de la cadena.
• Usa eth_blockNumber para confirmar el último bloque.
• Para registros, usa paginación para evitar tiempos de espera.

Compensaciones y Limitaciones

Los nodos de archivo en Base requieren significativamente más espacio en disco y memoria que los nodos completos. El tamaño exacto varía según el cliente y la instantánea, pero es una compensación conocida. Ejecutar un nodo de archivo también aumenta el tiempo de sincronización y la sobrecarga operativa.

La historia de Base es relativamente corta (desde 2023), por lo que los nodos de archivo son más factibles que en Ethereum L1. Sin embargo, a medida que la cadena crezca, los requisitos de almacenamiento aumentarán.

Algunos proveedores de RPC ofrecen endpoints de archivo a un precio premium. Compara los precios de RPC para decidir si un servicio administrado es rentable.

Para consideraciones de latencia, consulta la guía de latencia RPC de Base. Para límites de velocidad, consulta límites de velocidad y confiabilidad de RPC de Base.

Próximos Pasos y Lecturas Adicionales

Ahora que entiendes cómo consultar el estado histórico de Base, puedes aplicar esto a tu dApp o análisis. Para una comprensión más amplia de las consultas de datos históricos en cadenas EVM, consulta Consultando datos históricos de blockchain (recetario EVM).

Si estás construyendo en Base, explora la descripción general de la red Base y el centro de aprendizaje de OnFinality para más guías. Para decisiones de infraestructura de nodos, consulta la infraestructura de nodos de Base (Asistente de RPC).

Para uso en producción, considera usar el servicio API de OnFinality que proporciona endpoints de archivo confiables. Consulta los precios de RPC para obtener detalles.