Actualización de Glamsterdam y Corrección de Depósitos en Ethereum
Los desarrolladores de Ethereum han implementado una solución para un fallo en el manejo de depósitos en la próxima actualización de Glamsterdam, que podría haber permitido a un constructor de bloques recibir ETH destinado a un nuevo validador. Esta corrección se realizó tras una decisión inicial de rechazar el cambio propuesto.
«El mantenedor Justin Traglia fusionó la corrección el 26 de octubre, después de que el desarrollador avsetsin identificara un problema en la forma en que se procesarían los depósitos pendientes durante el fork de Gloas.»
El cambio separa los depósitos de los constructores de los depósitos de los validadores, de acuerdo con sus credenciales de retiro, evitando que los fondos se asignen a la cuenta equivocada cuando ambos utilizan la misma clave pública. La vulnerabilidad concernía a reglas en desarrollo y no a un robo confirmado en la mainnet de Ethereum.
Detalles del Problema y la Solución
El problema surgió de los cambios planeados bajo la separación consagrada de proponentes y constructores de Glamsterdam, que asigna la construcción de bloques y la propuesta de bloques a diferentes roles. Los constructores ensamblan cargas de transacción, mientras que los validadores participan en la propuesta y confirmación de bloques a través del sistema de prueba de participación de Ethereum.
El investigador avsetsin describió el fallo el 12 de octubre, identificando un problema en las reglas utilizadas para procesar depósitos en espera cuando la red se actualiza. Si un constructor se registraba utilizando una clave pública antes de que llegara un depósito de validador bajo la misma clave, la lógica propuesta podría acreditar ambos depósitos al constructor.
«El operador puede retirar los fondos del protocolo», advirtió avsetsin en su informe de GitHub.
Dado que se esperaba que el validador no se creara, el servicio de staking podría tener dificultades para obtener la prueba necesaria para completar sus procedimientos normales de depósito y recuperación.
Investigación y Resistencia Inicial
El investigador examinó la posible exposición que involucraba a Lido, Origin y Rocket Pool a través de una investigación preliminar de código. Esos hallazgos eran condicionales a cómo los protocolos individuales manejaban los depósitos, y el informe no estableció que los proyectos hubieran sufrido un exploit.
La corrección propuesta inicialmente encontró resistencia por parte de los desarrolladores de clientes de Ethereum, a pesar de la descripción del investigador sobre el riesgo de enrutamiento de depósitos. El 19 de octubre, Traglia cerró la solicitud de extracción después de discusiones entre los desarrolladores principales.
«No hubo suficiente apoyo de los clientes para hacer este cambio en este momento», escribió Traglia.
Sin embargo, la decisión no se mantuvo, y los desarrolladores reabrieron la propuesta el 23 de octubre tras un examen adicional. Posteriormente, el revisor potuz aprobó el enfoque, pero solicitó más pruebas para combinaciones específicas de depósitos.
Implementación de la Corrección
El cambio final se fusionó en las especificaciones de consenso de Ethereum el 26 de octubre, después de una revisión adicional del cliente. Este cambio dirige los depósitos válidos de validadores a la cola de validadores, mientras permite que los depósitos legítimos de constructores se registren o se agreguen a un constructor existente.
Las nuevas reglas distinguen los depósitos a través de credenciales de retiro, que determinan los arreglos de retiro permitidos. Preservan registros separados de constructores y validadores, incluso donde la misma clave pública aparece en ambos roles.
Problemas Adicionales y Postergación de Glamsterdam
La actualización de especificaciones llegó mientras los desarrolladores de Ethereum revisaban un problema separado que afectaba la activación programada de Glamsterdam en la testnet de Hoodi. La Fundación Ethereum pospuso la actualización del 26 de octubre después de que los investigadores identificaran riesgos de compatibilidad relacionados con EIP-8037.
«EIP-8037 podría interferir con contratos inteligentes que dependen de suposiciones sobre el gas que permanece durante la ejecución,» explicó el investigador Toni Wahrstätter.
Identificó casos donde la contabilidad de gas podría causar que una transacción se revirtiera inesperadamente o permitir un camino de ejecución que los desarrolladores asumieron que era inalcanzable. El problema de compatibilidad de contratos es distinto del fallo de depósito de constructores abordado en la corrección de GitHub.
Glamsterdam ya se activó en la testnet de Sepolia el 6 de octubre, donde los desarrolladores examinaron cambios en la construcción de bloques y una mayor capacidad de procesamiento de transacciones. El posterior ensayo de Hoodi sigue sin programarse, sin una fecha confirmada para la activación en la mainnet de Ethereum.
La corrección de depósito fusionada contiene pruebas de regresión que cubren cómo se clasifican los depósitos durante la transición de Gloas. Los equipos de clientes deben incorporar el cambio de especificación en su software y completar más pruebas antes de que las reglas actualizadas puedan operar durante una futura actualización de la red.
