Ethereum frena la bifurcación Hoodi de Glamsterdam: ¿qué encontraron los auditores?

Los desarrolladores de Ethereum han puesto en pausa la bifurcación de la testnet Hoodi de Glamsterdam mientras analizan los hallazgos sobre cómo se comportan las aplicaciones cuando una transacción se queda con poco gas. La actualización cambia la forma en que la red cobra por algunas operaciones que tocan o amplían su estado, y los auditores descubrieron que incluso los contratos escritos antes de la actualización pueden comportarse de manera diferente bajo las reglas propuestas.

Los desarrolladores de Ethereum debían bifurcar Hoodi el 26 de octubre. Pos pusieron esa prueba, y el 6 de noviembre el desarrollador de la Ethereum Foundation Marius van der Wijden dijo que seguía en pausa mientras los desarrolladores resolvían los problemas identificados en la revisión de gas.

La preocupación se centra en un detalle que la mayoría de las personas encuentra solo cuando una transacción falla. Los contratos pueden llamar a otros contratos y decidir qué hacer si esas llamadas no tienen éxito. El código que toma esa decisión puede verse exactamente igual después de una actualización, pero tomar una ruta diferente porque la red ahora cobra de manera distinta por partes de la operación.

Es por eso que una actualización dirigida a la forma en que Ethereum contabiliza el estado se ha convertido en una cuestión tanto para los desarrolladores de aplicaciones como para los equipos que escriben los clientes de Ethereum. Ambos necesitan saber qué suposiciones antiguas sobreviven al cambio.

Qué cambia Glamsterdam sobre el gas

EIP-8037 cambia cómo el protocolo contabiliza las operaciones que crean estado. El estado de Ethereum incluye registros como el almacenamiento de contratos. Un cambio puede persistir entre transacciones, por lo que su costo tiene implicaciones para los nodos que mantienen la cadena después de que finaliza la transacción original. La propuesta separa la contabilidad de cierta creación de estado del gas de ejecución ordinario, con un depósito del que se puede disponer para operaciones elegibles.

EIP-8038 vuelve a fijar el precio de las operaciones que acceden al estado. Las dos propuestas afectan diferentes partes de una ruta de ejecución. Un contrato podría leer un valor, hacer una llamada externa y escribir un resultado. Revisar solo el precio propuesto de la escritura final pasa por alto el efecto de las lecturas y llamadas anteriores sobre el presupuesto disponible cuando la ejecución llega a ella.

Una aplicación conocida puede, por lo tanto, producir un resultado diferente incluso cuando un usuario proporciona las mismas entradas de transacción. La pregunta importante es qué diferencias reflejan el cambio de precios previsto y cuáles exponen una suposición de la que depende un cliente o un contrato.

Cómo una llamada fallida puede cambiar el resultado final

Consideremos un contrato que llama a un segundo contrato para realizar un paso en una operación mayor. Si el segundo contrato falla, el llamador puede detener todo o manejar el fallo y continuar. Un procesador por lotes podría registrar un elemento fallido y continuar. Otra aplicación podría esperar que toda la operación se revierta si la llamada fallida agota suficiente gas.

El análisis de ChainSecurity describe cómo la nueva contabilidad puede afectar esa distinción. Ethereum ya limita cuánto gas puede pasar hacia adelante un llamador bajo la regla EIP-150. Aproximadamente un sesenta y cuatroavo puede permanecer con el llamador en el caso relevante. El problema es cuánto tiene realmente disponible el llamador una vez que la ejecución regresa, y cuánto cuesta terminar las instrucciones en esa ruta.

Supongamos que una aplicación trata un fallo de llamada como un resultado comercial ordinario. Si tiene suficiente gas para terminar el manejador de fallos, podría registrar un resultado o continuar el resto de la transacción. Si se queda sin gas mientras lo hace, la transacción externa se revierte. Esos resultados dejan registros diferentes aunque la llamada interna haya fallado en ambos casos.

El auditor también examinó las comprobaciones basadas en gasleft(). Un contrato puede usar la instrucción para comparar su presupuesto de ejecución restante con un mínimo codificado de forma fija. Un umbral calibrado bajo un esquema puede convertirse en un mal predictor bajo otro, particularmente cuando el contrato encuentra operaciones de estado o reenvía gas a otra dirección. El contrato no tiene forma automática de revisar un número que su desarrollador incorporó cuando fue desplegado.

