Por Canuto  

Los desarrolladores de Ethereum incorporaron una corrección a las especificaciones de Glamsterdam para impedir que depósitos destinados a nuevos validadores pudieran acreditarse a constructores con la misma clave pública. La decisión llegó después de que una propuesta inicial se cerrara y luego se reabriera para sumar pruebas; por separado, una revisión sobre compatibilidad de contratos mantiene sin fecha la activación de la actualización en la testnet Hoodi.
***

  • La corrección, fusionada el 26 de octubre, separa depósitos de constructores y validadores según sus credenciales de retiro.
  • El fallo podía desviar depósitos en determinadas condiciones, pero no se informó de un robo en la red principal de Ethereum.
  • La activación de Glamsterdam en Hoodi sigue aplazada por una revisión distinta sobre riesgos de compatibilidad asociados al EIP-8037.

Los desarrolladores de Ethereum fusionaron el 26 de octubre una corrección para el manejo de depósitos prevista en Glamsterdam, una próxima actualización de la red. El cambio responde a un fallo que, bajo ciertas condiciones, podía enviar a la cuenta de un constructor de bloques fondos destinados a crear un nuevo validador. La vulnerabilidad se refería a reglas todavía en desarrollo y no a un robo confirmado en la red principal.

El ajuste establece una separación entre los depósitos de constructores y los de validadores cuando ambos roles usan la misma clave pública. La modificación llegó después de que los desarrolladores rechazaran inicialmente la propuesta, antes de reabrirla y pedir pruebas adicionales. Aunque el cambio ya forma parte de las especificaciones de consenso, los equipos que desarrollan clientes todavía deben implementarlo y probar el comportamiento revisado.

Un depósito podía acreditarse al rol equivocado

El problema apareció en las reglas que Ethereum prepara para Glamsterdam, actualización que contempla una separación incorporada entre proponentes y constructores de bloques. En ese esquema, los constructores ensamblan las cargas de transacciones y los validadores participan en la propuesta y confirmación de bloques mediante el mecanismo de prueba de participación. La lógica de depósitos debía mantener diferenciados esos roles incluso cuando una clave pública apareciera en ambos.

El investigador identificado como avsetsin describió el fallo el 12 de octubre en un informe de GitHub sobre el procesamiento de depósitos pendientes durante la bifurcación Gloas. Según su análisis, si un constructor se registraba primero con una clave pública y después llegaba un depósito para un validador asociado a esa misma clave, las reglas propuestas podían acreditar los dos depósitos al constructor. El validador esperado, por tanto, no necesariamente se crearía como estaba previsto.

El riesgo señalado dependía de la secuencia de registro y depósito, así como de la coincidencia de la clave pública. Un operador de staking, por ejemplo, podía registrarse como constructor antes de recibir fondos que un protocolo le hubiera entregado para establecer un nuevo validador. Si el depósito se clasificaba en el saldo del constructor, la dirección de retiro podía quedar bajo el control del operador, en lugar de seguir el recorrido esperado para el validador.

Avsetsin advirtió que, en ese escenario, el operador podría retirar fondos pertenecientes al protocolo. Como el validador no llegaría a crearse, el servicio de staking también podría tener dificultades para obtener la prueba necesaria para completar sus procedimientos habituales de depósito y recuperación. El investigador examinó de forma preliminar posibles exposiciones relacionadas con Lido, Origin y Rocket Pool, pero aclaró que sus conclusiones dependían de cómo cada protocolo gestionara los depósitos y no demostraban que alguno hubiera sufrido un exploit.

Los desarrolladores reabrieron la propuesta y añadieron pruebas

La propuesta de corrección no obtuvo respaldo suficiente en su primera revisión. El 19 de octubre, el mantenedor Justin Traglia cerró el pull request luego de las conversaciones entre desarrolladores principales, con el argumento de que no había apoyo suficiente de los equipos de clientes para introducir el cambio en ese momento. Ese cierre reflejó una falta de consenso inicial, no una confirmación de que el problema descrito por el investigador fuera imposible.

