Logo
Nuevos usuarios de RPC: 35% de descuento el primer mesVer oferta
RPC Assistant

Alchemy BNB Smart Chain RPC: Cómo evaluar y configurar un endpoint de BSC

Resumen

Los desarrolladores que buscan Alchemy BNB Smart Chain RPC normalmente quieren un endpoint de BSC funcional, la configuración correcta de la cadena y una forma de juzgar si un proveedor gestionado se ajusta a su carga de trabajo. Esta página te proporciona los parámetros de la mainnet y testnet de BNB Smart Chain, un ejemplo de solicitud y los criterios que separan un endpoint compartido de una infraestructura de nodo dedicada. También explica cuándo una API RPC gestionada como OnFinality es una mejor opción que ejecutar tu propio nodo de BSC, y qué verificar antes de migrar el tráfico de producción.

Si estás buscando un endpoint de Alchemy BNB Smart Chain RPC, lo más probable es que necesites dos cosas a la vez: los parámetros exactos de la red BSC para que tu billetera o aplicación se conecte, y una forma de decidir si una API RPC gestionada o un nodo dedicado es el hogar adecuado a largo plazo para tu tráfico. Esta página cubre ambos aspectos. Te proporciona la configuración de mainnet y testnet de BNB Smart Chain, un ejemplo de solicitud funcional y los criterios de evaluación que importan cuando pasas de una prueba rápida a producción.

BNB Smart Chain (BSC) es una cadena compatible con EVM, por lo que cualquier endpoint que hable JSON-RPC estándar sobre HTTP o WebSocket funcionará con las herramientas que ya usas: ethers, viem, web3.js, Hardhat, Foundry y la mayoría de los diálogos de red de billeteras. El nombre del proveedor importa menos que el comportamiento del endpoint bajo tu carga de trabajo real, que es lo que el resto de esta página te ayuda a evaluar.

Configuración de la cadena de un vistazo

Usa estos valores cuando agregues BNB Smart Chain a una billetera, una configuración de Hardhat o un cliente backend. El chain ID es el campo que con mayor frecuencia causa una conexión fallida, así que confírmalo primero.

ConfiguraciónBNB Smart Chain mainnetBNB Chain testnet
Chain ID5697
Nombre de la cadenaBNB Smart Chain MainnetBNB Smart Chain Testnet
Moneda nativaBNB (18 decimales)tBNB (18 decimales)
Explorador de bloqueshttps://bscscan.comhttps://testnet.bscscan.com
TransportesHTTP, WebSocketHTTP
Endpoint público de OnFinalityhttps://bnb.api.onfinality.io/publichttps://bnb-testnet.api.onfinality.io/public

OnFinality expone un endpoint público para ambas redes, y puedes revisar los detalles completos de la red en la página de BNB Smart Chain RPC y la página de BNB Chain Testnet RPC. Los endpoints públicos son útiles para prototipos y lecturas de bajo volumen. Para tráfico sostenido, consultas de archivo o suscripciones WebSocket, un plan gestionado o un nodo dedicado suele ser la mejor opción.

Cuándo un endpoint compartido es suficiente y cuándo no

Antes de comprometerte con un proveedor, haz coincidir el tipo de endpoint con la carga de trabajo. El mismo endpoint de BSC que es perfecto para una demo de hackathon puede convertirse en un cuello de botella para un indexador que escanea años de registros.

  • Prototipos y pruebas de billetera: un endpoint público o compartido es suficiente. Necesitas configuración rápida y ajustes de cadena correctos, no garantías de capacidad.
  • Lecturas y escrituras de dApp en producción: una API RPC gestionada con un presupuesto de solicitudes definido y failover es el valor predeterminado práctico. Obtienes acceso predecible sin operar un nodo.
  • eth_getLogs intensivo, lecturas de archivo o llamadas de trace: estas son las cargas de trabajo que estresan la infraestructura compartida. Planifica soporte de archivo y límites más altos, o pasa a un nodo dedicado.
  • Trading o bots sensibles a la latencia: los endpoints compartidos introducen latencia variable. Un nodo dedicado te da recursos aislados y una conexión estable.

Si no estás seguro de en qué categoría encajas, comienza con un endpoint gestionado e instrumentalo. Mide las tasas de error y la latencia bajo carga real antes de decidir si actualizar. La guía de selección de proveedor analiza esa decisión con más profundidad.

Conexión a BNB Smart Chain

Una forma rápida de confirmar tu endpoint y chain ID es una única llamada JSON-RPC. El ejemplo a continuación utiliza el endpoint público de BSC de OnFinality.

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

Una respuesta correcta devuelve el chain ID en hexadecimal:

{"jsonrpc":"2.0","id":1,"result":"0x38"}

0x38 es 56 en decimal, lo que confirma que estás en la mainnet de BNB Smart Chain. Si obtienes un valor diferente, estás apuntando a la red incorrecta.

En JavaScript, la misma verificación con viem se ve así:

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

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

const chainId = await client.getChainId()
const block = await client.getBlockNumber()
console.log({ chainId, block })

Para billeteras, agrega una red personalizada con chain ID 56, símbolo BNB y la URL RPC anterior. Para trabajo en testnet, usa chain ID 97, símbolo tBNB y el endpoint de testnet. Los BNB de testnet están disponibles en faucets públicos; el endpoint de testnet no proporciona fondos.

Qué comparar entre proveedores de RPC de BSC

La elección del proveedor es un equilibrio entre control, costo y esfuerzo operativo. La siguiente tabla enmarca la comparación por carga de trabajo en lugar de por afirmaciones de marketing. OnFinality aparece primero porque es la opción que este sitio documenta en detalle, pero las columnas se aplican a cualquier proveedor que evalúes.

Proveedor / opciónMejor paraArchivo y traceWebSocketEsfuerzo operativo
API RPC de OnFinalitydApps en producción, indexadores, equipos que quieren acceso gestionadoDisponible en planes compatibles — confirma en la página de la redCompatibleBajo: endpoints gestionados y failover
Nodo dedicado de OnFinalityCargas de trabajo de alto rendimiento, sensibles a la latencia o aisladasConfigurableCompatibleDe bajo a medio: nodo gestionado, tú controlas la capacidad
Nodo BSC autoalojadoEquipos con estrictas necesidades de control de datos o personalizadasControl totalControl totalAlto: hardware, sincronización, actualizaciones, monitoreo
Otros proveedores gestionadosVaría según el plan y la regiónVaríaVaríaBajo, pero verifica límites y soporte de archivo

Dos preguntas separan a los proveedores serios de los superficiales. Primero, ¿el proveedor admite los métodos que realmente llamas — eth_getLogs con rangos de bloques amplios, debug_traceTransaction o estado de archivo en bloques históricos? Segundo, ¿qué sucede cuando un nodo falla: hay failover automático o tu aplicación ve errores hasta que intervienes? Haz ambas preguntas antes de migrar.

Puntos de control de migración

Si te estás moviendo de otro endpoint de BSC a un nuevo proveedor, trátalo como un cambio controlado en lugar de un simple cambio de URL.

  1. Inventario de tus métodos. Enumera cada método JSON-RPC que llama tu aplicación, incluidos los métodos de depuración o trace. Confirma que cada uno sea compatible con el plan de destino.
  2. Verifica las necesidades de archivo. Si consultas estado histórico o rangos amplios de registros, confirma la disponibilidad de archivo antes del cambio.
  3. Prueba en staging. Apunta un entorno de staging al nuevo endpoint y ejecuta tus pruebas de integración, incluidos los caminos de error.
  4. Agrega failover. Configura un endpoint secundario para que una caída de un solo proveedor no derribe tu aplicación.
  5. Monitorea después del cambio. Rastrea la tasa de error, los percentiles de latencia y las respuestas de límite de velocidad durante al menos un ciclo completo de tráfico.

Mantén el endpoint antiguo configurado hasta que el nuevo haya demostrado ser estable bajo tu carga real. La reversión debe ser un cambio de configuración, no un redespliegue.

Modos de fallo comunes y cómo depurarlos

La mayoría de los problemas de RPC de BSC caen en un pequeño conjunto de categorías. La siguiente tabla asigna síntomas a causas probables.

SíntomaCausa probablePrimera verificación
eth_chainId devuelve el valor incorrectoEl endpoint apunta a una red diferenteConfirma la URL y el chain ID
Las solicitudes fallan bajo cargaLímites de velocidad en un endpoint compartidoRevisa el presupuesto de solicitudes de tu plan
eth_getLogs agota el tiempo o da errorRango de bloques demasiado amplio, o sin soporte de archivoReduce el rango; confirma el acceso al archivo
WebSocket se desconectaTiempo de espera inactivo o límites de conexiónAgrega lógica de reconexión con retroceso
Las llamadas de estado histórico fallanNodo no archivadorCambia a un endpoint con capacidad de archivo
Resultados inconsistentes entre llamadasNodos balanceados en diferentes alturasFija a un solo nodo o acepta consistencia eventual