Qué necesitan establecer los auditores

La actualización de noviembre de la Fundación describe ocho supuestos bajo revisión. Hay al menos dos preguntas distintas para probar. Los clientes que implementan las nuevas reglas deben llegar al mismo resultado para una transacción dada. Los revisores de aplicaciones también deben identificar casos en los que ese resultado compartido difiere de lo que esperan los contratos existentes.

Una prueba para la primera pregunta puede ejecutar la misma transacción contra varios clientes y comparar los resultados de estado y gas. Una prueba para la segunda necesita seguir la lógica propia de la aplicación. Importa si el contrato trata una devolución de llamada fallida como una señal para continuar, si registra un cambio de estado antes de la llamada y si puede distinguir un rechazo comercial de una llamada que nunca tuvo suficiente gas.

Esas rutas pueden ser fáciles de pasar por alto en una prueba de despliegue convencional. Un presupuesto de transacción típico puede llevar la llamada y su manejador a través de ambos esquemas. Un presupuesto deliberadamente ajustado puede exponer la diferencia. Por lo tanto, las pruebas de límites tienen que incluir llamadas fallidas y casos cercanos a la cantidad de gas requerida para entrar o terminar el manejador de fallos.

Qué puede mostrar Hoodi

Glamsterdam ya había llegado a la red de prueba Sepolia de Ethereum, donde los desarrolladores probaron un límite de 200 millones de gas. Hoodi daría a los desarrolladores un despliegue compartido adicional en el que ejercitar la actualización revisada.

Una bifurcación de red de prueba pública da a los equipos de clientes y a los operadores de aplicaciones un entorno común en el que ejecutar estas comprobaciones. Los operadores pueden actualizar los clientes en un calendario compartido, comparar sus resultados y probar las herramientas contra las reglas de la bifurcación. Los equipos de aplicaciones pueden comprobar si la simulación de transacciones y la estimación de gas tienen en cuenta los mismos cambios que están viendo durante la ejecución.

Una bifurcación exitosa de Hoodi daría a los desarrolladores evidencia sobre las versiones y transacciones que probaron. La pregunta a más largo plazo es qué hacen las aplicaciones representativas en los límites de sus presupuestos de gas. Una nueva fecha de bifurcación será más fácil de evaluar junto con un registro de qué casos se reprodujeron, qué cambió en respuesta y cómo lo probaron los equipos.

El trabajo sobre el gas avanza junto con otras correcciones. Los desarrolladores de Ethereum revisaron por separado la especificación de depósito del validador mientras la revisión de gas de Hoodi estaba en curso. Esas correcciones necesitan sus propias pruebas porque afectan una parte diferente de la bifurcación.

Por ahora, la última actualización de los desarrolladores sobre los riesgos de gas da una razón para la pausa y dice que el trabajo en Hegota continúa. Deja el momento de la próxima prueba de Glamsterdam a una decisión posterior.

Cómo encajan los límites de gas y los costos de estado

Un límite de gas por bloque más alto le da a Ethereum espacio para más trabajo bajo su sistema de contabilidad. El precio asignado a una operación individual determina cuánto de ese espacio ocupa la operación. Por lo tanto, un cambio en el límite y un cambio en los precios pueden afectar diferentes partes de la misma transacción.

Parte del trabajo termina cuando lo hace la transacción. Crear estado es diferente porque los datos pueden persistir, dejando a los operadores de nodos algo que almacenar y procesar después. Una nueva ranura de almacenamiento, cuenta o contrato puede sumar a esa carga incluso si la aplicación que lo creó recibe poco tráfico posteriormente.

La EIP-8037 cambia cómo se contabiliza el costo de cierta creación de estado. La EIP-8038 vuelve a fijar el precio del acceso al estado, lo que puede incluir operaciones que involucran registros que ya existen. Una transacción que lee un valor, llama a otro contrato y crea una entrada de almacenamiento puede encontrarse con ambos cambios durante una sola ejecución.

