Los desarrolladores de Ethereum han presentado una propuesta que daría al código on-chain la capacidad de verificar lo que una transacción cambió realmente — y de revertir la transacción completa si el resultado infringe reglas que el usuario definió de antemano. El concepto, conocido como aserciones nativas de transacciones, fue destacado por la Ethereum Foundation en una publicación de blog publicada el 5 de octubre de 2026.

La propuesta ataca uno de los puntos débiles más antiguos y persistentes de la seguridad en las criptomonedas: la firma a ciegas.

El problema de la firma a ciegas

La firma a ciegas es el equivalente cripto a aceptar los términos y condiciones sin leerlos. Una wallet presenta una solicitud, los detalles son ilegibles o poco claros, y el usuario aprueba de todos modos. La mayoría de las veces no pasa nada, pero cuando algo sale mal, las consecuencias suelen ser costosas. Esta debilidad tiene raíz en cómo se construyen las transacciones de Ethereum: el payload firmado son datos con formato de máquina y no lenguaje natural, por lo que lo que aparece en la pantalla de la wallet es la interpretación que hace una interfaz de esos datos.

La Ethereum Foundation presentó este nuevo trabajo como una respuesta directa a esos riesgos, señalados en el marco de su iniciativa Trillion Dollar Security. Ese programa ya incluye medidas como Clear Signing, centrada en hacer legibles las solicitudes de transacción antes de que el usuario las apruebe.

Las aserciones nativas de transacciones operan en una etapa distinta del proceso. Clear Signing busca ayudar al usuario a entender una transacción antes de que se ejecute. Las aserciones verifican si el resultado coincidió con lo esperado después de ejecutarse.

Dentro de EIP-7906

El núcleo técnico de la propuesta es EIP-7906, que introduce tres nuevos opcodes en la Ethereum Virtual Machine: TXTRACE, TXDIFF y EVENTDATACOPY. Los opcodes son las instrucciones de bajo nivel que la EVM entiende, por lo que añadir nuevos amplía lo que el código de los contratos inteligentes puede ver y hacer.

En este caso, las nuevas instrucciones dan al código on-chain una forma de inspeccionar los cambios de estado reales que produjo una transacción. Esto desplaza la verificación de lo que una transacción dice que hará a lo que demostrablemente hizo.

Cómo se integra con EIP-8141

EIP-7906 no funciona sola. Se apoya en el marco establecido por EIP-8141, conocido como el formato de transacciones por frames. Los formatos de transacción son infraestructura fundamental: cada nodo, wallet y herramienta de desarrollo debe poder procesarlos, por lo que en esta capa el alcance abarca todo el stack.

Las transacciones por frames dividen una sola transacción en segmentos distintos, o frames. EIP-7906 añade un nuevo elemento a esa estructura: un frame POST_TX.

El frame POST_TX opera como una static call durante la ejecución. Una static call es una operación de solo lectura, es decir, puede examinar el estado pero no modificarlo. Si no se cumplen las condiciones definidas en ese frame, los efectos de la transacción pueden revertirse.

Estado y cronograma

Nada de lo descrito está activo todavía. EIP-7906 sigue en estado de borrador. Según el proceso de desarrollo de Ethereum, un borrador debe superar la revisión y obtener la aceptación de los desarrolladores que coordinan una actualización antes de que sus cambios lleguen a la red. El objetivo es incluirlo en la actualización Hegotá, prevista para su despliegue en 2027.

Ya se han realizado demostraciones preliminares en una red de desarrollo, lo que sugiere que la mecánica funciona fuera del papel. EIP-7906 también depende de EIP-8141, por lo que su destino está ligado a que el formato de transacciones por frames también sea aprobado.

Por qué importa más allá del código

Las aserciones nativas trasladarían parte de la carga del riesgo de firma a la capa base. Si el protocolo puede imponer verificaciones del resultado de forma directa, los usuarios dependen menos de que una wallet determinada tenga una lógica de visualización perfecta.

Para instituciones y empresas, el atractivo es evidente. Las organizaciones que mueven grandes sumas suelen querer garantías, no mejores esfuerzos. Un mecanismo capaz de revertir automáticamente una transacción cuyos resultados queden fuera de parámetros definidos encaja perfectamente con el tipo de controles de riesgo que esos actores ya utilizan en otros ámbitos.

Quedan preguntas abiertas. Los desarrolladores también deberán resolver cómo los usuarios comunes definen las reglas que sus transacciones deben cumplir, ya que una red de seguridad que requiera configuración experta podría terminar protegiendo principalmente a los expertos. La capa de usabilidad construida sobre EIP-7906 podría importar tanto como los propios opcodes.

También hay un costo que ponderar. Cada nuevo opcode amplía la superficie que debe implementarse y auditarse en múltiples clientes de Ethereum. Las mejoras de seguridad que introducen nuevos casos límite deben justificar ese costo.

Entre los hitos a observar están si EIP-7906 sale del estado de borrador, si EIP-8141 consigue un lugar en Hegotá y si las demostraciones tempranas son seguidas de más pruebas en devnet.