La abstracción de cuentas (Account Abstraction, AA) es una dirección de exploración a largo plazo importante en el ecosistema de Ethereum, que busca romper las barreras entre cuentas externas (EOA) y cuentas de contrato, permitiendo que las billeteras tengan una mayor programabilidad, seguridad y capacidad de actualización. EIP-4337, como la solución AA más prominente hasta ahora, se ha aplicado ampliamente en una serie de billeteras inteligentes basadas en EntryPoint (como Safe, Stacks, Argent). Sin embargo, EIP-4337, debido a que introduce un mecanismo de grupo de transacciones independiente y contratos de entrada, aún presenta ciertas limitaciones en términos de natividad en cadena, complejidad operativa y compatibilidad ecológica.
Para reducir aún más la barrera de entrada al uso de la abstracción de cuentas y mejorar su soporte nativo, Vitalik propuso EIP-7702 en 2024 e incorporó esta propuesta en la actualización de Pectra. La idea central de EIP-7702 es: permitir que un EOA original, al iniciar una transacción, ejecute el código del contrato (contract_code) de una dirección específica, definiendo así la lógica de ejecución de esa transacción.
EIP-7702 presenta un nuevo mecanismo de "inyección de código a nivel de transacción", que permite a las cuentas de usuario especificar dinámicamente la lógica de ejecución en cada transacción, en lugar de depender del código de contrato previamente implementado. Esto rompe el modelo tradicional de permisos basado en código estático, aporta una mayor flexibilidad e introduce nuevos desafíos de seguridad: los contratos que se basan en la lógica de juicio, como isContract y extcodehash, pueden dejar de ser válidos, y algunos sistemas que asumen que el llamador es EOA puro pueden omitirse. Para los auditores, es importante no solo verificar la seguridad del propio código inyectado, sino también evaluar su posible impacto en otros sistemas contractuales en un contexto dinámico.
En este artículo, el equipo de seguridad de Beosin se centrará en los principios de diseño y características clave de EIP-7702, sistematizando los riesgos de seguridad que puede enfrentar una billetera AA construida sobre esta base durante la auditoría. Además, desde una perspectiva práctica, se propondrán procesos y recomendaciones de auditoría para ayudar a los investigadores de seguridad a afrontar mejor los desafíos técnicos en este nuevo paradigma.
Uno, Introducción a EIP-7702
Resumen técnico de EIP-7702
EIP-7702 introduce un nuevo tipo de transacción 0x04 (SetCode), que permite a EOA autorizar el código de contrato que necesita ejecutarse a través de esta transacción, cuya estructura de transacción es la siguiente:
La lista de autorización_list contiene múltiples listas de autorización y también puede incluir acciones de autorización de no iniciadores de transacciones. La estructura interna es:
En este caso, chain_id representa la cadena en la que se activa la autorización del usuario, y su valor debe ser igual al ID de la cadena de ejecución o ser 0. Cuando chain_id es 0, significa que la autorización es válida para todas las cadenas EVM que soportan EIP-7702, siempre que otros parámetros (como nonce) coincidan. address se refiere a la dirección del contrato objetivo autorizado por el usuario.
Una vez completada la autorización, el sistema cambiará el campo code del usuario autorizado a 0xef0100 || address, donde address es la dirección del contrato autorizado. Si desea revocar la autorización, simplemente inicie una transacción SetCode estableciendo address a 0.
Ventajas de EIP7702
(1) Flexibilidad y personalización
Las cuentas abstractas pueden personalizarse de manera flexible según las necesidades al escribir la lógica de la cuenta en un contrato inteligente. Por ejemplo, los usuarios pueden configurar firmas múltiples, recuperación social, control de límites, etc., para satisfacer las diferentes necesidades de escenarios personales o empresariales. Este diseño mejora significativamente la capacidad de expansión funcional de la cuenta, superando las limitaciones de las cuentas externas tradicionales (EOA).
(2) Mejora de la seguridad
Las cuentas abstractas ofrecen múltiples mecanismos de seguridad, incluyendo autenticación múltiple, límites de transacción y recuperación social. Incluso si el usuario pierde su clave privada, puede recuperar la cuenta a través de contactos confiables o verificación múltiple, evitando así la pérdida permanente de activos que ocurre en cuentas tradicionales debido a la pérdida de la clave privada. Al mismo tiempo, funciones como el control de límites pueden prevenir el robo malicioso de grandes sumas de dinero.
(3) Gas optimización
Las cuentas abstractas soportan un mecanismo de abstracción de Gas flexible, que permite a los usuarios pagar el Gas a través de terceros, e incluso usar otros tokens para pagar las tarifas de transacción. Este mecanismo no solo reduce los costos operativos para los usuarios, sino que también simplifica aún más el proceso de uso de la blockchain, siendo especialmente adecuado para usuarios inexpertos o para escenarios de transacciones complejas en múltiples pasos.
(4) Impulsar la adopción de Web3
Al optimizar la experiencia y la seguridad, las cuentas abstractas ocultan la complejidad de la blockchain en un lugar que los usuarios no pueden ver, proporcionando una operación más conveniente y cercana a Web2. Este diseño reduce el costo de aprendizaje para los usuarios comunes, permitiendo que más personas participen sin obstáculos en las aplicaciones Web3, promoviendo así la difusión de la tecnología descentralizada.
II. Análisis de riesgos de seguridad en la práctica de EIP-7702
A pesar de que EIP-7702 ha inyectado nueva energía en el ecosistema de Ethereum y ha ampliado una rica variedad de escenarios de aplicación, al mismo tiempo, también ha introducido inevitablemente algunos nuevos riesgos de seguridad:
Ataque de repetición autorizado
Bajo el modelo EIP-7702, si un usuario establece el campo chain_id en 0 en la autorización, significa que dicha autorización es válida en múltiples cadenas. Este diseño de "autorización universal entre cadenas" mejora la flexibilidad en ciertos escenarios, pero también introduce riesgos de seguridad evidentes.
Es especialmente importante tener en cuenta que, aunque la identificación de la cuenta en la misma dirección puede ser igual en diferentes cadenas, la implementación del contrato detrás de ella puede ser completamente diferente. Esto significa que un atacante podría desplegar una versión maliciosa del contrato en otra cadena, aprovechando las acciones de autorización de la misma dirección en la cadena para ejecutar operaciones no previstas, lo que podría poner en riesgo los activos de los usuarios.
Por lo tanto, para los proveedores de servicios de billetera o plataformas de interacción frontal, al realizar operaciones de autorización de este tipo, se debe verificar claramente si el chainId declarado en la autorización del usuario coincide con la red actual a la que está conectado; si se detecta que el usuario ha configurado el chainId como 0, se debe proporcionar una advertencia de riesgo clara, recordando al usuario que dicha autorización será efectiva en todas las cadenas compatibles con EVM y podría ser abusada por contratos maliciosos.
Además, el proveedor de servicios también debe evaluar si se debe limitar o prohibir por defecto en la capa de UI la autorización con chainId igual a 0, para reducir el riesgo de errores operativos o ataques de phishing.
Problemas de compatibilidad de contratos
(1) compatibilidad de retrocesos de contrato
Los contratos de tokens existentes como ERC-721, ERC-777 y ERC1155, al transferir a una dirección de contrato, llamarán a la interfaz de devolución estándar (como onERC721Received, tokensReceived) para completar la operación de transferencia. Si la dirección de recepción no implementa la interfaz correspondiente, la transferencia fallará e incluso podría provocar el bloqueo de los activos.
En EIP-7702, las direcciones de los usuarios pueden recibir código de contrato a través de la operación "set_code", convirtiéndose así en cuentas de contrato. En este momento:
La dirección del usuario se considerará como un contrato;
Si el contrato no implementa la interfaz de callback necesaria, fallará la transferencia de tokens;
Los usuarios pueden no ser capaces de recibir tokens populares sin saberlo.
Por lo tanto, los desarrolladores deben asegurarse de que el contrato objetivo delegado por el usuario implemente las interfaces de callback relevantes para garantizar la compatibilidad con los tokens principales.
(2) La verificación de «tx.origin» ha fallado.
En los contratos tradicionales, «tx.origin» se utiliza a menudo para determinar si la transacción fue iniciada directamente por el usuario, y se utiliza para controles de seguridad como la prevención de llamadas de contrato.
Pero en el escenario de EIP-7702:
El usuario firma la transacción de autorización, que es transmitida realmente por un relé o servicio de agrupación (bundler); al ejecutar la transacción, "tx.origin" es la dirección del relé, no la dirección del usuario.
"msg.sender" es el contrato de billetera que representa la identidad del usuario.
Por lo tanto, la verificación de permisos basada en "tx.origin == msg.sender" resultará en que las operaciones de usuarios legítimos sean rechazadas, perdiendo fiabilidad; de igual manera, el uso de restricciones como "tx.origin == user" para llamar a contratos también será ineficaz. Se sugiere descontinuar el uso de "tx.origin" como base para el juicio de seguridad y optar por mecanismos de verificación de firmas o autorización.
(3) "isContract" error de juicio
Muchos contratos utilizan "isContract (address)" (verificar la longitud del código de la dirección) para prevenir que las cuentas de contrato participen en ciertas operaciones, como airdrops, compras masivas, etc:
Bajo el mecanismo EIP-7702, la dirección del usuario puede convertirse en una cuenta de contrato a través de la transacción "set_code", "isContract" devuelve verdadero, el contrato puede malinterpretar a los usuarios legítimos como cuentas de contrato, negando su participación en operaciones, lo que resulta en que los usuarios no pueden utilizar ciertos servicios y su experiencia se ve obstaculizada.
Con la creciente popularidad de las carteras de contratos, el diseño que depende de "isContract" para determinar "si es un usuario humano" ya no es seguro. Se recomienda adoptar métodos de identificación de usuarios más precisos, como la verificación de firmas.
Ataque de phishing
Después de implementar el mecanismo de delegación de EIP-7702, los activos en la cuenta del usuario estarán completamente controlados por el contrato inteligente delegado. Una vez que el usuario autoriza a un contrato malicioso, el atacante podría obtener el control total de los activos de la cuenta, lo que podría llevar a una rápida transferencia o robo de fondos, con un riesgo de seguridad extremadamente alto.
Por lo tanto, para los proveedores de servicios de billetera, es crucial apoyar lo antes posible el análisis de transacciones del tipo EIP-7702 y los mecanismos de identificación de riesgos. Cuando los usuarios firman transacciones delegadas, la interfaz debe mostrar de manera clara y destacada la dirección del contrato objetivo, junto con información auxiliar como la fuente del contrato y la información de implementación, para ayudar a los usuarios a identificar posibles comportamientos de phishing o fraude, reduciendo así el riesgo de firma incorrecta. Más allá de eso, los servicios de billetera deben integrar la capacidad de análisis de seguridad automática del contrato objetivo, como la verificación del estado de código abierto del contrato, el análisis del modelo de permisos, la identificación de operaciones potencialmente peligrosas, entre otros métodos, para ayudar a los usuarios a hacer juicios más seguros antes de otorgar autorización.
Es especialmente importante notar que el formato de firma delegada introducido por EIP-7702 no es compatible con los estándares de firma existentes EIP-191 y EIP-712. Su firma puede eludir fácilmente las advertencias de firma y las indicaciones interactivas que ya existen en las carteras, aumentando aún más el riesgo de que los usuarios sean engañados para firmar operaciones maliciosas. Por lo tanto, introducir un mecanismo de identificación y manejo de esta estructura de firma en la implementación de la cartera será un aspecto clave para garantizar la seguridad del usuario.
Riesgos del contrato de billetera
(1) gestión de permisos de contrato de billetera
Muchos contratos de billetera EIP-7702 utilizan un ( de arquitectura de proxy o un ) de privilegios administrativos incorporados para admitir actualizaciones lógicas. Sin embargo, esto también plantea un mayor riesgo para la gestión de derechos. Si el privilegio de actualización no está estrictamente restringido, un atacante puede reemplazar el contrato de implementación e inyectar código malicioso, lo que resulta en la manipulación de la cuenta del usuario o el robo de fondos.
Consejos de seguridad:
Utilizar firmas múltiples, autenticación de múltiples factores o mecanismos de bloqueo de tiempo para controlar los permisos de actualización.
Los cambios en el código y los permisos deben someterse a una auditoría rigurosa y a una verificación de seguridad.
Proceso de actualización público y transparente, que garantiza el derecho a la información y la participación del usuario.
(2) Riesgo de conflictos de almacenamiento y aislamiento de datos
Las versiones de contratos de billetera o diferentes proveedores de servicios de billetera pueden reutilizar el mismo espacio de almacenamiento (storage slot). Si un usuario cambia de proveedor de servicios de billetera o actualiza la lógica de la billetera, la reutilización del espacio de almacenamiento puede causar conflictos en las variables de estado, lo que resulta en problemas como sobrescritura de datos o lecturas anómalas. Esto no solo puede dañar la funcionalidad normal de la billetera, sino que también puede llevar a la pérdida de fondos o a anomalías en los permisos.
Consejos de seguridad:
Utilizar soluciones de aislamiento de almacenamiento especializadas (como el estándar EIP-1967) o gestionar los espacios de almacenamiento mediante un espacio de nombres único.
Al actualizar el contrato, asegúrese de que la disposición del almacenamiento sea compatible y evite la superposición de variables.
Probar rigurosamente la razonabilidad del estado de almacenamiento en el proceso de actualización.
(3) gestión de nonce interna de la billetera
Los contratos de billetera generalmente tienen nonce internamente y se administran a sí mismos para garantizar el orden de ejecución de las operaciones del usuario y evitar ataques de reproducción. Si el nonce no se utiliza correctamente, la operación del usuario no se ejecutará correctamente.
Consejos de seguridad:
nonce debe ser verificado como igual (o creciente), no se puede omitir.
Se prohíbe que la función modifique directamente el nonce; debe ser actualizado sincrónicamente solo cuando el usuario ejecute la operación.
Diseñar mecanismos de tolerancia a fallos y recuperación para situaciones anómalas de nonce, evitando el bloqueo por nonce.
( Comprobación de permisos del llamador de funciones
Para garantizar la seguridad, el contrato de la billetera debe asegurarse de que el llamador de las funciones clave sea la cuenta del propietario de la billetera. Las dos formas más comunes incluyen:
Autorización de firma fuera de la cadena
El usuario firma un conjunto de operaciones con su clave privada, y el contrato de la billetera verifica en la cadena si la firma es válida, si ha expirado y si cumple con el nonce correspondiente. Este método es adecuado para el modo de transacción de retransmisión promovido por EIP-7702 (firma fuera de línea del usuario + el emisor retransmite la transacción).
Llamar a la restricción (msg.sender == address )this()
La función de operación del usuario solo permite ser invocada por el contrato mismo, siendo esencialmente un mecanismo de control de ruta de llamada que asegura que el iniciador externo debe ser la misma cuenta. Esto es, de hecho, equivalente a requerir que el llamador sea el EOA original, ya que en este momento la dirección del contrato es la dirección del EOA.
Tres, perspectivas: EIP-7702 y el futuro del estándar de billetera AA
La propuesta de EIP-7702 no es solo una innovación del modelo de cuenta tradicional, sino también una importante promoción del ecosistema de abstracción de cuentas. La capacidad de los usuarios para cargar el código de contrato introducido por él brinda un amplio espacio para la exploración para el futuro diseño de billetera y sistema de contratos, y también presenta nuevos requisitos para los estándares de auditoría de seguridad.
Evolución colaborativa con EIP-4337: hacia la compatibilidad bimodal
Aunque EIP-7702 y EIP-4337 tienen objetivos de diseño diferentes, el primero reestructura el mecanismo de carga de código de la cuenta, mientras que el segundo construye una entrada de transacción completa y un ecosistema de empaquetado. Pero no son conflictivos, de hecho, tienen una fuerte complementariedad:
EIP-4337 proporciona un "canal de transacciones general" y una "interfaz de ejecución de cuentas abstractas";
EIP-7702 permite a las cuentas de usuario otorgar dinámicamente capacidades lógicas a los contratos sin cambiar la dirección.
Por lo tanto, la billetera futura podría adoptar una "arquitectura de soporte dual": utilizando EIP-7702 como una alternativa ligera en cadenas que no soportan EIP-4337, mientras que en escenarios que requieren empaquetado fuera de la cadena y agregación de múltiples usuarios, seguir confiando en la pila de protocolos completa de EIP-4337.
Este mecanismo de doble modo también impulsará a la billetera a soportar un modelo de permisos de cuenta más flexible, un mecanismo de degradación y un plan de reversión a nivel de núcleo.
Apoyo e inspiración para la lógica de billeteras nuevas como MPC, ZK, etc.
El mecanismo de contrato de cuenta promovido por EIP-7702 tiene un potencial de fusión natural con las nuevas arquitecturas populares como las billeteras MPC, las billeteras ZK y las billeteras modular.
En el modo MPC, la acción de firma ya no depende de una única clave privada, sino que es una decisión colaborativa de múltiples partes. A través de la fusión de EIP-7702 y MPC, la firma generada puede controlar la lógica del contrato que se carga dinámicamente, lo que permite estrategias de ejecución más flexibles.
La billetera ZK valida la identidad o la autorización del usuario a través de pruebas de conocimiento cero, sin necesidad de revelar información de la clave privada. Combinada con EIP-7702, la billetera ZK puede inyectar temporalmente un contrato lógico específico después de completar la verificación, permitiendo así la implementación de comportamientos personalizados tras el cálculo de la privacidad, como la ejecución automática de cierta lógica solo cuando se cumplen ciertas condiciones de privacidad.
Las billeteras modulares (Modular Wallets) pueden descomponer la lógica de la cuenta en varios módulos mediante EIP-7702, que se cargan dinámicamente cuando es necesario.
Por lo tanto, el EIP-7702 proporciona un «contenedor de ejecución» más nativo para las mencionadas billeteras avanzadas: la dirección del usuario permanece sin cambios y se puede inyectar lógica de contrato diferente, evitando así el problema de dependencia de dirección en el proceso de implementación de contratos tradicionales, y no se requiere preimplementación, lo que mejora significativamente la flexibilidad y la capacidad de combinación del comportamiento de la cuenta.
Inspiración para los desarrolladores de contratos y auditores
EIP-7702 impulsará una profunda transformación en el paradigma de desarrollo. Los desarrolladores de contratos ya no verán al llamador simplemente como una EOA tradicional o una cuenta de contrato fija, sino que deberán adaptarse a un mecanismo completamente nuevo: la identidad del llamador puede cambiar dinámicamente entre EOA y el estado del contrato durante el proceso de transacción, la lógica de comportamiento de la cuenta ya no estará estáticamente fijada, sino que podrá cambiar de manera flexible según las necesidades. Esto requiere que los desarrolladores y auditores tengan las siguientes habilidades:
Introducir una lógica de verificación de caller y control de permisos más estricta;
Verificar si la ruta de llamada está afectada por la lógica del contrato dinámico;
Identificar las vulnerabilidades potenciales de comportamientos como msg.sender.code.length == 0, isContract )(, etc.
Aclarar la "dependencia del contexto" de la lógica del contrato, como el control de límites de llamadas estáticas y deleGatecall;
Soporte para la simulación y análisis de restauración del escenario setCode a nivel de cadena de herramientas.
En otras palabras, la seguridad del código ya no es solo un "problema antes del despliegue", sino que se ha convertido en un "proceso dinámico que también debe verificarse durante la llamada y la transacción".
Cuatro, resumen
EIP-7702 presenta una implementación más ligera, nativa y flexible de la abstracción de cuentas (AA), que permite que la EOA ordinaria lleve la lógica del contrato y la ejecute en una sola transacción. Este mecanismo rompe las suposiciones estáticas tradicionales sobre el comportamiento de la cuenta, y los desarrolladores ya no pueden confiar simplemente en el estado del código de la dirección de la cuenta para juzgar su modelo de comportamiento, sino que necesitan reconstruir la comprensión de la identidad y el límite de autoridad del llamador. Con ello se produce un cambio de paradigma en la analítica de seguridad. El enfoque de la auditoría ya no se limita a "si una dirección tiene permisos", sino que se desplaza a "lo que la lógica del contrato llevada a cabo en la transacción puede hacer en el contexto actual". Cada transacción puede llevar una definición independiente de comportamiento, lo que le da a la cuenta una mayor funcionalidad y plantea requisitos más altos para las auditorías de seguridad.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Beosin: Análisis de auditoría de seguridad de EIP-7702 y la próxima generación de Billetera AA
Escrito por: Beosin
La abstracción de cuentas (Account Abstraction, AA) es una dirección de exploración a largo plazo importante en el ecosistema de Ethereum, que busca romper las barreras entre cuentas externas (EOA) y cuentas de contrato, permitiendo que las billeteras tengan una mayor programabilidad, seguridad y capacidad de actualización. EIP-4337, como la solución AA más prominente hasta ahora, se ha aplicado ampliamente en una serie de billeteras inteligentes basadas en EntryPoint (como Safe, Stacks, Argent). Sin embargo, EIP-4337, debido a que introduce un mecanismo de grupo de transacciones independiente y contratos de entrada, aún presenta ciertas limitaciones en términos de natividad en cadena, complejidad operativa y compatibilidad ecológica.
Para reducir aún más la barrera de entrada al uso de la abstracción de cuentas y mejorar su soporte nativo, Vitalik propuso EIP-7702 en 2024 e incorporó esta propuesta en la actualización de Pectra. La idea central de EIP-7702 es: permitir que un EOA original, al iniciar una transacción, ejecute el código del contrato (contract_code) de una dirección específica, definiendo así la lógica de ejecución de esa transacción.
EIP-7702 presenta un nuevo mecanismo de "inyección de código a nivel de transacción", que permite a las cuentas de usuario especificar dinámicamente la lógica de ejecución en cada transacción, en lugar de depender del código de contrato previamente implementado. Esto rompe el modelo tradicional de permisos basado en código estático, aporta una mayor flexibilidad e introduce nuevos desafíos de seguridad: los contratos que se basan en la lógica de juicio, como isContract y extcodehash, pueden dejar de ser válidos, y algunos sistemas que asumen que el llamador es EOA puro pueden omitirse. Para los auditores, es importante no solo verificar la seguridad del propio código inyectado, sino también evaluar su posible impacto en otros sistemas contractuales en un contexto dinámico.
En este artículo, el equipo de seguridad de Beosin se centrará en los principios de diseño y características clave de EIP-7702, sistematizando los riesgos de seguridad que puede enfrentar una billetera AA construida sobre esta base durante la auditoría. Además, desde una perspectiva práctica, se propondrán procesos y recomendaciones de auditoría para ayudar a los investigadores de seguridad a afrontar mejor los desafíos técnicos en este nuevo paradigma.
Uno, Introducción a EIP-7702
EIP-7702 introduce un nuevo tipo de transacción 0x04 (SetCode), que permite a EOA autorizar el código de contrato que necesita ejecutarse a través de esta transacción, cuya estructura de transacción es la siguiente:
La lista de autorización_list contiene múltiples listas de autorización y también puede incluir acciones de autorización de no iniciadores de transacciones. La estructura interna es:
En este caso, chain_id representa la cadena en la que se activa la autorización del usuario, y su valor debe ser igual al ID de la cadena de ejecución o ser 0. Cuando chain_id es 0, significa que la autorización es válida para todas las cadenas EVM que soportan EIP-7702, siempre que otros parámetros (como nonce) coincidan. address se refiere a la dirección del contrato objetivo autorizado por el usuario.
Una vez completada la autorización, el sistema cambiará el campo code del usuario autorizado a 0xef0100 || address, donde address es la dirección del contrato autorizado. Si desea revocar la autorización, simplemente inicie una transacción SetCode estableciendo address a 0.
(1) Flexibilidad y personalización
Las cuentas abstractas pueden personalizarse de manera flexible según las necesidades al escribir la lógica de la cuenta en un contrato inteligente. Por ejemplo, los usuarios pueden configurar firmas múltiples, recuperación social, control de límites, etc., para satisfacer las diferentes necesidades de escenarios personales o empresariales. Este diseño mejora significativamente la capacidad de expansión funcional de la cuenta, superando las limitaciones de las cuentas externas tradicionales (EOA).
(2) Mejora de la seguridad
Las cuentas abstractas ofrecen múltiples mecanismos de seguridad, incluyendo autenticación múltiple, límites de transacción y recuperación social. Incluso si el usuario pierde su clave privada, puede recuperar la cuenta a través de contactos confiables o verificación múltiple, evitando así la pérdida permanente de activos que ocurre en cuentas tradicionales debido a la pérdida de la clave privada. Al mismo tiempo, funciones como el control de límites pueden prevenir el robo malicioso de grandes sumas de dinero.
(3) Gas optimización
Las cuentas abstractas soportan un mecanismo de abstracción de Gas flexible, que permite a los usuarios pagar el Gas a través de terceros, e incluso usar otros tokens para pagar las tarifas de transacción. Este mecanismo no solo reduce los costos operativos para los usuarios, sino que también simplifica aún más el proceso de uso de la blockchain, siendo especialmente adecuado para usuarios inexpertos o para escenarios de transacciones complejas en múltiples pasos.
(4) Impulsar la adopción de Web3
Al optimizar la experiencia y la seguridad, las cuentas abstractas ocultan la complejidad de la blockchain en un lugar que los usuarios no pueden ver, proporcionando una operación más conveniente y cercana a Web2. Este diseño reduce el costo de aprendizaje para los usuarios comunes, permitiendo que más personas participen sin obstáculos en las aplicaciones Web3, promoviendo así la difusión de la tecnología descentralizada.
II. Análisis de riesgos de seguridad en la práctica de EIP-7702
A pesar de que EIP-7702 ha inyectado nueva energía en el ecosistema de Ethereum y ha ampliado una rica variedad de escenarios de aplicación, al mismo tiempo, también ha introducido inevitablemente algunos nuevos riesgos de seguridad:
Bajo el modelo EIP-7702, si un usuario establece el campo chain_id en 0 en la autorización, significa que dicha autorización es válida en múltiples cadenas. Este diseño de "autorización universal entre cadenas" mejora la flexibilidad en ciertos escenarios, pero también introduce riesgos de seguridad evidentes.
Es especialmente importante tener en cuenta que, aunque la identificación de la cuenta en la misma dirección puede ser igual en diferentes cadenas, la implementación del contrato detrás de ella puede ser completamente diferente. Esto significa que un atacante podría desplegar una versión maliciosa del contrato en otra cadena, aprovechando las acciones de autorización de la misma dirección en la cadena para ejecutar operaciones no previstas, lo que podría poner en riesgo los activos de los usuarios.
Por lo tanto, para los proveedores de servicios de billetera o plataformas de interacción frontal, al realizar operaciones de autorización de este tipo, se debe verificar claramente si el chainId declarado en la autorización del usuario coincide con la red actual a la que está conectado; si se detecta que el usuario ha configurado el chainId como 0, se debe proporcionar una advertencia de riesgo clara, recordando al usuario que dicha autorización será efectiva en todas las cadenas compatibles con EVM y podría ser abusada por contratos maliciosos.
Además, el proveedor de servicios también debe evaluar si se debe limitar o prohibir por defecto en la capa de UI la autorización con chainId igual a 0, para reducir el riesgo de errores operativos o ataques de phishing.
(1) compatibilidad de retrocesos de contrato
Los contratos de tokens existentes como ERC-721, ERC-777 y ERC1155, al transferir a una dirección de contrato, llamarán a la interfaz de devolución estándar (como onERC721Received, tokensReceived) para completar la operación de transferencia. Si la dirección de recepción no implementa la interfaz correspondiente, la transferencia fallará e incluso podría provocar el bloqueo de los activos.
En EIP-7702, las direcciones de los usuarios pueden recibir código de contrato a través de la operación "set_code", convirtiéndose así en cuentas de contrato. En este momento:
La dirección del usuario se considerará como un contrato;
Si el contrato no implementa la interfaz de callback necesaria, fallará la transferencia de tokens;
Los usuarios pueden no ser capaces de recibir tokens populares sin saberlo.
Por lo tanto, los desarrolladores deben asegurarse de que el contrato objetivo delegado por el usuario implemente las interfaces de callback relevantes para garantizar la compatibilidad con los tokens principales.
(2) La verificación de «tx.origin» ha fallado.
En los contratos tradicionales, «tx.origin» se utiliza a menudo para determinar si la transacción fue iniciada directamente por el usuario, y se utiliza para controles de seguridad como la prevención de llamadas de contrato. Pero en el escenario de EIP-7702:
El usuario firma la transacción de autorización, que es transmitida realmente por un relé o servicio de agrupación (bundler); al ejecutar la transacción, "tx.origin" es la dirección del relé, no la dirección del usuario.
"msg.sender" es el contrato de billetera que representa la identidad del usuario.
Por lo tanto, la verificación de permisos basada en "tx.origin == msg.sender" resultará en que las operaciones de usuarios legítimos sean rechazadas, perdiendo fiabilidad; de igual manera, el uso de restricciones como "tx.origin == user" para llamar a contratos también será ineficaz. Se sugiere descontinuar el uso de "tx.origin" como base para el juicio de seguridad y optar por mecanismos de verificación de firmas o autorización.
(3) "isContract" error de juicio
Muchos contratos utilizan "isContract (address)" (verificar la longitud del código de la dirección) para prevenir que las cuentas de contrato participen en ciertas operaciones, como airdrops, compras masivas, etc:
Bajo el mecanismo EIP-7702, la dirección del usuario puede convertirse en una cuenta de contrato a través de la transacción "set_code", "isContract" devuelve verdadero, el contrato puede malinterpretar a los usuarios legítimos como cuentas de contrato, negando su participación en operaciones, lo que resulta en que los usuarios no pueden utilizar ciertos servicios y su experiencia se ve obstaculizada. Con la creciente popularidad de las carteras de contratos, el diseño que depende de "isContract" para determinar "si es un usuario humano" ya no es seguro. Se recomienda adoptar métodos de identificación de usuarios más precisos, como la verificación de firmas.
Después de implementar el mecanismo de delegación de EIP-7702, los activos en la cuenta del usuario estarán completamente controlados por el contrato inteligente delegado. Una vez que el usuario autoriza a un contrato malicioso, el atacante podría obtener el control total de los activos de la cuenta, lo que podría llevar a una rápida transferencia o robo de fondos, con un riesgo de seguridad extremadamente alto.
Por lo tanto, para los proveedores de servicios de billetera, es crucial apoyar lo antes posible el análisis de transacciones del tipo EIP-7702 y los mecanismos de identificación de riesgos. Cuando los usuarios firman transacciones delegadas, la interfaz debe mostrar de manera clara y destacada la dirección del contrato objetivo, junto con información auxiliar como la fuente del contrato y la información de implementación, para ayudar a los usuarios a identificar posibles comportamientos de phishing o fraude, reduciendo así el riesgo de firma incorrecta. Más allá de eso, los servicios de billetera deben integrar la capacidad de análisis de seguridad automática del contrato objetivo, como la verificación del estado de código abierto del contrato, el análisis del modelo de permisos, la identificación de operaciones potencialmente peligrosas, entre otros métodos, para ayudar a los usuarios a hacer juicios más seguros antes de otorgar autorización.
Es especialmente importante notar que el formato de firma delegada introducido por EIP-7702 no es compatible con los estándares de firma existentes EIP-191 y EIP-712. Su firma puede eludir fácilmente las advertencias de firma y las indicaciones interactivas que ya existen en las carteras, aumentando aún más el riesgo de que los usuarios sean engañados para firmar operaciones maliciosas. Por lo tanto, introducir un mecanismo de identificación y manejo de esta estructura de firma en la implementación de la cartera será un aspecto clave para garantizar la seguridad del usuario.
(1) gestión de permisos de contrato de billetera
Muchos contratos de billetera EIP-7702 utilizan un ( de arquitectura de proxy o un ) de privilegios administrativos incorporados para admitir actualizaciones lógicas. Sin embargo, esto también plantea un mayor riesgo para la gestión de derechos. Si el privilegio de actualización no está estrictamente restringido, un atacante puede reemplazar el contrato de implementación e inyectar código malicioso, lo que resulta en la manipulación de la cuenta del usuario o el robo de fondos.
Consejos de seguridad:
Utilizar firmas múltiples, autenticación de múltiples factores o mecanismos de bloqueo de tiempo para controlar los permisos de actualización.
Los cambios en el código y los permisos deben someterse a una auditoría rigurosa y a una verificación de seguridad.
Proceso de actualización público y transparente, que garantiza el derecho a la información y la participación del usuario.
(2) Riesgo de conflictos de almacenamiento y aislamiento de datos
Las versiones de contratos de billetera o diferentes proveedores de servicios de billetera pueden reutilizar el mismo espacio de almacenamiento (storage slot). Si un usuario cambia de proveedor de servicios de billetera o actualiza la lógica de la billetera, la reutilización del espacio de almacenamiento puede causar conflictos en las variables de estado, lo que resulta en problemas como sobrescritura de datos o lecturas anómalas. Esto no solo puede dañar la funcionalidad normal de la billetera, sino que también puede llevar a la pérdida de fondos o a anomalías en los permisos.
Consejos de seguridad:
Utilizar soluciones de aislamiento de almacenamiento especializadas (como el estándar EIP-1967) o gestionar los espacios de almacenamiento mediante un espacio de nombres único.
Al actualizar el contrato, asegúrese de que la disposición del almacenamiento sea compatible y evite la superposición de variables.
Probar rigurosamente la razonabilidad del estado de almacenamiento en el proceso de actualización.
(3) gestión de nonce interna de la billetera
Los contratos de billetera generalmente tienen nonce internamente y se administran a sí mismos para garantizar el orden de ejecución de las operaciones del usuario y evitar ataques de reproducción. Si el nonce no se utiliza correctamente, la operación del usuario no se ejecutará correctamente.
Consejos de seguridad:
nonce debe ser verificado como igual (o creciente), no se puede omitir.
Se prohíbe que la función modifique directamente el nonce; debe ser actualizado sincrónicamente solo cuando el usuario ejecute la operación.
Diseñar mecanismos de tolerancia a fallos y recuperación para situaciones anómalas de nonce, evitando el bloqueo por nonce.
( Comprobación de permisos del llamador de funciones
Para garantizar la seguridad, el contrato de la billetera debe asegurarse de que el llamador de las funciones clave sea la cuenta del propietario de la billetera. Las dos formas más comunes incluyen:
Autorización de firma fuera de la cadena
El usuario firma un conjunto de operaciones con su clave privada, y el contrato de la billetera verifica en la cadena si la firma es válida, si ha expirado y si cumple con el nonce correspondiente. Este método es adecuado para el modo de transacción de retransmisión promovido por EIP-7702 (firma fuera de línea del usuario + el emisor retransmite la transacción).
Llamar a la restricción (msg.sender == address )this()
La función de operación del usuario solo permite ser invocada por el contrato mismo, siendo esencialmente un mecanismo de control de ruta de llamada que asegura que el iniciador externo debe ser la misma cuenta. Esto es, de hecho, equivalente a requerir que el llamador sea el EOA original, ya que en este momento la dirección del contrato es la dirección del EOA.
Tres, perspectivas: EIP-7702 y el futuro del estándar de billetera AA
La propuesta de EIP-7702 no es solo una innovación del modelo de cuenta tradicional, sino también una importante promoción del ecosistema de abstracción de cuentas. La capacidad de los usuarios para cargar el código de contrato introducido por él brinda un amplio espacio para la exploración para el futuro diseño de billetera y sistema de contratos, y también presenta nuevos requisitos para los estándares de auditoría de seguridad.
Aunque EIP-7702 y EIP-4337 tienen objetivos de diseño diferentes, el primero reestructura el mecanismo de carga de código de la cuenta, mientras que el segundo construye una entrada de transacción completa y un ecosistema de empaquetado. Pero no son conflictivos, de hecho, tienen una fuerte complementariedad:
EIP-4337 proporciona un "canal de transacciones general" y una "interfaz de ejecución de cuentas abstractas";
EIP-7702 permite a las cuentas de usuario otorgar dinámicamente capacidades lógicas a los contratos sin cambiar la dirección.
Por lo tanto, la billetera futura podría adoptar una "arquitectura de soporte dual": utilizando EIP-7702 como una alternativa ligera en cadenas que no soportan EIP-4337, mientras que en escenarios que requieren empaquetado fuera de la cadena y agregación de múltiples usuarios, seguir confiando en la pila de protocolos completa de EIP-4337.
Este mecanismo de doble modo también impulsará a la billetera a soportar un modelo de permisos de cuenta más flexible, un mecanismo de degradación y un plan de reversión a nivel de núcleo.
El mecanismo de contrato de cuenta promovido por EIP-7702 tiene un potencial de fusión natural con las nuevas arquitecturas populares como las billeteras MPC, las billeteras ZK y las billeteras modular.
En el modo MPC, la acción de firma ya no depende de una única clave privada, sino que es una decisión colaborativa de múltiples partes. A través de la fusión de EIP-7702 y MPC, la firma generada puede controlar la lógica del contrato que se carga dinámicamente, lo que permite estrategias de ejecución más flexibles.
La billetera ZK valida la identidad o la autorización del usuario a través de pruebas de conocimiento cero, sin necesidad de revelar información de la clave privada. Combinada con EIP-7702, la billetera ZK puede inyectar temporalmente un contrato lógico específico después de completar la verificación, permitiendo así la implementación de comportamientos personalizados tras el cálculo de la privacidad, como la ejecución automática de cierta lógica solo cuando se cumplen ciertas condiciones de privacidad.
Las billeteras modulares (Modular Wallets) pueden descomponer la lógica de la cuenta en varios módulos mediante EIP-7702, que se cargan dinámicamente cuando es necesario.
Por lo tanto, el EIP-7702 proporciona un «contenedor de ejecución» más nativo para las mencionadas billeteras avanzadas: la dirección del usuario permanece sin cambios y se puede inyectar lógica de contrato diferente, evitando así el problema de dependencia de dirección en el proceso de implementación de contratos tradicionales, y no se requiere preimplementación, lo que mejora significativamente la flexibilidad y la capacidad de combinación del comportamiento de la cuenta.
EIP-7702 impulsará una profunda transformación en el paradigma de desarrollo. Los desarrolladores de contratos ya no verán al llamador simplemente como una EOA tradicional o una cuenta de contrato fija, sino que deberán adaptarse a un mecanismo completamente nuevo: la identidad del llamador puede cambiar dinámicamente entre EOA y el estado del contrato durante el proceso de transacción, la lógica de comportamiento de la cuenta ya no estará estáticamente fijada, sino que podrá cambiar de manera flexible según las necesidades. Esto requiere que los desarrolladores y auditores tengan las siguientes habilidades:
Introducir una lógica de verificación de caller y control de permisos más estricta;
Verificar si la ruta de llamada está afectada por la lógica del contrato dinámico;
Identificar las vulnerabilidades potenciales de comportamientos como msg.sender.code.length == 0, isContract )(, etc.
Aclarar la "dependencia del contexto" de la lógica del contrato, como el control de límites de llamadas estáticas y deleGatecall;
Soporte para la simulación y análisis de restauración del escenario setCode a nivel de cadena de herramientas.
En otras palabras, la seguridad del código ya no es solo un "problema antes del despliegue", sino que se ha convertido en un "proceso dinámico que también debe verificarse durante la llamada y la transacción".
Cuatro, resumen
EIP-7702 presenta una implementación más ligera, nativa y flexible de la abstracción de cuentas (AA), que permite que la EOA ordinaria lleve la lógica del contrato y la ejecute en una sola transacción. Este mecanismo rompe las suposiciones estáticas tradicionales sobre el comportamiento de la cuenta, y los desarrolladores ya no pueden confiar simplemente en el estado del código de la dirección de la cuenta para juzgar su modelo de comportamiento, sino que necesitan reconstruir la comprensión de la identidad y el límite de autoridad del llamador. Con ello se produce un cambio de paradigma en la analítica de seguridad. El enfoque de la auditoría ya no se limita a "si una dirección tiene permisos", sino que se desplaza a "lo que la lógica del contrato llevada a cabo en la transacción puede hacer en el contexto actual". Cada transacción puede llevar una definición independiente de comportamiento, lo que le da a la cuenta una mayor funcionalidad y plantea requisitos más altos para las auditorías de seguridad.