Ethereum tiene un problema que casi nunca sale en los titulares: qué ocurre con los contratos inteligentes que ya están desplegados cuando la red cambia sus reglas de coste. El próximo gran hard fork, bautizado como Glamsterdam, incluye dos propuestas de mejora que encarecen la creación de contratos y el acceso a los datos guardados en la cadena. Dos desarrolladores han presentado soluciones rivales para evitar que miles de aplicaciones se rompan por el camino.
Conviene recordar qué es un contrato inteligente: un programa que vive dentro de Ethereum, se ejecuta solo cuando alguien lo invoca y, en la mayoría de los casos, no puede modificarse después. Ahí está el nudo. Un contrato que custodia fondos de usuarios no se actualiza sin más porque cambie el precio del gas.
Qué cambian EIP-8037 y EIP-8038 en la práctica
El gas es la unidad con la que Ethereum mide el esfuerzo computacional de cada operación: cada instrucción tiene un precio y el usuario paga la suma. La discusión, por tanto, no va de comisiones más caras o más baratas para quien envía una transferencia, sino de la aritmética interna que muchos contratos dan por sentada cuando llaman a otros contratos.
La propuesta EIP-8037 eleva el coste base de crear un contrato desde los 32.000 gas actuales hasta 183.600 gas, casi seis veces más, y a esa cifra se suman los costes de almacenar y ejecutar código. La EIP-8038 toca otra pieza: el precio de leer y escribir en el almacenamiento de la red, el armario donde cada contrato guarda saldos, permisos y su propio estado.
El fallo aparece cuando un contrato reserva una cantidad fija de gas para llamar a otro. Si la operación deja de caber en ese presupuesto, se revierte y la transacción se queda a medias. Afecta sobre todo a protocolos que mueven dinero ajeno, donde una ejecución fallida no es una molestia menor sino un saldo bloqueado.
Un contrato que no se puede reescribir no negocia con el nuevo tarifario: o le salen las cuentas o falla en silencio.
Dos propuestas rivales para el mismo problema
Las dos soluciones se presentaron el domingo y atacan el mismo punto desde ángulos distintos. Ninguna ha sido adoptada. Ninguna elimina el riesgo por completo.
EIP-8488: dos juegos de instrucciones
Leo Glisic firma la EIP-8488, que parte Ethereum en dos regímenes. Los contratos desplegados antes del fork conservan el tarifario actual; los nuevos tendrán que usar versiones revisadas de las instrucciones (los opcodes V2, las órdenes básicas que interpreta la máquina virtual) para asumir los costes de 8037 y 8038. El borrador lo resume en una línea: los contratos existentes mantienen el calendario heredado.
La doble contabilidad de Rebuffo
Giulio Rebuffo propone otra cosa: en lugar de dos juegos de instrucciones, dos medidores de gas dentro de cada transacción. Uno calcula lo que se le cobra al usuario con el tarifario nuevo; el otro ejecuta el contrato con las reglas antiguas. La factura sube, el comportamiento del código viejo no se toca.
El propio borrador reconoce su punto débil. No se ha ejecutado ninguna implementación en clientes de ejecución ni ninguna prueba de consenso: sobre el papel suena razonable, en la práctica está sin validar.
200.000 contratos en la lista y un ensayo que ya se aplazó
El desarrollador conocido como banteg señaló una lista de aproximadamente 200.000 contratos potencialmente afectados, recogida en el repositorio ethereum/repricing-impact, y avisó de que la metodología empleada puede quedarse corta. Traducido: puede haber bastante más de lo que dice el recuento.
El investigador de seguridad pcaversaccio fue más directo. Sostuvo en X que Glamsterdam no debería activarse tal y como está y que las advertencias llevaban dos semanas encima de la mesa de los desarrolladores core. El calendario ya se ha resentido: el upgrade está desplegado en una red de pruebas, pero el segundo ensayo, previsto en principio para el 26 de octubre, se aplazó tras esas alertas. Una red de pruebas es un Ethereum de laboratorio, sin fondos reales en juego, donde se comprueba si algo falla antes de que falle de verdad.
Tampoco es la primera vez que un reprecio incomoda a la red. En 2016, después de una oleada de ataques de denegación de servicio, Ethereum aprobó un reajuste de emergencia (EIP-150) que obligó a revisar contratos que habían calculado sus costes con el tarifario anterior. Y la EIP-1559, activada en agosto de 2021, cambió el mercado de comisiones para siempre. La lección de ambos episodios es parecida: el código que nadie mantiene es el que primero paga la factura.
Mi lectura es que el debate está bien planteado y mal cronometrado. Glamsterdam llega detrás de Fusaka con la vista puesta en 2027 y con varios frentes abiertos a la vez. Si el reprecio se hace deprisa, el coste no lo asume la red: lo asumen los usuarios de protocolos antiguos que nadie va a rescatar.
Las preguntas abiertas son concretas. ¿Se adopta la EIP-8488 y conviven dos Ethereum dentro de Ethereum? ¿Se apuesta por la doble contabilidad y se espera a que alguien la implemente? ¿O se retrasa el reprecio a un fork posterior? La condición que cambiaría el escenario sería una batería de pruebas de consenso limpia y una lista definitiva de contratos afectados. Ninguna de las dos existe todavía.
