BNB Chain implementó la actualización BEP-675 en su BSC Testnet el 7 de agosto, aumentando el rendimiento de 1.237 transacciones por segundo a 2.324 TPS. Se trata un aumento del 88%, logrado sin modificar el intervalo de bloque ni el límite de gas.
Cómo funciona realmente BEP-675
Antes de esta actualización, el proceso de construcción de bloques de BSC tenía un problema significativo de redundancia. Los constructores de bloques ensamblaban y ejecutaban transacciones, y luego los validadores re-ejecutaban esas mismas transacciones para verificarlas.
BEP-675 introduce un nuevo mecanismo llamado SendBidBlock, que permite a los constructores de bloques enviar bloques completamente ejecutados directamente. Los validadores pueden omitir el paso redundante de re-ejecución, confiando en los resultados pre-ejecutados mientras mantienen el modelo de seguridad de la cadena.
Las mejoras de rendimiento al eliminar esa redundancia son dramáticas. El tiempo de ejecución del validador de la ruta crítica disminuyó de aproximadamente 125 ms a solo 15 ms. Para ponerlo en perspectiva, el paso de ejecución que antes consumía más de una cuarta parte de cada intervalo de bloque de 450 ms ahora representa aproximadamente el 3%.
Ese espacio liberado se traduce directamente en un mayor uso de gas. El uso mediano de gas por bloque aumentó de 29,49M a 98,99M, lo que significa que los bloques que anteriormente utilizaban menos de un tercio de su límite de 100M de gas ahora se llenan casi por completo. Mismo tamaño de bloque, mismo tiempo de bloque, significativamente más cálculo real por bloque.
La actualización se redactó inicialmente como una propuesta el 10 de abril y se puso en funcionamiento en la testnet aproximadamente cuatro meses después. Los flujos Legacy SendBid siguen siendo compatibles para mantener la compatibilidad hacia atrás, aunque los desarrolladores que deseen utilizar el nuevo mecanismo SendBidBlock necesitan operar un nodo completo.
La configuración de prueba y lo que viene a continuación
BNB Chain realizó la evaluación de testnet utilizando una configuración interna de QANet entre regiones diseñada para replicar la topología real del mainnet. Al simular condiciones entre regiones, la cifra de 2,324 TPS debería ser una aproximación más cercana a lo que el mainnet podría ofrecer realmente.
La prueba cubrió varias cargas de trabajo de transacciones, no solo transferencias simples de tokens.
BEP-675 se enmarca dentro de una hoja de ruta técnica más amplia para BNB Chain en el segundo semestre de 2026. La cadena ha seguido una trayectoria agresiva de escalado, habiendo reducido ya los intervalos de bloque a 450 ms y acercado el rendimiento de referencia a cerca de 5.200 TPS en fases anteriores durante 2025 y principios de 2026. El siguiente objetivo es duplicar nuevamente el rendimiento del mainnet, con un objetivo a largo plazo de lograr mejoras de 10 veces sobre el rendimiento base actual.
Tras la fase exitosa de testnet, los siguientes pasos inmediatos incluyen la validación a escala mainnet. La hoja de ruta también contempla mejoras adicionales, como FOCIL (que se refiere a listas de inclusión forzada, un mecanismo diseñado para prevenir la censura en el nivel de producción de bloques) y Listas de Acceso a Nivel de Bloque, que podrían optimizar aún más la eficiencia de ejecución.
Por qué el MEV es importante aquí
BEP-675 reduce la carga operativa que la infraestructura MEV impone sobre la ruta crítica de la cadena. BNB Chain definió explícitamente la actualización como una solución a los cuellos de botella causados por ineficiencias de MEV. Al rediseñar el mecanismo de envío para que los constructores entreguen bloques completamente ejecutados, se elimina el paso redundante de re-ejecución que era en parte consecuencia de las suposiciones de confianza integradas en las arquitecturas conscientes de MEV.
Si el despliegue en mainnet coincide con los resultados de testnet, BNB Chain habrá duplicado casi su rendimiento práctico sin requerir que los usuarios o desarrolladores de dapps modifiquen nada sobre cómo interactúan con la red. Las garantías de finalidad y el tiempo de bloque permanecen idénticos.