BNB Chain activará el hard fork "Pasteur" el 25 de agosto para reforzar la seguridad y elevar la capacidad

BNB Chain activará el hard fork "Pasteur" en BNB Smart Chain (BSC) el 25 de agosto de 2026 a las 02:30 UTC. La actualización, obligatoria, exige el cliente v1.7.7 e incorpora tres propuestas a nivel de protocolo orientadas a reforzar la seguridad de los puentes, cerrar vías de escape para validadores y aumentar la capacidad de procesamiento de bloques. Todos los nodos de la mainnet de BSC deben ejecutar el nuevo cliente antes de la activación. Para usuarios habituales y la mayoría de desarrolladores de dApps no se esperan cambios: no es necesario mover fondos ni modificar el software. Cambios principales BEP-682: verificación cross-chain más estricta BSC verificará las firmas de los validadores antes de aceptar datos de bloques procedentes de otra cadena. El cambio evita que conjuntos de validadores diseñados de forma específica inflen el poder de voto contando dos veces a un mismo validador: se rechazarán entradas duplicadas, de modo que el umbral de votación refleje una supermayoría real. BEP-695: refuerzo de claves de consenso y gobernanza Cuando los validadores roten sus claves de consenso, la clave antigua perderá privilegios administrativos y no conservará autoridad tras la rotación. Las expulsiones por "slashing" que estén pendientes se trasladarán a la nueva clave del validador, para impedir que se esquiven sanciones cambiando de clave. La propuesta también bloquea que direcciones en lista negra eludan restricciones mediante votación de gobernanza basada en firmas. Estos ajustes impactan en contratos de sistema de staking y gobernanza, pero se aplican a nivel de protocolo/contrato de sistema, por lo que no se requiere migración de aplicaciones existentes. BEP-675: vía de bloques pre-ejecutados para constructores Los "builders" podrán enviar bloques ya ejecutados; los validadores podrán firmarlos y difundirlos con rapidez, dejando la verificación completa fuera de la ruta crítica sensible al tiempo. Esta opción exige que los builders operen nodos completos, ya que deberán producir bloques totalmente ejecutados. Las pujas de bloques heredadas seguirán disponibles, aunque con menos tiempo para rellenar bloques. Resultados de pruebas en QANet BNB Chain probó Pasteur en QANet, un entorno interno que replica la configuración de validadores multirregión de BSC, y observó mejoras relevantes en condiciones controladas: - El tiempo de procesamiento de la ruta crítica cayó de 125 ms a 15 ms. - El gas medio por bloque subió de 46,35M a 84,15M (frente al límite actual de 100M). - El rendimiento aumentó de ~1.237 a ~2.324 transacciones por segundo. - El intervalo de bloque se mantuvo en 450 ms y la latencia de finalidad no cambió. BNB Chain subraya que se trata de métricas de laboratorio en QANet; todavía no hay confirmación de mejoras equivalentes en mainnet. Tras la activación, operadores y desarrolladores seguirán de cerca cuánto de ese avance se traslada al tráfico real. Lista de verificación para operadores de nodos (obligatorio) - Instalar el cliente v1.7.7 antes de la activación. Los nodos de mainnet que no actualicen quedarán fuera. - Eliminar "[Eth] EnableBAL" de "config.toml"; si se mantiene, el cliente actualizado fallará al arrancar. - Recomendación: eliminar "[TxPool] OverflowPoolSlots" (si se deja, el cliente ignorará el campo silenciosamente). - Varias flags de línea de comandos pasan a estar obsoletas o inactivas, incluidas "journalfile", "enablebal" y "txpool.overflowpoolslots". Contexto A diferencia de actualizaciones recientes de BSC centradas principalmente en acortar tiempos de bloque, Pasteur busca aprovechar mejor la capacidad existente y cerrar brechas de seguridad relacionadas con transferencias cross-chain y la autoridad de los validadores. Pasteur está en testnet de BSC desde el 21 de julio; su llegada a mainnet será la prueba clave para comprobar si los incrementos de capacidad y rendimiento vistos en QANet se materializan bajo condiciones reales. Quienes operen nodos, validen o desarrollen a nivel de protocolo deben actualizar a v1.7.7 y aplicar los cambios de configuración antes de las 02:30 UTC del 25 de agosto para evitar interrupciones. Los usuarios y la mayoría de desarrolladores de aplicaciones no deberían tener que hacer nada.