Después de firmar: la comprobación final que propone Ethereum

La instrucción y el resultado recibido

Imagina que aceptas entregar un activo a cambio de una cantidad mínima de otro. La pantalla describe una acción; lo que te importa es el saldo que queda después. Son promesas relacionadas, pero no idénticas. Una firma autoriza los datos de una transacción. Por sí sola, no convierte cada expectativa en una condición exigible. Es un ejemplo hipotético, no el relato de una operación fallida.^[1][2]

La explicación publicada por Ethereum Foundation el 5 de octubre aborda esa distancia. Una pantalla de firma comprensible explica la acción solicitada; una simulación estima lo que ocurriría en un estado concreto de la cadena. El estado o el comportamiento del contrato pueden cambiar antes de la ejecución real. EIP-7906 plantea otra pregunta: ¿puede la transacción llevar una comprobación final de su propio resultado y rechazar sus efectos si no la supera?^[2]

Una idea conocida, con una visión más amplia

Las aplicaciones ya contienen condiciones sobre el resultado. La interfaz de intercambio de Uniswap v3 tiene amountOutMinimum, un límite inferior para lo que debe devolver el intercambio. Su guía advierte que fijarlo en cero, como hace un ejemplo didáctico simplificado, es arriesgado en producción. Un mecanismo de comprobación solo resulta útil si la condición elegida establece un límite significativo.^[7]

La extensión propuesta ofrecería a los contratos de comprobación una visión más general de lo que cambió durante una transacción. En lugar de depender únicamente de las verificaciones integradas en cada aplicación, una cartera podría añadir una aserción independiente. EIP-7906 depende de otro borrador, EIP-8141, que divide las transacciones en marcos o frames con funciones distintas: validación, aprobación del pago y ejecución, entre otras. Las aserciones añadirían un modo final.^[1][3]

Comprobar después del trabajo, dentro de la transacción

En el texto actual, los frames ASSERT se agrupan al final. Son de solo lectura: el comprobador puede observar el resultado, pero no modificar el estado y aprobar después su propia modificación. TXTRACE permite enumerar los cambios; TXDIFF consulta una cuenta o entrada de almacenamiento concreta; EVENTDATACOPY da acceso a los datos de los eventos emitidos. Son instrucciones propuestas para la EVM, no botones disponibles ya en las carteras habituales.^[1]

La diferencia de estado se parece a una comparación entre el antes y el después, no a un vídeo de todas las instrucciones. Varias escrituras en una misma posición de almacenamiento se condensan en su cambio neto; si recupera el valor inicial, no figura como cambio neto en esa lista. Los saldos del ETH nativo, el almacenamiento y el código desplegado son informaciones diferentes. Interpretar el significado económico de un token sigue requiriendo lógica adecuada: leer almacenamiento no produce automáticamente un inventario comprensible de todos los tokens y permisos.^[1]

En el intercambio hipotético, una aserción apropiada podría comprobar que el destinatario previsto recibió al menos la cantidad acordada. Pero verificar solo ese resultado no prohibiría cambios ajenos en otros lugares. Una política útil también debe precisar qué activos, destinatarios y permisos importan. El protocolo puede ejecutar la prueba; no puede deducir toda la intención del usuario de una autorización amplia para realizar una transacción.^[1]

Deshacer tiene un límite y un coste

Si falla un frame ASSERT, el diseño actual revierte el cuerpo de ejecución hasta el punto inmediatamente posterior al frame que aprobó el pago del gas. La transacción sigue siendo válida para incluirla en un bloque, y quien paga debe abonar el gas ya consumido. Sería incorrecto prometer que una aserción fallida borra toda la transacción o convierte un intento fallido en gratuito.^[1][5]

El prefijo de validación anterior permanece confirmado. Puede incluir el despliegue de una cuenta además de la aprobación del pago. La cartera debe colocar después de ese límite las acciones de la aplicación no confiable que pretende proteger; una acción situada dentro del prefijo queda fuera de esa reversión. La revisión del 15 de octubre hizo explícita esta separación. La imagen adecuada es una ejecución rechazada cuyo coste y preparación confiable permanecen registrados, no un botón universal de deshacer.^[1][3][5]

¿Quién escribe la regla de aceptación?

Una interfaz maliciosa o equivocada podría proporcionar una condición tan permisiva que aceptase un resultado indeseado. Por eso la especificación considera parte del diseño el origen de la regla, sus entradas y el código comprobador. Una prueba basada en un valor que la misma transacción puede alterar podría aprobar precisamente el comportamiento que debía limitar. La condición debe expresar la intención con suficiente independencia para tener sentido.^[1]

La propuesta tampoco obliga a cada transacción a llevar una aserción determinada. La validación de la cartera debe exigir el frame, el destino y los datos correctos, en lugar de suponer que habrá una comprobación útil. Siguen siendo necesarios comprobadores fiables, un presupuesto de gas adecuado y una lógica de validación confiable. El mecanismo aborda los efectos en cadena de la transacción actual; no garantiza protección frente a movimientos posteriores del mercado ni el cumplimiento en otra cadena.^[1]

Una especificación en desarrollo, no una garantía disponible

El artículo del 5 de octubre llamaba POST_TX a este modo. Tras aclarar el límite de reversión el día 15, un cambio incorporado el 16 lo renombró ASSERT. Al comprobarlo el 17, tanto EIP-7906 como su dependencia EIP-8141 conservaban el estado Draft. Forkcast registra EIP-7906 como Considered for Inclusion en Hegota. Esa etapa de planificación no anuncia una activación; la madurez de una especificación y su programación para una actualización son criterios distintos.^{[1][2][3][4][5][6]}

La importancia de la propuesta está en ampliar dónde puede expresar la cartera el acuerdo del usuario: no solo en la instrucción que firma, sino también en una prueba del resultado que produjo la ejecución. Que eso se convierta en protección útil dependerá de su adopción y de la regla exacta que exija la cartera. Por ahora es un mecanismo en desarrollo para limitar resultados, con una frontera de reversión definida, no una promesa de recuperar después cualquier transacción firmada.^[1][6]