• El 6 de noviembre, la Fundación Ethereum pidió a desarrolladores y auditores que verificaran el impacto de las especificaciones de Glamsterdam.
• EIP-8037 introduce un contador de gas independiente para la creación de estado; EIP-8038 modifica el precio del acceso al estado existente.
• El análisis de ChainSecurity del 13 de octubre identificó varios proyectos vulnerables con las especificaciones modificadas.
EIP-8037, EIP-8038 y la división del gas
Los desarrolladores y auditores de contratos inteligentes detrás de los despliegues en Ethereum recibieron una solicitud directa de la Fundación Ethereum el 6 de noviembre: verificar cómo afectarían a sus proyectos los cambios de especificación previstos para la próxima gran actualización de la red, Glamsterdam. Para facilitar esa revisión, la Fundación publicó material de referencia con ocho invariantes —condiciones que el código en ejecución puede dar por sentadas de forma implícita— que los cambios propuestos invalidarían. Cada entrada indica la condición, explica por qué dejaría de cumplirse y muestra dónde aparece ese supuesto en la práctica. La solicitud se centra en dos propuestas de mejora de Ethereum: EIP-8037 cambia el costo de gas de crear nuevo estado en la cadena, y EIP-8038 revisa el costo de acceder al estado que ya existe. El estado abarca la información de las cuentas y los datos que contiene un contrato almacenado. En Ethereum, las tarifas de gas miden los recursos computacionales que consume una transacción o la ejecución de un contrato. Toda operación en la red, desde una transferencia simple hasta una llamada anidada a un contrato, consume parte de este presupuesto. EIP-8037 va más allá de modificar los precios: introduce un contador de gas separado para el gas destinado a crear estado, distinto del gas destinado al procesamiento ordinario, que hoy se deduce de una asignación combinada. En la práctica, la actualización fijaría precios por separado para dos recursos que hoy se cubren con una sola cifra. Por lo tanto, los cambios pueden alterar tanto la cantidad de gas que necesita una operación como la cantidad que queda disponible después de que una operación falla a mitad de la ejecución. Este segundo efecto es el que supone un riesgo para el código en ejecución. El material se dirige a contratos ya desplegados, donde una regla modificada afecta al código activo y no a un borrador. Se pide a los desarrolladores y auditores que detecten una dependencia de cualquiera de las ocho condiciones que se pongan en contacto directamente con la Fundación. La solicitud llegó mientras el precio de Ethereum (ETH) caía un 5,1 % en las últimas 24 horas, aunque el motivo del contacto fue el proceso de actualización, no la evolución del mercado.
La empresa de seguridad ChainSecurity ya había rastreado el peligro. Un análisis técnico que publicó el 13 de octubre identificó varios proyectos que podrían volverse vulnerables con las especificaciones modificadas, porque dan por hecho que ciertos invariantes se mantienen: condiciones que un contrato necesita seguir cumpliendo para funcionar según lo previsto. El modo concreto de fallo involucra las llamadas externas, el mecanismo del que dependen los sistemas componibles para interactuar. Hoy, cuando una llamada a un contrato externo falla por falta de gas, la operación posterior no puede completarse y la transacción en su conjunto se revierte. Con las especificaciones propuestas, la operación posterior podría completarse mientras la fallida sigue sin poder reintentarse, dejando el contrato en un estado que su autor nunca previó. El nuevo repositorio de la Fundación registra los ocho invariantes que Glamsterdam rompería, y acompaña cada uno de una explicación, un ejemplo práctico y sugerencias que los desarrolladores pueden aplicar al revisar sus propios proyectos. El retraso de Glamsterdam en la red de pruebas Hoodi no es algo nuevo: el 22 de octubre, la Fundación aplazó una activación que inicialmente estaba prevista para el 26 de octubre, alegando que necesitaba estudiar más a fondo cómo interactúa EIP-8037 con los contratos de la red principal. No hay una nueva fecha y la actualización seguirá en suspenso hasta que se resuelvan las preguntas pendientes. La revisión del impacto cuenta con el apoyo de ChainSecurity y de la firma de auditoría Dedaub, que analizan cómo afectan las reglas modificadas a las implementaciones existentes, junto con la auditoría interna de la Fundación. No obstante, la Fundación admite que no puede examinar todos los proyectos, y mucho menos el código fuera de la cadena que se combina con los contratos en cadena. La decisión corresponde a la llamada de desarrolladores AllCoreDevs, que primero necesita un inventario de lo que dejaría de funcionar tras la activación y de las opciones de especificación que podrían evitarlo. Hasta que esa llamada emita un veredicto, recalcó la Fundación, nada de la especificación está decidido. El trabajo en Hegota, la actualización que seguirá a Glamsterdam, continúa en paralelo y no se ve afectado.
El punto de control de AllCoreDevs
La división del gas que constituye el núcleo de EIP-8037 es un cambio contable en la propia máquina virtual, lo que explica por qué la Fundación lo considera un riesgo a nivel de protocolo y no un ajuste rutinario de parámetros. Para quienes despliegan contratos, el repositorio de los ocho invariantes convierte una disputa abstracta en una lista de comprobación: un equipo puede poner a prueba sus suposiciones frente a ocho condiciones específicas, en vez de esperar una decisión. El factor limitante es la cobertura, y la propia Fundación lo reconoce, ya que es imposible revisar exhaustivamente el código en cadena y fuera de ella. El próximo hito es la reunión de AllCoreDevs, donde la decisión requiere tener sobre la mesa tanto el inventario de fallos como las alternativas de especificación.