Ethereum retrasa la actualización Glamsterdam tras detectarse ocho riesgos en los contratos inteligentes

ETH
Actualización Glamsterdamriesgo en contratos inteligentestestnet HoodiChainSecurityprecio del gasEthereumEIP-8037
hace 3 horasFuente: crypto.news
Ethereum retrasa la actualización Glamsterdam tras detectarse ocho riesgos en los contratos inteligentes

Los desarrolladores de Ethereum han retrasado la actualización Glamsterdam en la red de prueba Hoodi después de que investigadores de seguridad identificaran ocho supuestos existentes en contratos inteligentes que podrían volverse inválidos con los cambios propuestos en la contabilidad del gas.

Resumen

  • Los desarrolladores de Ethereum han retrasado la actualización Glamsterdam en la red de prueba Hoodi después de que ChainSecurity identificara ocho supuestos en contratos inteligentes que podrían volverse inválidos con los cambios propuestos en el gas.
  • EIP 8037 y EIP 8038 cambiarían cómo Ethereum cobra gas por ciertas operaciones, lo que podría afectar a contratos existentes que dependen de costos de gas fijos o de condiciones específicas de fallo de transacciones.
  • La Fundación Ethereum ha pedido a desarrolladores y auditores que revisen los proyectos afectados y reporten posibles problemas antes de que los desarrolladores principales decidan si son necesarios cambios en las especificaciones de la actualización.
  • La bifurcación dura de Hoodi permanecerá en espera hasta que se resuelvan las preocupaciones identificadas, mientras que el desarrollo de la siguiente actualización de Ethereum, Hegota, continúa sin interrupción.

En una publicación de blog del 6 de noviembre, la Fundación Ethereum dijo que la firma de auditoría ChainSecurity había identificado varios proyectos que podrían volverse vulnerables una vez que EIP-8037 y EIP-8038 entren en vigor.

Ambas propuestas cambian cómo Ethereum cobra gas por ciertas operaciones, particularmente aquellas que involucran la creación y el acceso al estado de la cadena de bloques. Algunos contratos existentes dependen de costos de gas fijos o de supuestos sobre cuánto gas queda después de que una operación falla.

Los hallazgos han llevado al grupo de Todos los Desarrolladores Principales (ACD) de Ethereum a posponer la bifurcación dura de Hoodi hasta que se aborden las preocupaciones de compatibilidad.

Los desarrolladores ahora están examinando si los contratos afectados pueden actualizarse de forma independiente o si son necesarios cambios en las especificaciones de la actualización.

La actualización Glamsterdam de Ethereum enfrenta ocho preocupaciones de compatibilidad

Las preocupaciones de seguridad se detallaron en un análisis del 13 de octubre de ChainSecurity, que examinó cómo Glamsterdam podría cambiar el comportamiento de los contratos que continúan ejecutándose después de que falla una llamada externa.

Según las reglas existentes de Ethereum, algunos contratos dependen de que una operación fallida deje muy poco gas para que las instrucciones posteriores se completen. La contabilidad revisada de Glamsterdam podría permitir que ciertas operaciones finalicen incluso cuando los desarrolladores originalmente esperaban que toda la transacción se revirtiera.

ChainSecurity advirtió que dicho comportamiento podría interferir con las salvaguardas diseñadas para evitar que las transacciones fallidas se registren permanentemente o que las operaciones legítimas pierdan sus opciones de reintento.

Un ejemplo involucra contratos que marcan una operación como no exitosa después de que una llamada externa se queda sin gas. Según las nuevas reglas, el gas previamente no disponible podría volver a ser accesible, permitiendo que el contrato registre un fallo permanente.

La Fundación Ethereum ha publicado un repositorio de GitHub que documenta ocho invariantes afectados, con explicaciones, ejemplos e instrucciones para que los desarrolladores examinen su propio código.

