Hard fork Pasteur en BNB Chain: qué cambiaron realmente BEP-675, BEP-682 y BEP-695 en BSC

El 25 de agosto de 2026, a las 02:30 UTC, BNB Smart Chain activó el hard fork Pasteur en mainnet. Viajaron juntas tres propuestas bajo BEP-673: BEP-682, BEP-695 y BEP-675. Cada una aborda una capa distinta de la red: verificación del bridge, gobernanza de validadores y eficiencia en la construcción de bloques. Este artículo explica qué cambió, por qué era necesario y qué significa realmente esta actualización para usuarios, desarrolladores y operadores de nodos.

Por qué importa Pasteur: contexto antes de los detalles

BSC había pasado tres hard forks consecutivos — Lorentz, Maxwell y Fermi — reduciendo el tiempo de bloque de tres segundos a 450 milisegundos. Pasteur es el primer fork desde Fermi que no toca ese parámetro. En vez de seguir acelerando la cadena, se enfocó en usar cada ventana de 450 ms de manera más eficiente y en cerrar vulnerabilidades conocidas en el bridge y en el sistema de gobernanza.

Ese contexto es importante para evaluar qué entrega esta actualización. Pasteur no promete gas más barato, confirmaciones más rápidas para usuarios normales ni un aumento inmediato del doble en el throughput real. Elimina cuellos de botella arquitectónicos y cierra agujeros de verificación que podían explotarse a escala.

BEP-682: cerrar la vulnerabilidad de firmas del bridge

Cuando los activos se mueven entre BSC y otras cadenas, el lado receptor no acepta la palabra del emisor. BSC verifica que una supermayoría de validadores en la cadena de origen haya firmado el bloque antes de procesar la transferencia. Esa verificación corre a través de un contrato precompilado en la dirección 0x67.

Antes de Pasteur, ese precompilado contaba firmas pero no verificaba que cada validador apareciera solo una vez en el conjunto. Un mensaje manipulado podía listar al mismo validador varias veces, contar su poder de voto de forma repetida y alcanzar el umbral de supermayoría con muchos menos firmantes genuinos de los que el protocolo exige. BEP-682 lo corrige verificando cuatro campos de identidad para cada entrada — dirección del validador, clave pública de consenso, clave BEP BLS y dirección del relayer — y rechazando cualquier conjunto que contenga duplicados antes de ejecutar la lógica de verificación restante.

El blog de BNB Chain describe el problema con claridad: "un conjunto manipulado puede listar al mismo validador repetidamente, contar su poder varias veces y superar el umbral con muchos menos firmantes reales de los que debería requerir." El exploit de Token Hub en octubre de 2022 drenó aproximadamente 570 millones de dólares del bridge de BSC antes de una recuperación parcial; también explotó una falla en la verificación de firmas cross-chain. BEP-682 es una corrección diferente para un agujero diferente, pero el historial explica por qué la verificación del bridge recibe atención prioritaria.

Para operaciones legítimas del bridge, BEP-682 es invisible. Los conjuntos de validadores correctos nunca deberían contener identidades duplicadas. El cambio es técnicamente breaking — entradas que antes pasaban ahora fallan — pero solo fallan las malformadas.

BEP-695: reforzar la rotación de claves y la gobernanza de validadores

Los validadores de BSC rotan sus claves de consenso como higiene de seguridad habitual. Antes de Pasteur, esa transición era incompleta en tres puntos específicos que BEP-695 corrige.

Primero, las claves rotadas conservaban autoridad de administrador de validador que no deberían retener. Después de rotar, la clave vieja seguía teniendo privilegios sobre el registro del validador. BEP-695 hace que StakeHub verifique que la dirección de consenso que llama sea la clave actual y no expirada del validador antes de otorgar acceso administrativo. La clave vieja sigue disponible para auditoría histórica, pero pierde autoridad operativa.

Segundo, la evicción por slashing no seguía de forma confiable a una rotación de clave. Si un validador era penalizado después de rotar, la sanción podía no retirarlo del conjunto activo de minado. El flujo actualizado pasa la clave de consenso actual del validador a BSCValidatorSet.felony inmediatamente después de ser encarcelado, con una ruta de respaldo basada en la clave previa a la rotación. Un validador que se porta mal no puede evadir una evicción pendiente simplemente rotando.

