Un ingeniero de Lido advierte sobre el riesgo de secuestro de depósitos de staking durante la transición de Ethereum Glamsterdam
¿Por qué los desarrolladores de Ethereum rechazaron la solución a nivel de protocolo
La próxima actualización principal de la red de ethereum busca escalar la capa base mediante la separación consagrada de propuesta y construcción y límites de gas más altos, pero una vulnerabilidad específica en el tiempo ha atraído nueva atención de uno de los mayores proveedores de staking líquido. El 20 de octubre de 2026, Dima Gusakov, Jefe de Ingeniería en Lido Finance, detalló públicamente cómo la transición a Glamsterdam podría permitir a un operador de nodo malicioso adelantarse al depósito del validador de un staker. El ataque utilizaría depósitos de constructores con credenciales de retiro prefijadas con 0xB0 que comparten temporalmente la cola de depósitos, posiblemente acreditando el ETH a una cuenta de constructor en lugar de activar el validador previsto. La ventana es limitada al propio tránsito de la bifurcación. Después de la actualización, los depósitos de constructores se mueven a una ruta de contrato separada.
Una propuesta de solución a nivel de protocolo en las especificaciones de consenso fue cerrada como “no planeada”, transfiriendo la carga defensiva a los protocolos de staking. Este artículo examina los mecanismos técnicos del riesgo, las decisiones de diseño del upgrade que crearon la superposición temporal, las razones por las cuales los desarrolladores principales rechazaron un parche de protocolo, los pasos prácticos que deben tomar los proveedores de staking líquido, el cronograma de testnet que otorga a los operadores solo días para prepararse, y las lecciones más amplias para la seguridad del staking delegado a medida que Ethereum avanza en su hoja de ruta de escalabilidad. El análisis se basa exclusivamente en informes y declaraciones primarias de los últimos 30 días, centrándose en detalles verificados en lugar de especulaciones.
El líder de ingeniería de Lido detalla el vector de front-running en X y en llamadas de desarrolladores
Dima Gusakov emitió la advertencia el 20 de octubre de 2026, dirigiéndose directamente a los protocolos de staking y a los stakers delegados. Explicó que un operador de nodo podría enviar un depósito de builder utilizando la misma clave pública antes de que la transacción de depósito del validador legítimo se registre. Dado que Glamsterdam introduce depósitos de builder que dependen de credenciales de retiro con prefijo 0xB0, y porque esos depósitos comparten la cola de depósitos de validador durante la transición, el primer depósito válido puede reclamar los fondos. El resultado es que el validador del staker nunca aparece en la beacon chain, mientras que los ETH se acreditan en la cuenta de builder del atacante. Gusakov enfatizó que el ataque es posible únicamente en el momento de la bifurcación. Antes de Glamsterdam, los depósitos de builder transitan por la cola existente de depósitos de validador; después, se redirigen a un contrato dedicado. Él señaló que la duración limitada hace factible la mitigación para protocolos preparados.
La misma preocupación surgió en la llamada de consenso de todos los desarrolladores principales (ACDC #189). Gusakov destacó que el mecanismo de incorporación única de Glamsterdam puede interferir con los patrones de protección de depósitos en los que los protocolos de staking han confiado durante mucho tiempo. Bajo las reglas actuales, el primer depósito válido para una clave pública establece permanentemente las credenciales de retiro. Los protocolos suelen depositar primero una pequeña cantidad, confirmar que aparecen las credenciales esperadas y solo luego completar el saldo restante. Durante la transición de la bifurcación, la ruta de incorporación especial puede producir un tercer resultado: ningún validador se activa, y el depósito completo se atribuye a un constructor. Los desarrolladores principales rechazaron un cambio tardío en la especificación que habría preservado la distinción entre depósitos de validador y constructor durante la incorporación única, citando el hecho de que Sepolia ya se había activado bajo las reglas existentes y las versiones del cliente Hoodi ya estaban en preparación. Cambiar el comportamiento en esa etapa habría requerido volver a implementar Sepolia y ciclos adicionales de pruebas.
Cómo las credenciales del constructor 0xB0 interactúan con la cola de depósitos compartida
Glamsterdam introduce depósitos de constructores como parte del movimiento hacia la separación consagrada entre propuesta y construcción. Estos depósitos llevan credenciales de retiro que comienzan con el prefijo 0xB0, distinguiéndolos de las credenciales de validador ordinarias. Durante el período de transición, ambos tipos de depósitos comparten la misma ruta de procesamiento en cola. Un operador de nodo que controle o pueda influir en el orden de envío de depósitos puede, por lo tanto, insertar un depósito con credenciales de constructor que coincida con una clave pública de staker pendiente. Una vez aceptado el primer depósito, la red trata la clave pública como reclamada bajo las credenciales del constructor. Los depósitos posteriores bajo la misma clave serán ignorados para la activación del validador o redirigidos según las nuevas reglas de interpretación que se aplican alrededor del límite de la bifurcación.
El efecto práctico es que el stakeador pierde tanto el validador esperado como el ETH depositado, que ahora se encuentra bajo el control del constructor. Los validadores activados existentes y los depósitos ya procesados permanecen sin afectar. El riesgo se limita a los depósitos nuevos o aún en cola que cruzan el epoch de activación. Debido a que el comportamiento de la cola compartida finaliza una vez que se completa la bifurcación y los depósitos del constructor se mueven a su contrato dedicado, la exposición es temporal. Ese carácter temporal es la razón central por la que Gusakov aconsejó evitar el pánico, mientras instaba a todos los servicios de staking delegado a implementar o fortalecer la verificación previa al depósito antes de la activación del mainnet.
Los desarrolladores principales cierran la propuesta de especificaciones de consenso como no planificada
La discusión técnica de un remedio a nivel de protocolo apareció en el issue #5735 de consensus-specs. La propuesta solicitaba controles previos al depósito que verificarían ciertas condiciones antes de aceptar un depósito en la cola. Tras su revisión, el issue se cerró con el estado “no planeado”. La decisión deja la responsabilidad defensiva en la capa de aplicación en lugar de incorporar controles adicionales en el protocolo principal. La orientación pública de Gusakov se centra por tanto en que los protocolos de staking realicen su propia validación previa al depósito. Las restricciones de tiempo influyeron fuertemente en el resultado. Sepolia ya había realizado un fork bajo la especificación existente el 6 de octubre de 2026.
Las versiones del cliente Hoodi avanzaban hacia la activación del 26 de octubre. Introducir un cambio conductual tardío arriesgaba forzar una nueva implementación en Sepolia y retrasos adicionales en las pruebas. Los desarrolladores principales consideraron que la ventana limitada y la capacidad de los equipos de la capa de aplicación para añadir controles hacían innecesaria una parche del protocolo en esta etapa. El resultado es un modelo de seguridad distribuida en el que cada proveedor de staking líquido debe confirmar que su canal de depósitos distingue o bloquea correctamente los depósitos con prefijo 0xB0 que intentan reclamar claves públicas de validador.
Las verificaciones previas al depósito se convierten en la primera línea de defensa para los servicios de staking líquido
Lido ha operado un Módulo de Seguridad de Depósito y un comité de guardianes desde que surgieron vulnerabilidades relacionadas con depósitos hace varios años. Los guardianes revisan instantáneas de root de depósito antes de que se procesen lotes, y un solo guardián honesto puede pausar depósitos. La pregunta pendiente es si esta infraestructura existente ya contempla el nuevo tipo de credencial 0xB0 y la dinámica temporal de la cola compartida, o si se requiere lógica adicional para la transición de Glamsterdam. Otros protocolos que carecen de una supervisión multipartita comparable enfrentan una tarea de preparación más compleja.
Las verificaciones previas al depósito pueden tomar varias formas concretas. Un protocolo puede rechazar cualquier depósito cuyas credenciales de retiro comiencen con 0xB0 cuando el propósito sea la activación estándar de un validador. Puede requerir una atestación en cadena o fuera de cadena de que la clave pública no ha sido reclamada previamente bajo credenciales de constructor. Puede pausar nuevos depósitos durante un breve intervalo alrededor del epoch de activación hasta que termine el período de cola compartida. Dado que la superficie de ataque existe únicamente mientras las colas se superponen, una pausa temporal o un escrutinio reforzado durante ese intervalo puede eliminar la mayoría de las exposiciones prácticas. Los servicios de staking más pequeños o nuevos que aún no hayan establecido comités de tipo guardian necesitarán actuar rápidamente si pretenden aceptar depósitos durante la transición al mainnet.
El calendario de activación de Glamsterdam deja poco margen para la preparación
La Fundación Ethereum confirmó que Glamsterdam se activará en la testnet Hoodi en el epoch 132.352, slot 4.235.264, correspondiente al 26 de octubre de 2026 a las 17:42:48 UTC. En el mismo epoch, el límite de gas de Hoodi aumenta a 200 millones. Sepolia ya se activó el 6 de octubre. La fecha para el mainnet aún no está decidida, con fechas candidatas a principios de diciembre en discusión, condicionadas a una bifurcación limpia de Hoodi. Por lo tanto, los operadores de nodos y los equipos de staking tienen solo días después de la advertencia de Gusakov para validar sus pipelines de depósito en Hoodi.
Los equipos de clientes han publicado lanzamientos compatibles para ambas capas de consenso y ejecución. Los operadores deben actualizar tanto los nodos de baliza como el cliente de validador, revisar cualquier cambio en las interfaces de constructores introducidos por la separación de propuesta-constructora incorporada, y confirmar que la lógica de envío de depósitos maneje correctamente el nuevo prefijo de credenciales. El corto intervalo entre la advertencia pública y la primera activación pública en testnet subraya por qué las defensas de la capa de aplicación deben estar listas antes de que se abra la ventana de transición al mainnet.
La separación consagrada entre propuesta y construcción introduce la nueva vía de depósito
Glamsterdam combina los cambios de la capa de ejecución de Amsterdam con los cambios de la capa de consenso de Gloas. Sus dos características principales son la separación consagrada de propuesta y constructor (EIP-7732) y las listas de acceso a nivel de bloque. Bajo ePBS, los constructores se registran en la cadena con sus propios saldos y claves públicas, presentan ofertas y más tarde revelan cargas de ejecución. El protocolo mismo gestiona el pago al propuesto, reduciendo la dependencia de relés externos. Los depósitos y salidas de constructores se convierten en solicitudes de ejecución de primera clase, por eso aparecen la prefijo de credencial 0xB0 y la superposición de la cola temporal.
El diseño mejora la escalabilidad al otorgar a los validadores más tiempo para procesar cargas útiles más grandes y al permitir límites de gas más altos. Al mismo tiempo, crea una nueva vía de incorporación para constructores que debe distinguirse cuidadosamente de los depósitos ordinarios de validadores. La mecánica de transición única es la fuente de la ambigüedad temporal. Una vez que la red haya cambiado completamente, los depósitos de constructores viajan a través de su propio contrato, y el riesgo de la cola compartida desaparece. Por lo tanto, la actualización mejora la arquitectura a largo plazo mientras requiere vigilancia a corto plazo de cualquier servicio que envíe depósitos en nombre de los usuarios.
La experiencia previa de Lido con la seguridad de los depósitos informa la respuesta actual
Lido enfrentó riesgos de front-running en depósitos en años anteriores y respondió formalizando el Módulo de Seguridad de Depósito junto con un comité de guardianes. El comité aprueba las instantáneas de la raíz de depósito; un solo guardián puede activar una pausa. Esa infraestructura ya ha demostrado ser útil en otros incidentes operativos. El caso Glamsterdam prueba si los mismos controles reconocen correctamente el nuevo tipo de credencial y el breve período de compartir cola.
Los protocolos que adoptaron patrones similares de firma múltiple o guardianes tras incidentes anteriores están mejor posicionados que aquellos que aún no han implementado salvaguardias comparables. El patrón más amplio es familiar: las actualizaciones de protocolo pueden revelar casos límite que los sistemas de capa de aplicación deben absorber. Debido a que los desarrolladores principales rechazaron un cambio tardío en la especificación, la industria debe tratar la validación previa al depósito como un requisito permanente, no como una mejora opcional. Los equipos que ya monitorean las raíces de depósito y pueden pausar rápidamente enfrentarán un menor riesgo operativo durante la transición.
Los operadores de nodos y los stakers delegados enfrentan una exposición concentrada durante la ventana
El ataque requiere un operador de nodo malicioso o comprometido que pueda enviar una transacción de depósito que se procese antes que la legítima. Los stakers comunes que simplemente depositan en un protocolo de staking líquido no pueden ejecutar el front-run por sí mismos; el riesgo recae en el operador que finalmente firma o envía el depósito en la cadena. Los validadores activados existentes y los depósitos ya confirmados permanecen fuera del área expuesta. Solo las claves públicas que aún tienen depósitos pendientes o recién enviados durante el epoch de transición están expuestas.
Los delegadores de staking deben confirmar que su protocolo elegido ha publicado orientación sobre el manejo de depósitos en torno a la activación de Glamsterdam. Los operadores deben auditar cuidadosamente el orden de envío, los límites de tasa o la secuencia de depósitos, y verificar que ningún depósito con prefijo 0xB0 pueda reclamar una clave destinada a un validador estándar. Dado que el plazo es corto, una reducción temporal en el rendimiento de nuevos depósitos o una postura de monitoreo elevada pueden cerrar la mayoría de las vías de ataque prácticas sin interrumpir a largo plazo las operaciones de staking.
Hoodi ofrece el primer entorno en vivo para la prueba de la tubería de depósitos
La activación de Hoodi el 26 de octubre es la primera oportunidad pública para que los equipos de staking observen el comportamiento de la cola compartida bajo condiciones realistas. Los protocolos pueden enviar depósitos de prueba con credenciales ordinarias y 0xB0, medir los resultados de ordenamiento y confirmar que sus filtros previos al depósito rechacen o pongan en cuarentena la ruta no deseada. Los equipos de clientes ya han lanzado versiones compatibles con Hoodi; los operadores deben asegurarse de que tanto los clientes de ejecución como los de consenso estén actualizados y que cualquier herramienta externa de builder haya sido revisada para las nuevas interfaces.
La prueba exitosa en Hoodi dará a la industria mayor confianza antes de que se abra la ventana del mainnet. Los fallos o casos límite inesperados descubiertos en el testnet aún pueden abordarse con cambios en la capa de aplicación o pausas cortas sin requerir un rediseño del protocolo. El corto plazo entre la advertencia pública y la activación de Hoodi hace esencial la prueba coordinada.
La responsabilidad de la mitigación ahora recae en cada protocolo de staking
Al cerrar el tema de consensus-specs como no planeado, los desarrolladores principales señalaron que el riesgo temporal se maneja mejor en la capa de aplicación. Los proveedores de liquid staking, las plataformas de operadores individuales y cualquier servicio que envíe depósitos en nombre de los usuarios deben implementar sus propias verificaciones. Los proveedores que ya mantienen comités guardianes o procesos de atestación de raíz de depósito pueden extender esos procesos para cubrir el prefijo 0xB0. Los proveedores sin dicha infraestructura enfrentan un plazo más ajustado para agregar controles equivalentes.
El modelo distribuido tiene ventajas y desventajas. Permite respuestas rápidas y personalizadas sin necesidad de esperar un cambio de bifurcación dura en toda la red. También significa que la seguridad del depósito de cualquier staker depende de las prácticas específicas del protocolo que eligieron. La transparencia sobre los procedimientos de manejo de depósitos alrededor del epoch de activación ayudará a los usuarios a evaluar el riesgo residual.
Los objetivos de escalabilidad y los casos límite temporales siguen vinculados en las actualizaciones de ethereum
Glamsterdam avanza la hoja de ruta de escalado L1 de Ethereum al aumentar el límite de gas práctico hacia 200 millones, habilitando el procesamiento paralelo de transacciones mediante listas de acceso a nivel de bloque y eliminando los relés externos de la ruta crítica de producción de bloques. Esos avances requieren nuevas primitivas en cadena para los constructores, lo que a su vez genera la superposición temporal de la cola de depósitos. El patrón es característico de actualizaciones importantes: las mejoras arquitectónicas a largo plazo pueden generar casos extremos de corta duración que los equipos de aplicaciones deben gestionar.
La capacidad de la industria para absorber esos casos extremos sin pérdidas de fondos de usuarios influirá en la confianza en actualizaciones posteriores. La validación previa al depósito, la pausa temporal de depósitos y la comunicación clara por parte del operador son las herramientas prácticas disponibles en este caso. Dado que el riesgo se limita a un intervalo conocido y breve, el costo de la preparación es finito, y el beneficio es la preservación de los depósitos de los usuarios durante la transición.
Los depósitos pendientes requieren un monitoreo reforzado hasta que se complete la transición
Cualquier clave pública que aún tenga un depósito sin procesar en el momento en que se activen las reglas de Glamsterdam se encuentra dentro de la ventana de ataque potencial. Los protocolos pueden mitigar esto agotando o acelerando sus colas de depósitos antes del epoch, rechazando credenciales 0xB0 para intenciones de validador, o pausando nuevas presentaciones durante un breve período alrededor de la activación. La monitorización continua de los cambios en el root de depósito y el estado de reclamación de claves públicas durante las horas críticas permitirá una respuesta rápida si aparece actividad anómala.
Una vez que se complete la bifurcación y los depósitos de los constructores se muevan a su ruta de contrato separada, el vector de cola compartida se cierra. Por lo tanto, la carga de monitoreo tiene una fecha de finalización clara. Los equipos que traten la transición como un período operativo de alta atención en lugar de una actualización rutinaria estarán mejor posicionados para proteger los fondos de los stakers.
🔥 Más allá de las noticias: qué significa KuCoin 5.0 para ti
Las noticias del mercado avanzan rápido — pero donde actúes sobre ellas importa igualmente. Este octubre, KuCoin lanza KuCoin 5.0, transformando KuCoin en una plataforma reconstruida. Aquí está lo que realmente cambia para ti:
-
Una cuenta para todo. Las plataformas antiguas dividían tu dinero entre cuentas separadas de "spot", "margin" y "futures" y esperaban que entendieras por qué. La cuenta unificada de KuCoin 5.0 elimina esto por completo: realiza un depósito una vez y todo estará simplemente disponible (actualmente solo disponible para VIPs).
-
Acciones, índices y materias primas. KuCoin 5.0 se expande más allá del cripto hacia mercados globales. Cuando el cripto se mueve lateralmente y las acciones suben (o al revés), rotates en minutos en lugar de abrir una cuenta de corretaje y esperar días para que se activen los canales de moneda fiduciaria.
-
Activos del mundo real (RWA). Exposición tokenizada a activos tradicionales como materias primas, directamente en tu cuenta de cripto. Uno de los segmentos de más rápido crecimiento en las finanzas globales ya no está reservado para instituciones: tú lo accedes desde el mismo saldo con el que operas.
-
Gana mientras aprendes. ¿Aún no estás listo para operar? KCUSD permite que tus stablecoins generen intereses diarios con autocomposición. La forma menos estresante de hacer que tus depósitos inactivos trabajen para ti con un rendimiento del 4%.
-
Un asistente de IA en lenguaje sencillo. Haz preguntas, obtén contexto del mercado, entiende lo que estás viendo: integrado en la plataforma, sin necesidad de jerga.
-
Una aplicación que no abruma. Más rápida, más limpia y coherente: intuitiva desde el primer toque, no después de un tutorial.
-
Seguridad que puedes verificar, no solo confiar. Una entidad de la UE con licencia MiCAR, Proof of Reserves que puedes verificar tú mismo, y seguridad certificada internacionalmente (SOC 2 Type II, ISO 27001:2022).
Crea tu cuenta en minutos y comienza en la plataforma diseñada para adónde va el cripto, no adónde ha estado.
Preguntas frecuentes
¿Qué es exactamente la actualización Glamsterdam y por qué es importante para el staking?
Glamsterdam es el nombre combinado para los cambios en la capa de ejecución de Amsterdam y la capa de consenso Gloas. Sus objetivos principales son la separación consagrada entre propuesta y construcción, y listas de acceso a nivel de bloque que permiten límites de gas más altos y un procesamiento de bloques más eficiente. Para el staking, la introducción del registro en cadena de constructores y la vía de depósito asociada crea el comportamiento temporal de compartición de colas que subyace al riesgo de front-running.
¿Cuánto dura la ventana de secuestro de depósito?
La ventana existe únicamente mientras los depósitos de builder aún viajan a través de la cola de depósitos del validador. Esa condición se mantiene durante la propia transición de la bifurcación. Después de completarse la actualización, los depósitos de builder se procesan a través de un contrato separado, cerrando la ruta de la cola compartida. La duración práctica, por lo tanto, se mide en las horas alrededor del epoch de activación, no en días o semanas.
¿Afecta el riesgo a los validadores ya activados o al ETH apostado existente?
No. El ataque tiene como objetivo nuevos depósitos o depósitos aún en cola para claves públicas que aún no han generado un validador activo. Los validadores existentes y sus saldos permanecen bajo sus credenciales de retiro establecidas y están fuera del ámbito del ataque descrito.
¿Qué pueden hacer los stakers comunes para protegerse?
Los stakers que realicen depósitos a través de un protocolo de staking líquido deben confirmar que el protocolo ha publicado orientación específica sobre el manejo de depósitos en torno a la activación de Glamsterdam. Elegir un proveedor que ya opere seguridad de depósito multi-partes o supervisión tipo guardian reduce el riesgo residual. Los stakers que ejecuten sus propios validadores deben asegurarse de que su lógica de envío de depósitos no permita que un depósito competidor 0xB0 reclame la misma clave pública.
¿Por qué los desarrolladores principales rechazaron una solución a nivel de protocolo?
La propuesta para las verificaciones previas al depósito se cerró como no planificada, principalmente debido a la presión de horario. Sepolia ya se había activado bajo las reglas existentes, y las versiones del cliente Hoodi estaban avanzando. Un cambio tardío en el comportamiento habría arriesgado redespliegues adicionales y retrasos en la testnet. Los desarrolladores consideraron que las mitigaciones a nivel de aplicación eran suficientes dado el breve período de exposición.
Descargo de responsabilidad: Este contenido tiene fines informativos únicamente y no constituye asesoramiento de inversión. Las inversiones en criptomonedas conllevan riesgos. Realiza tu propia investigación (DYOR).
Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.