El “hard fork” “Pasteur” de BNB Chain entra en funcionamiento el 25 de agosto — lo que debes saber BNB Chain activará el hard fork Pasteur en BNB Smart Chain a las 02:30 UTC del 25 de agosto de 2026. La actualización obligatoria (cliente v1.7.7) implementa tres propuestas a nivel de protocolo que refuerzan la seguridad de los puentes, limitan las soluciones alternativas de los validadores y aumentan la capacidad de procesamiento de bloques. Todos los nodos de la red principal de BSC deben ejecutar el nuevo cliente antes de la activación; los usuarios comunes y la mayoría de los desarrolladores de dApp no necesitan mover fondos ni cambiar su software. Qué cambia - BEP-682 — verificación más sólida entre cadenas: BSC validará ahora las firmas de los validadores antes de aceptar datos de bloques de otra cadena. La actualización evita que se construyan conjuntos de validadores de forma especial para contar dos veces el poder de voto de un único validador, rechazando entradas duplicadas de validadores, de modo que el umbral de votación refleje un verdadero supermayoritario. - BEP-695 — endurecimiento de claves de consenso y gobernanza: cuando los validadores rotan claves de consenso, la clave de consenso anterior perderá privilegios administrativos (ya no conservará la autoridad después de la rotación). Las expulsiones pendientes por slashing seguirán a un validador hasta su nueva clave, deteniendo intentos de evadir penalizaciones cambiando claves. La propuesta también bloquea a direcciones en listas negras de eludir restricciones mediante votaciones de gobernanza basadas en firmas. Estos cambios afectan a los contratos del sistema de staking y gobernanza, pero se implementan a nivel de protocolo/contrato del sistema, por lo que los desarrolladores no tendrán que migrar aplicaciones existentes. - BEP-675 — ruta de bloque más rápida y preejecutada para constructores: los constructores pueden enviar bloques que ya han ejecutado; los validadores pueden firmar y difundir esos bloques rápidamente y completar la verificación completa fuera de la ruta de producción sensible al tiempo. Esta opción exige que los constructores ejecuten nodos completos, ya que producirán bloques totalmente ejecutados. Las ofertas de bloques heredadas seguirán existiendo, pero darán a los constructores menos tiempo para llenar bloques. Rendimiento en pruebas (QANet) BNB Chain probó Pasteur en QANet — un entorno interno que replica la configuración de validadores entre regiones de BSC — y observó mejoras considerables en un entorno controlado: - El tiempo de procesamiento de la ruta crítica bajó de 125 ms a 15 ms. - El gas promedio usado por bloque subió de 46,35M a 84,15M (frente al límite existente 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 advierte que estas son cifras de laboratorio de QANet; aún no se han confirmado mejoras comparables en la red principal. Tras la activación en mainnet, los operadores y desarrolladores observarán cuánto de las ganancias del testnet se traslada al tráfico en vivo. Lista de verificación para operadores de nodo (obligatoria) - Instala el cliente v1.7.7 antes de la hora de activación. Los nodos de mainnet que no se actualicen quedarán rezagados. - Elimina [Eth] EnableBAL de config.toml — si no lo haces, el cliente actualizado fallará al iniciarse. - Se recomienda eliminar [TxPool] OverflowPoolSlots (el cliente ignorará este campo de forma silenciosa si se deja). - Varias opciones de línea de comandos ahora son obsoletas o están inactivas, incluidas --journalfile, --enablebal y --txpool.overflowpoolslots. Antecedentes y contexto El enfoque de Pasteur es distinto al de las actualizaciones recientes de BSC que principalmente acortaron los tiempos de bloque. En cambio, este fork busca aprovechar mejor la capacidad de bloque existente mientras cierra brechas de seguridad en torno a transferencias entre cadenas y la autoridad de los validadores. Pasteur ha estado funcionando en el testnet de BSC desde el 21 de julio; su llegada a mainnet será la prueba real de si las mejoras de capacidad y rendimiento de QANet se materializan bajo tráfico del mundo real. Si operas un nodo, ejecutas un validador o construyes a nivel de protocolo, actualiza al cliente v1.7.7 y sigue la guía de configuración antes de las 02:30 UTC del 25 de agosto para evitar interrupciones del servicio. Los usuarios habituales y la mayoría de los desarrolladores de aplicaciones no deberían necesitar tomar medidas. Lee más noticias generadas por IA en: undefined/news