BNB Chain activó el hard fork Pasteur en la red principal de BNB Smart Chain a las 02:30 UTC del 25 de agosto, introduciendo tres cambios centrados en la seguridad del puente, la autorización de validadores y la capacidad de bloques.
Resumen
- BNB Chain activó Pasteur en la red principal de BSC a las 02:30 UTC del 25 de agosto de 2026, con éxito.
- Tres propuestas fortalecen la verificación del puente, la autorización de validadores y la construcción de bloques sin acortar aún más los tiempos de bloque.
- BEP-682 rechaza validadores duplicados durante las comprobaciones de bloques ligeros entre cadenas, protegiendo ahora en cadena los requisitos de aprobación de supermayoría genuinos.
- Los puntos de referencia de QANet aumentaron el rendimiento un 88%, de 1.237 a 2.324 transacciones por segundo en condiciones controladas.
- Los operadores de nodos necesitaban la versión 1.7.7 del cliente y la eliminación de EnableBAL antes de que comenzara la activación en la red principal el martes.
La red confirmó que Pasteur estaba activo tras su activación programada. BSC continuó produciendo bloques en su intervalo existente de 450 milisegundos, sin que se informara públicamente de ninguna interrupción importante inmediatamente después de la actualización.
Pasteur combina BEP-682, BEP-695 y BEP-675 bajo el plan de actualización más amplio BEP-673. Los cambios habían operado en la testnet Chapel de BSC desde el 21 de julio antes de llegar a la red principal.
BNB Chain Pasteur fortalece la verificación del puente
BEP-682 cambia la forma en que BSC verifica los bloques ligeros enviados a través de la infraestructura entre cadenas. Antes de Pasteur, el proceso de verificación no rechazaba explícitamente las entradas duplicadas en una lista de validadores enviada.
Una solicitud manipulada podría, por tanto, incluir al mismo validador más de una vez. Contar esas entradas por separado corría el riesgo de hacer que una aprobación del puente pareciera tener el apoyo de más validadores independientes de los que realmente tenía.
Pasteur rechaza las entradas de validadores repetidas antes de calcular si se ha alcanzado el umbral de votación requerido. Cada aprobación debe provenir ahora de un validador distinto para que el bloque ligero cumpla el requisito de supermayoría.
BNB Chain no informó de que los atacantes hubieran explotado la falla ni atribuyó a ella pérdidas de activos anteriores. El cambio es una corrección preventiva de la verificación del puente, no una respuesta a un robo divulgado.
La infraestructura entre cadenas sigue siendo una gran preocupación de seguridad en las redes descentralizadas. En cobertura relacionada, los ataques a puentes han causado pérdidas acumuladas de miles de millones de dólares a través de claves comprometidas, fallas de contratos y verificación débil de mensajes.
Las claves antiguas de validadores pierden su autoridad
BEP-695 cierra brechas relacionadas con la rotación de claves de validadores, las penalizaciones y la gobernanza. Cuando un validador reemplaza su clave de operador, la clave anterior pierde ahora sus derechos de gestión.
La propuesta también impide que los validadores eviten penalizaciones pendientes rotando sus claves. Los procesos de slashing y eliminación permanecen vinculados al validador en lugar de desaparecer cuando cambia su dirección de operador.
Pasteur bloquea además que las direcciones restringidas utilicen firmas fuera de la cadena para participar en la gobernanza. BNB Chain ya impedía que las direcciones en la lista negra votaran directamente, pero esas cuentas podían firmar votos y hacer que otra dirección los enviara.
Los contratos de gobernanza actualizados verifican al firmante original antes de contar un voto delegado. Si ese firmante está restringido, el voto se rechaza independientemente de qué cuenta lo envíe.
La nueva ruta de bloques reduce la ejecución repetida
BEP-675 introduce una ruta opcional para que los constructores especializados envíen bloques que ya han ejecutado. Los validadores comprueban el bloque propuesto contra las reglas de consenso, lo firman y lo transmiten antes de completar la verificación completa de ejecución.
La ruta anterior requería que tanto el constructor como el validador ejecutaran las transacciones antes de que el validador firmara. Esa duplicación consumía parte de la breve ventana de bloque de BSC y podía dejar los bloques por debajo de su capacidad máxima durante períodos de alta demanda.
Los constructores pueden continuar usando el proceso anterior. La nueva ruta debe habilitarse a través de la interfaz de llamada a procedimiento remoto de la red, dando tiempo a los participantes para integrarla.
BNB Chain dijo que la ruta podría incluir más transacciones en cada bloque, pero sus cifras de rendimiento publicadas provienen de pruebas controladas, no de la actividad de la red principal.
Las pruebas en QANet, un entorno interno diseñado para reflejar validadores distribuidos geográficamente, aumentaron el rendimiento de 1.237 a 2.324 transacciones por segundo. El consumo promedio de gas por bloque aumentó de 46,35 millones a 84,15 millones, mientras que el límite de gas de 100 millones permaneció sin cambios.
Los datos de la red principal pondrán a prueba la ganancia de capacidad del 88%
Pasteur no aumenta el límite de gas por bloque ni reduce el intervalo de bloque de 450 milisegundos introducido por la actualización Fermi. Sus ganancias de capacidad dependen de que los constructores adopten BEP-675 y envíen bloques más completos.
BNB Chain requirió que los operadores de nodos instalaran la versión 1.7.7 del cliente antes de la activación. Los operadores también debían eliminar el campo obsoleto EnableBAL porque dejarlo en el archivo de configuración impediría que el cliente actualizado se iniciara.
Como se informó anteriormente, BNB Chain advirtió a los operadores que completaran la actualización obligatoria de Pasteur antes de la bifurcación. Los operadores que ejecutaran software incompatible corrían el riesgo de perder la sincronización con la red principal.
La próxima evidencia provendrá de la utilización de bloques en vivo, el rendimiento de transacciones, las tasas de bloques perdidos y el rendimiento de los validadores. Esas mediciones mostrarán si la mejora de capacidad de QANet se traslada a la demanda sostenida de la red principal.
