Beosin: EIP-7702 y análisis de auditoría de seguridad de billeteras AA de próxima generación

La abstracción de cuentas (AA) es una dirección importante de exploración a largo plazo en el ecosistema Ethereum, con el objetivo de romper el límite entre las cuentas externas (EOA) y las cuentas contractuales, de modo que la billetera tenga una mayor programabilidad, seguridad y capacidad de actualización. EIP-4337 es actualmente la solución de implementación de AA más convencional y se ha utilizado ampliamente en una serie de billeteras de contratos inteligentes basadas en EntryPoint (como Safe, Stacks y Argent). Sin embargo, EIP-4337 todavía tiene ciertas limitaciones en términos de nativa en la cadena, complejidad operativa y compatibilidad ecológica debido a su introducción de un grupo de transacciones independiente y un mecanismo de contrato de rampa de acceso.

Para reducir aún más la barrera de entrada y mejorar el soporte nativo para las abstracciones de cuentas, Vitalik propuso EIP-7702 en 2024 y lo incluyó en la actualización de Pectra. La idea central de EIP-7702 es permitir que un EOA original ejecute el código de contrato (contract_code) de una dirección especificada al iniciar una transacción, y utilizar este código para definir la lógica de ejecución de la transacción.

EIP-7702 presenta un nuevo mecanismo para la "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 también 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 las características clave de EIP-7702, clasificará sistemáticamente los riesgos de seguridad que la billetera AA construida en base a él puede enfrentar en la auditoría y presentará el proceso de auditoría y las sugerencias desde una perspectiva práctica para ayudar a los investigadores de seguridad a enfrentar mejor los desafíos técnicos bajo este nuevo paradigma.

1. Introducción a EIP-77021

. EIP-7702

Descripción técnicaEIP-7702 introduce un nuevo tipo de transacción, 0x 04 (SetCode), que permite a EOA autorizar el código de contrato que debe ejecutarse a través de esta transacción, con la siguiente estructura de transacción:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. destino, valor, datos, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Donde authorization_list contiene múltiples listas de autorización, y también puede contener acciones de autorización de iniciadores que no son de transacción, la estructura interna es:

1. authorization_list = [[chain_id, address, nonce, y_parity, r, s]].

donde chain_id representa la cadena en la que surte efecto la autorización del usuario, y su valor debe ser igual al ID de cadena de la cadena en ejecución o 0. Cuando chain_id es 0, la autorización surte efecto para todas las cadenas de EVM que admiten EIP-7702, pero solo si otros parámetros (como nonce) coinciden. Dirección indica la dirección del contrato de destino autorizada por el usuario.

Una vez completada la autorización, el sistema modificará el campo de código del usuario autorizado a la dirección 0x ef 0100 ||, donde la dirección es la dirección del contrato autorizado. Si desea desautorizar, simplemente inicie una transacción SetCode con la dirección establecida en 0.

número arábigo. Ventajas de EIP 7702

(1) Flexibilidad y personalización

Cuentas abstractasAl escribir la lógica de la cuenta en contratos inteligentes, puede personalizar las funciones de manera flexible de acuerdo con sus necesidades. Por ejemplo, los usuarios pueden configurar la firma múltiple, la recuperación social y el control de cuotas para satisfacer las necesidades de personas o empresas en diferentes escenarios. Este diseño mejora en gran medida la escalabilidad funcional de la cuenta y rompe con las limitaciones de las cuentas externas (EOA) tradicionales.

(2) Seguridad mejoradaLas

cuentas abstractas proporcionan un mecanismo de seguridad de múltiples capas, que incluye autenticación de múltiples factores, límites de transacciones y recuperación social. Incluso si un usuario pierde su clave privada, puede recuperar su cuenta a través de contactos de confianza o autenticación multifactor, evitando la pérdida permanente de activos causada por la pérdida de la clave privada en las cuentas tradicionales. Al mismo tiempo, funciones como el control de límites también pueden evitar el robo malintencionado de grandes cantidades de fondos.