Tercero, el voto con firma en gobernanza tenía una lista negra inconsistente. El sistema que impide que ciertas direcciones voten ya aplicaba a los votos directos. BEP-695 extiende esa verificación para cubrir castVoteBySig y castVoteWithReasonAndParamsBySig, cerrando un camino por el que una dirección en lista negra podía votar mediante un relayer. Ahora el votante real se recupera de la firma y se verifica antes de contar cualquier voto.

Estos cambios afectan los contratos del sistema StakeHub, BSCValidatorSet y BSCGovernor. No alteran interfaces binarias existentes, layouts de almacenamiento ni formatos de mensajes cross-chain. Los flujos de staking y gobernanza que cumplen el protocolo continúan sin cambios de integración.

BEP-675: llenar bloques sin cambiar el reloj

En el proceso de construcción de bloques anterior a Pasteur, constructores especializados compiten para enviar al validador el conjunto más valioso de transacciones. Había un problema de ejecución secuencial. El constructor ejecutaba todas las transacciones para producir un bloque válido y lo enviaba al validador. El validador re-ejecutaba cada transacción para verificar el bloque antes de sellarlo. Ambas partes hacían el mismo trabajo en la ruta crítica dentro de una ventana de 450 ms.

Esa duplicación consumía tiempo que el constructor podría haber usado para incluir más transacciones. Los benchmarks propios de BNB Chain encontraron que el re-trabajo del validador consumía alrededor de 125 ms por bloque en la ruta crítica, dejando a los constructores solo el 30% del intervalo de bloque para su propia ejecución. Muchos bloques salían a menos de la mitad de su capacidad no porque no hubiera transacciones disponibles, sino porque se acababa el tiempo.

BEP-675 introduce un nuevo flujo llamado SendBidBlock. El constructor envía un bloque candidato completamente ejecutado, que incluye transacciones de usuario firmadas, transacciones de sistema sin firmar y un encabezado con los resultados de ejecución: state root, receipts root, logs bloom y gas usado. El validador verifica el bloque contra las reglas de consenso, lo firma y lo difunde, luego completa la verificación completa del estado después. El trabajo de ejecución del constructor se acepta provisionalmente; la re-ejecución del validador abandona la ruta crítica.

En benchmarks controlados en QANet, una red interna que replica la topología de validadores cross-region de mainnet, esto redujo el re-trabajo del validador de 125 ms a 15 ms por bloque. La ventana del constructor se expandió del 30% al 45% del intervalo de bloque. El throughput pasó de 1.237 TPS a 2.324 TPS con el mismo tiempo de bloque de 450 ms y el mismo límite de gas de 100 millones. El gas promedio usado por bloque aumentó de 46,35 millones a 84,15 millones de los 100 millones disponibles.

Esas son cifras de testnet bajo una carga controlada. Los resultados reales en mainnet dependen de que los constructores adopten SendBidBlock, de la configuración de los validadores y de las condiciones reales de la red. BEP-675 crea margen; no obliga a que los bloques estén más llenos ni garantiza un número de throughput específico desde el primer día.

Importante: BEP-675 no requirió un hard fork por sí mismo. El nuevo flujo del lado del validador se activa después de que Pasteur entra en vigencia y se controla vía RPC, dando a constructores y validadores tiempo para integrarse antes de comprometerse con el nuevo flujo. Las pujas legacy siguen disponibles por compatibilidad retroactiva.

Qué cambió según el rol

Usuarios de wallets y la mayoría de los usuarios de dApps no debían hacer nada. Los saldos quedaron en la cadena. Las interfaces de wallets continuaron funcionando. Las mejoras de seguridad de BEP-682 y BEP-695 son invisibles cuando funcionan correctamente, y las ganancias de capacidad de BEP-675 llegan de forma gradual a medida que los constructores integran SendBidBlock. El riesgo práctico principal durante cualquier ventana de hard fork es el phishing: prompts de actualización falsos, enlaces sospechosos que reclaman acción urgente de la wallet y binarios no oficiales dirigidos a operadores de nodos.

