Cómo configurar un nodo Binance Smart Chain (BSC)

BNB Smart Chain — aún muy buscada como Binance Smart Chain, su nombre hasta febrero de 2022 — es una cadena EVM que produce un bloque cada 0,45 segundos desde el hard fork Fermi de enero de 2026, después de que Maxwell ya hubiera reducido a la mitad el intervalo a 0,75 segundos a mediados de 2025. Esa velocidad es agradable para los usuarios y exigente para los operadores de nodos: un full node de BSC quiere hardware de nivel servidor y la estrategia de sincronización correcta, y equivocarse en cualquiera de las dos cosas significa un nodo que nunca alcanza la cabeza de la cadena. Esta guía es la versión copiar y pegar donde se detiene la documentación oficial: configuración basada en snapshot con el fork geth de bnb-chain, una unidad systemd, notas de seguridad para nodos RPC, cálculo de tiempo de sincronización y costes, además de una mirada honesta a cuándo no debería ejecutar uno en absoluto.

¿Qué es un nodo BSC, y qué tipo necesita?

Un nodo BSC ejecuta el cliente de la cadena, valida bloques y le da un endpoint JSON-RPC local con la misma interfaz que Ethereum: eth_blockNumber, eth_call, eth_sendRawTransaction y el resto. En la práctica importan cuatro variantes.

Un full node mantiene el estado reciente y sirve RPC — el valor por defecto, y el tema de esta guía. Un fast node es un full node iniciado con --tries-verify-mode none; la documentación oficial lo recomienda para cargas RPC donde la velocidad de importación importa más que la verificación estricta del trie de estado. Un archive node almacena todo el estado histórico, necesita espacio en disco de dos dígitos en terabytes y solo tiene sentido para indexación y analítica. Un validator produce bloques, lo que requiere ser elegido dentro del pequeño conjunto validado con BNB en staking, un tema aparte más allá de una guía de configuración.

¿Y un light node? El fork geth heredó el código de light-client, pero en la práctica casi nada en BSC sirve a peers ligeros, así que considere el “light node de BSC” no disponible. Si un full node podado es más de lo que necesita, ese es precisamente el caso de uso de una API; vea la última sección.

La misma elección en formato de tabla, con cifras de disco de mediados de 2026:

BSC y Geth: una base de código, dos cadenas

El cliente de BSC es un fork de go-ethereum, mantenido en github.com/bnb-chain/bsc, y el binario se llama literalmente geth. Habla el mismo JSON-RPC, acepta la mayoría de las mismas flags, y añade especificidades de BSC: el consenso proof-of-staked-authority Parlia (un solo proceso es todo el nodo, sin cliente de consenso separado como en Ethereum post-merge), más flags como --tries-verify-mode. De ahí se derivan dos consecuencias prácticas. Sus herramientas de Ethereum funcionan sin cambios contra un nodo BSC. Y debe ejecutar el build de bnb-chain: el Geth upstream no puede sincronizar BSC, que es el error de principiante más común con “bsc geth”.

Requisitos de hardware para un nodo BSC

La base viene del README de bnb-chain/bsc, ajustada al crecimiento de datos hasta 2026:

La fila que hunde la mayoría de las instalaciones son las IOPS, no la capacidad. Con bloques de 0,45 segundos, el nodo escribe constantemente, y el almacenamiento en bloque en la nube con IOPS por defecto se queda atrás de la cabeza de la cadena y nunca se recupera. La referencia del README es AWS gp3 con 8000 IOPS aprovisionadas y latencia de lectura por debajo del milisegundo (clase de instancia m5zn.3xlarge en AWS, c2-standard-16 en Google Cloud); un disco NVMe local en un servidor dedicado supera ese listón con margen.

Paso a paso: full node de BSC desde el snapshot oficial

Sincronizar desde el génesis es posible y una mala idea. La propia documentación lo desaconseja: sugiere hardware de 40k+ IOPS para el intento, y aun así lleva semanas. La ruta compatible: descargar el snapshot de datos de la cadena, iniciar el nodo sobre él, dejar que se ponga al día. Los comandos asumen Ubuntu 24.04.

1. Preparar el servidor

sudo apt update && sudo apt install -y aria2 lz4 unzip jq
sudo useradd --no-create-home --shell /usr/sbin/nologin bsc
sudo mkdir -p /var/lib/bsc
sudo chown bsc:bsc /var/lib/bsc
sudo ufw allow 30311 comment 'bsc p2p'

El puerto 30311 es el puerto peer-to-peer de BSC y el único puerto de blockchain que debería estar abierto. El puerto RPC se queda en localhost.

2. Descargar el binario geth de bnb-chain

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="geth_linux") | .browser_download_url' \
  | xargs wget -O geth_linux
chmod +x geth_linux
sudo mv geth_linux /usr/local/bin/geth-bsc
geth-bsc version

Renombrar el binario a geth-bsc evita el accidente clásico de iniciar un Geth upstream instalado por la distro contra datos de BSC.

3. Obtener config.toml y genesis.json

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="mainnet.zip") | .browser_download_url' \
  | xargs wget -O mainnet.zip
unzip -o mainnet.zip
sudo mv config.toml genesis.json /var/lib/bsc/
sudo chown bsc:bsc /var/lib/bsc/config.toml /var/lib/bsc/genesis.json

Nota: geth-bsc init genesis.json solo hace falta al sincronizar desde el génesis. En la ruta de snapshot se salta el init: el snapshot trae su propia base de datos.

4. Descargar y descomprimir el snapshot

Los snapshots están en github.com/bnb-chain/bsc-snapshots, el repositorio oficial. A mediados de 2026 publica tres conjuntos de datos: el snapshot podado, de aproximadamente 1,6 TB comprimido (solo bloques recientes, el adecuado para esta guía), el snapshot completo, de unos 6 TB, y snapshots incrementales que solo traen los cambios desde uno anterior, una incorporación de la era Fermi (BEP-593). La generación actual requiere el cliente v1.7.2 o posterior, lo que la descarga del paso 2 ya satisface. El repositorio también incluye un script fetch-snapshot.sh que descarga, comprueba la suma MD5 (flag -c) y extrae en un solo comando; la ruta manual de abajo muestra lo que hace por dentro. Dos formas de poner el archivo en disco:

cd /var/lib/bsc
# Option A: resumable download, needs space for archive + extracted data
sudo -u bsc aria2c -x8 -s8 -c '<PASTE_SNAPSHOT_URL>'
sudo -u bsc bash -c "lz4 -cd geth.tar.lz4 | tar -x"

# Option B: stream-extract, needs space only once, but no resume
sudo -u bsc bash -c "wget -qO- '<PASTE_SNAPSHOT_URL>' | lz4 -d | tar -x"

aria2c descarga en ocho conexiones y reanuda tras interrupciones (-c) — con un wget normal, una descarga multi-terabyte interrumpida empieza de nuevo. Tras la extracción, la base de datos de la cadena debe quedar en /var/lib/bsc/geth/chaindata; el formato del archivo ha cambiado entre generaciones de snapshots, así que mueva la carpeta interna geth a ese sitio si hace falta. Verifique antes de extraer: compare el MD5 de la página del snapshot, o deje que fetch-snapshot.sh -c se encargue; un archivo de un terabyte con un bit alterado le cuesta un día. La opción A necesita espacio para el archivo y los datos extraídos al mismo tiempo, unos 2 TB de margen para el conjunto podado, y esa es la razón real detrás de la recomendación de un disco de 4 TB.

5. Unidad systemd

Cree /etc/systemd/system/bsc.service:

[Unit]
Description=BSC full node (bnb-chain geth fork)
After=network-online.target
Wants=network-online.target

[Service]
User=bsc
Group=bsc
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
LimitNOFILE=65536
ExecStart=/usr/local/bin/geth-bsc \
  --config /var/lib/bsc/config.toml \
  --datadir /var/lib/bsc \
  --cache 8000 \
  --tries-verify-mode none \
  --history.transactions 0 \
  --rpc.allow-unprotected-txs \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3

[Install]
WantedBy=multi-user.target

--tries-verify-mode none es el interruptor de “fast node” de la documentación oficial, recomendado para servir RPC cuando acepta el compromiso de consistencia de estado. --history.transactions 0 mantiene el índice de transacciones completo; guías más antiguas usan el ya obsoleto --txlookuplimit 0 con el mismo propósito. TimeoutStopSec=600 le da al nodo diez minutos para volcar datos al apagarse; los cierres forzados terminan corrompiendo la base de datos tarde o temprano.

6. Iniciar y verificar

sudo systemctl daemon-reload
sudo systemctl enable --now bsc
journalctl -fu bsc

Una salida saludable es un flujo constante de líneas “Imported new chain segment”. Compare su altura con un explorador público:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  http://127.0.0.1:8545

Convierta el resultado hexadecimal y compárelo con bscscan.com. Cuando eth_syncing devuelva false y la altura coincida, el nodo está en vivo.

Cómo asegurar un nodo RPC de BSC

