---
title: "EIP-3074 vs EIP-7702 vs ERC-4337: guia completo para desenvolvedores"
description: "Compare EIP-3074, EIP-7702 e ERC-4337: abordagens de account abstraction no Ethereum, recursos e trade-offs."
---

# EIP-3074 vs EIP-7702 vs ERC-4337: guia completo para desenvolvedores

O ecossistema de wallets do Ethereum está em constante evolução, avançando rumo a um futuro programável, com o **EIP-7702** como um passo fundamental em direção à account abstraction completa \(**ERC-4337**\). Mas para entender por que o 7702 está prestes a remodelar a forma como interagimos com o Ethereum através de** smart wallets**, precisamos reconhecer o EIP-3074, uma proposta que estabeleceu as bases fundamentais para que o 7702 fosse o que é hoje.

Se você é um desenvolvedor construindo [apps](https://www.alchemy.com/dapps/top/defi-dapps), provavelmente já lidou com as limitações das Externally Owned Accounts \(EOAs\) - as wallets tradicionais do Ethereum controladas por chaves privadas. O EIP-3074 introduziu uma forma de EOAs delegarem controle a smart contracts \(invokers\), habilitando funcionalidades como patrocínio de gas e transações em lote. O EIP-7702 vai além, oferecendo um caminho mais elegante e seguro para account abstraction.

Para desenvolvedores, esse conceito simplifica a adição de funcionalidades avançadas a apps mantendo os usuários em EOAs familiares. Para usuários, significa uma experiência mais fluida; pense em pagamentos de gas por terceiros ou na execução de múltiplas trades DeFi em um único clique.

Neste guia, vamos detalhar a mecânica do 3074 para contextualizar, mostrar os avanços do 7702 com código, e comparar ambos com o ERC-4337. Vamos ao que interessa e ficar técnicos.

## O problema que o EIP-3074 buscou resolver

EOAs são diretas: assinam transações com uma chave privada e as enviam para a rede Ethereum. Mas são limitadas. Não conseguem executar código, agrupar ações, ou recuperar chaves perdidas nativamente. Smart contract wallets \(habilitadas pelo ERC-4337\) oferecem mais flexibilidade, mas exigem que os usuários gerenciem novos endereços e frequentemente resultam em custos de gas mais altos. O EIP-3074 propôs uma solução introduzindo dois opcodes EVM: `AUTH` e `AUTHCALL`, permitindo que EOAs deleguem controle a invoker contracts, adicionando funcionalidades semelhantes às de smart contracts sem migração de wallet.

O EIP-3074 foi uma prova de conceito que moldou o roadmap de account abstraction do Ethereum: de EOAs para Smart EOAs \(EIP-7702\) e, finalmente, para Smart Wallets completas \(ERC-4337\). Vamos explorar a mecânica do 3074 para entender como ele abriu esse caminho.

<CardWithCta
  text="Smart wallets ajudam você a expandir seu app com UX onchain sem atrito."
  ctaLabel="Explorar recursos"
  ctaHref="#"
  theme="light"
/>

## Os componentes principais do EIP-3074: a base para o 7702

O EIP-3074 gira em torno de três elementos: o opcode `AUTH`, o opcode `AUTHCALL`, e os invoker contracts. Vale entendê-los, pois o 7702 se baseia nos princípios deles.

### 1. O opcode `auth`

O opcode `AUTH` \(`hex 0xf6`\) verifica uma assinatura ECDSA de uma EOA, comprovando que ela autorizou um invoker específico a agir em seu nome. A EOA assina uma mensagem contendo o endereço do invoker e um commitment \(um hash das ações a serem executadas\). Se a assinatura for válida, a EVM define um contexto autorizado.

Aqui está um trecho de [Solidity](https://www.alchemy.com/overviews/solidity) que simula a verificação de assinatura do 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);
}`} />

Esse código valida a intenção da EOA de delegar controle. Uma vez autorizado, o invoker pode agir como a EOA.

### 2. O opcode `authcall`

`AUTHCALL` \(`hex 0xf7`\) permite que o invoker execute transações como a EOA, usando o endereço da EOA como caller enquanto o invoker pode pagar o gas. Isso habilitou o patrocínio de gas e o batching no 3074.

Veja como você poderia usar `AUTHCALL` em 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)
        }
    }
}`}
/>

Esse trecho chama um contrato alvo \(por exemplo, um protocolo DeFi\) como a EOA. A função `gas\(\)` aloca o gas restante, e `AUTHCALL` garante que a ação reflita a identidade da EOA.

### 3. Invoker contracts

Invokers são smart contracts aos quais EOAs delegam. Os invokers do EIP-3074 eram persistentes, o que levantou preocupações de segurança que o 7702 endereça. Aqui está um invoker no estilo 3074 para patrocínio de gas e batching:

⚠️ **Nota de Segurança:** Invokers precisam ser auditados e construídos com cuidado. Um invoker com falhas pode fazer uso indevido de assinaturas ou repetir ações.