Usuarios activos de DeFi y desarrolladores tenían trabajo liviano: confirmar que los proveedores de RPC completaron la actualización y ejecutar pruebas de transacciones, eventos y lecturas de contrato contra la cadena post-fork. Las aplicaciones que dependen de metadatos de bloque específicos o de supuestos de MEV deben revisar su comportamiento contra líneas base post-Pasteur.

Operadores de nodos BSC necesitaban correr v1.7.7 antes de las 02:30 UTC del 25 de agosto. La actualización también requería eliminar el campo [Eth] EnableBAL de config.toml, que de lo contrario causaría un error al iniciar. Varios flags de CLI fueron deprecados o eliminados: --journalfile, --miner.txgaslimit, --enablebal, --multidatabase, --txpool.overflowpoolslots y la familia --fake-beacon. Un reemplazo binario era suficiente después de confirmar esos ítems de configuración.

Constructores de bloques que quieran usar el flujo BEP-675 necesitan ejecutar un fullnode en vez de un fastnode, ya que enviar un bloque completamente ejecutado requiere capacidad de ejecución completa. El envío de pujas legacy sigue funcionando. Las ganancias de BEP-675 se acumulan a medida que constructores y validadores adoptan el nuevo flujo.

Qué no cambia Pasteur

El tiempo de bloque sigue siendo 450 ms. El límite de gas sigue siendo 100 millones por bloque. Los precios del gas dependen de la demanda y la política de bloques, no directamente de esta actualización. No hay reducción garantizada de tarifas. Las direcciones de wallets, saldos, approvals pendientes y posiciones en contratos no son afectados por el fork en sí. Las cifras de throughput de BEP-675 describen un techo de rendimiento en condiciones de testnet, no un compromiso con ningún resultado específico de mainnet. Si esas ganancias se sostienen a escala de mainnet depende de la adopción y las condiciones de la red.

Cómo verificar que la actualización ocurrió

Exploradores como BscScan muestran el número de bloque actual y el estado de la red. La release BSC v1.7.7 en GitHub es el release oficial del nodo para Pasteur. El anuncio oficial de BNB Chain registra la hora exacta de activación y los tres BEPs. El post del blog de BNB Chain explica el razonamiento y los benchmarks de testnet detrás de cada propuesta.

Un hard fork que se activó sin incidentes no produce ninguna discontinuidad visible para usuarios comunes. La ausencia de quejas es lo esperado, no evidencia de comportamiento sin cambios. Para confirmar que un nodo BSC corre software compatible con Pasteur, verificá su versión de cliente reportada contra el release v1.7.7.

Pasteur en el contexto del roadmap de escalabilidad de BSC

BNB Chain ha descrito un objetivo de largo plazo de 100.000 TPS en una nueva Capa 1 de alto rendimiento con preconfirmaciones de menos de 50 ms y sin mempool público. En comunicaciones oficiales sobre el roadmap se mencionó testnet para fines de 2026 y mainnet para principios de 2027, aunque esas fechas no fueron confirmadas con una fecha de lanzamiento específica.

Pasteur encaja como un paso de capacidad a corto plazo: eliminar la ejecución redundante de la construcción de bloques, reforzar la seguridad de la infraestructura cross-chain y la gobernanza, y dar a BSC más margen efectivo al cadencia de bloque de 450 ms existente. El objetivo declarado para el segundo semestre de 2026 es doblar el throughput de mainnet, con Pasteur identificado como el primer paso habilitador en ese workstream. Si las ganancias del benchmark en QANet se trasladan a mainnet a escala es una pregunta abierta que requiere medición post-fork sobre tráfico real.

Fuentes

• BNB Chain — Upgrade Pasteur de BSC (anuncio oficial)
• Blog de BNB Chain — Pasteur llega a BSC Mainnet el 25 de agosto
• Release BSC v1.7.7 — GitHub
• BEP-673: Hardfork Meta-Pasteur — GitHub