La unidad anterior vincula el RPC a 127.0.0.1, lo cual es correcto para un nodo que solo usa software local. Si otras máquinas necesitan acceso, no abra el puerto 8545 en crudo hacia internet. Ponga nginx o Caddy delante, con TLS, un token de autenticación o una allowlist de IP, y rate limiting. Mantenga --http.api en eth,net,web3; nunca exponga admin, debug o txpool en un nodo accesible. Los endpoints públicos de BSC no autenticados se descubren y son atacados en cuestión de días, y las llamadas eth_getLogs sin restricciones pueden tumbar incluso hardware potente. El puerto P2P 30311 sigue siendo el único puerto de blockchain abierto. Merece la pena señalar una diferencia con Ethereum: aquí no hay engine API ni secreto JWT, porque Parlia no necesita un cliente de consenso separado; el firewall y el binding a localhost son todo el perímetro, así que tienen que estar bien configurados.

Monitorización y comprobaciones de salud

Un nodo BSC falla de una forma típica: el proceso sigue en ejecución mientras el nodo se queda atrás de la cabeza. Las comprobaciones de uptime a nivel de proceso pasan esto por alto por completo, así que compruebe el estado de sincronización y la altura en su lugar.

# false = at the head; a sync object = still catching up
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

# peer count as hex
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

La comprobación más estricta compara su eth_blockNumber con una segunda fuente —un endpoint público o un explorador— cada pocos minutos, y alerta si la brecha crece. Calibre el umbral al ritmo de BSC: 400 bloques suena a mucho y son tres minutos de tiempo de cadena con bloques de 0,45 segundos. Los umbrales copiados de herramientas de Ethereum son aquí demasiado laxos.

El fork hereda la pila de métricas de Geth. Empiece con --metrics (endpoint de Prometheus en el puerto 6060, manténgalo en localhost), y los dashboards estándar de Geth en Grafana funcionan en su mayoría sin cambios. Antes de cualquier dashboard, configure dos alertas: uso de disco por encima del 85 % y altura de bloque local estancada durante cinco minutos. Un journalctl -u bsc --since -24h | grep -ci error diario en un correo de cron redondea el conjunto: los recuentos de errores en aumento anticipan la mayoría de los fallos con días de antelación.

Tiempo de sincronización, y por qué los snapshots siguen siendo útiles

Aritmética en lugar de promesas: el snapshot podado de 1,6 TB, a 100 MB/s sostenidos, tarda unas 4,5 horas en descargarse, a 50 MB/s unas 9. La extracción está limitada por el disco y añade unas horas en NVMe. El snapshot va uno o dos días por detrás de la cabeza de la cadena; un nodo saludable importa varias veces más rápido que en tiempo real, así que ponerse al día cuesta horas, no días. En total, planifique una jornada laboral. La sincronización desde el génesis, en cambio, corre durante semanas en hardware extremo, por lo que la recomendación oficial es el snapshot, punto.

Crecimiento del estado y poda

La base de datos sigue creciendo después del primer día: estado con cada nuevo contrato y cuenta, datos de bloque al ritmo que dictan los bloques de 0,45 segundos. El crecimiento exacto depende de la actividad de la red; en lugar de confiar en una cifra fija, ejecute du -sh /var/lib/bsc/geth/chaindata semanalmente y construya su propia línea de tendencia. El patrón a esperar: cientos de GB por trimestre, no por año.

Tres herramientas mantienen el tamaño bajo control. geth-bsc snapshot prune-state es la poda offline integrada: descarta nodos de estado a los que ya nada hace referencia, tarda muchas horas en una base de datos multi-terabyte, y el nodo no sirve nada mientras tanto. Wipe-and-restore es la alternativa que muchos operadores prefieren: cada pocos meses, borrar el datadir y restaurar el snapshot podado más reciente. El tiempo de inactividad total suele ser menor que con la poda, y obtiene de propina una base de datos recién compactada.

La tercera herramienta llegó con Fermi: los snapshots incrementales (BEP-593). En lugar de volver a descargar 1,6 TB en cada actualización, solo trae lo que ha cambiado desde la generación de snapshot que ya tiene, lo que convierte la actualización periódica de un trabajo nocturno en cuestión de horas. El README de bsc-snapshots documenta ese flujo de trabajo junto a los archivos clásicos.

Erigon en BSC — y su sucesor