(3) La

admite un mecanismo de extracción de gas flexible, lo que permite a los usuarios pagar el gas a través de un tercero e incluso usar directamente otros tokens para pagar las tarifas de transacción. Este mecanismo no solo reduce el costo de operación de los usuarios, sino que también simplifica aún más el uso de la cadena de bloques, especialmente adecuado para usuarios novatos o escenarios complejos de transacciones de varios pasos.

(4) Promover la popularización de Web3Al

optimizar la experiencia y la seguridad, las cuentas abstractas ocultan la complejidad de la cadena de bloques en lugares que los usuarios no pueden ver, proporcionando operaciones convenientes más cercanas a Web2. Este diseño reduce el costo de aprendizaje de los usuarios comunes, permite que más personas participen en las aplicaciones Web3 sin barreras y promueve la popularización de la tecnología descentralizada.

2. Análisis de los riesgos de seguridad en EIP-7702 en

la práctica Aunque EIP-7702 ha inyectado un nuevo impulso en el ecosistema de Ethereum y ha ampliado una gran cantidad de escenarios de aplicación, al mismo tiempo, inevitablemente ha introducido algunos riesgos de seguridad nuevos:

1. Ataque de reproducción de autorización

Bajo el modelo EIP-7702, si el usuario autoriza el chain_ Si el campo id se establece en 0, la autorización puede surtir efecto en varias cadenas. Aunque este diseño de "autorización universal entre cadenas" mejora la flexibilidad en algunos escenarios, también introduce riesgos de seguridad obvios.

Es importante tener en cuenta que incluso si la identidad de la cuenta de la misma dirección es la misma 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 y realizar acciones no deseadas utilizando la autorización de la misma dirección en la cadena, lo que supondría un riesgo para los activos de los usuarios.

Por lo tanto, para los proveedores de servicios de billetera o las plataformas de interacción front-end, cuando los usuarios realicen dichas operaciones de autorización, deben verificar claramente si el chainId declarado en la autorización del usuario es coherente con la red de conexión actual; Si se detecta que un usuario establece chainId en 0, se debe proporcionar una advertencia de riesgo clara para recordar al usuario que la autorización surtirá efecto en todas las cadenas compatibles con EVM y puede ser objeto de abusos mediante contratos malintencionados.

Además, el proveedor de servicios también debe evaluar si restringir o prohibir la autorización con chainId 0 de forma predeterminada en la capa de la interfaz de usuario para reducir el riesgo de mal funcionamiento o ataques de phishing.

2. Compatibilidad del contrato

1) Compatibilidad de devolución de llamada del contrato

transferir dinero a una dirección de contrato para contratos de tokens existentes, como ERC-721, ERC-777 y ERC 1155, llamarán a interfaces de devolución de llamada estándar (como onERC 721 Received, tokensReceived) para completar la operación de transferencia. Si la dirección de recepción no implementa la interfaz correspondiente, la transferencia fallará o incluso hará que el activo se bloquee.

En EIP-7702, una dirección de usuario se puede transformar en una cuenta de contrato mediante la asignación de un código de contrato a través de la operación "set_code". En este caso:

• La dirección de usuario se considera un contrato;

• Si el contrato no implementa la interfaz de devolución de llamada necesaria, se producirá un error en la transferencia de tokens;

• Es posible que los usuarios no puedan recibir tokens convencionales sin su conocimiento.

Por lo tanto, los desarrolladores deben asegurarse de que el contrato de destino delegado por el usuario implemente la interfaz de devolución de llamada pertinente para garantizar la compatibilidad con los tokens principales.

(2) Falla la verificación de "tx.origin"En

los contratos tradicionales, "tx.origin" se usa a menudo para determinar si la transacción es iniciada directamente por el usuario, y se usa para evitar controles de seguridad como llamadas de contrato.

