
A principal distinção entre EIP-8141 e ERC-4337 está na arquitetura. O ERC-4337 implementa a abstração de contas sobre o sistema de transações atual do Ethereum, utilizando carteiras de contrato inteligente, UserOperations, bundlers, um contrato singleton chamado EntryPoint e paymasters opcionais. Já o EIP-8141 propõe uma nova Frame Transaction no nível de protocolo, permitindo que validação, pagamento de gas, implantação e execução sejam realizados por meio de múltiplos frames dentro de uma única transação.
Ambos visam recursos semelhantes de abstração de contas: transações patrocinadas, operações em lote, assinaturas flexíveis, mecanismos de recuperação e experiências de carteira mais simplificadas. O diferencial está no grau de integração dessas funções ao Ethereum.
O ERC-4337 opera sem alterar o tipo de transação nativo do Ethereum; o EIP-8141 adiciona Frame Transactions diretamente ao protocolo.
O ERC-4337 emprega UserOperations, bundlers, um contrato EntryPoint e contratos paymaster.
O EIP-8141 utiliza VERIFY, SENDER e outros frames para separar validação, pagamento de gas, implantação e execução.
Ambos proporcionam abstração de gas, operações em lote, assinaturas alternativas e transações patrocinadas.
O EIP-7702 oferece um caminho de migração para EOAs existentes adquirirem funcionalidades de contrato inteligente e pode ser integrado a ambas as abordagens de abstração de contas.
| Recurso | ERC-4337 | EIP-8141 |
|---|---|---|
| Objeto principal do usuário | UserOperation | Frame Transaction |
| Modelo de conta | Contrato inteligente de conta | Conta nativa compatível com AA |
| Alteração de protocolo exigida | Não | Sim |
| Coordenador de execução | Contrato singleton EntryPoint | Execução de frames pelo protocolo |
| Bundlers | Elemento central do fluxo padrão | Não exigido da mesma forma |
| Abstração de gas | Contrato paymaster | Aprovação de pagamento nos frames |
| Transações em lote | Lógica da conta inteligente | Múltiplos frames / lote atômico |
| Implantação de conta | Código de fábrica/init | Deploy frame |
| Validação | Validação da conta inteligente | VERIFY frame |
| Execução do usuário | Chamada da conta inteligente | SENDER frame |
| Caminho EOA | Suporte ao EIP-7702 | Código padrão / modelo compatível com EIP-7702 |
O ERC-4337 caracteriza o UserOperation como uma pseudo-transação. Ele inclui campos como call data, limites de gas, taxa máxima, assinatura e dados do paymaster, mas o bundler converte isso em uma transação Ethereum convencional enviada ao EntryPoint.
O EIP-8141 modifica a transação tradicional. Sua carga útil abrange múltiplos frames, assinaturas, parâmetros de taxa e um endereço de remetente, permitindo que cada frame tenha seu próprio modo de execução e limites de gas.
No ERC-4337, o usuário utiliza um contrato inteligente de conta em vez de uma conta tradicional externamente controlada.
O usuário assina uma UserOperation com os dados de chamada pretendidos. Um bundler coleta UserOperations pendentes e as submete via contrato EntryPoint, que valida cada conta e coordena a execução. Contratos paymaster podem patrocinar o gas, permitindo políticas de pagamento condicional ou pagamentos indiretos com tokens ERC-20.
Como o campo de assinatura é interpretado pelo contrato inteligente e não está fixado nas regras de consenso do Ethereum, o ERC-4337 oferece suporte a chaves de sessão, políticas multisig, lógica de recuperação e contas inteligentes modulares.
A arquitetura de abstração de contas ERC-4337 já proporciona funcionalidades abrangentes de contrato inteligente sem necessidade de atualizar o protocolo.
O EIP-8141 transfere mais dessas capacidades para o fluxo nativo de transações do Ethereum.
Um verify frame gerencia a validação. Um sender frame executa a operação desejada pelo usuário no contexto do remetente. Um deploy frame pode instalar código de conta antes da validação, enquanto outros frames cuidam do pagamento ou pós-execução.
O opcode APPROVE permite que o código de validação estabeleça escopos de autorização para execução, pagamento ou ambos. Após a autorização, os demais frames realizam as operações solicitadas.
Essa é a diferença fundamental entre Frame Transactions e ERC-4337: o protocolo compreende esses estágios diretamente, sem depender de pipelines separados de UserOperation.
Ambos os sistemas permitem que usuários realizem transações sem precisar manter ETH em cada operação.
No ERC-4337, um contrato paymaster cobre o gas e pode recuperar o custo em outro token. O provedor da carteira ou dApp pode definir regras de patrocínio.
No EIP-8141, o pagamento de gas integra-se à validação da transação. Um contrato patrocinador autoriza o pagamento enquanto o remetente autoriza a execução, permitindo que pagador e remetente sejam diferentes.
O EIP-8141 adota um modelo de gas explícito: cada frame recebe limites de gas para execução e estado, e a transação tem um custo máximo total. O gas não utilizado em um frame não pode ser transferido para os outros, restringindo o custo de simulação e validação.
Contas inteligentes ERC-4337 já permitem transações em lote, possibilitando múltiplas operações em uma única ação.
No EIP-8141, operações em lote são gerenciadas por múltiplos frames. Um lote atômico agrupa ações para que todas tenham sucesso ou falhem juntas. Se um frame falhar, todas as alterações agrupadas são revertidas.
Assim, aprovações de token e swaps podem ser realizados como uma sequência indivisível, evitando aprovações residuais caso o swap não ocorra.
Esse tratamento nativo de operações complexas é um dos objetivos do EIP-8141 para simplificar o design das contas inteligentes.
EIP-7702 permite que um EOA delegue execução para código de contrato sem alterar seu endereço, criando uma ponte entre contas convencionais e funcionalidades avançadas de conta inteligente.
O ERC-4337 pode operar com contas compatíveis com EIP-7702, sem exigir que todos os usuários migrem para novos endereços de contrato.
O EIP-8141 vai além, oferecendo código padrão que confere à conta um comportamento básico de Frame Transaction, mesmo com armazenamento vazio ou sem código implantado. O deploy frame adiciona ou delega código conforme necessário.
Dessa forma, EIP-7702, ERC-4337 e EIP-8141 formam etapas interligadas na evolução da abstração de contas no Ethereum, não sistemas excludentes.
A integração do EIP-8141 pode reduzir a dependência de bundlers e infraestrutura off-chain para operações comuns de abstração de contas.
A validação programável se aproxima do modelo de transação em nível de consenso. Lógicas de validação variadas podem habilitar políticas de recuperação, agregação de assinaturas, permissões temporárias e autenticação pós-quântica.
O desafio é a complexidade. Nós públicos precisam avaliar Frame Transactions pendentes com segurança. O EIP-8141 define um prefixo de validação restrito, limita o acesso ao estado, restringe o trabalho de validação e diferencia paymasters canônicos e não canônicos, mitigando riscos de invalidação em massa e ataques de negação de serviço.
A arquitetura ampla de abstração de contas do Ethereum evidencia a evolução da experiência do usuário em carteiras, migrando de soluções aplicacionais para suporte nativo de protocolo.
Resumidamente, o ERC-4337 implementa a abstração de contas sobre o Ethereum, enquanto o EIP-8141 a incorpora de forma nativa.
O ERC-4337 utiliza carteiras de contrato inteligente, UserOperations, bundlers, EntryPoint e paymasters. O EIP-8141 emprega Frame Transactions com etapas exclusivas para verificação, remetente, implantação, pagamento e execução.
O ERC-4337 permanece relevante por já oferecer infraestrutura madura de abstração de contas sem necessidade de upgrades de protocolo. O EIP-8141 tende a tornar abstração de gas, validação programável, operações em lote e transações patrocinadas funções nativas, eliminando dependências de pipelines externos.
Não automaticamente. O ERC-4337 já suporta contas inteligentes ativas e infraestrutura consolidada. O EIP-8141 amplia as funcionalidades nativas do Ethereum, e carteiras podem continuar aproveitando componentes do ERC-4337 conforme necessário.
Não é preciso um contrato singleton EntryPoint para o fluxo central da Frame Transaction. Validação e execução ocorrem diretamente pelos frames da transação, sem UserOperations intermediadas pelo EntryPoint.
Sim. O ERC-4337 utiliza paymasters para patrocinar UserOperations. O EIP-8141 permite que validação autorize separadamente o remetente e o pagador, possibilitando que um contrato patrocinador arque com o gas.
Sim, especialmente via EIP-7702. Um EOA pode delegar funções de contrato inteligente mantendo seu endereço, evitando a migração total da conta.
Porque validação, autorização de pagamento, implantação e execução são integrados a um novo formato de transação do Ethereum, sem depender prioritariamente de infraestrutura externa de UserOperation.
Este material é apenas para fins educacionais. Padrões Ethereum, atualizações de protocolo, implementações de carteira e especificações de EIP estão sujeitos a alterações.











