Ethereum corrige el fallo de depósito de validadores de Glamsterdam

Los desarrolladores principales de Ethereum han fusionado una corrección crítica de especificación para resolver un fallo en el manejo de depósitos inherente a la capa de consenso Gloas de la próxima actualización Glamsterdam. El mantenedor Justin Traglia aplicó el parche el 26 de octubre después de que el desarrollador avsetsin descubriera una lógica que podría provocar que los nuevos depósitos de staking de validadores se atribuyeran erróneamente a los constructores de bloques.

La actualización modifica la lógica de procesamiento de depósitos para diferenciar los registros de constructores de las activaciones de validadores basándose en credenciales de retiro explícitas en lugar de depender únicamente de la coincidencia de claves públicas.

Raíz arquitectónica de la vulnerabilidad de atribución errónea de depósitos

La vulnerabilidad proviene de adiciones estructurales introducidas por la Separación Proponente-Constructor Consagrada (ePBS) bajo el EIP-7732, una característica fundamental del hard fork Glamsterdam diseñada para institucionalizar la construcción de bloques a nivel de protocolo.

Según las especificaciones de consenso Gloas propuestas, tanto los constructores de bloques como los validadores de staking se registran en cadena utilizando claves públicas. El investigador avsetsin demostró el 12 de octubre que si un constructor de bloques se registraba con una clave pública específica antes de que llegara un depósito de validador vinculado a esa misma clave, la cola de depósitos pendientes asignaría los fondos al saldo del constructor.

Este mecanismo presentaba un riesgo operativo significativo para las entidades de staking institucional y los protocolos de staking líquido (como Lido, Rocket Pool y Origin). En un posible escenario de explotación, un operador de nodo que actuara como constructor podría interceptar los fondos de staking entrantes del protocolo, acreditándolos a una dirección bajo su control exclusivo e impidiendo que el nodo validador previsto se pusiera en marcha.

Cambio de consenso entre desarrolladores e integración de la especificación

La solicitud de extracción inicial que proponía la corrección encontró resistencia durante las discusiones de los desarrolladores principales. El 19 de octubre, Traglia cerró el PR, citando un consenso insuficiente entre los equipos de desarrollo de clientes para implementar el cambio en esa etapa.

Sin embargo, el análisis de riesgo continuado llevó a los mantenedores principales a reabrir la propuesta el 23 de octubre. El revisor potuz solicitó pruebas de regresión exhaustivas para validar casos límite complejos que implicaban claves compartidas en roles duales de constructor-validador. Tras la presentación de estas suites de pruebas ampliadas, los desarrolladores fusionaron formalmente el parche en la rama maestra de especificación de consenso el 26 de octubre.

Las reglas actualizadas imponen una separación estricta entre los tipos de cuenta mediante la validación de los campos de credenciales de retiro, garantizando que los depósitos legítimos de validadores se dirijan a la cola de activación de validadores independientemente de los registros previos de constructores.

Desafíos duales: retraso de la red de pruebas y requisitos de los clientes

La resolución del fallo de depósito coincide con una retención en curso del lanzamiento de la red de pruebas pública de Glamsterdam. La Fundación Ethereum pospuso la activación del 26 de octubre en la red de pruebas Hoodi para investigar los cambios de contabilidad de gas del EIP-8037 que los investigadores de seguridad señalaron como potencialmente disruptivos para la lógica de ejecución en contratos inteligentes existentes.

Si bien Glamsterdam se activó sin problemas en la red de pruebas Sepolia el 6 de octubre, el despliegue en la red principal sigue sin programarse a la espera de la finalización de las pruebas de Hoodi y de nuevas actualizaciones del software de los clientes. Los equipos de clientes de consenso individuales (incluidos Prysm, Lighthouse, Teku y Lodestar) ahora deben integrar el parche de depósito fusionado en sus versiones de software antes del próximo ensayo programado de la red de pruebas.