Dos desarrolladores de Ethereum, Leo Glisic y Giulio Rebuffo, presentaron el domingo propuestas rivales que describen estrategias distintas para proteger las aplicaciones ya desplegadas en la red. Ambas abordan las posibles consecuencias de las propuestas de mejora de Ethereum EIP-8037 y EIP-8038, que aumentarían el gas requerido para ciertas operaciones de contratos inteligentes. La disputa se ha convertido en un tema significativo para Glamsterdam, mientras los desarrolladores evalúan si los cambios de precios propuestos pueden introducirse sin interferir con contratos diseñados en torno al calendario de gas existente de Ethereum.

Los cambios de gas de Glamsterdam generan preocupaciones de compatibilidad

En el centro de la controversia están EIP-8037 y EIP-8038, dos propuestas incluidas en la planeada actualización Glamsterdam que modificarían el costo de crear contratos y de acceder a datos almacenados en la blockchain. El gas es la unidad que Ethereum utiliza para medir los recursos computacionales necesarios para ejecutar transacciones e instrucciones de contratos inteligentes, y los cambios en el precio del gas pueden alterar el comportamiento de las aplicaciones, en particular cuando los desarrolladores han programado contratos en torno a límites de ejecución específicos.

Las actualizaciones de Ethereum como Glamsterdam agrupan múltiples EIP en un único cambio coordinado de las reglas de la red, y las propuestas normalmente pasan por revisión de los desarrolladores principales, implementación en clientes y pruebas en testnet antes de tomar una decisión de activación. La disputa actual se desarrolla dentro de ese proceso: las objeciones están surgiendo mientras Glamsterdam todavía se encuentra en evaluación de testnet, antes de que algo llegue a la blockchain principal.

Bajo EIP-8037, el cargo base de gas para crear un contrato inteligente aumentaría de 32.000 a 183.600 de gas, con costos adicionales vinculados al almacenamiento y la ejecución de código aplicados por separado. El aumento ha generado preocupaciones porque algunas aplicaciones existentes de Ethereum fueron desarrolladas con la expectativa de que ciertas operaciones seguirían consumiendo la misma cantidad de gas.

Algunos contratos asignan una cantidad fija de gas al interactuar con otras aplicaciones. Si el costo de esas interacciones supera la cantidad asignada, las operaciones podrían fallar. Las consecuencias son particularmente graves para los contratos inteligentes que no pueden modificarse después del despliegue, ya que dichas aplicaciones pueden no tener un mecanismo directo para adaptarse a un calendario de gas revisado.

Investigadores de seguridad advierten de interrupciones generalizadas en contratos

Las preocupaciones ya han afectado el cronograma de pruebas de Glamsterdam. Aunque la actualización ha sido desplegada en una red de pruebas de Ethereum, un segundo ejercicio de pruebas programado para el 26 de octubre fue aplazado tras advertencias de investigadores de seguridad. Las redes de pruebas de Ethereum permiten a los desarrolladores evaluar los cambios de protocolo antes de que lleguen a la blockchain principal, donde las aplicaciones y transacciones involucran activos reales. Los calendarios de gas también han sido revisados en actualizaciones anteriores de Ethereum, por lo que las propuestas de reajuste de precios se verifican de forma rutinaria frente a contratos escritos con supuestos de costos antiguos.

El investigador de seguridad pcaversaccio criticó públicamente los ajustes de gas propuestos, argumentando que Glamsterdam no debería avanzar en su forma actual.

"imho Glamsterdam should not be shipped in its current form, period," escribió pcaversaccio en X.

El investigador dijo que las preocupaciones habían sido planteadas a los desarrolladores principales de Ethereum dos semanas antes.

El desarrollador seudónimo banteg también cuestionó el alcance de las evaluaciones de compatibilidad existentes, señalando una lista de aproximadamente 200.000 contratos potencialmente afectados en el repositorio ethereum/repricing-impact. Según banteg, las limitaciones metodológicas de la evaluación podrían significar que considerablemente más contratos están afectados de lo que indica la lista actual. El desarrollador advirtió además que los cambios propuestos podrían interferir con el despliegue y funcionamiento de varios protocolos prominentes de Ethereum, en lugar de afectar solo a aplicaciones menos utilizadas.

