¿Cuánto cuesta el RPC de BNB Chain y cómo elegir el plan adecuado?

Recomendación rápida: ajusta el plan a tu patrón de solicitudes

"Precio del RPC de BNB" normalmente significa una de tres cosas: quieres un endpoint gratuito para probar, quieres saber cuánto cuesta un plan de RPC gestionado a tu nivel de tráfico, o estás comparando un plan por solicitud con alquilar un nodo BNB dedicado. La respuesta depende menos del precio de portada y más de tu combinación de solicitudes.

• Prototipado o dApp de bajo volumen: un endpoint público compartido es suficiente. Empieza con el endpoint público de BNB Smart Chain de OnFinality y avanza cuando alcances los límites de velocidad.
• Aplicación en producción con tráfico moderado y estable: un plan de RPC gestionado facturado por volumen de solicitudes o unidades de cómputo suele ser la opción más sencilla. Pagas por lo que usas y evitas operar infraestructura.
• Cargas de alto rendimiento, de archivo o con muchas trazas: un nodo BNB dedicado te da capacidad predecible y evita sorpresas de facturación por llamada cuando eth_getLogs o las consultas de archivo dominan tu tráfico.

Si ya conoces tu número mensual de solicitudes y si necesitas datos de archivo, puedes saltar al modelo de costos de abajo. Si no, la siguiente sección muestra cómo estimarlo.

Qué determina realmente el costo del RPC de BNB Chain

El precio del RPC no es un único número. Los proveedores cobran según una combinación de los siguientes factores, y la combinación importa más que el precio de portada:

BNB Smart Chain es una cadena EVM, así que la superficie de métodos resulta familiar: eth_call, eth_getLogs, eth_getBalance, eth_sendRawTransaction, etc. La diferencia de costo entre proveedores suele aparecer en cómo miden los métodos de lectura pesados y si el archivo y la traza están incluidos o son un extra.

Estimar tu volumen mensual de solicitudes en BNB Chain

Antes de comparar precios, obtén un número aproximado. No necesitas cifras exactas para decidir; necesitas el orden de magnitud correcto.

1. Cuenta tus rutas de lectura. Una actualización de cartera, una visualización de saldo, una lista de tokens y un feed de precios disparan cada una una o más solicitudes eth_call o eth_getBalance.
2. Multiplica por las sesiones activas. Si 1.000 usuarios diarios generan 20 lecturas cada uno, son 20.000 solicitudes al día solo por lecturas.
3. Suma los trabajos en segundo plano. Los indexadores, bots y sondas de monitoreo suelen generar más tráfico que las lecturas de cara al usuario. Un solo sondeo de eth_getLogs cada pocos segundos se acumula rápido.
4. Suma reintentos y failover. Si tu cliente reintenta al agotarse el tiempo de espera, tu volumen real es mayor que tu volumen lógico.

Una comprobación rápida con un endpoint público:

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

Si estás midiendo una ruta con muchas lecturas, cronometra un lote de llamadas en lugar de una sola:

time for i in $(seq 1 50); do
  curl -s https://bnb.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]}' > /dev/null
done

Los endpoints públicos son compartidos, así que toma estos números como un mínimo, no como una garantía. Son útiles para confirmar que tu cliente funciona y para dimensionar de forma aproximada.

Compartido, gestionado o dedicado: qué plan de RPC de BNB encaja

Los tres modelos de entrega corresponden a perfiles de costo diferentes. Elige la fila que coincida con tu carga de trabajo y luego confirma los detalles en la página de precios de RPC.

OnFinality ofrece RPC de BNB Chain tanto a través de un servicio de API de RPC gestionado como de nodos dedicados, así que puedes empezar en un plan compartido y pasar a capacidad dedicada cuando tu tráfico lo justifique. La lista de redes RPC compatibles muestra qué cadenas y transportes están disponibles.

Conectarse a mainnet y testnet de BNB Smart Chain

BNB Smart Chain mainnet usa el chain ID 56 y el token nativo BNB. La testnet usa el chain ID 97 y tBNB. Mantén esto claro al configurar una cartera o un cliente, porque mezclar ajustes de mainnet y testnet es una fuente común de errores confusos.

Configuración de red de cartera para mainnet:

{
  "chainId": "0x38",
  "chainName": "BNB Smart Chain Mainnet",
  "nativeCurrency": { "name": "BNB Chain Native Token", "symbol": "BNB", "decimals": 18 },
  "rpcUrls": ["https://bnb.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://bscscan.com"]
}

Para trabajo en testnet, usa el endpoint de BNB Chain Testnet y el chain ID 97. El tráfico de testnet suele ser gratuito o más barato, lo que lo convierte en un buen lugar para validar tu volumen de solicitudes antes de dimensionar un plan de mainnet.

Un cliente viem mínimo para lecturas en mainnet:

import { createPublicClient, http } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: http('https://bnb.api.onfinality.io/public'),
});

const block = await client.getBlockNumber();
console.log('BNB Smart Chain head:', block);

Si necesitas datos en tiempo real, BNB Chain admite transporte WebSocket en endpoints gestionados. Las suscripciones mantienen una conexión abierta, así que confirma cómo las mide tu proveedor antes de escalar.

Cuándo un nodo BNB dedicado es la opción más económica

El precio por solicitud es eficiente cuando el tráfico es irregular o bajo. Se vuelve menos eficiente cuando tu tráfico es alto y estable, o cuando tu combinación de solicitudes está dominada por métodos costosos.

Un nodo dedicado suele tener sentido cuando:

• Tu volumen mensual de solicitudes es lo bastante alto como para que la facturación basada en uso supere el costo fijo de un nodo.
• Dependes de consultas de archivo o métodos de traza que se miden intensamente en planes compartidos.
• Necesitas capacidad constante durante picos predecibles, como el lanzamiento de un token o una ventana programada de reclamo de airdrop.
• Quieres aislamiento del tráfico de otros inquilinos para lecturas sensibles a la latencia.

Un nodo dedicado suele ser la compra inicial equivocada para un prototipo. Empieza compartido, mide y luego cambia cuando los números lo justifiquen. Vale la pena leer las compensaciones entre construir y comprar si estás decidiendo entre ejecutar tu propio nodo BNB y alquilar uno.

Reducir el costo del RPC de BNB sin afectar la confiabilidad

La mayoría de los equipos pueden recortar gastos antes de cambiar de plan. Estas son las palancas que más importan:

• Agrupa solicitudes. El batching de JSON-RPC envía varias llamadas en una sola solicitud HTTP, lo que reduce la sobrecarga y a menudo reduce las unidades facturadas.
• Cachea de forma agresiva. Los saldos y los metadatos de tokens cambian lentamente; cachéalos en el cliente o en una capa de borde.
• Ajusta los rangos de eth_getLogs. Los rangos de bloques amplios son costosos. Redúcelos y pagina.
• Usa WebSocket para suscripciones en lugar de polling. Hacer polling de eth_blockNumber en un bucle es una de las fuentes más comunes de solicitudes desperdiciadas.
• Separa las rutas de lectura y escritura. Enviar transacciones por una ruta dedicada mantiene las escrituras sensibles a la latencia lejos de las lecturas masivas.
• Añade failover, no duplicación. Un segundo endpoint para failover está bien; ejecutar dos rutas de tráfico completas duplica el costo sin beneficio.

Una sonda de monitoreo simple te ayuda a detectar un volumen de solicitudes descontrolado a tiempo:

#!/usr/bin/env bash
# Log head height and response time every minute
START=$(date +%s%3N)
HEAD=$(curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | grep -o '"result":"[^"]*"')
END=$(date +%s%3N)
echo "$(date -u +%FT%TZ) head=$HEAD latency_ms=$((END-START))"

Errores comunes de precios y facturación

• Dimensionar según promedios. Las solicitudes máximas por segundo determinan la capacidad y el costo más que el promedio mensual. Dimensiona para los picos.
• Olvidar los trabajos en segundo plano. Los indexadores y bots a menudo gastan más que las lecturas de cara al usuario.
• Asumir que el archivo está incluido. Las consultas de estado histórico necesitan nodos de archivo; confírmalo antes de construir una función que dependa de ellas.
• Ignorar las tormentas de reintentos. Un cliente que reintenta agresivamente al agotarse el tiempo de espera puede multiplicar tu volumen facturado durante un incidente.
• Mezclar mainnet y testnet. Un chain ID incorrecto o un endpoint equivocado producen errores que parecen problemas del proveedor pero son errores de configuración.
• Sobredimensionar el failover. Un endpoint en espera suele ser suficiente; dos rutas activas duplican el costo.

Puntos clave

• El precio del RPC de BNB Chain está determinado por el volumen de solicitudes, el peso de los métodos, el acceso a archivo y traza, las suscripciones WebSocket y si alquilas capacidad dedicada.
• Los endpoints públicos compartidos sirven para prototipos; los planes gestionados encajan con tráfico de producción variable; los nodos dedicados encajan con cargas de alto rendimiento, de archivo o con muchas trazas.
• Estima tu volumen mensual de solicitudes y tus solicitudes máximas por segundo antes de comparar planes.
• BNB Smart Chain mainnet es el chain ID 56; la testnet es el chain ID 97. Mantén la configuración separada.
• El batching, el caché, rangos más estrechos de eth_getLogs y las suscripciones WebSocket son las formas más rápidas de reducir costos sin afectar la confiabilidad.
• OnFinality proporciona RPC de BNB Chain a través de un servicio de API de RPC gestionado y nodos dedicados; consulta precios de RPC y redes RPC compatibles para las opciones actuales.

Preguntas frecuentes

¿Existe un endpoint de RPC de BNB Chain gratuito?

Sí. OnFinality publica un endpoint público compartido para mainnet y testnet de BNB Smart Chain. Tiene límite de velocidad y es compartido, por lo que sirve para prototipado y uso de bajo volumen, no para tráfico de producción.

¿Cómo se cobra el RPC de BNB Chain?

Los planes gestionados normalmente se facturan por volumen de solicitudes o unidades de cómputo, con métodos más pesados y acceso a archivo o traza medidos de forma diferente. Los nodos dedicados se facturan por nodo con capacidad fija. Consulta precios de RPC para los detalles actuales.

¿Cuándo debería pasar de un endpoint compartido a un nodo BNB dedicado?

Cuando tu volumen estable de solicitudes hace que la facturación basada en uso sea más cara que un nodo fijo, o cuando dependes de métodos de archivo o traza que se miden intensamente en planes compartidos.

¿El RPC de BNB Chain admite WebSocket?

BNB Smart Chain admite transporte HTTP y WebSocket en endpoints gestionados. Las suscripciones mantienen una conexión abierta, así que confirma cómo las mide tu proveedor.

¿Qué chain ID usa BNB Smart Chain?

Mainnet usa el chain ID 56 con el token nativo BNB. La testnet usa el chain ID 97 con tBNB. Consulta BNB Chain y BNB Chain Testnet para los detalles de los endpoints.

¿Puedo reducir mi factura de RPC de BNB sin cambiar de proveedor?

A menudo sí. Agrupar solicitudes, cachear datos que cambian lentamente, estrechar los rangos de eth_getLogs y reemplazar el polling por suscripciones WebSocket suelen reducir significativamente el volumen facturado.