Un límite de bloque más alto por sí solo no dice si esa secuencia costará más o menos. Describe el espacio disponible para el bloque en su conjunto. La ruta de la transacción y el precio de cada operación determinan si puede caber dentro del gas que proporcionó el remitente.

Esa distinción ya era relevante cuando Sepolia comenzó a probar Glamsterdam con un límite de 200 millones de gas. La prueba mostró lo que los desarrolladores estaban ejecutando en esa red. La suspensión en Hoodi aborda si las reglas están listas para la siguiente testnet, incluido el comportamiento de las aplicaciones que dependen de supuestos de gas anteriores.

Los ocho supuestos bajo revisión

El repositorio del auditor de la Ethereum Foundation agrupa sus ejemplos por cambios en los precios de las operaciones y cambios en la forma en que se rastrea el gas. Los números del repositorio provienen de una versión fijada de la especificación propuesta y pueden cambiar si las propuestas se revisan.

El primer grupo de preocupaciones involucra asignaciones fijas y el costo de completar el trabajo después de una llamada. Los desarrolladores pueden haber establecido un límite de gas para una operación que ahora cuesta más. Una reserva destinada a pagar una escritura final puede que ya no sea suficiente. En otro caso, la pequeña fracción retenida por un llamador puede ser suficiente para completar una ruta de fallo que la aplicación esperaba anteriormente que se revirtiera.

Los cambios de contabilidad introducen otras posibilidades. Si un depósito separado aún puede financiar la creación de estado elegible, un llamador puede escribir un registro después de una llamada fallida incluso cuando su presupuesto de ejecución ordinario es ajustado. El resultado final del llamador puede entonces depender de qué operaciones usan ese presupuesto separado.

Borrar una ranura creada anteriormente en la misma transacción puede devolver algo de gas de estado inmediatamente en la especificación revisada. Una llamada que se revierte también puede devolver gas de estado. Por lo tanto, el código escrito bajo el supuesto de que todo el gas consumido antes de una reversión se ha perdido puede malinterpretar lo que sucedió.

Un par de mediciones de gasleft() puede igualmente dar una visión incompleta del costo del trabajo. Un contrato que usa la diferencia para facturar a alguien o calcular un reembolso depende de supuestos sobre cómo cambia el gas entre las dos lecturas. Los cargos extraídos de un fondo separado y el gas de estado devuelto durante la ejecución pueden cambiar la relación.

El octavo caso involucra la EIP-7702, que permite a una cuenta autorizar la delegación a código de contrato. Una transacción puede incluirse incluso cuando una autorización dentro de ella no surtió efecto porque se quedó sin gas. Una billetera o servicio que usa la inclusión de la transacción por sí sola para inferir que la delegación funcionó podría tratar una acción incompleta como terminada.

El repositorio dice que muchos hallazgos recibidos por sus autores concernían a cantidades fijas o reservas. Pide a los desarrolladores y auditores que prueben sus aplicaciones contra los ejemplos e informen problemas. El inventario identifica patrones que requieren revisión. No implica que toda aplicación que use uno de esos patrones vaya a producir una pérdida.

Cómo una llamada fallida puede aun así dejar una transacción exitosa

Una transacción de Ethereum puede contener varias llamadas. Un contrato puede solicitar que otro contrato realice un paso y luego decidir cómo responder al resultado. Una llamada interna fallida y una transacción fallida son resultados distintos.

Un procesador por lotes proporciona un ejemplo útil. Si un elemento falla, el procesador podría registrar ese fallo y pasar al siguiente elemento. Si se queda sin gas antes de poder registrar el resultado, la transacción externa puede revertirse y deshacer los cambios anteriores. El mismo fallo interno, por lo tanto, deja un estado final diferente dependiendo de lo que el llamador pueda hacer después.

Una aplicación diferente podría tratar una llamada fallida como una razón para cambiar quién puede enviar una solicitud o si se permite intentarlo de nuevo. Si el llamador puede completar una ruta que la aplicación esperaba revertir, el estado resultante puede persistir. La consecuencia de seguridad depende de lo que la ruta completada registre realmente.

Un actor podría ser capaz de elegir cuánto gas suministra una transacción. Si esa persona puede dejar suficiente gas para que el contrato externo entre en una ruta pero demasiado poco para que la llamada interna termine, el fallo puede ser inducido por el presupuesto de la transacción. Un contrato que actúa sobre el fallo necesita distinguir ese caso de una llamada que llegó al destinatario y falló legítimamente.