Una sonda de monitoreo simple te ayuda a detectar estos problemas temprano. Consulta eth_blockNumber de forma programada y alerta si deja de avanzar o si las tasas de error se disparan.

# Sonda de salud mínima: confirma que el nodo está avanzando
curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Ejecuta esto desde la misma región que tu aplicación para que la latencia que midas refleje lo que experimentan tus usuarios.

Construir versus comprar para BSC

Ejecutar tu propio nodo de BNB Smart Chain te da control total, pero también significa aprovisionar hardware que pueda seguir el rendimiento de BSC, gestionar el crecimiento del disco, aplicar actualizaciones del cliente y manejar eventos de sincronización y reorganización. Para muchos equipos, esa carga operativa no es el producto que quieren construir.

Una API RPC gestionada elimina la mayor parte de esa carga: obtienes un endpoint y el proveedor se encarga de las operaciones del nodo, las actualizaciones y la disponibilidad. Un nodo dedicado se sitúa en el medio: obtienes recursos aislados y rendimiento predecible sin gestionar la infraestructura subyacente tú mismo. OnFinality ofrece ambos, y puedes comparar planes en la página de precios de RPC o leer sobre nodos dedicados.

Si tu carga de trabajo es irregular o está en etapa temprana, comienza con gestionado y escala. Si tienes un alto rendimiento constante o requisitos estrictos de aislamiento, un nodo dedicado suele ser la opción más económica y predecible.

Puntos clave

  • La mainnet de BNB Smart Chain usa chain ID 56; la testnet usa chain ID 97. Confirma el chain ID primero cuando fallen las conexiones.
  • Los endpoints públicos son suficientes para prototipos; el tráfico de producción se beneficia de una API RPC gestionada con failover.
  • El soporte de archivo, los límites de eth_getLogs y el comportamiento de WebSocket son los campos que con mayor frecuencia deciden si un proveedor encaja.
  • Trata la migración de proveedor como un cambio controlado: inventario de métodos, prueba en staging, agrega failover y monitorea después del cambio.
  • OnFinality proporciona endpoints gestionados de BSC y nodos dedicados; revisa las redes RPC compatibles y los precios de RPC para ajustar un plan a tu carga de trabajo.

Preguntas frecuentes

¿El RPC de BNB Smart Chain de Alchemy es lo mismo que cualquier otro endpoint de BSC? Cualquier endpoint que hable JSON-RPC estándar para el chain ID 56 funcionará con herramientas EVM. Las diferencias entre proveedores se manifiestan en el soporte de métodos, el acceso a archivo, los límites de velocidad y el comportamiento de failover, no en el formato básico de solicitud.

¿Qué chain ID uso para BNB Smart Chain? La mainnet es 56 (0x38). La testnet es 97 (0x61). Usar el chain ID incorrecto es la causa más común de una conexión fallida de billetera.

¿Necesito un nodo de archivo para BSC? Solo si consultas estado histórico o rangos amplios de registros. Las lecturas y escrituras estándar de bloques recientes funcionan en un nodo completo regular. Confirma la disponibilidad de archivo antes de depender de ella.

¿Puedo usar WebSockets en BNB Smart Chain? Sí. BSC admite suscripciones WebSocket para eventos y nuevos bloques. Si las usas en producción, agrega lógica de reconexión con retroceso, ya que las conexiones inactivas pueden ser eliminadas.

¿Cómo muevo mi aplicación de un proveedor de RPC de BSC a otro? Cambia la URL del endpoint en tu configuración, mantén un endpoint secundario para failover y ejecuta tus pruebas de integración en staging primero. No se requieren cambios de contrato o billetera porque el chain ID sigue siendo el mismo.

¿Dónde puedo ver qué redes admite OnFinality? La página de redes RPC compatibles enumera las redes actuales, y la página de BNB Smart Chain RPC tiene los detalles específicos del endpoint y la cadena.

Base de conocimiento RPC

Detalles RPC relacionados

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar