La Fundación Ethereum está explorando afirmaciones sobre transacciones que permitirían a los usuarios adjuntar condiciones exigibles al resultado final de una transacción, en lugar de depender únicamente de la aprobación de la acción solicitada. La investigación, que forma parte de su iniciativa Trillion Dollar Security, aborda una deficiencia en la seguridad de las transacciones: una firma válida no garantiza que los saldos, permisos o controles de la cuenta resultantes coincidan con lo que pretendía quien firmó.
Conclusiones clave
- Las comprobaciones propuestas evaluarían los resultados de las transacciones durante la ejecución y revertirían las acciones que incumplan una regla firmada.
- La protección depende de reglas aprobadas de forma independiente del constructor de transacciones, que podría estar comprometido.
- La investigación podría respaldar políticas de seguridad para monederos, agentes delegados y flujos de trabajo de solucionadores, pero no se ha anunciado su implementación.
Índice
- Por qué aprobar una transacción aún puede provocar una pérdida
- Cómo comprobarían el resultado las afirmaciones sobre transacciones
- Qué expondría la implementación propuesta
- Qué cambios necesitarían los monederos y protocolos
- Qué podrían aportar a los agentes y a los flujos de trabajo de solucionadores
- Conclusión
Por qué aprobar una transacción aún puede provocar una pérdida
Ethereum ejecuta la solicitud que autoriza un usuario contra el código y el estado disponibles en el momento de la ejecución. Esas condiciones pueden diferir de lo que el usuario examinó. Por ejemplo, la implementación de un proxy puede cambiar antes de la ejecución, mientras que el orden de las transacciones puede alterar el precio que encuentra un intercambio.
La fundación distingue entre solicitudes engañosas y resultados no deseados. En los ataques a Bybit y BadgerDAO, las interfaces comprometidas presentaron solicitudes de firma distintas de las que los usuarios creían estar aprobando. En cambio, una solicitud mostrada con exactitud aún puede permitir un resultado económicamente perjudicial.
Su ejemplo es un intercambio de colateral de Aave y CoW que involucró unos 50,4 millones de aEthUSDT. La escasa liquidez de AAVE y el límite de gas de CoW dejaron una cotización verificada de aproximadamente 329 aEthAAVE. A pesar de que se mostró una advertencia de impacto en el precio del 99,9 % y se confirmó que podía perderse todo el valor, el usuario firmó y recibió tokens valorados en unos 36.000 dólares.
Esta distinción explica por qué mejorar las descripciones de las transacciones no es una solución completa. Clear Signing ayuda a los usuarios a entender la acción solicitada. La simulación estima los efectos según el estado seleccionado de la cadena. Ninguna de las dos, por sí sola, impone una condición independiente al resultado que realmente se produce.
| Elemento | Detalles |
|---|---|
| TXTRACE | Enumera los cambios netos de estado y los eventos emitidos por la transacción. |
| TXDIFF | Obtiene los valores iniciales y finales de las direcciones y las ranuras de almacenamiento especificadas. |
| EVENTDATACOPY | Copia los datos de un evento en memoria para su inspección. |
| Información de implementación | Los datos propuestos sobre cambios de estado incluyen los contratos recién implementados y sus hashes de código. |
Cómo comprobarían el resultado las afirmaciones sobre transacciones
Una afirmación compararía el estado inicial y final de una transacción mediante lógica de solo lectura, una vez ejecutadas sus acciones. La condición se incluiría en la transacción y se firmaría junto con las acciones. Si no se cumpliera, esas acciones se revertirían.
Entre las reglas posibles figuran una cantidad mínima recibida, un límite de gasto, restricciones sobre nuevas autorizaciones de tokens o la preservación de la lógica de control de una cuenta. La capacidad de inspección propuesta abarca no solo los saldos, sino también el almacenamiento, el código, los contratos recién implementados y los eventos emitidos.
Las comprobaciones existentes en los contratos ya protegen determinados resultados. Uniswap puede rechazar intercambios por debajo de una cantidad mínima de salida especificada, y un guard de Safe puede inspeccionar el estado de una cuenta después de la ejecución. La limitación es la visibilidad: estas comprobaciones deben anticipar qué examinar y, por lo general, dependen de las interfaces que exponen otros contratos. Un proxy, por ejemplo, no tiene por qué ofrecer una función que revele la dirección de su implementación.
Las afirmaciones nativas permitirían comprobar todos los efectos netos de la transacción, incluidos cambios que un guard convencional quizá no sabría que debe buscar. Sin embargo, una mayor visibilidad solo es útil si la regla es confiable. Una interfaz maliciosa podría proporcionar una condición que permita su propio ataque, por lo que la política debe proceder de una intención aprobada de forma independiente, de la política de la cuenta o de lógica de protocolo protegida.
Qué expondría la implementación propuesta
El anuncio de la fundación sobre las afirmaciones nativas de transacciones describe EIP-7906 como una posible implementación, no como un diseño definitivo. Se basa en las transacciones por marcos de EIP-8141, que organizan los pasos de validación y acción en una secuencia ordenada. EIP-8141 está previsto para Hegotá; EIP-7906 ha alcanzado la fase Considered for Inclusion, pero no está confirmado para esa actualización.
Con este enfoque, un marco POST_TX de solo lectura inspeccionaría los resultados al final de la ejecución. Las instrucciones propuestas para acceder a los datos funcionarían únicamente dentro de ese marco, no en toda la EVM.
La información describiría los efectos netos, no un historial de cada escritura intermedia. Una ranura de almacenamiento modificada varias veces aparecería con sus valores inicial y final; una ranura que recuperara su valor original no aparecería. Por eso es importante distinguir entre hacer cumplir el estado final y supervisar cada paso de la ejecución.
Si una comprobación fallara, el cuerpo de la ejecución se revertiría, pero la transacción permanecería en el bloque como fallida. El pagador del gas seguiría pagando el gas consumido, lo que impediría que transacciones que fallan deliberadamente impusieran trabajo de ejecución gratuito a los constructores.
Qué cambios necesitarían los monederos y protocolos
La propuesta proporciona un mecanismo de comprobación, no una obligación automática de utilizarlo. En las transacciones de un usuario, el monedero tendría que incorporar su política de seguridad a la construcción de la transacción, en vez de dejar que el constructor la omita. Esa política podría derivarse de la propia simulación del monedero o aplicarse como regla permanente de la cuenta.
En el caso de los protocolos, la protección tendría que integrarse en las condiciones de acceso a una función protegida. No bastaría con proporcionar una transacción capaz de usar afirmaciones: la llamada tendría que incluir la comprobación concreta que exige el protocolo. Esto cambiaría los requisitos de integración para quienes realizan las llamadas, mientras que los contratos inmutables ya desplegados no podrían incorporar retroactivamente esa comprobación de acceso.
Estas dependencias distinguen una capacidad potencialmente poderosa de la EVM de una garantía para el usuario. Una protección eficaz requeriría tanto una condición sólida como software que haga sistemáticamente imposible eludirla.
Qué podrían aportar a los agentes y a los flujos de trabajo de solucionadores
Los agentes delegados podrían estar limitados tanto por los resultados como por los permisos. Los límites sobre los contratos que puede utilizar un agente o sobre cuánto puede gastar podrían complementarse con requisitos que rijan lo que deja cada transacción.
En la ejecución basada en solucionadores, un protocolo podría especificar un resultado aceptable y permitir que el solucionador eligiera la ruta. La garantía se limitaría a una transacción en una sola red, no a una ruta que abarcase varias cadenas.
Las afirmaciones también podrían comprobar la limpieza del flujo de trabajo, como la devolución de los tokens no utilizados y la revocación de las autorizaciones restantes. La fundación está solicitando aportaciones de equipos de monederos y protocolos mientras continúa el diseño, por lo que estas posibles aplicaciones son líneas de investigación, no funciones de productos anunciadas.
Conclusión
Las afirmaciones nativas sobre transacciones trasladarían parte de la seguridad de las transacciones de Ethereum de la interpretación de una solicitud a la aplicación de su resultado. Su valor práctico dependería de políticas confiables y de que los monederos y protocolos responsables de aplicarlas las adoptaran.
Leer más noticias
Aviso legal
Este artículo de FinanceVelix ofrece información general, no asesoramiento financiero, de inversión, jurídico ni fiscal personalizado. Los precios de las criptomonedas pueden cambiar rápidamente y podrías perder todos los fondos invertidos. Los hechos reflejan la información disponible en el momento de la publicación y pueden cambiar. Verifica de forma independiente la información importante y consulta a un profesional cualificado cuando sea necesario. La mención de un activo, empresa o servicio no constituye un respaldo.
