¿Qué es el explorador de Binance Beacon Chain y cómo se consulta?

Qué mostraba realmente el explorador de Binance Beacon Chain

La Binance Beacon Chain era la capa de consenso proof-of-stake que funcionaba junto a BNB Smart Chain (BSC). Gestionaba el staking, el registro de validadores, la delegación y la gobernanza del ecosistema BNB Chain. Su explorador era la interfaz web donde podías consultar:

• Validadores y su poder de voto — quién producía bloques y cuánto BNB estaba en staking con cada validador.
• Delegaciones — qué direcciones delegaban stake a qué validadores, y el historial de recompensas resultante.
• Eventos entre cadenas — transferencias y mensajes entre la Beacon Chain y BNB Smart Chain.
• Propuestas de gobernanza — votos on-chain y sus resultados.

Si buscabas un "explorador de Binance Beacon Chain", probablemente intentabas responder una de tres preguntas: ¿a dónde fueron mis recompensas de staking?, ¿a qué validador debería delegar? o ¿cómo obtengo estos datos programáticamente?. Las dos primeras son búsquedas históricas. La tercera es donde entra la infraestructura RPC, y es la parte que aún importa para los desarrolladores hoy.

Guía de decisión: consulta en explorador vs. consulta RPC

Antes de dedicar tiempo a configurar un endpoint, decide qué necesitas realmente. Los exploradores son para humanos que leen una página; RPC es para software que necesita leer el estado bajo demanda.

Si tu respuesta está en la mitad inferior de esa tabla, sigue leyendo: el resto de esta página trata sobre consultar datos de BNB Chain a través de RPC en lugar de hacer clic en un explorador.

Por qué el explorador de Beacon Chain ya no es el punto de entrada principal

El ecosistema BNB Chain consolidó su arquitectura, y el rol de Beacon Chain se integró en el stack más amplio de BNB Chain. Eso significa que:

1. El nuevo desarrollo ocurre en BNB Smart Chain. Los contratos, tokens y la mayoría de las dApps viven allí, y ahí es donde va el tráfico RPC.
2. Los datos de staking aún existen, pero se accede a ellos de forma diferente. Los registros históricos de staking pueden seguir disponibles a través de archivos e indexadores, pero no son el flujo de trabajo principal para la mayoría de los constructores.
3. Los exploradores y RPC sirven a audiencias diferentes. Un explorador es una interfaz de solo lectura. Un endpoint RPC es una interfaz programable que tu backend, billetera o bot llama directamente.

Así que la pregunta práctica ya no es "qué explorador de Beacon Chain debo abrir", sino "a qué endpoint de BNB Smart Chain debe conectarse mi aplicación".

Configuración RPC de BNB Smart Chain de un vistazo

Si estás pasando de consultas en exploradores a consultas programáticas, estos son los valores que necesitas. Coinciden con la configuración de la mainnet de BNB Smart Chain que utiliza OnFinality.

Para trabajo en testnet, BNB Chain Testnet usa el ID de cadena 97, el token nativo tBNB, el explorador en https://testnet.bscscan.com y el endpoint público https://bnb-testnet.api.onfinality.io/public. Puedes encontrar ambos en la página de red de BNB Chain y la página de BNB Chain Testnet.

Consultar datos de BNB Chain con JSON-RPC

Una vez que tienes un endpoint, el trabajo del explorador se convierte en un conjunto de llamadas a métodos. Aquí tienes un ejemplo rápido con curl que obtiene el último número de bloque:

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

Para verificar una transacción que encontraste previamente en un explorador, usa el hash:

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

En JavaScript con ethers, la misma consulta se ve así:

import { JsonRpcProvider } from "ethers";

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

async function checkTx(hash) {
  const receipt = await provider.getTransactionReceipt(hash);
  if (!receipt) {
    console.log("Pending or unknown transaction");
    return;
  }
  console.log("Status:", receipt.status === 1 ? "success" : "reverted");
  console.log("Block:", receipt.blockNumber);
}

checkTx("0xYOUR_TX_HASH");

Para actualizaciones en vivo —útil si estás reemplazando una actualización manual del explorador con un panel— suscríbete por WebSocket:

const ws = new WebSocket("wss://bnb.api.onfinality.io/public");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "eth_subscribe",
    params: ["newHeads"]
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.params?.result?.number) {
    console.log("New block:", parseInt(data.params.result.number, 16));
  }
};

El soporte de WebSocket depende del endpoint y del plan que utilices. Confirma la disponibilidad del transporte en la página de red de BNB Chain antes de basar tu desarrollo en él.

Cuándo un endpoint público es suficiente —y cuándo no

Un endpoint RPC público es la forma más rápida de reemplazar una consulta en un explorador con un script. Funciona bien para:

• Prototipado y consultas puntuales.
• Billeteras de bajo volumen o herramientas internas.
• Leer saldos, bloques y recibos a un ritmo moderado.

Se convierte en un cuello de botella cuando necesitas:

• Alto volumen de solicitudes desde un backend o bot.
• Datos de archivo para estado histórico, como saldos en un bloque antiguo.
• Métodos de trace y depuración para transacciones fallidas.
• Suscripciones WebSocket consistentes para funciones en tiempo real.