<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;
    }

}`} />

💡** Dica de Implementação**: Os invokers do EIP-3074 precisavam de auditorias para prevenir replays de assinaturas. O EIP-7702 evita invokers persistentes, reduzindo os riscos.

## EIP-3074 vs. EIP-7702: por que o 7702 vence

O EIP-3074 foi um experimento ousado, mas o EIP-7702 e o ERC-4337 são o futuro. Aqui está uma comparação rápida:

**EIP-3074 vs. ERC-4337**

- **EIP-3074:** Adicionou `AUTH` e `AUTHCALL` à EVM, funcionava com EOAs mas exigia invokers.
- **ERC-4337:** Nenhuma mudança de protocolo; usa um mempool separado e bundlers para smart contract wallets.
- **Conclusão:** O 3074 era mais simples para EOAs, mas a flexibilidade do 4337 o torna ideal para abstraction completa.

**EIP-3074 vs. EIP-7702**

- EIP-3074: Invokers persistentes representavam riscos de segurança e não ofereciam compatibilidade futura.
- EIP-7702: Habilita funcionalidades de smart contract por transação, alinhando-se ao 4337.
- **Conclusão:** O 7702 refina as ideias do 3074, oferecendo um caminho mais seguro e escalável, mais alinhado ao roadmap de AA do Ethereum.

O EIP-3074 introduziu ideias que o 7702 aperfeiçoa, levando a um ecossistema alinhado com o [roadmap do Ethereum](https://ethereum.org/en/roadmap/pectra/7702/) para account abstraction completa.

1. **Patrocínio de Gas**: apps pagam o gas pelos usuários, reduzindo as barreiras de onboarding.
1. **Transações em Lote**: Usuários combinam ações \(por exemplo, token swaps e staking\) em uma única transação.
1. **Mecanismos de Recuperação**: Usuários recuperam EOAs perdidas via delegados confiáveis.

## Comece a construir com smart wallets

O EIP-3074 abriu caminho para que o EIP-7702 pudesse avançar. Enquanto o 3074 introduziu ideias inovadoras para delegação de EOA, o 7702 as refina em uma solução mais segura e escalável, aproximando-nos do estágio final da account abstraction do Ethereum junto ao ERC-4337. O EIP-7702 faz parte da atualização Pectra do Ethereum, com testnets ativas desde abril de 2025. A ativação na mainnet está em vigor desde 7 de maio de 2025, dependendo da adoção pelos clients \([Geth](https://www.alchemy.com/overviews/what-is-a-geth-node-and-how-to-run-one), Nethermind, etc.\). Enquanto isso, o ERC-4337 já está ativo, oferecendo account abstraction completa para smart contract wallets.

Seja otimizando a UX de dApps ou criando experiências de usuário fluidas, agora é a hora de mergulhar no 7702 e no 4337. [Acesse a documentação](https://www.alchemy.com/docs/wallets/react/quickstart) e [comece a construir](https://dashboard.alchemy.com/services/smart-wallets/overview)!

Entre em contato conosco a qualquer momento com suas dúvidas. Estamos aqui para conversar sobre estratégia de integração, questões de implementação técnica, trade-offs, e ajudar você a encontrar a melhor solução para o seu app. Bons trabalhos!

## Perguntas frequentes

### O que é o EIP-3074?

O EIP-3074 foi uma proposta que introduziu dois opcodes EVM (`AUTH` e `AUTHCALL`) para permitir que EOAs deleguem controle a smart contracts chamados invokers, habilitando funcionalidades como patrocínio de gas e transações em lote sem exigir que os usuários migrem para novas wallets.

### Como o EIP-7702 melhora o EIP-3074?

O EIP-7702 refina os conceitos do EIP-3074 ao habilitar funcionalidades de smart contract por transação em vez de invokers persistentes, oferecendo um caminho mais seguro e escalável que resolve os riscos de segurança associados ao modelo de delegação persistente do 3074.

### Qual é a diferença entre o EIP-7702 e o ERC-4337?

O EIP-7702 permite que EOAs deleguem temporariamente controle a código de smart contract durante transações, enquanto o ERC-4337 oferece account abstraction completa para smart contract wallets usando um mempool off-chain e bundlers, sem exigir mudanças de protocolo.

### O EIP-3074 e o ERC-4337 podem funcionar juntos?

Sim, eles se complementam: o EIP-3074 poderia permitir que EOAs interajam com smart accounts do ERC-4337 para execução, proporcionando benefícios como patrocínio de gas e melhor experiência do usuário sem exigir migração completa para smart contract wallets.

### Quais são as preocupações de segurança com o EIP-3074?

Os invokers persistentes do EIP-3074 representavam riscos de segurança ao conceder aos invokers controle significativo sobre EOAs, com vulnerabilidades potenciais incluindo replays de assinaturas e uso indevido da autoridade delegada, que exigiam auditorias cuidadosas.

### Por que o EIP-7702 foi escolhido em vez do EIP-3074?

O EIP-7702 foi preferido porque resolve as preocupações de segurança do EIP-3074 relacionadas a invokers persistentes, oferece melhor compatibilidade futura com o ERC-4337, e se alinha mais estreitamente ao roadmap de account abstraction do Ethereum.

### Quais funcionalidades essas propostas habilitam para desenvolvedores?

Essas propostas habilitam patrocínio de gas (apps pagando o gas pelos usuários), transações em lote (combinando múltiplas ações em uma transação), e mecanismos de recuperação para EOAs perdidas via delegados confiáveis.

### O EIP-7702 está ativo na mainnet do Ethereum?

Sim, o EIP-7702 entrou em vigor na mainnet em 7 de maio de 2025, como parte da atualização Pectra do Ethereum, dependendo da adoção completa pelos clients em implementações como Geth e Nethermind.