¿Qué es un nodo de archivo de Binance Smart Chain y cuándo lo necesitas?

Si buscaste un nodo de archivo de Binance Smart Chain, probablemente te topaste con uno de dos obstáculos: una consulta histórica devolvió un error, o un proveedor te dijo que el acceso de archivo cuesta más. Esta página explica qué almacena realmente un nodo de archivo, cómo saber si necesitas uno y cómo conectarte a infraestructura de BNB Chain con capacidad de archivo sin aprovisionar en exceso.

¿Realmente necesitas un nodo de archivo?

La mayoría de las aplicaciones no lo necesitan. Un nodo completo estándar mantiene el estado reciente y la cadena completa de bloques, lo cual es suficiente para enviar transacciones, leer saldos actuales y suscribirse a nuevos eventos. Los nodos de archivo son para consultas que se remontan a estados más antiguos.

Usa esta prueba rápida antes de aprovisionar cualquier cosa:

• Si solo lees el último bloque o los últimos miles de bloques, un nodo completo es suficiente.
• Si necesitas un saldo, un slot de almacenamiento o el resultado de una llamada a contrato en un bloque específico de hace meses o años, necesitas estado de archivo.
• Si ejecutas un indexador que reproduce la historia desde el génesis, necesitas estado de archivo más un plan para lecturas históricas sostenidas.
• Si construyes herramientas fiscales, contables o de auditoría, el estado de archivo suele ser un requisito estricto porque debes reconstruir tenencias en marcas de tiempo arbitrarias.

Una regla útil: en el momento en que pasas un número de bloque histórico explícito a una consulta y esperas una respuesta correcta, estás en territorio de archivo.

Qué almacena un nodo de archivo que un nodo completo no

BNB Smart Chain es compatible con EVM, por lo que el concepto de archivo coincide con Ethereum. Un nodo mantiene dos cosas: la cadena de bloques y transacciones, y el trie de estado que mapea cuentas y contratos a sus valores actuales.

Un nodo completo poda el estado antiguo para ahorrar disco. Todavía puede decirte qué sucedió en el bloque 20,000,000 si pides las transacciones de ese bloque, porque los bloques se conservan. Lo que no puede hacer de manera confiable es responder "cuál era el saldo de esta cuenta en el bloque 20,000,000" o "qué valor tenía este slot de almacenamiento entonces", porque el estado en esa altura se ha descartado.

Un nodo de archivo conserva cada raíz de estado histórica, por lo que las consultas de estado en cualquier bloque pasado se resuelven correctamente. Esa es toda la diferencia, y es por eso que los nodos de archivo son mucho más grandes y costosos de operar.

Configuración de la cadena de un vistazo

Cuando configuras un cliente o billetera para BNB Chain, usa los parámetros de red correctos. La siguiente tabla refleja la configuración de mainnet y testnet que necesitarás.

Para un endpoint gestionado, OnFinality expone BNB Smart Chain a través de su servicio RPC de BNB Chain. El trabajo en testnet debe apuntar al endpoint de BNB Chain Testnet para que no consultes accidentalmente el estado de producción.

Cómo consultar el estado histórico a través de JSON-RPC

Los métodos que requieren estado de archivo son los que aceptan un parámetro de bloque. Si pasas un número de bloque en lugar de latest, el nodo debe poder resolver el estado en esa altura.

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBalance",
    "params": ["0x0000000000000000000000000000000000000000", "0x1B4AF0"]
  }'

El segundo parámetro es el número de bloque en hexadecimal. Reemplázalo con el bloque histórico que te interesa. El mismo patrón se aplica a eth_getStorageAt, eth_getCode, eth_getTransactionCount y eth_call cuando pasas una etiqueta de bloque.

En JavaScript con una biblioteca EVM estándar, la etiqueta de bloque es el último argumento:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://bnb.api.onfinality.io/public");

// Leer un saldo en un bloque histórico específico
const balance = await provider.getBalance(
  "0x0000000000000000000000000000000000000000",
  28_000_000
);

console.log(balance.toString());

Si el endpoint no tiene capacidad de archivo, estas llamadas suelen fallar con un mensaje sobre nodo trie faltante o estado no disponible, en lugar de devolver un número incorrecto. Ese error es tu señal de que estás apuntando a un nodo podado.

Opciones de acceso de archivo para BNB Chain

Hay tres formas prácticas de obtener estado de archivo, y difieren principalmente en cuánto trabajo operativo asumes.

OnFinality proporciona tanto un servicio de API RPC gestionado como opciones de nodo dedicado para BNB Chain. La elección correcta depende de cuán predecible sea tu volumen de consultas históricas. Las lecturas de archivo esporádicas y ocasionales suelen encajar en un endpoint gestionado; la reproducción continua o las lecturas pesadas de eth_getLogs y estado a menudo justifican un nodo dedicado.

