Polygon ha corregido dos vulnerabilidades en BlockSTM V2, el sistema de ejecución paralela dentro del cliente Bor que impulsa la blockchain de Polygon PoS, las cuales habrían permitido que transacciones válidas ralentizaran los nodos de la red. Según la revisión técnica publicada por Polygon, los errores no alteraron los resultados de las transacciones ni comprometieron el consenso. Su riesgo era la disponibilidad: un nodo podía calcular el resultado correcto de un bloque, pero tardar tanto en procesarlo que se quedaba atrás respecto al resto de la red. La empresa divulgó los hallazgos junto con el lanzamiento público de Bor v2.10.3, la versión del cliente que contiene las correcciones.

Polygon declara que no tiene conocimiento de explotaciones en mainnet ni en la testnet Amoy.

Por qué la ejecución serial que terminaba primero no ponía fin al retraso

Bor procesa los bloques entrantes mediante ejecución serial y paralela, adoptando la ruta que termine primero. La ejecución serial sigue el orden de las transacciones, mientras que la ejecución paralela intenta procesarlas de manera concurrente y luego verifica si sus dependencias asumidas eran correctas. Este enfoque puede acelerar cargas de trabajo ordinarias cuando las transacciones no dependen entre sí, pero también genera trabajo especulativo que debe detenerse con rapidez cuando deja de ser útil.

Este diseño sitúa a Bor en la familia de sistemas de ejecución paralela optimista: el cliente asume que la mayoría de las transacciones son independientes, las ejecuta en paralelo y asume un costo de verificación cuando una suposición resulta incorrecta. Los errores de rendimiento en tales sistemas suelen manifestarse como trabajo desperdiciado en lugar de respuestas incorrectas, lo cual coincide con el perfil descrito por Polygon.

La prueba de hash de código repetido de Polygon expuso la brecha. La ejecución serial completó la transacción en decenas de milisegundos, pero la ruta paralela siguió trabajando durante unos 11 segundos. En ese momento, la cancelación solo se verificaba entre transacciones, lo que significaba que una transacción costosa ya en ejecución paralela tenía que terminar incluso después de que la ejecución serial hubiera producido el resultado.

Por eso la prueba era importante: la transacción era válida y Bor podía determinar su estado final rápidamente, pero el nodo aún tenía que esperar a que terminara el procesamiento innecesario.

Dos fallas creaban trabajo que el gas no precioaba por completo

Las dos vulnerabilidades provenían de fuentes distintas de trabajo excesivo. Una permitía que la ejecución especulativa retuviera demasiados datos calculados. La otra recalculaba repetidamente el hash de código de un contrato cuando podía reutilizar un resultado anterior.

Los límites de gas cobran a los usuarios por operaciones de transacción específicas, pero no siempre capturan cada costo introducido por la implementación de un cliente. En estos casos, el crecimiento de la caché y el hash redundante podían generar trabajo del lado del nodo desproporcionado respecto al costo aparente de la transacción.

Polygon clasificó ambos errores con severidad media y afirmó que ninguno afectaba el consenso. La calificación coincide con el perfil de los hallazgos: la exposición eran nodos más lentos y recursos desperdiciados, no resultados deacciones alterados ni un consenso dañado.

Qué cambia el parche de Bor v2.10.3

Las correcciones de la v2.10.3 limitan esa sobrecarga sin cambiar los resultados de ejecución. La actualización restringe la caché compartida utilizada durante la ejecución especulativa y permite que Bor reutilice un resultado de hash de código en lugar de recalcularlo en lecturas repetidas. El objetivo es evitar que una carga de trabajo válida pero problemática consuma recursos excesivos o extienda innecesariamente el tiempo de procesamiento de bloques.

Según las notas de la versión de Bor v2.10.3, el lanzamiento público no requiere hard fork, migración de base de datos ni resincronización de nodos. Los operadores pueden actualizar sus nodos de forma individual.

La aplicación privada del parche precedió a la divulgación pública

Polygon afirmó que distribuyó una compilación privada para la testnet Amoy el 5 de octubre, seguida de una compilación privada para mainnet el 8 de octubre. Publicó la divulgación técnica en el foro de gobernanza de Polygon el 15 de octubre, después de que las actualizaciones alcanzaran a la mayor parte de la red. Un anuncio de versión aparte cubre el despliegue en mainnet y testnet.

Las notas de la versión indican que la mayoría de los validadores y los principales proveedores de RPC ya ejecutaban la versión privada. Eso no significa que todos los nodos conectados se hubieran actualizado, razón por la cual el anuncio de Polygon a los operadores insta a los usuarios de Bor v2.10.2 o anterior a actualizar con prontitud. Los operadores que ya usan las compilaciones privadas pueden pasar al lanzamiento público durante su próximo período de mantenimiento.

El problema pendiente es la cobertura del parche

Para billeteras, aplicaciones y otros servicios, los nodos que se quedan atrás pueden devolver información de la cadena con retraso o tardar más en enviar transacciones. La divulgación de Polygon no establece que los usuarios experimentaran dicha interrupción, y la empresa afirma que no tiene conocimiento de explotaciones en mainnet ni en Amoy.

Como la v2.10.3 se publica sin hard fork, no existe un plazo a nivel de protocolo que obligue a los rezagados a actualizar; la adopción avanza según el calendario de cada operador. Eso convierte la cobertura del parche en la señal observable a seguir: la rapidez con la que los operadores de Bor en v2.10.2 o anterior migran a la versión corregida.

El trabajo más amplio de Polygon en procesamiento más rápido e infraestructura de pagos hace que esa confiabilidad operativa sea relevante. El parche elimina las dos fuentes identificadas de trabajo excesivo; el siguiente paso práctico es que los operadores de Bor restantes lo apliquen.

Este artículo se proporciona únicamente con fines informativos. Las descripciones de vulnerabilidades y las evaluaciones de explotación reflejan la divulgación publicada por Polygon.

Fuente: Coindoo