EIP-7702 Después de Pectra: Manual Práctico para Desarrolladores de Aplicaciones Ethereum
· 10 min de lectura
El 7 de mayo de 2025, la actualización Pectra de Ethereum (Prague + Electra) llegó a mainnet. Entre sus cambios más visibles para desarrolladores está EIP-7702, que permite a una cuenta de propiedad externa (EOA) "montar" lógica de smart-contract—sin migrar fondos o cambiar direcciones. Si construyes wallets, dapps, o relayers, esto desbloquea un camino más simple hacia la UX de smart-account.
A continuación hay una guía concisa, orientada a implementación: lo que realmente se lanzó, cómo funciona 7702, cuándo elegirlo sobre ERC-4337 puro, y un andamio de copiar y pegar que puedes adaptar hoy.
Lo Que Realmente Se Lanzó
- EIP-7702 está en el alcance final de Pectra. El meta-EIP para el hard fork Pectra oficialmente lista 7702 entre los cambios incluidos.
- Detalles de activación: Pectra se activó en mainnet en la época 364032 el 7 de mayo de 2025, siguiendo activaciones exitosas en todas las testnets principales.
- Nota de toolchain: Solidity v0.8.30 actualizó su objetivo EVM predeterminado a prague para compatibilidad con Pectra. Necesitarás actualizar tus compiladores y pipelines CI, especialmente si fijas versiones específicas.
EIP-7702—Cómo Funciona (Tuercas y Tornillos)
EIP-7702 introduce un nuevo tipo de transacción y un mecanismo para que una EOA delegue su lógica de ejecución a un smart contract.
- Nuevo Tipo de Transacción (0x04): Una transacción Tipo-4 incluye un nuevo campo llamado
authorization_list. Esta lista contiene una o más tuplas de autorización—(chain_id, address, nonce, y_parity, r, s)—cada una firmada por la clave privada de la EOA. Cuando se procesa esta transacción, el protocolo escribe un indicador de delegación al campo de código de la EOA:0xef0100 || address. A partir de ese momento, cualquier llamada a la EOA se redirige a laaddressespecificada (la implementación), pero ejecutan dentro del contexto de almacenamiento y balance de la EOA. Esta delegación permanece activa hasta que se cambie explícitamente. - Alcance de Chain: Una autorización puede ser específica de chain proporcionando un
chain_id, o puede aplicar a todas las chains sichain_idse establece en0. Esto permite desplegar el mismo contrato de implementación en múltiples redes sin requerir que los usuarios firmen una nueva autorización para cada una. - Revocación: Para revertir una EOA de vuelta a su comportamiento original no programable, simplemente envías otra transacción 7702 donde la
addressde implementación se establece a la dirección cero. Esto limpia el indicador de delegación. - Auto-Patrocinado vs. Relayed: Una EOA puede enviar la transacción Tipo-4 ella misma, o un relayer de terceros puede enviarla en nombre de la EOA. Esto último es común para crear una experiencia de usuario sin gas. El manejo de nonce difiere ligeramente dependiendo del método, así que es importante usar bibliotecas que manejen correctamente esta distinción.
Cambio de Modelo de Seguridad: Debido a que la clave privada EOA original aún existe, siempre puede anular cualquier regla de smart contract (como recuperación social o límites de gasto) enviando una nueva transacción 7702 para cambiar la delegación. Este es un cambio fundamental. Los contratos que dependen de
tx.originpara verificar que una llamada es de una EOA deben ser re-auditados, ya que 7702 puede romper estas suposiciones. Audita tus flujos en consecuencia.
¿7702 o ERC-4337? (Y Cuándo Combinar)
Tanto EIP-7702 como ERC-4337 habilitan la abstracción de cuenta, pero sirven necesidades diferentes.
- Elige EIP-7702 cuando…
- Quieres proporcionar UX de smart-account instantánea para EOAs existentes sin forzar a los usuarios a migrar fondos o cambiar direcciones.
- Necesitas direcciones consistentes entre chains que puedan actualizarse progresivamente con nuevas características.
- Quieres escalonar tu transición a la abstracción de cuenta, comenzando con características simples y agregando complejidad con el tiempo.
- Elige ERC-4337 puro cuando…
- Tu producto requiere programabilidad completa y motores de política complejos (ej. multi-sig, recuperación avanzada) desde el día uno.
- Estás construyendo para nuevos usuarios que no tienen EOAs existentes, haciendo nuevas direcciones de smart-account y la configuración asociada aceptables.
- Combínalos: El patrón más poderoso es usar ambos. Una EOA puede usar una transacción 7702 para designar una implementación de wallet ERC-4337 como su lógica. Esto hace que la EOA se comporte como una cuenta 4337, permitiéndole ser empaquetada, patrocinada por paymasters, y procesada por la infraestructura 4337 existente—todo sin que el usuario necesite una nueva dirección. Este es un camino hacia adelante compatible explícitamente alentado por los autores del EIP.
Andamio 7702 Mínimo Que Puedes Adaptar
Aquí hay un ejemplo práctico de un contrato de implementación y el código del lado cliente para activarlo.
1. Un Contrato de Implementación Pequeño y Auditable
Este código de contrato se ejecutará en el contexto de la EOA una vez designado. Manténlo pequeño, auditable, y considera agregar un mecanismo de actualización.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/// @notice Ejecuta llamadas desde el contexto EOA cuando se designa via EIP-7702.
contract DelegatedAccount {
// Slot de almacenamiento único para evitar colisiones con otros contratos.
bytes32 private constant INIT_SLOT =
0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;
event Initialized(address indexed account);
event Executed(address indexed to, uint256 value, bytes data, bytes result);
modifier onlyEOA() {
// Opcional: agregar verificaciones para restringir quién puede llamar ciertas funciones.
_;
}
function initialize() external payable onlyEOA {
// Establecer una bandera de inicialización única en el almacenamiento de la EOA.
bytes32 slot = INIT_SLOT;
assembly {
if iszero(iszero(sload(slot))) { revert(0, 0) } // Revertir si ya está inicializado
sstore(slot, 1)
}
emit Initialized(address(this));
}
function execute(address to, uint256 value, bytes calldata data)
external
payable
onlyEOA
returns (bytes memory result)
{
(bool ok, bytes memory ret) = to.call{value: value}(data);
require(ok, "CALL_FAILED");
emit Executed(to, value, data, ret);
return ret;
}
function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
external
payable
onlyEOA
{
uint256 n = to.length;
require(n == value.length && n == data.length, "LENGTH_MISMATCH");
for (uint256 i = 0; i < n; i++) {
(bool ok, ) = to[i].call{value: value[i]}(data[i]);
require(ok, "CALL_FAILED");
}
}
}
2. Designar el Contrato en una EOA (tx Tipo-4) con viem
Clientes modernos como viem tienen helpers incorporados para firmar autorizaciones y enviar transacciones Tipo-4. En este ejemplo, una cuenta relayer paga el gas para actualizar una eoa.
import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";
// 1. Definir el relayer (patrocina gas) y la EOA a ser actualizada
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);
const client = createWalletClient({
account: relayer,
chain: sepolia,
transport: http(),
});
// 2. La EOA firma la autorización apuntando al contrato de implementación
const authorization = await client.signAuthorization({
account: eoa,
contractAddress: implementationAddress,
// Si la EOA misma fuera a enviar esto, agregarías: executor: 'self'
});
// 3. El relayer envía una transacción Tipo-4 para establecer el código de la EOA y llamar initialize()
const hash = await client.sendTransaction({
to: eoa.address, // El destino es la EOA misma
authorizationList: [authorization], // El nuevo campo EIP-7702
data: encodeFunctionData({ abi, functionName: "initialize" }),
});
// 4. Ahora, la EOA puede ser controlada via su nueva lógica sin más autorizaciones
// Por ejemplo, para ejecutar una transacción:
// await client.sendTransaction({
// to: eoa.address,
// data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });
3. Revocar Delegación (De Vuelta a EOA Simple)
Para deshacer la actualización, haz que la EOA firme una autorización que designe la dirección cero como la implementación y envía otra transacción Tipo-4. Después, una llamada a eth_getCode(eoa.address) debería retornar bytes vacíos.
Patrones de Integración Que Funcionan en Producción
- Actualizar en Sitio para Usuarios Existentes: En tu dapp, detecta si el usuario está en una red compatible con Pectra. Si es así, muestra un botón opcional "Actualizar Cuenta" que activa la firma de autorización única. Mantén caminos de respaldo (ej.
approve+swapclásico) para usuarios con wallets más antiguas. - Onboarding Sin Gas: Usa un relayer (ya sea tu backend o un servicio) para patrocinar la transacción Tipo-4 inicial. Para transacciones sin gas continuas, enruta operaciones de usuario a través de un bundler ERC-4337 para aprovechar paymasters existentes y mempools públicas.
- Despliegues Cross-Chain: Usa una autorización
chain_id = 0para designar el mismo contrato de implementación en todas las chains. Luego puedes habilitar o deshabilitar características por chain dentro de tu lógica de aplicación. - Observabilidad: Tu backend debería indexar transacciones Tipo-4 y parsear el
authorization_listpara rastrear qué EOAs han sido actualizadas. Después de una transacción, verifica el cambio llamandoeth_getCodey confirmando que el código de la EOA ahora coincide con el indicador de delegación (0xef0100 || implementationAddress).
Modelo de Amenaza y Gotchas (No Te Saltes Esto)
- La Delegación es Persistente: Trata los cambios al contrato de implementación de una EOA con la misma gravedad que una actualización estándar de smart contract. Esto requiere auditorías, comunicación clara al usuario, e idealmente, un flujo opt-in. Nunca empujes nueva lógica a los usuarios silenciosamente.
- Minas Terrestres de
tx.origin: Cualquier lógica que usómsg.sender == tx.originpara asegurar que una llamada vino directamente de una EOA ahora es potencialmente vulnerable. Este patrón debe ser reemplazado con verificaciones más robustas, como firmas EIP-712 o listas de permitidos explícitas. - Matemáticas de Nonce: Cuando una EOA patrocina su propia transacción 7702 (
executor: 'self'), su nonce de autorización y nonce de transacción interactúan de manera específica. Siempre usa una biblioteca que maneje esto correctamente para evitar problemas de replay. - Responsabilidad de UX de Wallet: La especificación EIP-7702 advierte que las dapps no deberían pedir a los usuarios que firmen designaciones arbitrarias. Es responsabilidad del wallet verificar las implementaciones propuestas y asegurar que son seguras. Diseña tu UX para alinearse con este principio de seguridad mediada por wallet.
Cuándo 7702 es una Victoria Clara
- Flujos DEX: Un
approvemulti-paso yswappuede combinarse en un solo clic usando la funciónexecuteBatch. - Juegos y Sesiones: Otorga privilegios similares a session-key por tiempo limitado o alcance sin requerir que el usuario cree y financie una nueva wallet.
- Empresa y Fintech: Habilita transacciones patrocinadas y aplica políticas de gasto personalizadas mientras mantienes la misma dirección corporativa en cada chain para contabilidad e identidad.
- Puentes L2 e Intents: Crea flujos de meta-transacción más suaves con una identidad EOA consistente en diferentes redes.
Estos casos de uso representan los mismos beneficios centrales prometidos por ERC-4337, pero ahora están disponibles para cada EOA existente con solo una autorización única.
Lista de Verificación de Envío
Protocolo
- Asegurar que nodos, SDKs, y proveedores de infraestructura soporten transacciones Tipo-4 y EVM "prague" de Pectra.
- Actualizar indexadores y herramientas de analítica para parsear el campo
authorization_listen nuevas transacciones.
Contratos
- Desarrollar un contrato de implementación mínimo y auditado con características esenciales (ej. batching, revocación).
- Probar a fondo los flujos de revocar y re-designar en testnets antes de desplegar a mainnet.
Clientes
- Actualizar bibliotecas del lado cliente (
viem,ethers, etc.) y probar las funcionessignAuthorizationysendTransaction. - Verificar que tanto los caminos de transacción auto-patrocinados como relayed manejen nonces y replays correctamente.
Seguridad
- Remover todas las suposiciones basadas en
tx.originde tus contratos y reemplazarlas con alternativas más seguras. - Implementar monitoreo post-despliegue para detectar cambios de código inesperados en direcciones de usuario y alertar sobre actividad sospechosa.
Línea de fondo: EIP-7702 proporciona una rampa de baja fricción hacia la UX de smart-account para los millones de EOAs ya en uso. Comienza con una implementación pequeña y auditada, usa un camino relayed para configuración sin gas, haz la revocación clara y fácil, y puedes entregar el 90% de los beneficios de la abstracción de cuenta completa—sin el dolor de la rotación de direcciones y migración de activos.