Lista de verificación para producción

Antes de dirigir tráfico de producción al estado de archivo, confirma lo siguiente:

• Tu cliente pasa números de bloque explícitos solo donde se requiere estado de archivo, para que no pagues el costo de archivo por lecturas de estado más reciente.
• Tienes un endpoint de respaldo o una segunda ruta de proveedor para cuando un solo endpoint esté degradado.
• Entiendes tu volumen de lecturas históricas, especialmente para rangos de eth_getLogs, que pueden ser la carga de trabajo de archivo más pesada.
• Has probado la misma consulta en testnet antes de apuntarla a mainnet.
• Sabes qué rango de bloques necesita realmente tu aplicación, para no solicitar más historia de la necesaria.

Si aún estás decidiendo entre capacidad compartida y dedicada, la guía de selección de proveedor RPC cubre los criterios de evaluación con más profundidad.

Modos de fallo comunes y cómo interpretarlos

Los problemas de archivo suelen aparecer como errores específicos en lugar de respuestas incorrectas silenciosas. Conocer el síntoma ahorra tiempo de depuración.

Un error frecuente es asumir que cada endpoint RPC tiene capacidad de archivo. Muchos endpoints públicos y compartidos no la tienen, y fallarán en llamadas de estado histórico. Siempre verifica el soporte de archivo antes de construir una dependencia sobre él.

Consideraciones de dimensionamiento y costo

Los nodos de archivo son grandes porque retienen todo el estado histórico. El disco, el tiempo de sincronización y la E/S son los costos dominantes, y crecen con la antigüedad de la cadena. Por eso el acceso de archivo suele tener un precio diferente al RPC estándar.

Cuando compares opciones, mira cómo se facturan o limitan las lecturas de archivo, si se admiten suscripciones WebSocket de archivo y si el proveedor mantiene el estado de archivo para toda la historia de la cadena o solo una ventana reciente. Para detalles actuales del plan, consulta Precios de RPC y la lista de redes RPC compatibles para confirmar la cobertura de BNB Chain.

Si tu carga de trabajo es constante y de alto volumen, un nodo dedicado puede ser más predecible que las llamadas de archivo medidas. Si es ocasional, un endpoint gestionado evita la sobrecarga de ejecutar y sincronizar tu propio nodo de archivo.

Puntos clave

• Un nodo de archivo conserva el estado histórico, por lo que puedes consultar saldos, almacenamiento y estado de contratos en cualquier bloque pasado.
• Los nodos completos retienen bloques pero podan el estado antiguo, por lo que las consultas de estado histórico fallan contra ellos.
• Necesitas estado de archivo cuando pasas números de bloque históricos explícitos, reproduces la historia o construyes herramientas de auditoría y contabilidad.
• BNB Smart Chain mainnet usa chain ID 56; testnet usa chain ID 97.
• OnFinality ofrece opciones de RPC gestionado y nodo dedicado para BNB Chain, para que elijas según la carga de trabajo en lugar del hardware.
• Verifica el soporte de archivo antes de depender de él, y divide las consultas de logs amplias para evitar tiempos de espera.

Preguntas frecuentes

¿Un nodo de archivo de BNB Chain es lo mismo que un nodo de archivo de Ethereum?

Conceptualmente sí. BNB Smart Chain es compatible con EVM, por lo que el modelo de archivo, los métodos JSON-RPC que necesitan estado histórico y los síntomas de fallo son los mismos. La configuración de la cadena difiere, así que usa chain ID 56 para mainnet y 97 para testnet.

¿Puedo usar un endpoint RPC público para consultas de archivo?

A veces, pero no de manera confiable. Muchos endpoints públicos y compartidos ejecutan nodos completos podados y devolverán un error de nodo trie faltante para estado histórico. Confirma el soporte de archivo antes de construir sobre un endpoint.

¿Hasta dónde llega el estado de archivo?

Depende del proveedor o de la configuración de tu propio nodo. Algunos mantienen la historia completa; otros mantienen una ventana reciente. Si tu aplicación necesita historia profunda, confirma explícitamente la profundidad de archivo.

¿Necesito un nodo dedicado para acceso de archivo?

No siempre. Las lecturas históricas ocasionales suelen encajar en un endpoint gestionado. La reproducción continua, las consultas de logs pesadas o los requisitos de aislamiento se sirven mejor con un nodo dedicado.

¿Por qué mi consulta histórica devuelve un error en lugar de un valor incorrecto?

Porque el nodo no puede resolver el estado en esa altura. Un nodo podado no tiene la raíz de estado histórica, por lo que falla la solicitud en lugar de adivinar. Apunta la consulta a un endpoint con capacidad de archivo para solucionarlo.