Un cambio de especificación fusionado el 26 de octubre cierra una falla en el procesamiento de depósitos de Ethereum que podría haber permitido a operadores de nodos redirigir los depósitos de los stakers en cola hacia balances bajo su propio control una vez que se active la actualización Glamsterdam de la red. La corrección llegó al repositorio consensus-specs —las reglas de referencia que implementan los equipos de clientes de Ethereum— dos semanas después de que la falla fuera reportada en GitHub. Solo los depósitos que siguieran esperando en la cola cuando el fork se active podrían haber sido mal dirigidos, y como Glamsterdam no ha llegado a la mainnet, no se han perdido fondos.

Cómo un operador podría haber tomado el depósito de un staker

Los protocolos de staking agrupado comúnmente dividen el trabajo de operar un validador. El protocolo aporta el ETH, mientras que un operador de nodos externo custodia la clave de firma del validador. Ethereum mantiene separadas la firma y los retiros, por lo que un operador puede ejecutar un validador sin poder retirar el stake del protocolo.

Glamsterdam combina cambios en la capa de ejecución con una actualización de la capa de consenso llamada Gloas y añade a los builders como un nuevo tipo de participante bajo la separación de proponent y builder incorporada en el protocolo. Los builders arman la parte de cada bloque que lleva las transacciones y mantienen sus propios balances. En el fork, Ethereum convierte los depósitos elegibles que aún esperan en la cola en cuentas de builder.

En esa conversión se encontraba la falla. Bajo la regla anterior, una vez que un depósito pendiente registraba un builder para una clave, cada depósito posterior para esa clave recargaba al builder, sin importar a dónde apuntaban sus credenciales de retiro. Un operador podía poner en cola un depósito de builder para una clave nueva desde una dirección que controlaba. Si el protocolo de staking luego financiaba unósito de validador para la misma clave, y ambos seguían pendientes en el fork, el ETH del protocolo habría sido acreditado al balance de builder del operador, que este podría haber retirado. Tampoco se habría creado ningún validador. Algunos protocolos liberan el resto del stake solo después de demostrar que un nuevo validador lleva sus credenciales de retiro, y esa prueba nunca habría llegado.

En un comentario posterior, el autor del issue enumeró los diseños que el bug podría haber afectado: la garantía de predepósito de Lido, OETH de Origin y Saturn de Rocket Pool, al tiempo que señalizó que la lista era una investigación rápida asistida por IA que podía contener errores. En cada caso, la exposición habría sido un primer depósito —1 ETH en los ejemplos de Lido y Rocket Pool— con el resto del stake bloqueado hasta ejecutar pasos de recuperación. El autor describió estos hallazgos como condicionales en el código, no exploits activos.

Rechazado el 19 de octubre, fusionado una semana después

La corrección fue propuesta el 12 de octubre. Tras discutirse en dos llamadas de desarrolladores core, se cerró el 19 de octubre por falta de soporte de los clientes, y la llamada de testing planteó prototiparla después de la actualización de la testnet Hoodi en lugar de alterar el calendario.

Tres días después, la Ethereum Foundation pospuso la activación de Glamsterdam en Hoodi para investigar cómo interactúa EIP-8037 con los smart contracts existentes, un problema ajeno a los depósitos. El tiempo adicional reabrió el debate. Un comentario del 23 de octubre en la agenda de la próxima llamada de testing vinculó el cambio de depósitos al cronograma revisado, el autor añadió pruebas de ordenamiento de depósitos el mismo día, y el cambio fue fusionado el 26 de octubre.

Qué hace la nueva regla

Después del fork, los depósitos de builder y de validador ya viajan por caminos separados bajo EIP-8282. La corrección aplica la misma lógica a la cola en el fork: las credenciales de retiro, y no la clave pública, deciden a dónde va cada depósito pendiente.

Reutilizar una misma clave para un validador y un builder sigue permitido; el propósito declarado en cada depósito ahora decide qué cuenta financia.

Qué falta antes del fork

La fusión de la especificación es solo el primer paso; los equipos de clientes ahora deben implementar la misma regla. Un cambio en Teku abierto el 27 de octubre seguía en revisión, y el equivalente en Lodestar permanecía abierto.

Un cambio tardío también debe llegar de forma idéntica en cada cliente. Las pruebas de referencia anteriores codifican el enrutamiento previo, por lo que un cliente que siga la nueva regla las fallaría. El autor de Teku reporta haber pasado las pruebas generadas a partir de la especificación actualizada, que aún no ha sido empaquetada en una versión de la especificación. Si los clientes llegaran al fork aplicando reglas distintas a la misma cola, calcularían balances diferentes y discreparían sobre el estado de la cadena.

La Foundation no ha fijado una nueva fecha para Hoodi ni para la mainnet de Glamsterdam. Los protocolos de staking que dependen de pruebas de depósito también tienen su propia línea de defensa: según el autor del issue, las verificaciones previas al depósito que rechazan una clave que ya lleva un dep de builder pueden prevenir este escenario. Los indicadores a seguir de aquí en adelante son los dos pull requests de clientes abiertos, una versión de la especificación que empaquete las pruebas actualizadas y nuevas fechas para Hoodi y la mainnet.