EIP-3074 vs EIP-7702 vs ERC-4337: guía completa para desarrolladores
Escrito por Usman Asim
El ecosistema de wallets de Ethereum evoluciona constantemente, avanzando hacia un futuro programable, con EIP-7702 como un paso clave hacia la abstracción de cuentas completa (ERC-4337). Pero para entender por qué 7702 está en posición de transformar cómo interactuamos con Ethereum a través de Smart Wallets, debemos reconocer a EIP-3074, una propuesta que sentó las bases fundamentales para que 7702 sea lo que es.
Si eres un desarrollador construyendo apps, probablemente te has enfrentado a los límites de las Externally Owned Accounts (EOAs), las wallets tradicionales de Ethereum controladas por claves privadas. EIP-3074 introdujo una forma de que las EOAs delegaran control a smart contracts (invokers), habilitando funciones como el patrocinio de gas y las transacciones en lote. EIP-7702 lleva esto más lejos, ofreciendo un camino más simple y seguro hacia la abstracción de cuentas.
Para los desarrolladores, este concepto simplifica agregar funcionalidad avanzada a las apps mientras se mantiene a los usuarios en EOAs conocidas. Para los usuarios, significa una experiencia más fluida; piensa en pagos de gas por terceros o en ejecutar múltiples operaciones DeFi con un solo clic.
En esta guía, explicaremos la mecánica de 3074 como contexto, mostraremos los avances de 7702 con código, y compararemos ambos con ERC-4337. Empecemos y entremos en los detalles técnicos.
El problema que EIP-3074 buscaba resolver
Las EOAs son simples: firman transacciones con una clave privada y las envían a la red de Ethereum. Pero tienen limitaciones. No pueden ejecutar código, agrupar acciones en lote, ni recuperar claves perdidas de forma nativa. Las smart contract wallets (habilitadas por ERC-4337) ofrecen más flexibilidad, pero requieren que los usuarios gestionen nuevas direcciones y suelen implicar costos de gas más altos. EIP-3074 propuso una solución al introducir dos opcodes de EVM: AUTH y AUTHCALL, que permiten a las EOAs delegar control a contratos invoker, agregando funciones similares a las de smart contracts sin necesidad de migrar de wallet.
EIP-3074 fue una prueba de concepto que dio forma a la hoja de ruta de abstracción de cuentas de Ethereum: de EOAs a Smart EOAs (EIP-7702) y finalmente a Smart Wallets completas (ERC-4337). Exploremos la mecánica de 3074 para entender cómo abrió el camino.
Las smart wallets te ayudan a hacer crecer tu app con una UX onchain fluida.
Los componentes principales de EIP-3074: la base para 7702
EIP-3074 gira en torno a tres piezas: el opcode AUTH, el opcode AUTHCALL, y los contratos invoker. Vale la pena entenderlos porque 7702 se construye sobre sus principios.
1. El opcode auth
El opcode AUTH (hex 0xf6) verifica una firma ECDSA de una EOA, comprobando que ha autorizado a un invoker específico a actuar en su nombre. La EOA firma un mensaje que contiene la dirección del invoker y un commitment (un hash de las acciones a realizar). Si la firma es válida, la EVM establece un contexto autorizado.
Aquí hay un fragmento en Solidity que imita la verificación de firma de AUTH:
*// Invoker contract: Verify EOA authorization*
function authenticate(bytes memory signature, address eoa, bytes32 commitment) public pure returns (bool) {
*// Hash the message the EOA signed*
bytes32 messageHash = keccak256(abi.encodePacked(eoa, commitment));
*// Recover the signer from the signature*
address signer = recoverSigner(messageHash, signature);
*// Check if the signer matches the EOA*
return signer == eoa;
}
_// Helper function to recover signer_
function recoverSigner(bytes32 messageHash, bytes memory signature) internal pure returns (address) {
bytes32 r; bytes32 s; uint8 v;
assembly {
r := mload(add(signature, 32))
s := mload(add(signature, 64))
v := byte(0, mload(add(signature, 96)))
}
return ecrecover(messageHash, v, r, s);
}Este código valida la intención de la EOA de delegar control. Una vez autorizado, el invoker puede actuar como la EOA.
2. El opcode authcall
AUTHCALL (hex 0xf7) permite que el invoker ejecute transacciones como la EOA, usando la dirección de la EOA como el caller mientras el invoker puede pagar el gas. Esto habilitó el patrocinio de gas y el batching en 3074.
Así es como podrías usar AUTHCALL en assembly:
// Invoker contract: Execute a call as the EOA
function executeAsEOA(address target, bytes memory data) public {
// Assumes prior AUTH verification
assembly {
// AUTHCALL: gas, target, value, argsOffset, argsSize, retOffset, retSize
let success := authcall(gas(), target, 0, add(data, 32), mload(data), 0, 0)
if iszero(success) {
revert(0, 0)
}
}
}Este fragmento llama a un contrato objetivo (por ejemplo, un protocolo DeFi) como la EOA. La función gas\(\) asigna el gas restante, y AUTHCALL asegura que la acción refleje la identidad de la EOA.
3. Contratos invoker
Los invokers son smart contracts a los que las EOAs delegan. Los invokers de EIP-3074 eran persistentes, lo que generaba preocupaciones de seguridad que 7702 aborda. Aquí hay un invoker estilo 3074 para patrocinio de gas y batching:
⚠️ Nota de seguridad: Los invokers deben auditarse y construirse con cuidado. Un invoker defectuoso puede hacer mal uso de firmas o repetir acciones.
// EIP-3074 invoker for gas sponsorship and batching
contract LegacyInvoker {
address public authorizedEOA;
// Set authorized EOA
function setAuthorizedEOA(address eoa, bytes memory signature, bytes32 commitment) external {
require(authenticate(signature, eoa, commitment), "Invalid signature");
authorizedEOA = eoa;
}
// Execute batch transactions, optionally sponsored
function executeBatch(
address[] memory targets,
bytes[] memory datas,
uint256[] memory values,
bool sponsored
) external payable {
require(msg.sender == authorizedEOA || sponsored, "Not authorized");
if (sponsored) {
require(msg.value >= estimateGas(targets, datas), "Insufficient gas funds");
}
for (uint i = 0; i < targets.length; i++) {
assembly {
let success := authcall(
gas(),
mload(add(targets, add(32, mul(i, 32)))),
mload(add(values, add(32, mul(i, 32)))),
add(mload(add(datas, add(32, mul(i, 32)))), 32),
mload(mload(add(datas, add(32, mul(i, 32))))),
0,
0
)
if iszero(success) { revert(0, 0) }
}
}
}
// Estimate gas for sponsored transactions
function estimateGas(address[] memory targets, bytes[] memory datas) internal view returns (uint256) {
uint256 totalGas = 21000; // Base transaction gas
for (uint i = 0; i < targets.length; i++) {
totalGas += 10000; // Approximate per call
}
return totalGas;
}
}💡 Consejo de implementación: Los invokers de EIP-3074 requerían auditorías para prevenir la repetición de firmas. EIP-7702 evita los invokers persistentes, reduciendo los riesgos.
EIP-3074 vs. EIP-7702: por qué gana 7702
EIP-3074 fue un experimento audaz, pero EIP-7702 y ERC-4337 son el futuro. Aquí una comparación rápida:
EIP-3074 vs. ERC-4337
- EIP-3074: Agregó
AUTHyAUTHCALLa la EVM, funcionaba con EOAs pero requería invokers. - ERC-4337: Sin cambios de protocolo; usa un mempool separado y bundlers para smart contract wallets.
- Conclusión: 3074 era más simple para las EOAs, pero la flexibilidad de 4337 la hace ideal para la abstracción completa.
EIP-3074 vs. EIP-7702
- EIP-3074: Los invokers persistentes representaban riesgos de seguridad y carecían de compatibilidad futura.
- EIP-7702: Habilita funciones de smart contract por transacción, alineándose con 4337.
- Conclusión: 7702 refina las ideas de 3074, ofreciendo un camino más seguro y escalable, más alineado con la hoja de ruta de AA de Ethereum.
EIP-3074 introdujo ideas que 7702 perfecciona, dando lugar a un ecosistema alineado con la hoja de ruta de Ethereum para la abstracción de cuentas completa.
- Patrocinio de gas: las apps pagan el gas por los usuarios, reduciendo las barreras de entrada.
- Transacciones en lote: los usuarios combinan acciones (por ejemplo, swaps de tokens y staking) en una sola transacción.
- Mecanismos de recuperación: los usuarios recuperan EOAs perdidas a través de delegados de confianza.
Empieza a construir con smart wallets
EIP-3074 abrió el camino para que EIP-7702 pudiera avanzar. Mientras 3074 introdujo ideas innovadoras para la delegación de EOAs, 7702 las refina en una solución más segura y escalable, acercándonos al objetivo final de abstracción de cuentas de Ethereum junto con ERC-4337. EIP-7702 forma parte de la actualización Pectra de Ethereum, con testnets activas desde abril de 2025. La activación en mainnet está vigente desde el 7 de mayo de 2025, pendiente de la adopción por parte de los clientes (Geth, Nethermind, etc.). Mientras tanto, ERC-4337 ya está en funcionamiento, ofreciendo abstracción de cuentas completa para smart contract wallets.
Ya sea que estés optimizando la UX de una dApp o diseñando experiencias de usuario fluidas, ahora es el momento de explorar 7702 y 4337. Explora la documentación y empieza a construir!
Contáctanos cuando quieras si tienes preguntas. Estamos aquí para hablar sobre estrategia de integración, preguntas de implementación técnica, trade-offs, y ayudarte a encontrar la mejor solución para tu app. ¡A construir!
Preguntas frecuentes
¿Qué es EIP-3074?
EIP-3074 fue una propuesta que introdujo dos opcodes de EVM (AUTH y AUTHCALL) para permitir que las EOAs delegaran control a smart contracts llamados invokers, habilitando funciones como el patrocinio de gas y las transacciones en lote sin requerir que los usuarios migraran a nuevas wallets.
¿Cómo mejora EIP-7702 a EIP-3074?
EIP-7702 refina los conceptos de EIP-3074 al habilitar funciones de smart contract por transacción en lugar de invokers persistentes, ofreciendo un camino más seguro y escalable que aborda los riesgos de seguridad asociados con el modelo de delegación persistente de 3074.
¿Cuál es la diferencia entre EIP-7702 y ERC-4337?
EIP-7702 permite que las EOAs deleguen temporalmente el control a código de smart contract durante las transacciones, mientras que ERC-4337 ofrece abstracción de cuentas completa para smart contract wallets usando un mempool fuera de la cadena y bundlers, sin requerir ningún cambio de protocolo.
¿Pueden EIP-3074 y ERC-4337 trabajar juntos?
Sí, se complementan entre sí: EIP-3074 podría permitir que las EOAs interactúen con smart accounts de ERC-4337 para la ejecución, aportando beneficios como el patrocinio de gas y una mejor experiencia de usuario sin requerir una migración completa a smart contract wallets.
¿Cuáles son las preocupaciones de seguridad con EIP-3074?
Los invokers persistentes de EIP-3074 representaban riesgos de seguridad al otorgarles un control significativo sobre las EOAs, con posibles vulnerabilidades como la repetición de firmas y el mal uso de la autoridad delegada, lo que requería una auditoría cuidadosa.
¿Por qué se eligió EIP-7702 en lugar de EIP-3074?
Se prefirió EIP-7702 porque aborda las preocupaciones de seguridad de EIP-3074 relacionadas con los invokers persistentes, ofrece mejor compatibilidad futura con ERC-4337, y se alinea más estrechamente con la hoja de ruta de abstracción de cuentas de Ethereum.
¿Qué funciones habilitan estas propuestas para los desarrolladores?
Estas propuestas habilitan el patrocinio de gas (las apps pagan el gas por los usuarios), las transacciones en lote (combinar múltiples acciones en una sola transacción), y mecanismos de recuperación para EOAs perdidas a través de delegados de confianza.
¿EIP-7702 ya está activo en la mainnet de Ethereum?
Sí, EIP-7702 se activó en mainnet el 7 de mayo de 2025, como parte de la actualización Pectra de Ethereum, pendiente de la adopción completa por parte de los clientes en implementaciones como Geth y Nethermind.
Resúmenes relacionados
Wallets2 de septiembre de 2026
Agent wallets: el modelo de sesión y permisos para agentes de IA
Cómo los agentes de IA obtienen acceso a wallets con alcance limitado y revocable sin tener las private keys: sessions, delegated signing y revocación instantánea.
Wallets29 de julio de 2026
Deja de pegar claves privadas en Cursor: cómo darle una wallet a tu coding agent
Dale una wallet a tu coding agent sin darle la clave. Cómo las agent wallets de Alchemy CLI usan sesiones con permisos limitados para que los agentes transaccionen sin claves privadas en .env.
Wallets24 de junio de 2026
¿Qué es un bundler de criptomonedas?
Un bundler de criptomonedas combina múltiples transacciones u operaciones en un solo envío onchain, abarcando batching, MEV, rollups, lanzamientos de tokens y account abstraction.
Construye magia blockchain
Alchemy combina los productos y herramientas de desarrollo Web3 más potentes con recursos, comunidad y un soporte legendario.