Nodos de Polygon PoS quedan fuera del consenso tras los hard forks Austin y Kyoto

Polygon Labs alertó que los nodos de Polygon PoS que no actualizaron Bor y Heimdall tras los hard forks Austin y Kyoto quedaron fuera del consenso. La actualización resulta necesaria para que esos operadores vuelvan a sincronizarse con la red y adopten correcciones destinadas a reducir riesgos de agotamiento de recursos y fallos entre nodos.
***

• Los nodos que ejecutan Bor por debajo de la versión 2.10.0 o Heimdall por debajo de la 0.11.0 quedaron fuera del consenso tras los hard forks.
• Austin se activó en el bloque 91.949.700 y corrigió dos riesgos relacionados con el consumo de recursos y el tamaño de TxDependency.
• Kyoto se activó en la altura 51.533.000 y exige Heimdall v0.11.0 o superior para mantenerse al día con la red.

Polygon Labs emitió un aviso urgente para los operadores de nodos de Polygon PoS que todavía ejecutan versiones antiguas de sus clientes. Tras la activación de los hard forks Austin y Kyoto, esos nodos quedaron fuera del consenso de la red y deben actualizarse para volver a ponerse al día con la cadena. El anuncio coloca el foco en una tarea operativa que, aunque suele ocurrir detrás de escena, resulta esencial para mantener la continuidad y la coordinación de una red blockchain.

La alerta fue reportada el 29 de agosto, en horario UTC+8, por ME News, que citó información atribuida a Polygon Labs. De acuerdo con ese reporte, los operadores no pueden continuar utilizando versiones desactualizadas de Bor o Heimdall si pretenden participar correctamente en el consenso de Polygon PoS. La situación no describe una interrupción general de toda la red, sino una incompatibilidad concreta entre determinados clientes y las reglas adoptadas después de las actualizaciones.

Qué cambió con Austin y Kyoto

Los hard forks son cambios coordinados en las reglas que utiliza una red para procesar bloques y validar transacciones. Cuando un nodo no incorpora las versiones de software requeridas antes o después de la activación, puede interpretar de manera distinta las nuevas condiciones y dejar de seguir la misma cadena que el resto de participantes. En este caso, Austin y Kyoto establecieron requisitos separados para los componentes Bor y Heimdall de Polygon PoS.

Austin se activó en el bloque 91.949.700 de la red principal de Polygon y exige que los nodos ejecuten Bor v2.10.0 o una versión superior. Bor es uno de los componentes centrales de la infraestructura de Polygon PoS, por lo que la actualización determina qué clientes pueden procesar los bloques bajo las reglas adoptadas con ese hard fork. Los operadores que permanezcan en una versión anterior corren el riesgo de no reconocer correctamente los cambios y quedar apartados del consenso.

Kyoto, por su parte, se activó en la altura de bloque 51.533.000 y estableció un requisito para Heimdall v0.11.0 o superior. La activación ocurrió el 18 de agosto de 2026, según el anuncio de lanzamiento de Heimdall v0.11.0. La separación entre las versiones de Bor y Heimdall refleja que los dos componentes recibieron cambios con calendarios y funciones diferentes dentro de la arquitectura de Polygon PoS. Para los operadores, el aviso implica revisar ambos clientes, porque actualizar solo uno no necesariamente resuelve la incompatibilidad provocada por el otro.

Polygon Labs instó a los responsables de nodos desactualizados a actualizar sus clientes para sincronizarse nuevamente con la red. La recomendación tiene una consecuencia inmediata: los operadores deben verificar qué versiones están instaladas, aplicar los lanzamientos requeridos y comprobar que el nodo recupere su estado correcto dentro de Polygon PoS. El reporte no indicó un plazo adicional ni proporcionó una cifra sobre cuántos nodos permanecían fuera del consenso.

Los riesgos técnicos que abordó Austin

El hard fork Austin se diseñó para atender dos riesgos de agotamiento de recursos relacionados con el funcionamiento de Bor. El primero estaba vinculado con los eventos de sincronización del puente de capa 1 a capa 2, que no se contabilizaban dentro del límite de gas. Esa omisión podía permitir que determinadas operaciones consumieran recursos de procesamiento sin quedar reflejadas adecuadamente en el límite que regula la ejecución de los bloques.