La decisión cambió pocos días después, cuando los desarrolladores reabrieron la propuesta el 23 de octubre y continuaron examinando el comportamiento de las reglas. El revisor potuz respaldó el enfoque general, aunque pidió más pruebas para combinaciones concretas de depósitos. Así, la discusión pasó de evaluar si debía hacerse el ajuste a verificar que la lógica distinguiera correctamente cada operación en los casos más delicados.

Avsetsin incorporó esas pruebas el mismo 23 de octubre, con escenarios en los que los depósitos de constructores y validadores comparten una clave pública, pero requieren tratamientos separados. La versión final se fusionó en las especificaciones de consenso de Ethereum el 26 de octubre, después de una revisión adicional de los equipos de clientes. El cambio encamina los depósitos válidos de los validadores hacia su cola correspondiente y permite registrar constructores o añadir fondos a uno ya existente.

La distinción se apoya en las credenciales de retiro, que determinan las modalidades de retiro permitidas para cada depósito. Con ese criterio, las reglas preservan registros separados para constructores y validadores aunque aparezca la misma clave pública en ambos roles. La especificación incorpora pruebas de regresión para comprobar cómo se clasifican los depósitos durante la transición de Gloas, pero la fusión por sí sola no significa que todos los clientes ya hayan actualizado su software.

Hoodi continúa a la espera de otra revisión

La corrección de depósitos coincidió con una revisión diferente que afecta el calendario de Glamsterdam en Hoodi, una testnet de Ethereum. La Ethereum Foundation anunció el 22 de octubre que aplazaba la activación prevista para el 26 de octubre en esa red de pruebas, después de que investigadores identificaran riesgos de compatibilidad vinculados con el EIP-8037. La decisión retiró de la activación planificada tanto los cambios de ejecución de Amsterdam como los cambios de consenso de Gloas.

El aumento propuesto del límite de gas a 200 millones también quedó aplazado junto con esos cambios. Toni Wahrstätter, investigador de Ethereum, explicó que el EIP-8037 podía interferir con contratos inteligentes que dependen de supuestos sobre la cantidad de gas restante durante la ejecución. Entre los casos que identificó figuran situaciones en las que la contabilidad del gas podía provocar una reversión inesperada de una transacción o permitir una ruta de ejecución que los desarrolladores consideraban inalcanzable.

Ese análisis de compatibilidad no es el mismo problema que la clasificación incorrecta de depósitos de constructores y validadores. Ambos asuntos se relacionan con Glamsterdam, pero el aplazamiento de Hoodi respondió específicamente a la necesidad de investigar las interacciones del EIP-8037 con contratos existentes. Mantener separados los dos temas ayuda a entender que la corrección ya fusionada no resolvió, por sí sola, las dudas que llevaron a posponer la prueba de actualización.

Glamsterdam se activó en la testnet Sepolia el 6 de octubre, donde los desarrolladores examinaron cambios en la construcción de bloques y una mayor capacidad de procesamiento de transacciones. En cambio, el ensayo posterior en Hoodi permanece sin programación y no hay una fecha confirmada para activar la actualización en la red principal de Ethereum. La pausa deja tiempo para que los equipos revisen tanto la compatibilidad de contratos como la implementación de las reglas de depósito.

El siguiente paso para la corrección consiste en que los clientes de consenso incorporen el cambio de especificación y completen pruebas adicionales antes de aplicarlo durante una futura actualización de la red. Las pruebas de regresión buscan comprobar que los depósitos compartidos por clave pública mantengan la clasificación correcta, mientras los desarrolladores continúan evaluando los riesgos relacionados con el EIP-8037. Por ahora, la corrección de Glamsterdam está aprobada en las especificaciones, pero su aplicación depende de ese trabajo técnico posterior.


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

Artículos Relacionados