Puntos clave de la noticia:
- Los desarrolladores integraron una corrección para Glamsterdam tras detectar que la lógica de Gloas podía dirigir depósitos de validadores hacia builders con la clave pública.
- El bug afectaba el onboarding del fork, no mainnet, y podía sacar depósitos de la cola de validadores si coincidían condiciones durante la transición.
- El PR #5736 separa el routing según withdrawal credentials, preserva los depósitos de validadores y añade regression tests antes del despliegue.
Los desarrolladores de Ethereum integraron una corrección en las especificaciones de Glamsterdam tras identificar un bug en el onboarding de Gloas que podía dirigir depósitos de validadores hacia block builders con la misma clave pública. El pull request #5736 se incorporó a master el 26 de octubre y modifica depósitos pendientes. El fallo afectaba una futura actualización de Ethereum, no al protocolo activo en mainnet, por lo que quedó dentro del desarrollo y pruebas de Ethereum.
La corrección de Gloas separa las rutas de depósitos de validadores y builders
El problema aparecía cuando Gloas inicializaba su registro separado de builders. Con la regla anterior, tras registrar un builder, otros depósitos con la misma clave pública podían aumentar su balance sin importar sus withdrawal credentials. Un depósito destinado a un validador podía salir de la cola de validadores y acreditarse al builder. Así, fondos para staking podían terminar en una cuenta controlada por otra parte.
La descripción del bug ilustra el riesgo con un protocolo de staking financiando un validador operado por un tercero. Si el operador colocaba primero un depósito válido de builder con la misma clave y ambos seguían pendientes durante el fork, el depósito del validador podía dirigirse al builder. Ese depósito no crearía ningún validador, pudiendo alterar la contabilidad basada en proofs o los procedimientos de recuperación. Era un edge case, no evidencia de depósitos desviados en mainnet.
La corrección separa los depósitos según sus withdrawal credentials durante el onboarding de Gloas. Los depósitos de validadores permanecen en su cola aunque un builder utilice la misma clave, mientras los depósitos válidos de builders pueden registrar o aumentar balances independientemente. El cambio alinea el onboarding con los registros separados de validadores y builders descritos por EIP-8282 y añade regression tests para distintos órdenes de depósitos y comportamientos de routing.
El timing importa porque Glamsterdam combina cambios de Amsterdam en la execution layer con cambios de Gloas en la consensus layer, incluida la separación enshrined entre proponentes y builders. La actualización ya pasó por pruebas públicas, mientras su despliegue en Hoodi fue aplazado para revisión y la activación en mainnet sigue sin confirmarse. La corrección fortalece las especificaciones de un fork futuro, no repara un exploit activo en Ethereum. El caso refuerza la necesidad de probar la lógica de transición antes de llevar cambios de staking y construcción de bloques a producción.