El gas funciona como una medida del trabajo computacional que puede incluirse en un bloque, aunque su aplicación depende de las reglas específicas de cada red. Si ciertos eventos del puente L1 a L2 quedaban fuera de ese cálculo, el procesamiento podía volverse más lento al aumentar la carga que debía manejar Bor. Según la información reportada, Austin incorporó una corrección para que esos eventos se contabilicen dentro del límite de gas y se reduzca ese riesgo operativo.

El segundo problema afectaba al campo TxDependency, que no tenía restricciones de tamaño. Polygon Labs señaló que esa ausencia de límites podía provocar fallos en los nodos pares, es decir, en los equipos que se comunican entre sí para intercambiar información de la red. Un campo sin controles suficientes puede generar mensajes difíciles de procesar o aumentar la presión sobre los recursos de los clientes, especialmente cuando los nodos deben manejar numerosas conexiones.

Al establecer restricciones para TxDependency, Austin busca limitar la posibilidad de que datos excesivos desencadenen errores entre nodos pares. La medida también muestra que la actualización no se concentró únicamente en una modificación visible para los usuarios finales, sino en condiciones internas de procesamiento y comunicación. Para los operadores, la versión Bor v2.10.0 o superior representa la vía indicada para incorporar esas protecciones y continuar siguiendo las reglas vigentes de Polygon PoS.

El caso pone de relieve la diferencia entre usar una red y mantener la infraestructura que la sostiene. Un usuario puede interactuar con aplicaciones basadas en Polygon sin administrar un nodo, mientras que los operadores deben vigilar versiones, cambios de consenso y requisitos de compatibilidad. En esta ocasión, la falta de actualización no solo deja un cliente expuesto a problemas técnicos descritos por Polygon Labs, sino que también lo separa de la coordinación necesaria para participar en la red.

Qué deben considerar los operadores

La prioridad para los operadores afectados consiste en identificar si sus instalaciones utilizan Bor por debajo de la versión 2.10.0 o Heimdall por debajo de la 0.11.0. El aviso de Polygon Labs vincula esas versiones antiguas con la pérdida de consenso después de Austin y Kyoto, por lo que la revisión debe abarcar los dos componentes y no limitarse al software que cada administrador considere principal. La comprobación también debe confirmar que el proceso de actualización terminó correctamente.

Después de instalar las versiones exigidas, el nodo necesita ponerse al día con el estado de la red y verificar su comunicación con los demás participantes. Esa sincronización es importante porque actualizar el cliente no equivale automáticamente a recuperar toda la información que el nodo dejó de procesar mientras operaba con reglas anteriores. El reporte disponible no especificó instrucciones detalladas de instalación, tiempos de recuperación ni procedimientos concretos para cada tipo de operador.

Los hard forks también recuerdan que la participación en una blockchain depende de una coordinación técnica continua. Las reglas pueden cambiar en alturas de bloque predeterminadas, y los clientes que no incorporan esas modificaciones pueden dejar de ser compatibles incluso si antes funcionaban sin inconvenientes. En Polygon PoS, Austin y Kyoto aplicaron esa lógica en puntos concretos de la cadena, con requisitos distintos para Bor y Heimdall.

La información publicada tampoco señaló pérdidas de fondos, una vulneración de activos o una detención completa de Polygon PoS. El hecho confirmado es que los nodos que seguían ejecutando versiones desactualizadas quedaron fuera del consenso y recibieron la instrucción de actualizarse. Por ello, el impacto conocido recae sobre la operación y la sincronización de esos nodos, mientras que cualquier conclusión adicional sobre el comportamiento de la red requeriría datos que no aparecen en el reporte original.

La advertencia de Polygon Labs convierte la gestión de versiones en el asunto central para los participantes que mantienen infraestructura de Polygon PoS. Austin y Kyoto no solo cambiaron requisitos de software, sino que también incorporaron respuestas a riesgos específicos de recursos y comunicación entre nodos. Hasta que los operadores completen las actualizaciones correspondientes, los clientes antiguos permanecerán desalineados con el consenso vigente.

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 y revisado por un editor humano para garantizar calidad y precisión.

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