¿Qué es la delegación EIP-7702? Explicación de las cuentas inteligentes de EOA

La delegación EIP-7702 permite que una cuenta de propiedad externa (EOA) delegue su lógica de ejecución en otro contrato sin cambiar de dirección ni ceder su clave privada. El campo de código se establece en 0xef0100 más la dirección del delegado, y las llamadas posteriores ejecutan ese código dentro del contexto de la propia EOA, mientras que el saldo, el nonce y el almacenamiento siguen perteneciendo a la cuenta.

Está dirigida a lectores que ya conocen las billeteras de autocustodia y el modelo de cuentas de la EVM. Ethereum ha tenido durante mucho tiempo dos tipos de cuentas: las EOA controladas por claves y las cuentas de contrato con código, y solo las segundas podían incluir lógica de validación personalizada, a costa de una dirección nueva. Se implementó con la actualización Pectra y trasladó la validación personalizada de abrir una cuenta nueva a escribir código en una dirección ya utilizada.

Una tupla de autorización contiene seis campos, y el designador de delegación ocupa 23 bytes: un prefijo de tres bytes más una dirección de 20 bytes. La ruta de escritura, los límites de las nuevas capacidades, la diferencia con ERC-4337 y la fiabilidad del delegado determinan cuánto control conserva la cuenta tras esa firma.

Puntos clave:

• La delegación EIP-7702 mantiene la dirección, la clave privada, el saldo y el nonce, y dirige únicamente el campo de código a un contrato delegado.

• Una transacción de tipo 0x04 escribe la delegación mediante una tupla de autorización. El mensaje firmado no contiene campos de comisión y el remitente no tiene que ser el propietario.

• Una delegación no caduca. La revocación elimina el código, pero no el almacenamiento, las aprobaciones de tokens ni las firmas Permit.

• Un delegado sin receive() ni fallback() hace que las transferencias simples de ETH se reviertan, y tx.origin ya no implica que una cuenta no tenga código.

• ERC-4337 crea un sistema de cuentas independiente, mientras que EIP-7702 añade código a EOA existentes, por lo que ambos pueden combinarse.

¿Qué cambia la delegación EIP-7702 en una cuenta de propiedad externa?

Ethereum tiene dos tipos de cuentas: una cuenta de propiedad externa, controlada por una clave privada, y una cuenta de contrato, que contiene código.

Con EIP-7702, lo que cambia es el campo de código, no la identidad de la cuenta, porque una EOA puede apuntar temporalmente a código de contrato sin cambiar su dirección. La dirección, la clave privada, el saldo y el nonce permanecen donde estaban. La diferencia es que la dirección ahora contiene código ejecutable procedente de otro contrato desplegado.

El campo contiene un designador de delegación de 23 bytes: el prefijo 0xef0100 más una dirección de 20 bytes. Cuando una llamada se dirige a esa EOA, la EVM lee el designador y carga el código del delegado, de modo que la cuenta puede comportarse como una cuenta inteligente mientras la clave privada mantiene el control y el remitente, el saldo y el almacenamiento se leen como los de la EOA.

El delegado no puede acceder a su propio estado. Su lógica de ejecución se carga desde el contrato objetivo, mientras que el almacenamiento y el contexto del remitente siguen siendo los de la EOA, y las escrituras siguen esa misma lógica en un almacenamiento que la EOA nunca utilizó.

Las firmas siguen procediendo de la clave privada original, por lo que la cuenta no se convierte en una multisig. El diseño es un paso hacia la abstracción de cuentas, incluida su variante nativa, y no un cambio de tipo de cuenta.

Tipo 0x04 y tuplas de autorización: cómo llega la delegación al código de contrato

La escritura requiere un nuevo tipo de transacción, 0x04, cuyo cuerpo contiene una lista de autorizaciones. Cada tupla la firma el titular de la cuenta, mientras que cualquier dirección puede enviar y pagar la propia transacción, y la autorización especifica qué código permite ejecutar la cuenta.

La tupla es [chain_id, address, nonce, y_parity, r, s], y el mensaje firmado es keccak(0x05 || rlp([chain_id, address, nonce])). La especificación de EIP-7702 utiliza el prefijo 0x05 para separar las firmas de autorización de las firmas de transacciones ordinarias, y el mensaje no contiene campos de gas ni de comisión.