Sin embargo, en el escenario EIP-7702, el

• usuario firma una transacción de autorización y el repetidor o empaquetador la difunde en nombre del usuario. Cuando se ejecuta una transacción, "tx.origin" es la dirección del repetidor, no la dirección del usuario.

• "msg.sender" es un contrato de billetera que representa la identidad del usuario.

Por lo tanto, la verificación de permisos basada en "tx.origin == msg.sender" hará que las operaciones legítimas del usuario se rechacen y pierdan fiabilidad, y también se invalidarán las mismas llamadas de contrato restringidas como "tx.origin == user". Se recomienda abandonar "tx.origin" como base para el juicio de seguridad y utilizar el mecanismo de autorización o verificación de firma en su lugar.

(3) "isContract" juzga malMuchos

contratos impiden que las cuentas de contrato participen en ciertas operaciones, como lanzamientos aéreos, ventas flash, etc., a través de "isContract(address)":

require(!isContract(msg.sender), "Contracts not allowed").

Bajo el mecanismo EIP-7702, la dirección del usuario se puede cambiar a una cuenta de contrato a través de una transacción "set_code", y "isContract" devuelve true, y el contrato identificará erróneamente al usuario legítimo como la cuenta del contrato y se negará a participar en la operación, lo que resultará en que el usuario no pueda usar ciertos servicios y se bloquee la experiencia.

Con la popularización gradual de las billeteras de contratos, el diseño de confiar en "isContract" para determinar si "un usuario humano" ya no es seguro, y se recomienda utilizar métodos de identificación de usuario más precisos, como la verificación de firma.

3. Ataque de phishingDespués

de la implementación del mecanismo de delegación de EIP-7702, los activos de la cuenta del usuario estarán totalmente controlados por el contrato inteligente delegado. Una vez que un usuario autoriza un contrato malicioso, un atacante puede obtener el control total sobre los activos de la cuenta, lo que resulta en la transferencia rápida o el robo de fondos, lo cual es extremadamente riesgoso.

Por lo tanto, para los proveedores de servicios de billetera, es necesario respaldar el mecanismo de resolución de transacciones e identificación de riesgos EIP-7702 lo antes posibleCrucial. Cuando un usuario firma una transacción de encomienda, el front-end debe mostrar de forma clara y destacada la dirección del contrato de destino, y combinar la información de apoyo, como el origen del contrato y la información de implementación, para ayudar a los usuarios a identificar posibles comportamientos de phishing o fraudulentos, reduciendo así el riesgo de firma errónea. Además, el servicio de billetera debe integrar capacidades automáticas de análisis de seguridad para el contrato de destino, como la verificación del estado de código abierto del contrato, el análisis del modelo de permisos y la identificación de operaciones potencialmente peligrosas, para ayudar a los usuarios a tomar decisiones más seguras antes de la autorización.

En particular, EIP-7702 introduce un formato de firma delegada que no es compatible con los estándares de firma EIP-191 y EIP-712 existentes. Su firma puede eludir fácilmente la advertencia de firma original y el aviso de interacción de la billetera, lo que aumenta aún más el riesgo de que los usuarios sean engañados para firmar operaciones maliciosas. Por lo tanto, la introducción del mecanismo de identificación y procesamiento de la estructura de firma en la implementación de la billetera será un eslabón clave para garantizar la seguridad de los usuarios.

4. Riesgos del contrato de billetera

( 1) Gestión de la autoridad del contrato de billetera

Muchos contratos de billetera EIP-7702 adoptan una arquitectura de proxy (o permisos de administración incorporados) para admitir actualizaciones lógicas. Sin embargo, esto también plantea un mayor riesgo para la gestión de derechos. Si los privilegios de escalamiento no están estrictamente restringidos, 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.

Recomendaciones de seguridad

• : Utilice mecanismos de firma múltiple, autenticación multifactor o bloqueo de tiempo para controlar los privilegios de escalación.