El límite de reenvío de EIP-150 es una parte de esto. Un llamador que reenvía tanto gas como se permite retiene aproximadamente un sesenta y cuatroavo bajo la regla relevante. La cantidad retenida todavía tiene que pagar las instrucciones que siguen. Si esas instrucciones se completan depende del calendario y de la contabilidad que se les aplique.

Un contrato puede ser vulnerable a un rango estrecho de presupuestos. Dé a la llamada interna suficiente gas y funciona normalmente. Dé a toda la transacción demasiado poco y la ruta externa se revierte. El intervalo problemático es donde la llamada interna falla mientras el llamador todavía tiene suficiente para llevar a cabo una acción que el desarrollador no pretendía para ese fallo.

Por qué cambiar un número de gas fijo puede no resolver el problema

Un umbral codificado de forma rígida puede dar a un contrato una forma sencilla de comprobar que tiene suficiente gas antes de hacer una llamada. El desarrollador podría haber probado el umbral con transacciones comunes y dejado un margen para el trabajo que sigue. El número se convierte en una dependencia del calendario bajo el cual fue elegido.

Una operación también puede costar cantidades diferentes dependiendo de si la aplicación está actualizando un registro existente o creando uno. Una transferencia a alguien que ya tiene un saldo puede encontrar una ruta de almacenamiento diferente de una transferencia que crea un primer saldo. Una prueba que solo cubre destinatarios recurrentes puede pasar por alto la ruta más costosa.

El punto en el que el contrato mide el gas importa. Una lectura inmediatamente antes de la llamada es diferente de una lectura después de varios accesos de estado y de la propia llamada. Un contrato que infiere la razón del fallo a partir de la última lectura asume que entiende qué podría haberse cobrado o devuelto en el intervalo.

Cambiar un estipendio puede tener consecuencias propias. Puede permitir que una ruta que antes fallaba se complete, y también puede dar al destinatario suficiente gas para realizar un trabajo que no podía realizar bajo la asignación anterior. El desarrollador necesita saber qué se pretendía evitar con la asignación antes de ajustarla.

Algunos contratos pueden cambiarse mediante un proceso de gobernanza o administrativo. Otros son inmutables o dependen de componentes que no pueden cambiarse en su lugar. Incluso cuando un contrato puede revisarse, los servicios que estiman, patrocinan o retransmiten sus transacciones también pueden necesitar actualizar sus propias suposiciones.

Qué necesita mostrar una reproducción convincente

Una prueba puede comenzar con la misma transacción, estado y límite de gas bajo las reglas antiguas y propuestas. Una comparación debería identificar qué llamada devuelve un fallo, qué hace el llamador a continuación y si la transacción registra algún cambio que no persistía antes.

Probar presupuestos justo por encima y por debajo del umbral ayuda a mostrar si el efecto ocupa un rango estrecho. También puede identificar dónde diverge la ejecución. Una comprobación de saldo temprana, la cantidad reenviada al destinatario y una escritura en el manejador de fallos son puntos diferentes en los que puede aflorar un cambio.

El revisor entonces tiene que preguntar quién puede alcanzar esa ruta. Un cambio reproducido en un contrato de prueba establece una diferencia en la ejecución. Una aplicación real puede requerir una autorización, comprobar una condición separada o hacer que la operación afectada sea reintentable. Esos detalles determinan si alguien puede forzar un resultado no deseado.

También existe una prueba separada para los equipos de clientes. Todos los clientes de ejecución deberían alcanzar el mismo resultado para una transacción bajo la misma configuración de bifurcación. Un desacuerdo entre clientes es un problema distinto de que todos los clientes produzcan de forma consistente un resultado que una aplicación no anticipó.

Una suite de pruebas necesita rutas exitosas así como fallos. Forzar que cada llamada fallida revierta podría evitar un cambio de estado no deseado, pero también eliminar una capacidad legítima de completar el resto de un lote. El comportamiento previsto de la aplicación determina qué debe preservar una corrección.

