EIP-7702: delegación de código de una EOA y sus riesgos

Una EOA habitual firma transacciones con una clave privada y no tiene código ejecutable en su propia dirección. EIP-7702 permite que la cuenta apunte a código ya desplegado en otra dirección. Cuando una operación de ejecución llega a la cuenta delegada, el cliente carga el código de destino y lo ejecuta en el contexto de la cuenta. El código está en otra dirección, pero el saldo, el almacenamiento y la identidad de ejecución pertenecen a la cuenta delegante.

Esto no migra la cuenta a una dirección de contrato nueva ni reemplaza la clave privada. La dirección y la clave originales continúan. Una cuenta con un marcador de delegación válido aún puede iniciar transacciones ordinarias. Lo que cambia es que una llamada puede ejecutar lógica de cuenta; el estándar no divide automáticamente una clave en funciones más seguras.

La especificación EIP-7702 define una transacción set-code de tipo 4 y una lista de autorizaciones. La guía de Ethereum.org sobre Pectra y EIP-7702 también la describe como un puntero a código desplegado. Una etiqueta de cartera como «cuenta inteligente» no revela las reglas de validación, recuperación ni el código delegado que realmente se usa.

Distingue quién conserva la clave privada de quién desplegó o controla el código delegado. Comprueba si el código puede cambiarse, quién puede actualizarlo y qué puede hacer con los activos y el almacenamiento de la cuenta. El EIP no resuelve por sí solo estas cuestiones de seguridad.

La transacción set-code se identifica por el byte de tipo 0x04. Incluye los campos habituales de la transacción externa y una lista de autorizaciones. Cada tupla contiene un ID de cadena, una dirección de código, el nonce de la cuenta autorizante y una firma que aprueba esa tupla. La cuenta autorizante firma la autorización; el remitente firma por separado la transacción externa. Pueden ser la misma cuenta o cuentas distintas.

Como el remitente puede incluir una autorización válida de otra persona, comprueba qué está aprobando exactamente la cuenta autorizante. El ID de cadena normalmente limita la autorización a una cadena; el valor 0 permite un alcance más amplio entre cadenas compatibles. Eso no garantiza que la misma autorización vaya a funcionar en todas partes: la red debe admitir EIP-7702 y el nonce y estado de la cuenta deben coincidir. Aun así, un alcance amplio puede permitir que la firma se use en otra cadena compatible.

Una tupla puede omitirse si el nonce no coincide o falla otra validación. Un solo carácter incorrecto en la dirección objetivo puede apuntar a otro código. Compara la red, la cuenta y la dirección completa con la vista previa de firma y un explorador fiable. Un aviso vago sobre «actualizar» o «ahorrar gas» no explica qué permiso se concede.

La documentación de transacciones de Ethereum.org señala que las transacciones de tipo 4 incluyen una lista de autorizaciones. La transacción externa sigue teniendo condiciones de gas y una parte que paga la comisión; presentarla desde otra dirección no hace que la ejecución sea gratis. El tipo 4 tampoco equivale a UserOperations y paymasters de ERC-4337, que se explican aparte en la guía de cuentas inteligentes.

Tras una autorización válida, el código de la EOA recibe un marcador compuesto por el prefijo 0xef0100 y la dirección de destino. El cliente reconoce el marcador y carga el código de esa dirección durante la ejecución. Por ello, la dirección de cuenta mostrada en la cartera puede diferir de la dirección cuyo código se ejecuta. Revisa ambas.

El código se obtiene de la cadena actual donde se usa la delegación. Una dirección de destino en otra red no hace que se ejecute aquí el código de aquella red. La misma dirección de 20 bytes puede tener código distinto o ninguno según la cadena. Comprueba el despliegue y el código verificado en cada red, sin confiar solo en nombres, iconos o direcciones coincidentes.

