\n
Los desarrolladores de Ethereum integraron una correcci\u00f3n en las especificaciones de Glamsterdam tras identificar un bug en el onboarding de Gloas que pod\u00eda dirigir dep\u00f3sitos de validadores hacia block builders con la misma clave p\u00fablica. El pull request #5736<\/a> se incorpor\u00f3 a master el 26 de octubre y modifica dep\u00f3sitos pendientes. El fallo afectaba una futura actualizaci\u00f3n de Ethereum, no al protocolo activo en mainnet<\/strong>, por lo que qued\u00f3 dentro del desarrollo y pruebas de Ethereum<\/a>.<\/p>\n <\/p>\n El problema aparec\u00eda cuando Gloas inicializaba su registro separado de builders<\/a>. Con la regla anterior, tras registrar un builder, otros dep\u00f3sitos con la misma clave p\u00fablica pod\u00edan aumentar su balance sin importar sus withdrawal credentials. Un dep\u00f3sito destinado a un validador pod\u00eda salir de la cola de validadores y acreditarse al builder.<\/strong> As\u00ed, fondos para staking pod\u00edan terminar en una cuenta controlada por otra parte.<\/p>\n La descripci\u00f3n del bug ilustra el riesgo con un protocolo de staking<\/a> financiando un validador operado por un tercero. Si el operador colocaba primero un dep\u00f3sito v\u00e1lido de builder con la misma clave y ambos segu\u00edan pendientes durante el fork, el dep\u00f3sito del validador pod\u00eda dirigirse al builder. Ese dep\u00f3sito no crear\u00eda ning\u00fan validador, pudiendo alterar la contabilidad basada en proofs o los procedimientos de recuperaci\u00f3n.<\/strong> Era un edge case, no evidencia de dep\u00f3sitos desviados en mainnet.<\/p>\n La correcci\u00f3n separa los dep\u00f3sitos seg\u00fan sus withdrawal credentials durante el onboarding de Gloas. Los dep\u00f3sitos de validadores permanecen en su cola aunque un builder utilice la misma clave, mientras los dep\u00f3sitos v\u00e1lidos 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<\/strong> y a\u00f1ade regression tests para distintos \u00f3rdenes de dep\u00f3sitos y comportamientos de routing.<\/p>\n El timing importa porque Glamsterdam combina cambios de Amsterdam en la execution layer con cambios de Gloas en la consensus layer, incluida la separaci\u00f3n enshrined entre proponentes y builders. La actualizaci\u00f3n ya pas\u00f3 por pruebas p\u00fablicas<\/a>, mientras su despliegue en Hoodi fue aplazado para revisi\u00f3n y la activaci\u00f3n en mainnet sigue sin confirmarse. La correcci\u00f3n fortalece las especificaciones de un fork futuro, no repara un exploit activo en Ethereum.<\/strong> El caso refuerza la necesidad de probar la l\u00f3gica de transici\u00f3n antes de llevar cambios de staking y construcci\u00f3n de bloques a producci\u00f3n.<\/p>\n","protected":false},"excerpt":{"rendered":" Puntos clave de la noticia: Los desarrolladores integraron una correcci\u00f3n para Glamsterdam tras detectar que la l\u00f3gica de Gloas pod\u00eda dirigir dep\u00f3sitos de validadores hacia builders con la clave p\u00fablica. El bug afectaba el onboarding del fork, no mainnet, y pod\u00eda sacar dep\u00f3sitos de la cola de validadores si coincid\u00edan condiciones durante la transici\u00f3n. El … <\/p>\nLa correcci\u00f3n de Gloas separa las rutas de dep\u00f3sitos de validadores y builders<\/h2>\n
![\"Los](\"https:\/\/crypto-economy.com\/es\/\/wp-content\/uploads\/sites\/4\/2026\/10\/Ethereum-Developers-Patch-Glamsterdam.jpg\")
<\/p>\n