Una buena reproducción debería hacer que el estado final sea fácil de inspeccionar. Si un registro de fallo permanece después de una ejecución y desaparece después de otra, la prueba puede mostrar la diferencia exacta en lugar de depender de un informe general sobre el uso de gas. Eso facilita evaluar tanto el riesgo como un cambio propuesto.

Qué aportan las redes de prueba públicas después de una reproducción local

Un desarrollador puede probar un caso límite en una bifurcación local o en un entorno de cliente controlado. Una red de prueba pública permite entonces que varios operadores ejecuten la misma actualización y comparen su comportamiento en condiciones compartidas. También da a los equipos de billeteras e infraestructura un lugar donde probar su propio software contra las reglas activas.

Sepolia y Hoodi cumplen pasos diferentes en ese proceso. La activación de Sepolia mostró que los desarrolladores podían ejecutar el código planificado en esa red y examinar su funcionamiento bajo el límite de gas configurado. Hoodi les ofrece un despliegue adicional después de abordar los hallazgos que cobraron importancia durante la revisión.

Las aplicaciones, el tráfico y el estado histórico en una red de prueba difieren de la red principal. Una bifurcación sin problemas puede aportar evidencia sobre el acuerdo entre clientes y las transacciones rutinarias sin ejercitar todos los patrones de contratos de los que dependen los usuarios. Una reproducción dirigida aporta evidencia sobre un caso límite que puede estar ausente del tráfico ordinario de la red de prueba.

Las instrucciones de actualización son otra parte de la prueba. Un operador necesita una versión que implemente la configuración prevista y un punto de activación preciso. Una aplicación necesita saber cuándo sus simulaciones deberían empezar a usar las reglas revisadas. Una nueva fecha es útil junto con esos detalles.

El aplazamiento de octubre y el informe de estado de noviembre describen la misma pausa en momentos diferentes. El primero eliminó la fecha programada de Hoodi. El segundo explicó que los problemas aún debían resolverse. El siguiente aviso de despliegue puede mostrar qué cambios están listos para que los operadores los prueben.

Cómo las billeteras pueden informar éxito mientras una acción falla

Las billeteras comúnmente estiman el gas antes de pedirle a un usuario que firme. La estimación depende del estado y las reglas que el nodo aplica en su simulación. Un servicio que usa una configuración de bifurcación más antigua puede dar una estimación que ya no es adecuada para una transacción que la cadena actual ejecuta.

Una transacción que revierte aún puede costarle gas al remitente. Una transacción externa que se completa después de capturar un fallo interno puede ser más difícil de interpretar. La cadena puede registrar la transacción general como exitosa mientras una acción dentro de ella no ocurrió. La billetera puede necesitar los eventos o el estado de la aplicación para explicarle la diferencia al usuario.

Los relayers y patrocinadores de transacciones enfrentan un problema relacionado. Pueden elegir el presupuesto o pagar los costos de una transacción que otra persona solicita. Si el presupuesto ya no cubre la ruta prevista, el patrocinador puede pagar por una ejecución que no logra entregar la acción solicitada.

Los indexadores pueden ver el efecto después de la ejecución. Una ruta de fallo que ahora se completa puede producir registros o cambios de estado que el sistema posterior no veía antes. El indexador sigue el estado real de la cadena. Una aplicación que depende del indexador puede necesitar cambiar cómo interpreta el registro resultante.

Una prueba de extremo a extremo puede comparar la estimación de una billetera, el presupuesto enviado por un relayer, el resultado de ejecución del cliente y la explicación de la interfaz. Cada paso puede tener éxito por sí solo mientras el usuario aún recibe un relato engañoso de qué acciones surtieron efecto. La distinción importa más donde la aplicación trata un resultado como definitivo.

Qué resolvería la pausa de Hoodi

La Fundación está pidiendo a los equipos de aplicaciones que identifiquen los supuestos que utilizan y proporcionen casos que los desarrolladores puedan reproducir. Algunos problemas pueden abordarse mediante cambios en las reglas de gas propuestas. Otros pueden requerir que un proveedor de aplicaciones o infraestructura revise cómo maneja el nuevo comportamiento.

