BNB Chain activó la bifurcación dura 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 de los puentes, la autorización de validadores y la capacidad de los bloques.
La red confirmó que Pasteur estaba activa 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.
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 diseñada podría, por lo tanto, incluir al mismo validador más de una vez. Contar esas entradas por separado arriesgaba hacer que una aprobación de 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 satisfaga el requisito de supermayoría.
BNB Chain no informó que los atacantes hubieran explotado la falla ni atribuyó ninguna pérdida de activos anterior a ella. El cambio es una corrección preventiva a la verificación de puentes en lugar de una respuesta a un robo divulgado.
La infraestructura entre cadenas sigue siendo una preocupación de seguridad importante en todas las redes descentralizadas. En cobertura relacionada, los ataques a puentes han causado miles de millones de dólares en pérdidas acumuladas a través de claves comprometidas, fallas de contratos y verificación de mensajes débil.
BEP-695 cierra brechas relacionadas con la rotación de claves de validador, las penalizaciones y la gobernanza. Cuando un validador reemplaza su clave de operador, la clave anterior ahora pierde sus derechos de gestión.
La propuesta también impide que los validadores escapen de las penalizaciones pendientes rotando sus claves. Los procesos de slashing y eliminación permanecen adjuntos al validador en lugar de desaparecer cuando cambia su dirección de operador.
Pasteur además bloquea 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 podrían potencialmente firmar votos y hacer que otra dirección los enviara.
Los contratos de gobernanza actualizados verifican el firmante original antes de contar un voto delegado. Si ese firmante está restringido, el voto es rechazado sin importar qué cuenta lo envíe.
BEP-675 introduce una ruta opcional para que los constructores especialistas envíen bloques que ya han ejecutado. Los validadores verifican el bloque propuesto contra las reglas de consenso, lo firman y lo difunden antes de completar la verificación completa de la 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 corta ventana de bloque de BSC y podría dejar los bloques por debajo de su capacidad máxima durante períodos de alta demanda.
Los constructores pueden seguir utilizando 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 caber más transacciones en cada bloque, pero sus cifras de rendimiento publicadas provinieron de pruebas controladas en lugar 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.
Pasteur no aumenta el límite de gas de los bloques 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ó a los operadores de nodos instalar la versión de cliente 1.7.7 antes de la activación. Los operadores también necesitaron 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 ejecutaban software incompatible corrían el riesgo de desincronizarse 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 del validador. Esas mediciones mostrarán si la mejora de capacidad de QANet se traslada a la demanda sostenida de la red principal.
