Puntos Clave de la Noticia:
- Dos vulnerabilidades mitigadas: Polygon corrigió fallos catalogados de severidad media en el motor de ejecución paralela BlockSTM V2 de su cliente Bor.
- Sobrecarga computacional: Las pruebas técnicas registraron demoras de hasta 11 segundos en el procesador paralelo frente a milisegundos requeridos por la ruta serial.
- Despliegue escalonado: La actualización privada comenzó el 5 de octubre en Amoy y el 8 de octubre en mainnet, sin reportes de explotación maliciosa activa.
El equipo de Polygon corrige fallos en la arquitectura de ejecución de su red principal tras publicar una actualización para el cliente Bor el 15 de octubre. La intervención técnica resolvió dos brechas de severidad media que permitían a transacciones válidas y de bajo coste de gas consumir recursos computacionales desproporcionados en los nodos validadores.
Puntos clave del fallo en el motor BlockSTM V2
El incidente involucró directamente a BlockSTM V2, el subsistema responsable del procesamiento paralelo dentro de la red Polygon Proof of Stake (PoS).
En este cliente, los bloques entrantes se procesan a través de dos canales simultáneos: una ruta serial y otra paralela, tomando el resultado de la primera que termine. Las pruebas internas demostraron que transacciones con código de hash repetido tardaban decenas de milisegundos en la ejecución serial. Sin embargo, la vía paralela permanecía ocupada durante aproximadamente 11 segundos procesando trabajo redundante.
El reporte técnico divulgado por la organización aclaró que la cancelación de procesos solo ocurría al cambiar de transacción, obligando al nodo a finalizar tareas especulativas costosas aunque el resultado de la cadena ya estuviera definido. Según el análisis de la firma, el vector no alteraba los resultados de las transferencias ni ponía en peligro el consenso de la red, pero representaba una amenaza operativa directa para la disponibilidad y sincronización de los nodos.
Las dos fallas identificadas provenían de un uso ineficiente de los recursos locales. Por un lado, la ejecución especulativa mantenía en memoria una cantidad excesiva de información mediante una caché compartida sin límites de contención. Por el otro, el software recalculaba repetidamente el hash del código de contratos inteligentes en lugar de reutilizar lecturas previas.
La documentación oficial explica que los límites de gas asignados a los usuarios cubren operaciones estándar, pero no siempre reflejan las ineficiencias internas de procesamiento en el cliente de software. En este escenario, operaciones con tarifas económicas generaban una carga de cómputo no monetizada ni prevista en los parámetros de la máquina virtual.
Para resolver este desfase operativo, Polygon lanzó la versión Bor v2.10.3, la cual establece un límite estricto para el tamaño de la memoria intermedia compartida. Asimismo, el parche habilita la reutilización de datos previamente calculados cuando las lecturas se repiten sobre un mismo contrato inteligente.
Despliegue de la versión Bor v2.10.3 y recomendaciones para operadores
La distribución de las correcciones técnicas se gestionó de forma gradual antes de la divulgación pública para salvaguardar la infraestructura.
El cronograma oficial detalló que el 5 de octubre se distribuyó una versión privada preliminar en la red de pruebas Amoy. Posteriormente, el 8 de octubre, Polygon entregó compilaciones confidenciales a los operadores de la red principal para asegurar la estabilidad del ecosistema. La publicación abierta del informe técnico y de las notas del parche tuvo lugar el 15 de octubre, una vez que la mayor parte de los validadores y proveedores de llamadas a procedimientos remotos (RPC) ya ejecutaban el código corregido.
La documentación técnica del cliente Bor v2.10.3 confirma que la implementación no requiere un hard fork, migraciones de bases de datos ni la resincronización de los nodos participantes. Cada entidad operadora puede aplicar la actualización de forma independiente en sus servidores.
Si los nodos quedan rezagados frente al avance de la red, los usuarios finales podrían experimentar retrasos en la confirmación de operaciones o inconsistencias en la lectura de datos para billeteras y aplicaciones descentralizadas. Los registros de auditoría de Polygon aseguran que no se detectaron explotaciones activas en la red principal ni en el entorno de pruebas Amoy antes del despliegue del parche.
El hito inmediato del protocolo consiste en que el resto de los operadores independientes que aún ejecutan Bor v2.10.2 o versiones previas migren hacia la versión v2.10.3 durante su próxima ventana de mantenimiento programada.
