BNB Chain activará mañana el hard fork Pasteur con nuevas defensas para puentes

BNB Chain activará Pasteur el 25 de agosto con cambios para reforzar la seguridad de los puentes, ordenar la gobernanza de validadores y acelerar el procesamiento de bloques. Los operadores deberán actualizar sus nodos, mientras las pruebas de QANet mostraron un aumento de rendimiento que todavía no está garantizado en la red principal.

***

• El hard fork Pasteur se activará en BNB Smart Chain el 25 de agosto de 2026 a las 02:30 UTC.
• Los operadores de nodos deben instalar la versión 1.7.7 y eliminar EnableBAL de su configuración.
• Las propuestas BEP-682, BEP-695 y BEP-675 modifican la validación de puentes, la rotación de claves y el procesamiento de bloques.
• QANet registró 2.324 TPS en pruebas controladas, aunque BNB Chain no garantiza que ese rendimiento se replique en la red principal.

BNB Chain activará el hard fork Pasteur en la red principal de BNB Smart Chain el 25 de agosto de 2026 a las 02:30 UTC.

La actualización obligatoria reúne cambios destinados a reforzar la validación de puentes, ajustar la gobernanza de los validadores y mejorar la eficiencia con la que se procesan los bloques.

Según la información divulgada por Crypto.news, los operadores de nodos deben ejecutar la versión 1.7.7 antes de la activación, aunque los usuarios comunes y la mayoría de los desarrolladores de aplicaciones no tendrían que mover fondos ni modificar su software.

Pasteur llega después de haber funcionado en la red de pruebas desde el 21 de julio, lo que permitió a los desarrolladores observar sus efectos antes del despliegue en producción. A diferencia de algunas actualizaciones recientes que redujeron los tiempos de bloque, esta propuesta concentra su atención en la seguridad de las transferencias entre cadenas, la autoridad de los validadores y la capacidad de procesamiento.

El rendimiento medido en un entorno controlado debe interpretarse con cautela, porque las condiciones de la red principal pueden producir resultados diferentes.

Una validación de puentes más estricta

Una de las piezas centrales de Pasteur es la propuesta BEP-682, que modifica la forma en que BNB Smart Chain valida los bloques utilizados para transferencias entre cadenas. Con el nuevo mecanismo, la red comprobará que las firmas de los validadores alcancen el umbral de votos requerido antes de aceptar información procedente de otra cadena. El objetivo es que el peso contabilizado represente realmente la participación válida de los miembros autorizados.

El cambio responde a una limitación del procedimiento anterior, que no garantizaba que cada validador apareciera una sola vez dentro de un conjunto de firmas. En teoría, un conjunto construido de manera especialmente maliciosa podía repetir a un mismo validador y hacer que su poder de voto contara más de una vez. BEP-682 rechazará esas entradas duplicadas, de modo que el umbral refleje un número válido de participantes y no una representación inflada.

La medida tiene relevancia directa para los puentes, que conectan redes distintas y procesan mensajes o activos entre ellas. Cuando un puente acepta datos sin comprobar correctamente las firmas y la unicidad de los validadores, una falla en la lógica de autorización puede ampliar el riesgo de transferencias indebidas. Pasteur no elimina todos los riesgos asociados con las operaciones entre cadenas, pero introduce una comprobación específica contra la duplicación dentro del conjunto de votos.

BNB Chain presentó esta protección junto con el resto de los cambios de Pasteur como una mejora de seguridad y validación, no como una modificación que exija acciones a los usuarios finales. Las aplicaciones que interactúan con BSC no necesitarían migrar fondos por la activación del hard fork, según la información disponible. La responsabilidad operativa recae principalmente en quienes mantienen nodos capaces de validar la cadena y producir bloques.

Gobernanza y rotación de claves

La propuesta BEP-695 aborda el comportamiento del protocolo cuando un validador rota sus claves de consenso. Después de Pasteur, una clave antigua ya no conservará con la misma prioridad la autorización administrativa asociada al validador. El cambio busca evitar ambigüedades durante la transición y establecer que la nueva clave represente de forma efectiva las acciones posteriores del operador.

La rotación también transferirá los procesos pendientes a la nueva clave, una modificación diseñada para impedir que un validador evada una compensación que ya estuviera en curso. En términos prácticos, el cambio vincula las obligaciones administrativas con la identidad actualizada del validador, en lugar de permitir que una sustitución de claves interrumpa el proceso. Así, una operación técnica de seguridad no debería convertirse en una vía para abandonar responsabilidades pendientes.

