---
title: "EIP-3074 vs EIP-7702 vs ERC-4337: guía completa para desarrolladores"
description: "Compara EIP-3074, EIP-7702 y ERC-4337: enfoques, características y trade-offs de account abstraction en Ethereum."
---

# EIP-3074 vs EIP-7702 vs ERC-4337: guía completa para desarrolladores

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](https://www.alchemy.com/dapps/top/defi-dapps), 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.

<CardWithCta
  text="Las smart wallets te ayudan a hacer crecer tu app con una UX onchain fluida."
  ctaLabel="Explorar funciones"
  ctaHref="#"
  theme="light"
/>

## 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](https://www.alchemy.com/overviews/solidity) que imita la verificación de firma de AUTH:

<CodeSnippet language="solidity" code={`*// 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:

<CodeSnippet
  language="solidity"
  code={`// 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.

<CodeSnippet language="jsx" code={`// 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ó `AUTH` y `AUTHCALL` a 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](https://ethereum.org/en/roadmap/pectra/7702/) para la abstracción de cuentas completa.

1. **Patrocinio de gas**: las apps pagan el gas por los usuarios, reduciendo las barreras de entrada.
1. **Transacciones en lote**: los usuarios combinan acciones \(por ejemplo, swaps de tokens y staking\) en una sola transacción.
1. **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](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one), 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](https://www.alchemy.com/docs/wallets/react/quickstart) y [empieza a construir](https://dashboard.alchemy.com/services/smart-wallets/overview)!

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.