Lo que se firma es la dirección a la que debe apuntar el código, no una transacción concreta, por lo que algunos sistemas vinculan la autorización a una intención. La cuenta también puede firmar una vez sin conexión mientras un patrocinador adelanta el gas.

La validación del nodo se realiza en seis pasos, y la vinculación con el nonce hace que una autorización solo pueda utilizarse una vez, con el nonce correspondiente.

La lista de autorizaciones se incluye en el cuerpo de la transacción del mismo modo que una lista de acceso amplía el formato de transacción: el ID de cadena es 0 o coincide con la cadena local (0 significa válido en cualquier cadena), el nonce es inferior a 2^64-1, ecrecover verifica la firma, el código de la cuenta está vacío o ya delegado, el nonce coincide con el valor actual, y el código se escribe como 0xef0100 || address mientras se incrementa el nonce.

La revocación sigue la misma ruta con la dirección establecida en cero, lo que elimina el hash del código sin realizar un cambio de estado permanente en la EOA subyacente.

¿Qué propiedades de la cuenta no cambian?

Cuatro propiedades permanecen como estaban y solo cambian el código y el almacenamiento: el código pasa de 0x al designador, las ranuras de almacenamiento no utilizadas empiezan a recibir escrituras y esos valores sobreviven a la revocación. La especificación enumera por separado tres invariantes en cadena que dejan de cumplirse, relacionadas con el saldo, el nonce y la identidad del llamador. La sección de riesgos las aborda.

1. Dirección: no cambia, por lo que el historial, las aprobaciones de tokens y los registros de nombres siguen apuntando a una misma dirección.

2. Clave privada: no cambia y firma tanto transacciones ordinarias como una nueva autorización que sobrescribe o revoca la delegación.

3. Saldo: no cambia, porque la delegación no mueve activos y la cuenta sigue manteniéndolos directamente.

4. Nonce: sigue incrementándose, ya que la autorización consume uno, lo que impide la repetición de la misma firma.

¿Una cuenta delegada puede seguir recibiendo ETH normalmente?

No de forma predeterminada. Cuando la cuenta contiene código, una transferencia simple de ETH entra en la ruta de ejecución del código. Si el delegado no implementa receive() ni fallback(), la transferencia se revierte y los fondos regresan al remitente.

Este problema puede producirse en flujos de pago habituales, como retiros de exchanges, nóminas y airdrops. El software de la billetera normalmente solo informa de un fallo, no de que el delegado es la causa. Antes de firmar, confirma que el objetivo implementa una función receive, o dirige los pagos entrantes mediante una llamada que incluya calldata. El software de la billetera debería mostrar esta causa con mayor claridad a los usuarios.

Figura 1. La ruta de escritura de EIP-7702: la EOA firma la tupla de autorización, una transacción de tipo 0x04 establece el código en 0xef0100 más la dirección del delegado, y las llamadas posteriores ejecutan ese código en el contexto de la EOA.

¿Qué puede hacer una cuenta delegada? Agrupación, patrocinio de gas y recuperación

La delegación transforma una EOA de una cuenta que solo puede firmar transacciones en una cuenta que se comporta como una cuenta inteligente para usuarios cotidianos, con las ventajas más claras en la agrupación, el patrocinio de gas y la recuperación basada en reglas.

La agrupación es la ventaja más concreta: aprobar e intercambiar pueden realizarse en una sola transacción. Un patrocinador también puede facilitar la incorporación o la agrupación al ayudar a completar varios pasos en segundo plano en el momento adecuado, de modo que una única firma liquida una vez y no queda ninguna aprobación sin utilizar entre medias.

El patrocinio de gas surge de separar la firma del remitente: un tercero paga, la cuenta no necesita ETH por adelantado y, con un pagador ERC-4337, el coste puede recaer en la aplicación. Esto también significa que algunas aplicaciones pueden cubrir el gas o facilitar la incorporación gestionándolo en segundo plano, pero los desarrolladores deben evitar solicitar una delegación cuando el usuario simplemente está solicitando otra función.

La recuperación y las claves de sesión se basan en que el delegado verifique por sí mismo las firmas, por ejemplo, con una passkey, un conjunto de guardianes o límites de gasto en lugar de una sola clave. El delegado también puede aplicar funciones similares a políticas en torno a las transferencias o al uso de firmantes.

El límite es claro: quien tenga la clave privada siempre puede firmar una autorización nueva que sobrescriba la delegación, por lo que la recuperación aquí es más débil que en una cuenta inteligente nativa y solo reduce el coste de perder una clave.

Una delegación no caduca. Permanece activa hasta que una nueva autorización la sobrescriba o una dirección cero la revoque, por lo que el permiso es duradero y requiere una gestión activa. Desde el punto de vista de la seguridad, revisa el alcance de lo que el código delegado puede acceder y controlar.

¿En qué se diferencia la delegación EIP-7702 de ERC-4337 y la abstracción de cuentas?

EIP-7702 añade código a una EOA existente, mientras que ERC-4337 crea un sistema de cuentas independiente. Como enfoques complementarios de la abstracción de cuentas, ambos pueden combinarse en lugar de sustituirse.

ERC-4337 parte de un contrato recién desplegado, por lo que los activos y las aprobaciones se trasladan. 7702 parte de la dirección original y añade código, evitando la migración al permitir que las cuentas existentes utilicen el comportamiento de contratos inteligentes sin desplegar primero una billetera independiente.

Juntos permiten que una cuenta 7702 actúe como implementación de cuenta para ERC-4337, y los desarrolladores pueden crear flujos compatibles con 4337 sobre una cuenta delegada mediante 7702. Esto reintroduce una condición de carrera de inicialización: entre el momento en que se registra la delegación y el momento en que finaliza la inicialización, cualquiera puede llamar al inicializador y establecerse como propietario.

Existen dos soluciones: initWithSig, que vincula la firma a los argumentos de inicialización, o restringir la inicialización a EntryPoint.

¿Es fiable el delegado? Cómo verificar que es inmutable

Delega únicamente en contratos inmutables desplegados mediante initcode CREATE2 estándar. El mecanismo de verificación debe priorizar objetivos sin ruta de actualización, ya que los contratos proxy, actualizables y con una ruta de autodestrucción son objetivos poco adecuados.

La delegación concede derechos de ejecución a ese código y el titular no recibe ninguna notificación de cambios. Un objetivo actualizable implica que quien lo actualiza tiene poder de ejecución sobre todas las cuentas que delegan en él. Uno inmutable, al menos, fija de antemano la superficie de ataque, donde puede auditarse. La exposición de seguridad aumenta si el código delegado puede cambiar tras la autorización.

Tres criterios, código inmutable, sin proxy y despliegue reproducible, se convierten en cuatro comprobaciones en un explorador de bloques que las billeteras y los desarrolladores deben verificar antes de conceder una delegación:

1. Lee las ranuras de implementación y administrador: una ranura EIP-1967 distinta de cero que empiece por 0x360894 indica un proxy o una ruta de actualización.

2. Compara el bytecode en cadena con el código fuente verificado y confirma que los argumentos del constructor y el bytecode desplegado coinciden.

3. Busca selfdestruct y delegatecall, y confirma que ninguna rama puede eliminar el código ni redirigir la ejecución a otro lugar.

4. Vuelve a calcular la dirección CREATE2 a partir de initcode y salt, y confirma que el desplegador no puede sustituirlo por otro contrato en una dirección diferente.

¿Cuáles son los riesgos de la delegación EIP-7702?

El riesgo se concentra en tres áreas: errores en el delegado, la semántica de cuenta que modifica la delegación y la irreversibilidad de una firma de una sola vez. Es una compensación de seguridad además de una mejora funcional, y la principal preocupación es el amplio alcance del código que puede controlar la cuenta una vez concedida la autorización.

La fila de tx.origin tiene el mayor alcance. Una cuenta delegada puede ejecutar código dentro de la pila de llamadas, por lo que msg.sender == tx.origin ya no significa que el llamador no tenga código, y las protecciones basadas en esa comparación dejan de proteger. Los bloqueos nonReentrant o de almacenamiento transitorio no dependen de la identidad del llamador.

En la práctica, si las billeteras no muestran claramente los detalles de la autorización, los usuarios pueden aprobar acceso que no pretendían revisar. La guía de EIP-7702 en la documentación de Pectra lo enumera por separado.