El código delegado se ejecuta en el contexto de la cuenta autorizante y puede usar su almacenamiento. Según su lógica, podría enviar ETH o tokens, llamar a contratos externos y cambiar valores guardados. EIP-7702 no añade automáticamente reglas como «solo este token» o «una llamada al día». Esas restricciones deben implementarse correctamente en el sistema delegado.

Si el destino es un proxy o puede actualizarse, el código que revisas hoy quizá no sea el de mañana. Comprueba quién administra el proxy, los permisos para cambiar la implementación, los retrasos y el proceso público de actualización. Un administrador desconocido es un riesgo de confianza mientras la delegación siga activa.

El protocolo no restringe por sí solo el código delegado a un conjunto reducido de permisos. Un fallo de validación puede permitir transferir activos, aprobar tokens, realizar llamadas externas arbitrarias o cambiar el almacenamiento. Una insignia de auditoría no prueba que la dirección y versión exactas de la solicitud coincidan con el código y el alcance auditados.

Las consideraciones de seguridad del EIP advierten que la lógica delegada puede tener que vincular a la firma la protección contra repetición, el destino y los datos de llamada, el valor de ETH y las condiciones de gas. Si faltan campos, un patrocinador u otra parte podría enviar una solicitud distinta de la intención del firmante o provocar un fallo. Revisa qué llamadas valida el código y si un tercero puede eludir esas comprobaciones.

Por ejemplo, una cartera puede agrupar la aprobación de un token y un intercambio en una sola confirmación. Comprueba si ambas operaciones se revierten juntas, si la aprobación se limita a la cantidad necesaria y si luego puede reducirse. Si un paymaster cubre las comisiones, revisa quién paga y en qué condiciones. Lee la vista previa completa para que la etiqueta «gratis» no oculte las llamadas o permisos aprobados.

La seguridad depende de los permisos reales y del control de actualización, no solo de la reputación del destino. Comprueba los contratos que puede llamar la cuenta, cómo valida firmas, quién tiene poderes de emergencia o actualización y si el código desplegado coincide con el código fuente verificado. Si la dirección es desconocida o viene de un mensaje no solicitado, pausa y consulta la documentación oficial de la cartera.

EIP-7702 procesa la lista de autorizaciones antes de ejecutar la transacción externa. La especificación indica que los marcadores de delegación ya procesados no se revierten si la ejecución posterior falla o hace revert. No des por hecho que todo el estado vuelve al inicio porque el recibo muestre un fallo. Comprueba por separado el recibo y el código actual de la cuenta.

Esto importa con llamadas agrupadas, inicialización y transacciones presentadas por un patrocinador. La autorización puede ser válida aunque falle una llamada posterior: la delegación puede permanecer activa y, a la vez, la configuración o acción de la aplicación puede quedar incompleta. Si la propia tupla no era válida, quizá no se aplicó. Revisa la transacción de tipo 4, la cuenta autorizante, el nonce y el puntero de código actual en vez de confiar en una etiqueta de éxito o fallo.

El estado «fallido» de una cartera puede resumir un problema al procesar la autorización, una llamada externa u otra fase de ejecución. Si no está claro, compara el hash de transacción, la cuenta y el nonce firmantes y el código de la cuenta mediante una herramienta fiable de la cadena. Al reintentar puede haber cambiado el nonce y la autorización anterior dejar de servir; comprueba si ya hubo una presentación duplicada o procesada.

Esta diferencia importa si el usuario espera que todos los pasos de una confirmación se deshagan juntos. Probar la función con una cuenta de prueba o de poco valor ayuda a observar su comportamiento, pero no demuestra que el código sea seguro. Antes de usar una cuenta con fondos, asegúrate de poder revisar el alcance de cadena, destino, datos y estado que podría quedar tras un fallo.

Una autorización nueva puede apuntar a otro código. El EIP también define borrar el marcador mediante una autorización a la dirección nula, dejando vacío el código de la cuenta. Esto elimina el marcador de delegación; no es un comando universal de limpieza o recuperación.

