Cargando precios…
🔥BULLISH

Polygon Labs exige upgrade inmediato de nodos Bor y Heimdall

Los nodos Bor y Heimdall desactualizados ya están fuera del consenso canónico, así que la resincronización es la única vía de regreso, y los riesgos divulgados dejan claro por qué era importante parchear con prontitud.

Polygon Labs ordenó a los operadores de nodos que ejecutan binarios pre-hardfork actualizar de inmediato, tras su revisión de seguridad del 27 de agosto que confirmó que los nodos Bor por debajo de v2.10.0 y los nodos Heimdall por debajo de v0.11.0 ya no siguen el consenso canónico. Austin se activó en el bloque de mainnet 91.949.700 en el lado del cliente de ejecución, mientras que Kyoto se activó a la altura 51.533.000 el 18 de agosto a las 10:10:31 UTC para la capa de consenso.

Por qué importa

Austin cerró dos rutas de agotamiento de recursos en Bor. La primera limitó el gas que Bor consume al procesar eventos de sincronización de estado desde depósitos del puente L1-to-L2, ya que esas llamadas anteriormente se ejecutaban fuera del techo de gas del bloque y podían detener el procesamiento si llegaban suficientes eventos. La segunda eliminó el campo de metadatos extra TxDependency de Bor tras demostrar los investigadores que un productor podía colar un blob de tamaño excesivo en el campo y bloquear nodos pares que gestionaban un bloque hermano. Polygon afirmó que no ha observado interrupciones en la mainnet por Austin y enmarcó los cambios como soluciones proactivas.

La corrección de mayor severidad de Kyoto añadió una comprobación de anidamiento a nivel de bytes en los mensajes google.protobuf.Any en Heimdall, cerrando un vector por el que una sola transacción barata podía obligar a cada validador a gastar mucho en decodificación. Kyoto también limitó las listas de monedas de comisión antes de un escaneo de validación O(n) (Heimdall permite una moneda de comisión), normalizó los bytes de recuperación de firma del checkpoint para que una firma válida no pueda fallar la recuperación en Ethereum, hizo idempotentes los mensajes repetidos de inactividad del productor, vinculó los votos del rango de hitos al hash del padre firmado, evitó que las creaciones fallidas de tramos futuros bloquearan el compromiso de hitos, e hizo inyectivas las claves de repetición para eventos de topup, clerk y stake a través de índices de log fuera de rango. Una interrupción RPC de aproximadamente una hora reportada previamente se relacionó con un hotfix de Heimdall en esta misma ruta de código.

Impacto en el mercado

Ambos hardforks son actualizaciones binarias simples sin migración de estado ni cambio de génesis, por lo que los nodos que actualizaron a tiempo no tienen nada que hacer. Los operadores que ya pasaron la altura relevante en un cliente antiguo deben instalar la versión aplicable, retroceder a un bloque pre-hardfork si es necesario y resincronizar siguiendo la guía de Polygon.

Preguntas frecuentes

  1. ¿Qué deben hacer los operadores de nodos tras los hardforks Austin y Kyoto?

    Los operadores que ejecutan Bor por debajo de v2.10.0 o Heimdall por debajo de v0.11.0 deben instalar la última versión, retroceder a un bloque pre-hardfork si es necesario y resincronizar siguiendo la guía de Polygon. Los nodos que ya actualizaron a tiempo no requieren ninguna acción.

  2. ¿Cuándo se activaron Austin y Kyoto en la mainnet de Polygon PoS?

    Austin se activó en el bloque 91.949.700 en el lado del cliente de ejecución. Kyoto se activó a la altura 51.533.000 el 18 de agosto a las 10:10:31 UTC para la capa de consenso. Ambas alturas de activación ya han pasado.

  3. ¿Qué corrigió el hardfork Austin en Polygon PoS?

    Austin limitó el gas que Bor consume al procesar eventos de sincronización de estado desde depósitos del puente L1-to-L2 y eliminó el campo de metadatos extra TxDependency, que carecía de límite de tamaño y podía permitir que un productor bloqueara nodos pares con un blob de tamaño excesivo. Polygon clasificó ambos…

  4. ¿Cuál fue la corrección de mayor severidad de Kyoto?

    Kyoto añadió una comprobación de anidamiento a nivel de bytes en los mensajes google.protobuf.Any en Heimdall, cerrando un vector por el que una sola transacción barata podía obligar a cada validador a gastar mucho en decodificación. Una interrupción RPC de aproximadamente una hora reportada previamente se relacionó…

  5. ¿Estos hardforks requieren una migración de estado o resincronización desde cero?

    No. Ambos son actualizaciones binarias simples sin migración de estado ni cambio de génesis. Los nodos que no se habían desviado no requieren resincronización, aunque los operadores que ya pasaron la altura relevante en un cliente antiguo deben retroceder y resincronizar siguiendo la guía de Polygon.

Atribución de fuente
Agregado de CryptoSlate · Verificado · Última actualización hace 3h
Abrir original →