Si las especificaciones cambian, la prueba relevante es si un caso que antes divergía ahora alcanza el resultado previsto. Si los desarrolladores mantienen un cambio de comportamiento, los equipos de aplicaciones necesitan suficiente detalle para determinar si su software depende del resultado anterior. Ambos resultados dependen de describir la llamada afectada y qué persiste después de ella.

Una especificación revisada también tiene que llegar a las compilaciones de clientes que ejecutan los operadores. Una compilación que admitía una configuración anterior de Glamsterdam puede no contener los cambios posteriores. Los números de versión en un nuevo aviso de Hoodi identificarían qué versiones se pueden probar juntas.

La actualización de noviembre de la Fundación dice que el trabajo en Hegota continúa en paralelo. Eso significa que la suspensión del fork anterior no abarca todas las decisiones de desarrollo sobre el siguiente. Para Glamsterdam, el siguiente hito relevante es un calendario revisado de Hoodi con una configuración que los desarrolladores estén listos para ejecutar públicamente.

Un fork exitoso daría a los equipos un registro compartido que examinar antes de una decisión sobre la mainnet. Los casos que motivaron el retraso siguen siendo las pruebas más claras de si las reglas revisadas están listas. Esas pruebas tienen que mostrar qué sucede cuando una llamada falla cerca de su límite de gas y la transacción externa todavía tiene trabajo pendiente.

Qué muestran los números de gas propuestos sobre los diferentes caminos

El repositorio de la Fundación ofrece un ejemplo concreto de la diferencia entre crear estado y actualizarlo. Según su especificación fijada de Glamsterdam, una escritura en frío que crea una nueva ranura se divide entre costos de ejecución y un cargo de estado sustancialmente mayor. Una escritura en una ranura existente también se vuelve a fijar de precio, pero sigue un cálculo diferente.

La diferencia puede alcanzar a dos usuarios que hacen lo que parece ser la misma solicitud de aplicación. Un usuario puede haber usado el servicio antes, por lo que el contrato actualiza una entrada existente. Otro puede necesitar un registro nuevo. Una asignación de gas que funciona para el primer usuario puede fallar para el segundo.

El repositorio también dice que un depósito separado está disponible solo por encima de un límite de gas de transacción especificado en la configuración que probó. En transacciones más pequeñas, los costos de estado provienen en cambio del presupuesto ordinario. Ese umbral hace importante probar varios presupuestos en lugar de suponer que el depósito se comporta de la misma manera para cada llamada.

El código que lee el gas restante puede, por lo tanto, observar solo parte de los recursos de la transacción en algunos casos. Los datos que lee siguen siendo significativos para el presupuesto que expone la instrucción. Lo que cambia es la inferencia que la aplicación puede extraer sobre los recursos totales que se han consumido o que siguen disponibles.

Los ejemplos de gas están vinculados a la configuración propuesta. No ofrecen un multiplicador único que pueda aplicarse a las estimaciones existentes de una billetera. Una escritura de almacenamiento por primera vez, una llamada que usa un estipendio fijo y una delegación fallida requieren cada una una verificación separada porque encuentran partes diferentes de las reglas.

Esa es también la razón por la que una fecha revisada de Hoodi sería más útil con la revisión de la especificación y la lista de casos cubiertos por la versión. Esos detalles permitirían a los equipos volver a ejecutar pruebas que coincidan con sus aplicaciones antes de sacar conclusiones de la estabilidad general de la testnet.

Qué observar

• Calendario de Hoodi: Una fecha de bifurcación revisada debería identificar las versiones de cliente y la configuración de bifurcación que se espera que ejecuten los operadores.
• Acuerdo entre clientes: Las pruebas entre clientes pueden mostrar si los clientes de ejecución alcanzan el mismo estado y resultados de gas en torno a los nuevos límites.
• Comportamiento del contrato: Las reproducciones deberían mostrar cuándo una llamada externa fallida deja al llamador suficiente gas para terminar y qué registra la transacción externa.
• Revisiones de la propuesta: Los cambios a EIP-8037 o EIP-8038 ayudarán a mostrar qué hallazgos de la revisión requirieron un cambio de protocolo.
• Herramientas de aplicación: Los resultados de simulación y estimación de gas pueden mostrar si las billeteras y los proveedores de infraestructura reflejan correctamente las reglas de la bifurcación.

Preguntas frecuentes