En ese punto, la elección es entre gestionar tu propio nodo de BNB o usar infraestructura gestionada. Ejecutar tu propio nodo implica manejar la sincronización, el crecimiento del disco, las actualizaciones y el monitoreo. Una API RPC gestionada o un nodo dedicado elimina esa carga operativa y te da un endpoint estable en el que tu equipo puede confiar. OnFinality ofrece tanto acceso a la API RPC como opciones de nodo dedicado para BNB Chain, para que puedas comenzar en un endpoint compartido y pasar a capacidad dedicada a medida que crece el tráfico.

Errores comunes al dejar las consultas en exploradores

Los exploradores ocultan mucha complejidad. Cuando cambias a RPC, algunas cosas suelen causar problemas:

• Asumir que todos los endpoints son nodos de archivo. Las llamadas históricas a eth_getBalance en un bloque antiguo fallan en nodos que no son de archivo. Verifica el soporte de archivo antes de depender de él.
• Ignorar los límites de velocidad en endpoints públicos. Un script que bombardea un endpoint compartido será limitado. Planifica un nivel de pago o un nodo dedicado si tu volumen es real.
• Olvidar las verificaciones del ID de cadena. Las billeteras y herramientas necesitan el ID de cadena 56 para mainnet y 97 para testnet. Confundirlos envía transacciones a la red incorrecta.
• Tratar un recibo como final demasiado pronto. Una transacción puede incluirse y luego reorganizarse. Espera unas cuantas confirmaciones antes de marcar algo como liquidado.
• Codificar un solo endpoint. Si tu único endpoint falla, tu aplicación falla. Mantén un respaldo y monitorea ambos.

Lista de verificación para producción

Si estás reemplazando flujos de trabajo basados en exploradores con RPC en un producto en vivo, revisa esto antes del lanzamiento:

Una sonda de monitoreo simple puede detectar la mayoría de los problemas a tiempo:

#!/bin/bash
# Poll block height and alert if it stalls
HEIGHT=$(curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  | grep -o '"result":"[^"]*"' | cut -d'"' -f4)

echo "Current block: $((HEIGHT))"
# Compare against a previous value and alert on stagnation

Dónde encaja OnFinality

OnFinality ejecuta endpoints de API RPC y nodos dedicados para BNB Chain y muchas otras redes. Para los equipos que se alejan de los flujos de trabajo basados en exploradores, eso significa que obtienes un endpoint estable, opciones de archivo y trace donde se admiten, y la capacidad de escalar desde una API compartida a infraestructura dedicada sin cambiar el código de tu aplicación. Puedes revisar los precios de RPC para ajustar un plan a tu carga de trabajo, y explorar las redes RPC compatibles si también construyes en cadenas más allá de BNB. Si aún estás decidiendo entre proveedores, la guía de selección de proveedores de RPC repasa los criterios de evaluación.

Puntos clave

• El explorador de Binance Beacon Chain era una interfaz para datos de staking, validadores y gobernanza en la capa de consenso de BNB Chain.
• El desarrollo de BNB Chain ahora se centra en BNB Smart Chain, donde los endpoints RPC son la interfaz programática principal.
• Los ID de cadena 56 (mainnet) y 97 (testnet) son los valores que necesitas para la configuración de billeteras y aplicaciones.
• Los endpoints públicos están bien para prototipar; las cargas de trabajo en producción generalmente necesitan acceso a archivo, soporte de WebSocket y redundancia.
• OnFinality ofrece API RPC e infraestructura de nodo dedicado para BNB Chain, con planes que puedes ajustar a tu tráfico.

Preguntas frecuentes

¿El explorador de Binance Beacon Chain sigue disponible?

El rol de Beacon Chain cambió a medida que BNB Chain consolidó su arquitectura. Los datos históricos de staking aún pueden ser accesibles a través de archivos e indexadores, pero el nuevo desarrollo apunta a BNB Smart Chain. Para datos actuales, usa un explorador de BNB Smart Chain o un endpoint RPC.

¿Cuál es la diferencia entre un explorador y un endpoint RPC?

Un explorador es un sitio web de solo lectura para humanos. Un endpoint RPC es una interfaz programable que tu código llama para leer el estado, enviar transacciones y suscribirse a eventos. Los exploradores son buenos para consultas puntuales; RPC es sobre lo que construyes.

¿Qué ID de cadena debo usar para BNB Smart Chain?

Usa el ID de cadena 56 para la mainnet de BNB Smart Chain y el ID de cadena 97 para BNB Chain Testnet. La moneda nativa es BNB en mainnet y tBNB en testnet.

¿Puedo consultar datos históricos de staking por RPC?

Algo de estado histórico está disponible si el endpoint admite consultas de archivo, pero los datos específicos de staking pueden requerir un indexador en lugar de una llamada JSON-RPC estándar. Confirma el soporte de archivo con tu proveedor antes de depender de él.

¿Necesito un nodo dedicado para un proyecto pequeño?

No siempre. Un endpoint RPC público o compartido suele ser suficiente para aplicaciones de bajo volumen. Pasa a un nodo dedicado cuando necesites rendimiento constante, acceso a archivo o aislamiento del tráfico de otros usuarios.

¿Cómo evito el tiempo de inactividad si mi endpoint RPC falla?

Configura al menos un endpoint de respaldo, monitorea las tasas de error y el retraso de bloques, y mantén a mano la información de estado de tu proveedor. La redundancia en la capa de aplicación es la protección más simple.