La actualización Glamsterdam de Ethereum podría interrumpir los contratos inteligentes existentes

Propuestas en Competencia para la Actualización Glamsterdam

Los desarrolladores de Ethereum han presentado dos propuestas en competencia para evitar que la próxima actualización Glamsterdam interrumpa los contratos inteligentes existentes, ante el creciente temor por los cambios en las reglas de precios del gas de la red. Leo Glisic y Giulio Rebuffo, los desarrolladores detrás de estas propuestas, las dieron a conocer el domingo 8 de noviembre, ofreciendo diferentes enfoques para introducir los nuevos cargos de gas sin afectar a las aplicaciones que ya operan en Ethereum.

Contexto y Preocupaciones de Seguridad

Estas propuestas surgen tras advertencias de seguridad que han llevado a los desarrolladores a posponer partes del cronograma de pruebas de Glamsterdam. Algunos contratos inteligentes existentes dependen de costos de gas fijos, y modificar esos costos podría provocar fallos en las transacciones o interferir con aplicaciones que no pueden ser actualizadas después de su implementación.

Propuesta de Leo Glisic: EIP-8488

La propuesta de Glisic, conocida como EIP-8488, introduciría un conjunto separado de instrucciones para los contratos inteligentes recién desplegados, permitiendo que los contratos más antiguos continúen operando bajo sus reglas de gas actuales. Según esta propuesta, los nuevos contratos utilizarían códigos de operación V2 que seguirían la estructura de precios revisada introducida a través de EIP-8037 y EIP-8038. Los contratos existentes retendrían la estructura de precios original, lo que permitiría a los desarrolladores implementar cambios sin obligar a las aplicaciones más antiguas a adaptarse.

Propuesta de Giulio Rebuffo

Por su parte, Rebuffo ha sugerido una solución diferente en un borrador separado que introduciría dos sistemas de contabilidad de gas dentro de cada transacción. Uno de estos sistemas calcularía cuánto gas consume un contrato bajo las reglas anteriores, preservando las condiciones esperadas durante la ejecución. El segundo calcularía la tarifa de transacción real utilizando el nuevo cronograma de precios. Sin embargo, su propuesta reconoce que aún no se han completado las implementaciones de clientes de ejecución ni las pruebas de consenso para este diseño.

Preocupaciones sobre la Compatibilidad

Hasta el momento, ninguna de las propuestas ha sido aprobada para su inclusión en Glamsterdam. Las preocupaciones sobre la compatibilidad surgen de EIP-8037 y EIP-8038, que modifican la forma en que Ethereum cobra por crear y acceder al estado de la blockchain. EIP-8037 aumentaría el cargo base de gas para crear un contrato inteligente de 32,000 a 183,600, excluyendo costos adicionales de ejecución y almacenamiento de código. Aunque estos cambios buscan reflejar mejor los recursos consumidos por la actividad de la blockchain, investigadores de seguridad han advertido que las aplicaciones existentes pueden no estar preparadas para los nuevos cargos.

Como se informó anteriormente en crypto.news, la firma de seguridad ChainSecurity identificó ocho suposiciones utilizadas por contratos inteligentes existentes que podrían volverse inválidas bajo las nuevas reglas de gas propuestas.

Algunos contratos reservan una cantidad fija de gas para llamadas externas, mientras que otros dependen de un comportamiento específico cuando las transacciones fallan. Un cambio inesperado en el consumo de gas podría interferir con esas operaciones.

Opiniones de la Comunidad

El desarrollador seudónimo banteg advirtió en X que un análisis previo ya había identificado aproximadamente 200,000 contratos potencialmente afectados, y que problemas metodológicos podrían significar que el número real sea aún mayor. Además, el desarrollador señaló que las preocupaciones se extienden a la implementación y operación de varios protocolos prominentes, en lugar de limitarse a errores de codificación aislados.

Las propuestas de cambio han suscitado críticas de desarrolladores y figuras de la industria DeFi, quienes creen que Ethereum debería abordar las preocupaciones de compatibilidad antes de avanzar. Michael Egorov, fundador de Curve Finance, advirtió en X que Glamsterdam podría causar problemas graves si los desarrolladores continúan sin abordar los riesgos.

"Querido, por favor no rompas la cadena. Parece que Glamsterdam, en su forma actual, llevaría a otro hard fork de emergencia hacia atrás, con mucho drama"

.

Ryan Berckmans, miembro de la comunidad de Ethereum e inversor, inicialmente apoyó avanzar con la actualización, argumentando que Ethereum no podía garantizar precios de gas inalterados para cada aplicación existente. Sin embargo, Berckmans revirtió su posición tras revisar las preocupaciones de compatibilidad.

"No deberíamos (claramente, ahora) continuar hacia la activación de Glam lo antes posible. Estuve equivocado al decirlo"

.

El investigador de seguridad pcaversaccio ha adoptado una postura más firme, argumentando que Glamsterdam no debería ser desplegado en su forma actual.

"En mi humilde opinión, Glamsterdam no debería ser lanzado en su forma actual, punto"

, escribió el investigador, refiriéndose a los cambios de gas que supuestamente habían sido señalados a los desarrolladores centrales de Ethereum semanas antes.

Aplazamiento de la Activación de Hoodi

Los desarrolladores de Ethereum pospusieron la activación de Hoodi del 26 de octubre después de que surgieron preocupaciones sobre cómo las reglas de gas revisadas podrían afectar a los contratos ya desplegados en la mainnet. Este aplazamiento abarcó los cambios en la capa de ejecución de Ámsterdam, los cambios de consenso de Gloas y un aumento planificado en el límite de gas de Hoodi a 200 millones.

En una declaración del 6 de noviembre, Marius van der Wijden, desarrollador de la Fundación Ethereum, indicó que la organización estaba trabajando con ChainSecurity y Dedaub para examinar las aplicaciones afectadas y recopilar comentarios de los desarrolladores. Una prueba privada posterior de Glamsterdam había sido discutida tentativamente para el 16 al 20 de noviembre como muy pronto, durante una reunión de desarrolladores del 29 de octubre. Este cronograma se elaboró antes de que se presentaran las dos propuestas en competencia.