BEP-695 además impide utilizar el método de voto por firma para resolver decisiones relacionadas con bloqueos de listas negras. La propuesta afecta a los contratos de gobernanza y de participación de BNB Smart Chain, por lo que sus consecuencias se ubican en el nivel del protocolo y de los contratos del sistema. Los desarrolladores no tendrían que cambiar las concesiones existentes, ya que la modificación opera sobre esos componentes fundamentales.

La combinación de control de claves y límites para determinados votos intenta reducir escenarios en los que una transición administrativa altere la autoridad efectiva de un validador. Ese enfoque resulta especialmente importante en una red donde los validadores participan tanto en el consenso como en decisiones operativas del sistema. Pasteur, por tanto, no se limita a optimizar el rendimiento, sino que también define con mayor precisión cómo se conserva la responsabilidad cuando cambian las credenciales.

Bloques ejecutados y resultados de QANet

La tercera propuesta principal, BEP-675, permite que los constructores entreguen bloques que ya fueron ejecutados. Los validadores podrán verificar esos bloques conforme a las reglas de consenso, firmarlos y emitir su contenido, mientras la comprobación posterior se realiza fuera de la ruta crítica de tiempo. Al retirar parte del trabajo de la etapa más sensible, el diseño busca dejar más espacio para procesar transacciones sin modificar el intervalo de bloque ni la finalidad.

En QANet, un entorno de pruebas que replica la configuración de validadores de BNB Smart Chain, el procesamiento dentro de la ruta crítica cayó de 125 milisegundos a 15 milisegundos. Durante esas pruebas, el gas promedio por bloque aumentó de 46,35 millones a 84,15 millones, todavía por debajo del límite de 100 millones. La combinación permitió evaluar bloques con mayor carga sin alterar los tiempos de bloque ni la finalidad observada en el entorno.

El rendimiento medido en QANet subió de 1.237 a 2.324 transacciones por segundo, una mejora que prácticamente duplicó la tasa registrada en la configuración anterior. Sin embargo, esos resultados corresponden a condiciones controladas y no garantizan que se mantengan después de la activación en la red principal. La capacidad efectiva dependerá de factores operativos y de carga que pueden diferir del escenario reproducido durante las pruebas.

El modelo exige que los nodos completos procesen y verifiquen bloques ya ejecutados, siempre que estos cumplan con las reglas de consenso. Esa condición no implica que los usuarios de aplicaciones descentralizadas deban instalar un nodo, pero sí aumenta la importancia de que los operadores mantengan clientes compatibles. Tras la activación, el equipo de BNB Chain deberá vigilar el comportamiento de la red para comprobar si las ganancias observadas en QANet se trasladan al entorno práctico.

Qué deben hacer los operadores

Los operadores de nodos de la red principal deben sustituir el binario actual por la versión 1.7.7 antes de las 02:30 UTC del 25 de agosto. También tienen que eliminar de su archivo de configuración la línea [Eth] EnableBAL, porque el cliente no iniciará si esa entrada permanece activa. La instrucción convierte la actualización en un requisito operativo para quienes quieran continuar participando en la validación de BSC.

BNB Chain recomendó además retirar la línea [TxPool] OverflowPoolSlots, aunque el cliente la ignorará sin problemas si continúa presente. Las opciones de entrada --journalfile, --enablebal y --txpool.overflowpoolslots dejaron de utilizarse con esta versión. La limpieza de esos parámetros busca evitar configuraciones heredadas que ya no tienen efecto o que podrían generar confusión durante el cambio de cliente.

El calendario de activación deja a los operadores una ventana definida para instalar el software y revisar sus archivos de configuración. Un nodo que no complete el cambio a tiempo puede quedar fuera de la cadena compatible cuando se active la nueva lógica de consenso. Para los usuarios regulares, en cambio, la actualización no exigiría una transferencia de activos ni una migración automática de fondos, de acuerdo con el anuncio de la red.

El despliegue en la red principal será también una prueba de las afirmaciones de rendimiento realizadas durante el desarrollo. BNB Chain deberá verificar si BEP-675 mantiene la reducción del trabajo crítico y si el aumento del gas medio puede convivir con una operación estable bajo carga real. La supervisión posterior permitirá determinar si Pasteur entrega únicamente una mejora teórica o una capacidad sostenida para el ecosistema de BSC.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín