Polygon Labs emite un aviso urgente de actualización para clientes tras los hardforks de Austin y Kioto

Polygon Labs dijo que cualquier nodo de Polygon PoS que se quedara en las versiones binarias de Bor o Heimdall anteriores al hardfork después de dos alturas de activación de agosto ya ha caído fuera del consenso canónico. En la práctica, el nodo obsoleto debe actualizarse y ponerse al día antes de poder seguir la historia aceptada de la red nuevamente.

La revisión de seguridad de la compañía del 27 de agosto describió una consecuencia de compatibilidad del cliente. Polygon dijo que no había observado interrupciones en la mainnet debido a Austin y enmarcó los cambios divulgados como correcciones proactivas.

Bor es el cliente de ejecución de Polygon PoS, mientras que Heimdall maneja el consenso y el control de puntos. Las versiones de Bor anteriores a la v2.10.0 son incompatibles después de que Austin se activara en el bloque 91,949,700 de la mainnet, un límite que se aplica a todos los roles de nodo de Bor.

Los validadores de Heimdall y los nodos completos necesitan la v0.11.0 después de que Kioto se activara en la altura 51,533,000. El aviso de lanzamiento de Heimdall de Polygon data esa activación de la mainnet al 18 de agosto a las 10:10:31 UTC.

Austin y Kioto abordaron riesgos de cliente separados

Austin limitó el gas consumido mientras Bor procesa eventos de sincronización de estado de depósitos de puente L1 a L2. Esos eventos ejecutan código de contrato y precompilaciones, pero su uso de gas no se contaba previamente contra un techo fijo a nivel de bloque.

Suficientes eventos, o un evento suficientemente costoso, podrían hacer que el procesamiento de bloques se ralentizara lo suficiente como para detener temporalmente la cadena.

La segunda debilidad se encontraba en el campo de datos extra TxDependency de Bor, una pista utilizada para la ejecución paralela. Debido a que el campo proporcionado por el productor no tenía límite de tamaño, un productor de bloques podría colocar un blob arbitrariamente grande en un bloque hermano que de otro modo sería válido y hacer que los pares que intentaran procesarlo se bloquearan.

Austin eliminó el campo del formato de transmisión, y Polygon clasificó ambas debilidades como riesgos de agotamiento de recursos.

El lanzamiento público de Bor v2.10.0 registra los bloques de activación de Austin y Amoy en la mainnet. GitHub mostró la v2.10.1 como el último lanzamiento de Bor cuando se verificó el 28 de agosto, mientras que la v2.10.0 o posterior proporciona compatibilidad con Austin.

Operativamente, un camino de Austin amenazaba con retrasar el procesamiento de bloques, mientras que el otro podría terminar con pares que recibían un campo de datos sobredimensionado de un productor.

La corrección de mayor gravedad de Kioto se dirige a mensajes google.protobuf.Any profundamente anidados. Un remitente podría construir una transacción de bajo costo que obligara a cada validador a gastar mucho en decodificación. El hardfork agregó una verificación de anidamiento a nivel de byte tanto en la admisión de mempool como en el procesamiento de propuestas de bloques, manteniendo esos caminos consistentes.

Además, limitó las listas de monedas de tarifas antes de un escaneo de validación O(n), y la integración de Heimdall permite una moneda de tarifa.

Otros cambios de Kioto abordan casos extremos distintos. Normalizan los bytes de recuperación de firmas de control de puntos para que una firma válida no pueda fallar en la recuperación en Ethereum y detener el anclaje, hacen que los mensajes de tiempo de inactividad del productor repetidos sean idempotentes, vinculan los votos de rango de hitos al hash padre firmado y evitan que la creación de un rango futuro fallido bloquee el compromiso de hitos.

Las claves de repetición para eventos de recarga, secretario y participación también se hicieron inyectivas para índices de registro fuera de rango, de modo que eventos distintos de la capa 1 no puedan silenciarse entre sí.

Ambos hardforks son simples actualizaciones binarias sin migración de estado ni cambio de génesis, y los nodos que no se habían desviado no requieren re-sincronización.

Los operadores que ya han pasado la altura relevante en un cliente más antiguo deben instalar la versión aplicable, retroceder a un punto anterior al hardfork si es necesario y re-sincronizar bajo la guía de Polygon.