• Los cambios en el código y los permisos están sujetos a rigurosas auditorías y validaciones de seguridad.

• El proceso de actualización es abierto y transparente para garantizar el derecho de los usuarios a saber y participar.

(2) Riesgo de conflictos de almacenamiento y aislamiento de datos, versiones de contratos de

billetera o diferentes proveedores de servicios de billetera pueden reutilizar la misma ranura de almacenamiento. Si el usuario cambia el proveedor de servicios de billetera o actualiza la lógica de la billetera, la reutilización de la ranura de almacenamiento causará el conflicto de variables de estado, sobrescritura de datos, excepciones de lectura y otros problemas. Esto no solo puede interrumpir el funcionamiento normal de la billetera, sino que también puede provocar la pérdida de fondos o permisos anormales.

Recomendaciones de seguridad:

• Utilice un esquema de aislamiento de almacenamiento especializado, como el estándar EIP-1967, o aproveche un espacio de nombres único para administrar ranuras de almacenamiento.

• Al actualizar el contrato, asegúrese de que el diseño de almacenamiento sea compatible y evite la superposición de variables.

• Pruebe rigurosamente la plausibilidad del estado almacenado durante el proceso de actualización.

(3) La gestión de nonce dentro de la billetera

El contrato de la billetera generalmente configura un nonce dentro y se administra a sí mismo para garantizar el orden de ejecución de las operaciones del usuario y evitar ataques de repetición. Si el nonce se utiliza incorrectamente, la operación del usuario no se ejecutará correctamente.

Recomendación de seguridad:

• El nonce debe comprobarse a la fuerza para obtener un valor equivalente (o incremento) y no se puede omitir.

• Está prohibido que las funciones modifiquen directamente el nonce, y el nonce solo se actualizará cuando se ejecute la operación del usuario.

• Diseñe mecanismos de recuperación y tolerancia a errores para las excepciones de nonce a fin de evitar interbloqueos de nonce.

(4) Verificación de permisos del llamador

de funcionesPara garantizar la seguridad, el contrato de billetera debe garantizar que el llamador de la función clave sea la cuenta propietaria de la billetera. Los dos métodos comunes incluyen:

• firma fuera de la cadena autoriza

a los usuarios a firmar un conjunto de operaciones a través de la clave privada, y el contrato de billetera verifica si la firma es legítima, caducada y cumple con el nonce correspondiente en la cadena. Este método es aplicable al modo de transacción de retransmisión recomendado por EIP-7702 (la firma fuera de línea del usuario + el repetidor envía la transacción en nombre del usuario).

• La restricción de llamada (msg.sender == address(this))

solo puede ser activada por el propio contrato, que es esencialmente un mecanismo de control de ruta de llamada que garantiza que el iniciador externo debe ser la propia cuenta. Esto equivale efectivamente a exigir que la persona que llama sea la EOA original, ya que la dirección del contrato es la dirección EOA.

3. Perspectiva: La propuesta de EIP-7702 y el futuro estándar de billetera AA

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 cargar el código de contrato introducida por él brinda un amplio espacio para la exploración para el futuro diseño de billeteras y sistemas de contratos, y también presenta nuevos requisitos para los estándares de auditoría de seguridad.

1. Coevolución con EIP-4337: Hacia la compatibilidad de modo dualAunque

EIP-7702 y EIP-4337 tienen diferentes objetivos de diseño, el primero reconstruye el mecanismo de carga de código de la cuenta y el segundo construye un ecosistema completo de entrada y empaquetado de transacciones. Sin embargo, los dos no están en conflicto, sino que tienen una fuerte complementariedad:

● EIP-4337 proporciona un "canal de transacción común" y una "interfaz de ejecución de cuenta abstracta";

● EIP-7702 permite que las cuentas de usuario otorguen dinámicamente capacidades de lógica de contrato sin cambiar la dirección;