Un chain_id de 0 amplía la tercera categoría: la misma firma es válida en otras cadenas EVM, por lo que una cuenta puede recibir código en una cadena que su titular nunca consideró. Los dispositivos de firma suelen omitir el ID de cadena, que es donde se encuentra la compensación de habilitar la delegación en una billetera fría.

¿Cómo comprobar y revocar una delegación?

La comprobación requiere una sola lectura de código: si eth_getCode devuelve 0x, no hay delegación. Si devuelve 23 bytes que empiezan por 0xef0100, la cuenta es una cuenta de propiedad externa delegada. Cualquier otro bytecode significa que es una cuenta de contrato.

La delegación es un estado de la cadena, por lo que una dirección puede estar delegada en una cadena y no modificada en otra, y cada cadena requiere su propia comprobación. Los últimos 20 bytes corresponden al delegado, y una billetera o plataforma puede automatizar estas comprobaciones entre cadenas y mantener registros de las comprobaciones o cambios de estado para auditoría y supervisión.

Para una revisión manual rápida, comprobar y revocar una delegación explica el procedimiento.

La revocación se realiza dentro de la billetera: firma una nueva autorización con el campo de dirección establecido en cero y el nodo elimina el hash del código, devolviendo la cuenta a una EOA simple. Las dApps externas generalmente no pueden hacerlo en nombre del titular y, si los equipos de billeteras admiten flujos de revocación, cualquier solicitud para actuar en nombre de un titular debe seguir requiriendo la aprobación del propio titular.

La revocación elimina el código delegado, pero no elimina las aprobaciones previas de contratos inteligentes ni otros accesos ya concedidos a aplicaciones. Las notas sobre la delegación de EOA de OpenZeppelin establecen este límite.

Resumen

EIP-7702 aporta programabilidad a una EOA con una firma: la dirección y la clave se mantienen, el campo de código apunta a un delegado y la ejecución se realiza en el propio contexto de la cuenta.

El coste es una semántica modificada y un permiso duradero: los pagos entrantes simples pueden fallar, tx.origin deja de ser una EOA, una firma con chain_id de 0 puede utilizarse entre cadenas y la revocación solo elimina el código.

Preguntas frecuentes

¿EIP-7702 convierte mi billetera en una multisig?

No. La delegación solo cambia el campo de código y las firmas siguen procediendo de la clave privada original, por lo que el titular de una sola clave puede realizar transacciones de forma independiente y sobrescribir la delegación con una nueva autorización. Un delegado que requiera varias firmas también puede ser eludido por esa clave.

¿Cómo puedo comprobar si mi billetera está delegada mediante EIP-7702?

Llama a eth_getCode en la dirección. Un resultado de 0x significa que no hay delegación. 23 bytes que empiezan por 0xef0100 significan que está delegada, y los últimos 20 bytes identifican al delegado. Cualquier otro bytecode significa que es una cuenta de contrato.

La delegación se registra por cadena, así que comprueba cada una. Las billeteras o los sistemas de administración pueden conservar registros de esas comprobaciones para su revisión. En resumen, la respuesta puede variar únicamente en los detalles de la interfaz entre billeteras, pero la comprobación de código subyacente es la misma.

¿Cómo revoco una delegación EIP-7702?

Firma una nueva autorización con el campo de dirección establecido en cero desde la billetera, y el nodo elimina el hash del código cuando se supera la validación. Solo el titular de la cuenta puede firmarla y las dApps externas normalmente no pueden actuar en su nombre.

¿Caduca una delegación y sobreviven las aprobaciones de tokens anteriores a la revocación?

Una delegación no caduca y permanece activa hasta que se sobrescribe o revoca. La revocación solo elimina el código y deja intactos el almacenamiento, las aprobaciones ERC-20 y las firmas Permit.

Mi clave nunca se filtró. ¿Una autorización EIP-7702 maliciosa aún puede vaciar la cuenta?

Sí. La firma es una transferencia de autoridad: con ella, un atacante puede escribir una delegación que apunte a un contrato malicioso y obtener acceso amplio a la cuenta, moviendo activos sin llegar a tocar la clave privada.

Comprueba el ID de cadena y la dirección de destino en la tupla, y firma únicamente para contratos inmutables. Los equipos de billeteras también deben verificar la función del firmante antes de conceder aprobaciones internas relacionadas con la delegación en nombre de una organización.