Durante años, la respuesta a las necesidades de archive en BSC fue bsc-erigon, el port de Erigon de NodeReal: una sincronización de archive completa desde cero en unos tres días, almacenada en unos 4,3 TB donde el fork geth necesita decenas de terabytes. Ese capítulo se cerró. El mantenimiento terminó a finales de 2025, y el repositorio node-real/bsc-erigon se archivó en abril de 2026: solo lectura, sin correcciones, sin soporte para futuros forks. NodeReal dirige a los operadores hacia Reth-BSC, el sucesor basado en Rust, como cliente de archive recomendado de cara al futuro.

Lo que eso significa en la práctica a mediados de 2026: para el nodo RPC podado de esta guía, el fork geth oficial sigue siendo la referencia y la opción más segura. Para cargas de archive, evalúe primero Reth-BSC, y considere las máquinas bsc-erigon existentes como migraciones pendientes; un cliente sin mantenimiento se pierde el próximo hard fork en su fecha.

Cuánto cuesta un nodo BSC

Tómeselo como una forma de calcular, no como una lista de precios. La clase de 16 núcleos / 64 GB / 4 TB NVMe es territorio de servidor dedicado; ningún nivel honesto de VPS lo cubre. En hosts europeos, máquinas con esas especificaciones se sitúan, como orden de magnitud, en el rango bajo a medio de los tres dígitos de euros al mes. Las mismas especificaciones construidas con instancias en la nube con 8k IOPS aprovisionadas (la referencia de AWS del README) suelen quedar más altas, a menudo por un factor de dos o más, porque las IOPS aprovisionadas se facturan por separado.

Después sume sus horas: configuración inicial de una jornada laboral con esta guía, más actualizaciones por hard forks y refrescos de snapshot de unas pocas horas al mes. Multiplique por su tarifa por hora. Para la mayoría de los equipos, la línea de mano de obra acaba siendo mayor que la de hosting; conviene saberlo antes de comprometerse.

Mantenimiento: hard forks y actualizaciones

BSC hace hard forks a un ritmo que sorprende a los operadores de Ethereum. Solo 2025 trajo Lorentz y Maxwell, cada uno reduciendo a la mitad el intervalo de bloques; Fermi llegó el 14 de enero de 2026 y llevó los bloques de 0,75 a 0,45 segundos mientras añadía snapshots incrementales y reforzaba la finalidad rápida. Cada fork tiene una versión mínima de cliente —v1.6.4 para Fermi— y un nodo por debajo se atasca en el bloque del fork con errores de consenso. A mediados de 2026 la línea de versiones está en v1.7.x, y los snapshots actuales asumen al menos la v1.7.2.

Suscríbase, pues, al feed de releases de bnb-chain/bsc en GitHub y trate las actualizaciones como rutina en lugar de como eventos. El procedimiento es breve: descargar el nuevo geth_linux, verificarlo, detener el servicio, reemplazar /usr/local/bin/geth-bsc, reiniciar; la base de datos se conserva. Las notas de la versión señalan cambios de configuración, y BSC renombra flags con más frecuencia que el Geth upstream, así que revíselas antes de reiniciar, no después. Reserve un cuarto de hora por release, y espere un fork cada pocos meses.

Para configuraciones de desarrollo, hay disponible una red privada local a través del toolkit BSC-Deploy en lugar de ejecutar nodos de mainnet.

Solución de problemas

El nodo importa bloques pero sigue quedándose atrás de la cabeza

Casi siempre son las IOPS del disco. Haga benchmark con fio y compare con la referencia de 8k IOPS; el almacenamiento en red con IOPS por defecto es el culpable habitual. Confirme que --tries-verify-mode none está configurado. Si el hardware está por debajo de la tabla de requisitos, ninguna flag cerrará la brecha.

Errores “missing trie node”, o el nodo empieza a sincronizar desde el bloque 0 tras restaurar un snapshot

El formato del datadir es incorrecto. La base de datos de la cadena debe estar en <datadir>/geth/chaindata; si el log muestra “Writing custom genesis block”, geth encontró un datadir vacío y empezó de cero. Detenga el servicio, mueva la carpeta geth extraída al lugar correcto, reinicie.

El número de peers se queda cerca de cero

Compruebe que el puerto 30311 está abierto y redirigido. Un config.toml desactualizado es el segundo sospechoso: las listas de bootstrap y nodos estáticos cambian con el tiempo, así que vuelva a descargar mainnet.zip desde la última release. En conexiones domésticas, revise también el NAT.

lz4 informa de “Decoding error” durante la extracción

El archivo está incompleto. Reanude la descarga con aria2c -c y compare el tamaño del archivo con el de la página del snapshot antes de volver a extraer. Recuerde que la opción A necesita espacio libre para el archivo y los datos extraídos al mismo tiempo.

El OOM killer termina el nodo

