Los desarrolladores del protocolo han logrado neutralizar una vulnerabilidad en las especificaciones de consenso de la red antes de su despliegue definitivo. El equipo central implementó una modificación técnica que evita que los fondos de nuevos validadores queden asignados erróneamente a los constructores de bloques dentro de la esperada bifurcación Glamsterdam.
Este ajuste de arquitectura llega tras un intenso debate dentro de la comunidad técnica. Gracias a una pausa en el calendario de pruebas, los equipos de investigación identificaron el riesgo a tiempo, protegiendo a los proveedores de staking líquido antes de que cualquier fondo pudiera verse comprometido.
La vulnerabilidad detectada en la actualización Glamsterdam
El núcleo de la red se prepara para una de sus transiciones técnicas más profundas con la llegada de Glamsterdam. Esta actualización introduce una división estructural de funciones entre dos actores fundamentales del ecosistema: los constructores de bloques (costruttori), encargados de agrupar y ordenar las transacciones, y los validadores, cuya función es proponer y certificar dichos bloques para mantener el consenso. Sin embargo, un análisis de seguridad reveló que los desarrolladores de Ethereum corrigieron un fallo en Glamsterdam que habría permitido desviar depósitos de staking hacia los builders durante el procesamiento de transacciones pendientes.
El problema residía en cómo el borrador de las especificaciones de consenso gestionaba las claves públicas compartidas. En un escenario específico analizado durante las pruebas técnicas de octubre de 2026, un operador malicioso podía registrarse inicialmente como constructor empleando una clave pública determinada. Si un protocolo o usuario enviaba posteriormente un depósito para activar un nodo validador utilizando esa misma clave identificativa, las reglas provisionales acreditaban la totalidad del saldo al constructor. Esto dejaba a la entidad emisora sin la posibilidad técnica de generar las pruebas criptográficas necesarias para retirar o reclamar su capital, permitiendo al operador del nodo constructor retirar los fondos transferidos.
El papel de los protocolos de staking y la investigación técnica
La anomalía fue sacada a la luz por el investigador técnico avsetsin, vinculado a la organización técnica de Lido. El especialista evaluó el impacto potencial en diferentes soluciones del ecosistema como Lido, Rocket Pool y Origin Protocol. Aunque se trataba de hallazgos condicionales de código y no de exploits ejecutados en la red principal, la posibilidad teórica de desviar depósitos representaba una amenaza de seguridad que no podía ignorarse en un entorno descentralizado de alta capitalización.
Para entender la importancia de este mecanismo, conviene repasar los fundamentos técnicos disponibles en plataformas educativas como Accademia Bit2Me, donde se analiza cómo opera el consenso de prueba de participación (Proof of Stake). En Ethereum, cada validador debe comprometer 32 ETH para participar en la validación, y los proveedores de staking agregan depósitos de miles de usuarios individuales. Si la capa de consenso confunde la titularidad de los depósitos pendientes al momento de aplicar una bifurcación dura, los contratos inteligentes de estas plataformas carecen de mecanismos nativos para revertir la asignación en la capa base. La rápida intervención de los auditores impidió que el error pasara a etapas avanzadas de integración en el software cliente.
Del rechazo inicial a la integración definitiva en el código
El proceso para resolver este fallo técnico atravesó momentos de fricción técnica entre los mantenedores del repositorio de especificaciones y los equipos que desarrollan los clientes de la red. La propuesta de corrección se cerró temporalmente el 19 de octubre, después de que Justin Traglia, uno de los principales responsables de las especificaciones de consenso, señalara que no existía suficiente respaldo por parte de los equipos de clientes para aplicar la modificación en ese instante. Varios desarrolladores consideraban que los filtros existentes en los contratos inteligentes ya mitigaban la posibilidad de registrar claves duplicadas.
No obstante, la ampliación de los plazos de prueba permitió profundizar en las simulaciones. El 23 de octubre se incorporaron pruebas adicionales al repositorio que demostraron la necesidad de contar con una regla determinista en la capa de consenso. Finalmente, la modificación fue aprobada y fusionada formalmente el lunes siguiente. Con la nueva lógica, todos los depósitos en cola se clasifican estrictamente según sus credenciales de retirada (withdrawal credentials). Esto garantiza que, incluso si un constructor y un validador coinciden en el uso de una misma clave pública, los fondos destinados a la validación permanecen asignados exclusivamente a la dirección de retiro configurada por el depositante legítimo.
Calendario de despliegue en redes de prueba y mainnet
La resolución de esta discrepancia en las especificaciones teóricas no implica que la actualización esté lista de inmediato para su activación general. Los diferentes equipos responsables del software de validación —que incluye clientes de ejecución y de consenso— deben adaptar su código fuente a estas nuevas especificaciones antes de que Glamsterdam pueda continuar su hoja de ruta hacia la red principal.
En términos de despliegue práctico, Glamsterdam ya completó una fase inicial de pruebas en la red Sepolia. Sin embargo, su lanzamiento programado para el 26 de octubre en la red de pruebas Hoodi tuvo que posponerse para dar margen a la revisión de la seguridad de contratos preexistentes y a la incorporación de esta corrección de depósitos. Hasta que la comunidad técnica no valide el comportamiento de las nuevas credenciales de retiro en Hoodi y determine una fecha definitiva para esa red, no se programará el despliegue en la red principal de Ethereum. Esta rigurosidad técnica refleja el compromiso del ecosistema con la estabilidad de los fondos institucionales y minoristas que aseguran la infraestructura.
Impacto de la seguridad en la infraestructura cripto bajo MiCA
La robustez técnica de los protocolos subyacentes es un factor determinante para las entidades reguladas en el marco de la Unión Europea. Bajo el Reglamento MiCA, los proveedores de servicios de criptoactivos deben garantizar una gestión de riesgos exhaustiva, auditada y transparente sobre las plataformas y redes en las que operan sus clientes. Los incidentes potenciales en la capa de consenso de cadenas principales exigen una supervisión constante por parte de los operadores autorizados.
En el mercado europeo y español, la custodia y el soporte de activos vinculados a staking requieren estándares estrictos de diligencia debida. Detectar y corregir vulnerabilidades en etapas previas al despliegue en mainnet protege la integridad del mercado y consolida la confianza en los modelos basados en validación descentralizada. Para quienes deciden analizar la actualidad cripto con criterio técnico, la capacidad de respuesta demostrada por los ingenieros de Ethereum subraya la madurez de los procesos de gobernanza de software abierto frente a fallos potencialmente críticos.
Domande frequenti
¿Qué provocaba exactamente el fallo en la actualización Glamsterdam?
El error permitía que, si un operador se registraba como constructor de bloques con una clave pública y luego se enviaba un depósito de validador con esa misma clave, ambos fondos se asignaran al constructor. Esto impedía al validador recuperar su depósito original.
¿Se produjo alguna pérdida de fondos reales por esta vulnerabilidad?
No se ha registrado ninguna pérdida económica en la red. El fallo fue descubierto de forma preventiva en el repositorio de especificaciones teóricas y en entornos de prueba, lo que permitió aplicar la solución antes de su llegada a la red principal.
¿Cómo soluciona el nuevo código la asignación de depósitos?
La corrección aprobada clasifica los depósitos pendientes mediante sus credenciales de retirada. De este modo, los fondos dirigidos a validación se mantienen separados de los constructores, independientemente de la clave pública utilizada durante el registro en el protocolo.
¿Cuándo se activará Glamsterdam en la red principal de Ethereum?
La fecha para la red principal aún no está fijada. Los desarrolladores deben completar primero las pruebas en la red Hoodi, reprogramada tras varias revisiones de seguridad, antes de que los clientes de software coordinen la actualización definitiva.
La detección y resolución oportuna de este error en Glamsterdam pone de manifiesto la vital importancia de las etapas de auditoría y pruebas exhaustivas en el desarrollo de redes descentralizadas. Gracias a la colaboración activa entre investigadores externos y los mantenedores del protocolo, Ethereum refuerza sus defensas frente a posibles vectores de conflicto en la asignación de capital.
A medida que la red avanza hacia una separación más sofisticada de sus roles de validación y construcción de bloques, la estabilidad operativa continuará siendo el pilar indispensable para garantizar la seguridad de los usuarios y de las plataformas que interactúan a diario con la tecnología de contratos inteligentes.
Gli investimenti in criptovalute non sono completamente regolamentati, potrebbero non essere adatti agli investitori al dettaglio a causa dell'elevata volatilità e sussiste il rischio di perdere tutti gli importi investiti.
Per la creazione di questo articolo sono stati utilizzati strumenti di intelligenza artificiale generativa.