Las advertencias han intensificado el escrutinio sobre cómo pretenden los desarrolladores de Ethereum implementar el reajuste del precio del gas preservando la funcionalidad de los contratos que ya operan en la red.

EIP-8488 propone reglas de gas separadas para contratos existentes y nuevos

La propuesta de Glisic, identificada como EIP-8488, introduce un mecanismo de compatibilidad que distinguiría entre los contratos inteligentes desplegados antes de la actualización y los creados después. Los contratos existentes continuarían operando bajo las reglas actuales de precios de gas de Ethereum, mientras que los contratos recién desplegados utilizarían un conjunto revisado de instrucciones que refleja los mayores costos de gas introducidos por EIP-8037 y EIP-8038.

La propuesta dividiría efectivamente el conjunto de instrucciones de Ethereum en dos versiones, permitiendo que las aplicaciones más antiguas conserven sus costos de ejecución establecidos y exigiendo que las nuevas aplicaciones sigan la estructura de precios actualizada.

"Existing contracts keep the legacy schedule," señala el borrador del EIP-8488.

Los nuevos contratos deberían usar los opcodes V2 asociados con el calendario de gas revisado. El enfoque tiene como objetivo reducir los riesgos de compatibilidad para las aplicaciones que no pueden actualizarse, al tiempo que permite a Ethereum introducir sus cambios planificados de precios de gas para futuros despliegues.

Propuesta alternativa introduce doble contabilidad de gas

Rebuffo ha presentado un mecanismo diferente que aplicaría el nuevo calendario de precios de gas a la facturación de transacciones preservando el comportamiento de ejecución existente de los contratos inteligentes más antiguos. En lugar de mantener conjuntos de instrucciones separados para aplicaciones antiguas y nuevas, el diseño introduciría dos mecanismos de contabilidad de gas dentro de cada transacción. Un medidor rastrearía la ejecución del contrato según las reglas de gas existentes, mientras que un segundo calcularía los cargos de la transacción utilizando el calendario de precios actualizado.

Bajo esta estructura, el nuevo calendario determinaría la tarifa de la transacción, pero las aplicaciones más antiguas seguirían ejecutándose bajo los supuestos establecidos por las reglas de gas anteriores. La propuesta busca separar el cálculo de los costos de transacción de las condiciones de ejecución de las que dependen los contratos inteligentes existentes.

Sin embargo, el borrador reconoce que el diseño permanece sin probar a nivel de implementación.

"no execution-client implementation or consensus tests have been run for this design," indica la propuesta.

Los desarrolladores enfrentan decisiones sobre los cambios de gas de Glamsterdam

Las propuestas en competencia destacan enfoques diferentes para abordar el mismo problema de compatibilidad. El EIP-8488 de Glisic preservaría los precios de gas existentes para los contratos previamente desplegados mientras introduce el calendario revisado mediante nuevas instrucciones. La alternativa de Rebuffo aplicaría la facturación de transacciones actualizada manteniendo el comportamiento de ejecución heredado. Ambos enfoques buscan evitar que el reajuste planificado del precio del gas interrumpa las aplicaciones que dependen de los costos de ejecución existentes de Ethereum.

El tema ha atraído atención porque los contratos afectados pueden incluir protocolos establecidos que no pueden modificar fácilmente su código desplegado. Con las pruebas ya aplazadas tras las advertencias de seguridad, las propuestas introducen posibles soluciones técnicas para los desarrolladores que evalúan los riesgos de compatibilidad de Glamsterdam.

Los hitos que harían avanzar el debate son concretos: una ronda de testnet reprogramada ejecutada con un mecanismo de compatibilidad implementado y, si alguno de los borradores avanza, implementaciones en clientes de ejecución y resultados de pruebas de consenso para evaluarlo. Hasta que ocurran esos pasos, la cuestión de compatibilidad sigue abierta mientras Glamsterdam avanza en su ciclo de desarrollo.

La información disponible no establece si alguna de las propuestas será adoptada. El diseño de Rebuffo también sigue sin implementación en clientes de ejecución ni resultados de pruebas de consenso, dejando su viabilidad técnica sujeta a evaluación adicional.

Fuente: CoinDesk

Publicado por primera vez en: Hokanews