journalctl -k | grep -i oom resuelve la duda. La unidad fija --cache 8000, y el uso real de memoria supera con creces la cifra del caché durante la puesta al día; sin problema con los 64 GB recomendados, sí lo es en hardware recortado. Baje --cache antes de bajar cualquier otra cosa, mantenga el swap activado como amortiguador de caídas, y recuerde que un nodo terminado por OOM no vuelca nada: el siguiente arranque puede recibirle con el caso “missing trie node” de arriba.

El disco se llena

df -h primero, luego du -h --max-depth=2 /var/lib/bsc para encontrar el crecimiento. Los archivos de snapshot olvidados son el hallazgo más común; solo el .tar.lz4 podado ronda 1,6 TB, y la opción A lo deja atrás si se salta la limpieza. Si el problema es el propio chaindata, actualice desde el snapshot podado más reciente o ejecute poda offline (vea la sección sobre crecimiento del estado). En la curva de crecimiento de BSC, un disco lleno es un fallo de planificación, no mala suerte; la alerta del 85 % de la sección de monitorización existe para darle la semana que necesita.

Preguntas frecuentes

¿Es un nodo Binance Smart Chain lo mismo que un nodo BNB Smart Chain?

Sí. La cadena se renombró de Binance Smart Chain a BNB Smart Chain en febrero de 2022. La documentación, los binarios y esta guía describen todos la misma red; solo cambió la marca.

¿Cuánto pesa un full node de BSC en 2026?

El snapshot podado oficial pesa aproximadamente 1,6 TB comprimido a mediados de 2026, el snapshot completo unos 6 TB, y la base de datos de trabajo más los datos de puesta al día rondan los 2-3 TB. Con el espacio temporal necesario durante la extracción del snapshot, un disco NVMe de 4 TB es el tamaño realista.

¿Puedo ejecutar un nodo BSC con el Geth de Ethereum normal?

No. BSC usa el consenso Parlia y sus propias reglas de protocolo; solo el fork en github.com/bnb-chain/bsc puede sincronizarlo. El nombre de binario idéntico causa esta confusión, de ahí el renombrado a geth-bsc en el paso 2.

¿Existe un nodo ligero de BSC?

Prácticamente no. El código de light-client existe en el fork, pero la red apenas sirve a peers ligeros. Sus opciones realistas son un full node podado, un fast node o una API.

¿Gano BNB por ejecutar un full node?

No. Las recompensas de bloque van al conjunto de validadores elegidos, lo que requiere BNB en staking sustancial y votos de la comunidad. Un full node le da acceso independiente a la cadena, no ingresos.

¿Ejecutar su propio nodo, o usar una API?

Una comparación honesta, ya que Chaingateway vende la alternativa.

Ejecute el nodo cuando consuma JSON-RPC en bruto a un volumen alto y sostenido —indexación, backtesting, escaneo de logs sobre millones de bloques— o cuando ningún tercero pueda situarse entre usted y la cadena. Un servidor dedicado es un coste fijo con peticiones ilimitadas, y a partir de cierto volumen de llamadas vence a cualquier plan medido. El punto de equilibrio llega antes en BSC que en la mayoría de las cadenas, precisamente porque el listón de hardware es alto pero plano.

Use una API cuando el nodo solo fuera tubería para pagos. Un full node de BSC sincronizado le da eth_sendRawTransaction y logs; todo lo que un sistema de pagos realmente necesita —direcciones de depósito por cliente, detección de transferencias BEP-20 entrantes, webhooks firmados, almacenamiento de claves, reintentos— es software que tendría que construir encima y mantener en funcionamiento. Esas horas de ingeniería, a las tarifas de la sección de costes, superan con creces la factura del servidor.

La API de BNB Smart Chain de Chaingateway cubre esa capa como REST: importar direcciones (POST /api/v2/bsc/addresses/import), enviar tokens BEP-20 (POST /api/v2/bsc/transactions/bep20), y recibir webhooks de depósito firmados con HMAC — GET /api/v2/bsc/webhooks/notifications/failed lista las entregas fallidas, y cada una puede reenviarse mediante el endpoint de reintento. El punto de equilibrio en una frase: servidor dedicado más sus horas de construcción y operación, frente a un plan en /es/pricing/. Para flujos de pago, la API sigue siendo más barata mucho más allá de la escala de pequeña empresa; para potencia RPC en bruto, el nodo gana pronto. El quickstart y la guía de webhooks le llevan a una primera prueba en minutos, y el periodo de prueba de 7 días no necesita KYC (registro).

¿También ejecuta otras cadenas? Vea las guías de configuración para Ethereum y TRON.