Si el código delegado guardó datos en el almacenamiento de la cuenta, borrar el marcador no los elimina automáticamente. Una autorización de token guardada por un contrato ERC-20 también es un estado aparte. Puede que tengas que revocar una autorización ilimitada en el contrato del token. Borrar la delegación no deshace tokens ya enviados, cambios en contratos externos ni transacciones completadas.

El nuevo código puede reutilizar el mismo almacenamiento de la cuenta; dos versiones que interpreten de forma distinta una posición pueden entrar en conflicto. Revisa el diseño de almacenamiento y la migración antes de cambiar. Sin compatibilidad, una actualización puede bloquear la cuenta o hacer que el estado anterior se comporte de forma inesperada; el protocolo no incluye un borrado general de almacenamiento.

Elige la respuesta según el problema. Si sospechas de código malicioso, revisa rápidamente un flujo de borrado compatible con tu cartera o un reemplazo confiable. Para autorizaciones de tokens, consulta la guía de aprobaciones y allowances de tokens. Si se expuso la clave o la frase semilla, borrar el código no recupera esa clave; sigue la guía de recuperación de carteras y evalúa mover los activos a una cuenta segura.

Primero confirma en la documentación oficial de la cartera que admite EIP-7702 en la red elegida. Compara red e ID de cadena, cuenta, dirección exacta de destino, verificación del código y cualquier administrador de proxy o actualización. Comprende si el ID 0 amplía el alcance a varias cadenas o si está limitado a una. Si la pantalla de firma no es clara, busca documentación de la cartera que explique los datos de autorización antes de aprobar.

Después distingue la firma de autorización del remitente de la transacción externa y de quien paga la comisión. Que otra dirección presente la transacción no cambia lo que firmó la cuenta autorizante. El patrocinio tampoco hace que el código delegado sea seguro ni limita sus llamadas. Compara el tipo de transacción, la lista de autorizaciones, los destinos y datos de llamada y cualquier cambio de allowance con la vista previa.

Si ya hay una delegación activa, no te limites a comprobar si la transacción tuvo éxito. Inspecciona el marcador actual de la cuenta y la dirección del código. Si no coincide con lo esperado, pausa otras llamadas y aprobaciones; evita repetir autorizaciones de reemplazo aleatorias. Para comisiones externas, consulta la guía de tarifas de gas de Ethereum; para nonce y transacciones pendientes de una EOA, la guía de transacciones pendientes.

EIP-7702 estandariza un formato de transacción que conecta una EOA con código desplegado. La agrupación de llamadas, las comisiones patrocinadas, los permisos de sesión y la recuperación pueden construirse sobre ese mecanismo, pero dependen de código y servicios concretos. No todas las carteras o delegaciones usan las mismas reglas ni admiten todas las funciones.

Ver «cuenta inteligente» en una interfaz no indica quién tiene la clave, quién puede actualizar el código o quién controla la recuperación. Revisa la implementación y configuración reales. Si la cartera no admite la cadena o función, puede mostrar la delegación de forma distinta a la esperada. Confirma la compatibilidad antes de cambiar una cuenta con fondos.

El anuncio de Pectra para la red principal de Ethereum Foundation describe cómo las EOA apuntan a código delegado y luego pueden reemplazar o revocar esa autorización. Las capacidades del estándar y la forma en que una cartera concreta las presenta son cuestiones distintas. UserOperations y paymasters de ERC-4337 son otro camino de abstracción de cuentas, no la autorización de tipo 4.

Esta guía explica la mecánica de las cuentas y no recomienda una cartera ni un delegado. Define primero el objetivo —agrupar acciones, patrocinar comisiones, usar permisos de sesión o recuperar acceso— y luego identifica el código y servicio que lo implementan y la confianza que requieren. La guía de cuentas inteligentes y ERC-4337 explica mecanismos relacionados.