Por lo tanto, en el futuro, las billeteras pueden adoptar una "arquitectura de soporte de modo dual": usar EIP-7702 como un reemplazo liviano en cadenas que no admiten EIP-4337, y continuar confiando en la pila de protocolo completa de EIP-4337 en escenarios que requieren empaquetado fuera de la cadena y agregación multiusuario.

Este mecanismo de modo dual también permitirá que las billeteras admitan modelos de permisos de cuenta más flexibles, mecanismos de degradación y esquemas de reversión en la capa del kernel.

2. Soporte e inspiración para la nueva lógica de billetera como MPC y ZK, y el

mecanismo de contrato de cuenta defendido por EIP-7702 tiene un potencial de integración natural con la popular billetera MPC actual, la billetera ZK, la billetera modular y otras arquitecturas nuevas:

● En el modelo MPC, el comportamiento de la firma ya no se basa en una sola clave privada, sino que es una toma de decisiones colaborativa de múltiples partes. Las firmas generadas a través de la convergencia de EIP-7702 y MPC controlan la lógica del contrato cargada dinámicamente, lo que permite estrategias de ejecución más flexibles.

● La billetera ZK verifica la identidad o autorización del usuario a través de pruebas de conocimiento cero, sin exponer la información de la clave privada. Combinado con EIP-7702, las billeteras ZK pueden inyectar temporalmente contratos lógicos específicos después de que se complete la verificación, para realizar la implementación de comportamientos personalizados después de la computación de privacidad, como la ejecución automática de una determinada lógica solo después de que se cumplan ciertas condiciones de privacidad.

● Las billeteras modulares pueden usar EIP-7702 para desensamblar la lógica de la cuenta en múltiples módulos y cargarlos dinámicamente cuando sea necesario.

Por lo tanto, EIP-7702 proporciona un "contenedor de ejecución" más nativo para las billeteras avanzadas mencionadas anteriormente: se pueden inyectar diferentes lógicas de contrato con la misma dirección de usuario, evitando el problema de dependencia de direcciones en el proceso tradicional de implementación de contratos y eliminando la necesidad de implementación previa, mejorando en gran medida la flexibilidad y la combinación del comportamiento de la cuenta.

3. Implicaciones para los Desarrolladores y Auditores de

impulsará un cambio profundo en el paradigma de desarrollo. Los desarrolladores de contratos ya no tratan simplemente a la persona que llama como una EOA tradicional o una cuenta de contrato fijo, sino que deben adaptarse a un nuevo mecanismo: la identidad de la persona que llama se puede cambiar dinámicamente entre EOA y el estado del contrato durante la transacción, y la lógica de comportamiento de la cuenta ya no se solidifica estáticamente, sino que se puede cambiar de manera flexible según la demanda. Esto requiere que los desarrolladores y auditores:

• introduzcan una verificación de llamadas más estricta y una lógica de juicio de permisos;

• Compruebe si la ruta de llamada se ve afectada por la lógica del contrato dinámico;

• identificar posibles vulnerabilidades que se basan en comportamientos como msg.sender.code.length == 0, isContract(), etc.;

• Clarificar las "dependencias de contexto" de la lógica del contrato, como el control de límites de las llamadas estáticas y las llamadas delegadas;

• En el nivel de la cadena de herramientas, se admite la simulación y el análisis de reversión de escenarios de setCode.

En otras palabras, la seguridad del código ya no es solo un "problema previo a la implementación", sino un "proceso dinámico que debe verificarse durante la invocación y la transacción".

4.

presenta una implementación más ligera, nativa y flexible de la abstracción de cuentas (AA), de modo que la EOA ordinaria puede llevar la lógica del contrato y ejecutarla 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 eso viene un cambio de paradigma en el análisis de seguridad. El enfoque de la auditoría ya no se limita a "si una dirección tiene permisos", sino a "lo que la lógica del contrato llevada 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.