BSC eleva el límite de gas del bloque a 70 millones: qué cambió el 14-15 de septiembre de 2026
Los validadores de BNB Smart Chain coordinaron una subida del límite de gas por bloque a 70 millones el 14-15 de septiembre de 2026, tras el hard fork Pasteur. Este artículo explica qué habilitó BEP-675, por qué la red corría al 95% de utilización, cómo funciona el límite dinámico y hacia dónde apunta la hoja de ruta.

Los validadores de BSC elevaron el límite de gas por bloque a 70 millones el 14-15 de septiembre de 2026. Qué cambió con BEP-675, por qué era necesario y qué viene después.
El 14 y 15 de septiembre de 2026, los validadores de BNB Smart Chain completaron una actualización coordinada que elevó el objetivo del límite de gas por bloque de aproximadamente 55 millones a 70 millones. Es la primera subida de capacidad explícita desde que el hard fork Pasteur se activó el 25 de agosto, y constituye la señal más concreta de que BEP-675 — el cambio arquitectónico que Pasteur introdujo — funciona lo suficientemente bien bajo tráfico real como para justificar subir el techo.
La actualización no fue una decisión repentina. Se basó en tres semanas de datos de mainnet que mostraban que BidBlock V2, la nueva ruta de construcción de bloques introducida por BEP-675, había alcanzado el 98% de adopción entre los bloques producidos por builders y promediaba un 28% más de gas por bloque que el método anterior. La red también corría por encima del 95% de utilización, lo suficientemente cerca del límite como para que las subidas de comisiones y la congestión fueran un resultado previsible sin intervención.
Por qué la red necesitaba más capacidad ahora
El límite de gas por bloque establece la cantidad total de trabajo computacional que puede caber en un bloque. Cada transacción en BSC consume una cantidad de gas: una transferencia simple de BNB usa 21.000 gas, un swap en DeFi típicamente entre 100.000 y 300.000, y las interacciones complejas con protocolos como PancakeSwap o Venus pueden consumir bastante más. Cuando los bloques se llenan, las transacciones pendientes esperan más tiempo y el mercado de comisiones — que se ajusta dinámicamente — sube los precios del gas para racionar el espacio disponible.
BSC entró en septiembre de 2026 con un límite de 55 millones de gas y una utilización sistemáticamente por encima del 95%. Eso dejaba casi ningún margen ante picos de demanda. Un aumento del volumen de trading, el lanzamiento de un token popular o un breve episodio de congestión podrían elevar las comisiones notablemente para los usuarios comunes. Los validadores decidieron no esperar a que eso ocurriera.
El momento importa porque la actualización era contingente a que la arquitectura Pasteur se probara a sí misma. BEP-675 necesitaba ser estable a escala antes de que el equipo se sintiera cómodo aumentando el techo. Los datos de la primera semana después del 25 de agosto aportaron esa evidencia, y la ventana del 14-15 de septiembre fue la primera oportunidad planificada para actuar en consecuencia.
Qué cambió BEP-675 en la producción de bloques
Para entender por qué una subida del límite de gas es menos arriesgada ahora que antes de Pasteur, conviene saber qué cambió realmente BEP-675.
Antes de Pasteur, construir un bloque en BSC implicaba tres pasadas por la Máquina Virtual de Ethereum. Un builder ejecutaba las transacciones para construir un bloque candidato, lo enviaba a un validador, y el validador volvía a ejecutar las mismas transacciones antes de sellar el bloque. Esa tercera pasada era una comprobación de seguridad, pero también era computación redundante: el validador reproducía trabajo que el builder ya había hecho.
BEP-675 introdujo un procedimiento llamado SendBidBlock que permite a los builders enviar un bloque completamente ejecutado — incluyendo resultados de transacciones y cambios de estado — directamente al validador. El validador puede entonces ensamblar y sellar el bloque sin reproducir cada transacción de usuario. El resultado es que más tiempo de la ventana de sellado del bloque está disponible para que los builders empaqueten transacciones, y los validadores dedican menos tiempo a trabajo ya realizado. La comprobación de corrección sigue ocurriendo después de que el bloque se difunde: los validadores ejecutan el bloque durante la importación local y verifican la raíz de estado, los recibos y otros compromisos. Bid V1 sigue disponible como alternativa de seguridad.
Bajo condiciones reales de mainnet, este cambio arquitectónico produjo bloques BidBlock V2 que promediaron un 28% más de gas que los bloques Bid V1. En el percentil 99 — los bloques con mayor densidad — BidBlock V2 alcanzó 43,8 millones de gas frente a los 33,8 millones de Bid V1. Ambas cifras están por debajo del límite de 55M, lo que significa que aún había margen. Elevar el límite a 70 millones crea más de ese margen sin exigir que la red opere al borde de su capacidad.
El mecanismo del límite de gas dinámico
Un aspecto de la actualización a 70M que la distingue de un simple cambio de configuración es cómo se establece el objetivo. Los validadores no codifican de forma fija 70 millones en sus nodos. En cambio, cada validador calcula el objetivo de forma dinámica, basándose en las condiciones de la red en tiempo real: plenitud reciente de bloques, bloques perdidos, latencia y otras señales de salud. Los 70 millones son el objetivo hacia el que convergen los validadores, no un techo fijo que se aplica uniformemente independientemente de lo que experimente la red.
Esto importa por varias razones. Significa que el límite de gas efectivo puede ajustarse ligeramente por debajo de 70M si la red muestra señales de estrés: bloques perdidos, latencia elevada o comportamiento anómalo en los bloques. También significa que los validadores son responsables de monitorizar su propia capacidad de hardware a medida que crecen las cargas útiles de los bloques. Los bloques más grandes tardan más en propagarse por la red, más en ejecutarse durante la importación y generan más datos que todos los nodos conectados deben procesar.
Las instrucciones de @BNBChainDevs a los validadores durante la actualización fueron específicas: establecer el gas limit objetivo en 70 millones, reiniciar el nodo, y reconsiderar los presupuestos de simulación de empaquetado de bloques para tener en cuenta la ventana de bloque más grande. La instrucción de no codificar de forma fija 70M fue explícita: la derivación dinámica a partir del bloque padre es necesaria para que el mecanismo funcione correctamente.
Qué significa para usuarios y aplicaciones en BSC
Para los usuarios cotidianos — enviar BNB, hacer swaps en PancakeSwap, depositar colateral en Venus — el efecto más inmediato de un límite de gas más alto es la reducción de la probabilidad de picos de comisiones y colas de transacciones durante períodos de alta demanda. Una red que corre al 55M con 95% de utilización tiene casi ningún margen. Una red con un techo de 70M y la misma demanda subyacente tiene aproximadamente un 27% más de capacidad antes de alcanzar la misma presión.
Para aplicaciones como PancakeSwap, que ya procesaba alrededor de 29.000 millones de dólares en volumen DEX a 30 días en septiembre de 2026, más espacio en los bloques significa que más transacciones pueden liquidarse en la misma ventana de tiempo. Para las plataformas de RWA, los protocolos DeFi y los productos de renta variable tokenizada que requieren ejecución multistep atómica, los bloques más grandes reducen el riesgo de que una transacción falle por no caber en un bloque congestionado.
Los usuarios no necesitan hacer nada. La actualización ocurre en el nivel de los validadores. No hay reconfiguración de wallet, no hay cambio de red, no hay nuevos endpoints RPC. Los precios del gas pueden bajar a medida que la utilización relativa cae desde el nivel anterior de 95%+, aunque el mercado de comisiones eventualmente alcanzará un nuevo equilibrio según la demanda se ajuste al espacio disponible.
Riesgos y requisitos de infraestructura
Los límites de gas más altos no son gratuitos. Los bloques más grandes requieren más ancho de banda para la propagación entre nodos, más memoria y CPU para la ejecución, y más E/S de disco a medida que se acumulan los cambios de estado. A medida que BSC avanza hacia 70M y más allá, varias actualizaciones de infraestructura están en desarrollo para mantener la red en buen estado.
Una es el cambio de entrega de bloques en JSON y hexadecimal a datos RLP codificados sobre gRPC, que reduce la sobrecarga de serialización y mejora la entrega de BidBlocks grandes bajo presión de latencia. Otra es eth/70, un protocolo revisado de sincronización entre pares que permite que los recibos de bloque abarquen múltiples respuestas — importante porque el protocolo actual crea un límite práctico alrededor de 83 millones de gas, donde los recibos ya no caben en una sola respuesta de 10 MiB. Una tercera son las Listas de Acceso a Nivel de Bloque (BAL), que exponen los accesos de estado con anticipación y habilitan técnicas como la precarga de estado y la ejecución paralela consciente de dependencias. BAL no es necesaria para el paso de 70M pero forma parte del camino hacia 90M.
También existe un riesgo de centralización de validadores que vale la pena mencionar explícitamente. Si las cargas útiles de los bloques crecen significativamente, solo los validadores con hardware de alto rendimiento podrán procesarlas de forma fiable. Eso crea presión para que los validadores con menos recursos abandonen el conjunto activo, lo que podría reducir la amplitud del grupo de validadores con el tiempo. El enfoque secuencial de BSC, con datos de mainnet como requisito previo para cada paso, está diseñado para detectar este riesgo antes de que se materialice, pero sigue siendo una preocupación estructural para cualquier red que escale el tamaño del bloque en lugar de la frecuencia de los bloques.
Lo que viene: 80M y 90M
El objetivo de 70 millones está explícitamente posicionado como un paso en una hoja de ruta de tres etapas. Los desarrolladores de BSC han trazado objetivos secuenciales de 70M, 80M y potencialmente 90M, con cada incremento condicionado a la evidencia de mainnet de la etapa anterior: tasas de finalidad, frecuencia de bloques perdidos, comportamiento con bloques grandes, latencia entre regiones, tiempos de importación de nodos, cuota de mercado de builders y salud del path de fallback.
A 90M, la actualización del protocolo eth/70 se vuelve necesaria porque la arquitectura actual de propagación de recibos no puede soportar bloques de ese tamaño sin un mecanismo de división de respuestas. BAL también puede volverse importante a esa escala para una ejecución paralela eficiente. El equipo ha dejado claro que estas son metas, no fechas garantizadas.
A modo de contexto sobre dónde sitúa esto a BSC en el panorama EVM más amplio: la mainnet de Ethereum típicamente opera con bloques en el rango de 15-30M de gas, aunque su Gas Limit actual ronda los 36M. El movimiento de BSC a 70M refleja una elección arquitectónica deliberada de priorizar el rendimiento sobre la gestión de capacidad más conservadora de la mainnet de Ethereum. La contrapartida son mayores requisitos de hardware para los validadores y el trabajo de infraestructura descrito anteriormente.
Fuentes
- Blog de BNB Chain — Post-Pasteur Hard Fork: BSC Packs 28% More Gas Per Block (14 septiembre 2026)
- @BNBChainDevs en X — hilo sobre la actualización del límite de gas (14 septiembre 2026)
- @BNBChainDevs en X — instrucciones a validadores para el objetivo de 70M
- BEP-675 — Builder-Proposed Block with Validator Blind Signing (GitHub)