EIP-3074 vs EIP-7702 vs ERC-4337: guia completo para desenvolvedores
Escrito por Usman Asim
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, 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.
Smart wallets ajudam você a expandir seu app com UX onchain sem atrito.
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 que simula a verificação de assinatura do 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);
}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:
// 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.
// 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
AUTHeAUTHCALLà 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 para account abstraction completa.
- Patrocínio de Gas: apps pagam o gas pelos usuários, reduzindo as barreiras de onboarding.
- Transações em Lote: Usuários combinam ações (por exemplo, token swaps e staking) em uma única transação.
- 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, 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 e comece a construir!
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.
Visões gerais relacionadas
Carteiras2 de setembro de 2026
Agent wallets: o modelo de sessão e permissões para agentes de IA
Como agentes de IA obtêm acesso a wallets com escopo definido e revogável, sem manter chaves privadas: sessions, delegated signing e revogação instantânea.
Carteiras29 de julho de 2026
Pare de colar chaves privadas no Cursor: como dar uma wallet ao seu coding agent
Dê ao seu coding agent uma wallet sem dar a chave. Como as agent wallets do Alchemy CLI usam sessões com escopo definido para que agents transacionem sem private keys no .env.
Carteiras24 de junho de 2026
O que é um crypto bundler?
Um crypto bundler combina múltiplas transações ou operações em um único envio onchain, abrangendo batching, MEV, rollups, lançamentos de tokens e account abstraction.
Construa magia blockchain
A Alchemy combina os produtos e ferramentas de desenvolvimento Web3 mais poderosos com recursos, comunidade e suporte lendário.