Entre los riesgos identificados se encuentran contratos que asumen que el consumo de gas solo puede moverse en una dirección, que las asignaciones fijas de gas seguirán siendo suficientes, o que las llamadas revertidas no pueden devolver gas ya gastado en la creación de estado.

El repositorio identifica los presupuestos fijos de gas y las reservas de gas como los problemas más comunes encontrados hasta ahora, particularmente en contratos que dependen de costos de transacción predeterminados.

Se ha pedido a los desarrolladores que revisen tanto los contratos en la cadena como los sistemas de apoyo fuera de la cadena, incluidos monederos, retransmisores e infraestructura que puedan contener límites de gas codificados de forma fija.

La activación de Hoodi permanece en espera mientras continúan las revisiones de seguridad

Los últimos hallazgos proporcionan más detalles detrás de la decisión anterior de Ethereum de posponer la activación de Hoodi, originalmente programada para el 26 de octubre a las 17:42:48 UTC.

Como informó previamente crypto.news, el aplazamiento eliminó tanto las activaciones de la capa de ejecución Amsterdam como de la capa de consenso Gloas del calendario de Hoodi, junto con un aumento planificado en el límite de gas de la red de prueba a 200 millones.

No se ha anunciado ninguna fecha de activación de reemplazo.

El desarrollador de la Ethereum Foundation, Marius van der Wijden, dijo que la organización está trabajando con ChainSecurity y Dedaub mientras realiza auditorías internas para evaluar los posibles efectos en las aplicaciones existentes.

La Fundación reconoció que sus revisiones no pueden cubrir todos los proyectos de Ethereum, particularmente donde las vulnerabilidades pueden involucrar interacciones entre contratos inteligentes e infraestructura fuera de la cadena.

Por lo tanto, ha pedido a los desarrolladores y auditores independientes que identifiquen las aplicaciones afectadas y envíen sus hallazgos antes de las próximas discusiones de All Core Developers.

El repositorio solicita detalles de los contratos afectados, la invariante específica involucrada, posibles correcciones y pruebas de respaldo cuando estén disponibles. Los informes pueden enviarse de forma privada a [email protected].

Dependiendo de los comentarios, los desarrolladores podrían considerar ajustes a EIP-8037 y EIP-8038 antes de continuar con la actualización.

El trabajo en la siguiente actualización de Ethereum, Hegotá, continuará en paralelo y no se verá afectado por el retraso de Glamsterdam, según la Fundación.

Los cambios de escalabilidad de Glamsterdam siguen en pruebas

Glamsterdam ya se había activado en la testnet Sepolia el 6 de octubre, donde los desarrolladores comenzaron a examinar sus cambios de escalabilidad bajo un límite de 200 millones de gas.

La actualización introduce la separación consagrada entre proponente y constructor mediante EIP-7732, que incorpora las responsabilidades de construcción de bloques al protocolo de consenso de Ethereum.

Otro componente importante, EIP-7928, introduce listas de acceso a nivel de bloque diseñadas para ayudar a los clientes a procesar los datos de transacciones de manera más eficiente y respaldar la ejecución paralela.

La repreciación del gas forma otra parte de la actualización. EIP-8037 cambia el costo de crear nuevo estado en la cadena de bloques, mientras que EIP-8038 ajusta los cargos por acceder al estado existente.

En una evaluación técnica de agosto, la Ethereum Foundation dijo que las reproducciones de transacciones históricas mostraron que la mayoría de los contratos inteligentes no se vieron afectados por los cambios de precios propuestos.

Sin embargo, un grupo más pequeño requirió límites de gas más altos o modificaciones más sustanciales para evitar fallos inesperados.

Por separado, los desarrolladores fusionaron una corrección del depósito de validadores el 26 de octubre después de identificar un fallo que podría haber acreditado depósitos de staking a constructores de bloques que compartían la misma clave pública.

La corrección abordó un problema separado relacionado con los cambios de consenso Gloas de Glamsterdam, con pruebas de regresión añadidas a las especificaciones antes de que las implementaciones de los clientes incorporen el comportamiento revisado.