
A principal distinção entre EIP-8141 e ERC-4337 reside na arquitetura. O ERC-4337 adiciona abstração de contas ao sistema de transações já existente do Ethereum por meio de Carteiras de contrato inteligente, UserOperation, bundler, um Contrato inteligente EntryPoint singleton designado EntryPoint e paymaster opcionais. O EIP-8141 propõe, por sua vez, uma nova Frame Transaction ao nível da camada do protocolo, permitindo que validação, pagamento de gas, deployment e execução ocorram através de múltiplos frames numa única transação.
Ambas as propostas oferecem funcionalidades avançadas de abstração de contas: transações patrocinadas, operações em lote, assinaturas flexíveis, mecanismos de recuperação e experiências de carteira simplificadas. A diferença reside na profundidade de integração dessas capacidades no Ethereum.
O ERC-4337 opera sem modificar o tipo de transação nativa do Ethereum; o EIP-8141 introduz Frame Transactions diretamente no protocolo.
O ERC-4337 utiliza UserOperation, bundler, um Contrato inteligente EntryPoint singleton e contratos paymaster.
O EIP-8141 recorre a VERIFY, SENDER e outros frames para separar validação, pagamento de gas, deployment e execução.
Ambos possibilitam abstração de gas, operações em lote, assinaturas alternativas e transações patrocinadas.
O EIP-7702 oferece um caminho de migração para EOA, permitindo funcionalidades de contrato inteligente e integração com ambas as abordagens de abstração de contas.
| Funcionalidade | ERC-4337 | EIP-8141 |
|---|---|---|
| Objeto principal do utilizador | UserOperation | Frame Transaction |
| Modelo de conta | Contrato de conta inteligente | Conta nativa com capacidade AA |
| Necessidade de alteração do protocolo | Não | Sim |
| Coordenador de execução | Contrato inteligente EntryPoint singleton | Execução de frames ao nível do protocolo |
| Bundler | Elemento central do fluxo padrão | Não é requerido 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 |
| Deployment de conta | código de fábrica/init | frame de deployment |
| Validação | Validação da conta inteligente | Frame VERIFY |
| Execução do utilizador | Chamada da conta inteligente | Frame SENDER |
| Caminho EOA | Suporte EIP-7702 | Código padrão / modelo compatível com EIP-7702 |
O ERC-4337 define intencionalmente o UserOperation como uma pseudo-transação. Inclui campos como call data, limites de gas, taxa máxima, assinatura e dados do paymaster, mas é o bundler que, em última instância, empacota tudo numa transação Ethereum convencional enviada ao EntryPoint.
O EIP-8141 altera a própria estrutura tradicional das transações. O seu payload incorpora múltiplos frames, assinaturas, parâmetros de taxa e endereço do remetente, permitindo que cada frame tenha o seu próprio modo de execução e limites de gas.
Com o ERC-4337, o utilizador cria ou interage através de um Contrato de conta inteligente em vez de utilizar apenas uma conta tradicional externamente detida.
O utilizador assina uma UserOperation com os dados de chamada pretendidos. Um bundler recolhe UserOperation pendente e submete-as ao Contrato inteligente EntryPoint singleton, que valida cada conta e coordena a execução. Um contrato paymaster pode patrocinar o custo de gas, permitindo aplicações com políticas de pagamento condicional ou pagamentos indiretos em tokens ERC-20.
Como o campo de assinatura é interpretado pela conta inteligente, não pelas regras de consenso do Ethereum, o ERC-4337 permite chaves de sessão, políticas de assinatura múltipla, lógica de recuperação e contas inteligentes modulares.
A arquitetura de abstração de contas ERC-4337 oferece, assim, funcionalidades de contrato inteligente avançadas sem exigir upgrades de protocolo.
O EIP-8141 transfere mais capacidades para o fluxo nativo de transações do Ethereum.
Um frame de validação gere a validação. Um frame de remetente executa a operação pretendida, utilizando o contexto de execução do remetente. Um frame de deployment instala código de conta antes da validação, quando necessário, e frames adicionais podem tratar do pagamento ou da lógica pós-execução.
O opcode APPROVE permite ao código de validação definir um âmbito de aprovação sobre execução, pagamento ou ambos. Após a autorização, os frames restantes podem executar as operações multi-etapa solicitadas.
Esta é a diferença crucial em Frame Transaction vs. ERC-4337: o protocolo compreende estas fases diretamente, sem depender de um pipeline separado de UserOperation.
Ambos os sistemas possibilitam que utilizadores realizem transações sem deter ETH diretamente.
No ERC-4337, um contrato paymaster cobre o gas, podendo recuperar o custo noutra moeda. O fornecedor da carteira ou DApp (aplicação descentralizada) pode definir as condições de patrocínio.
No EIP-8141, o pagamento de gas integra-se na sequência de validação da transação. Um contrato patrocinador autoriza o pagamento, enquanto o remetente autoriza a execução. O pagador pode, portanto, não ser o remetente.
O EIP-8141 apresenta um modelo de gas explícito. Cada frame tem limites de gas de execução e de estado, e a transação fica limitada ao custo máximo global. O gas não utilizado num frame não está simplesmente disponível para o frame atual ou para os restantes frames utilizarem, o que facilita a limitação do custo de simulação e validação.
A conta inteligente ERC-4337 já permite operações em lote, permitindo múltiplas ações numa única operação de conta.
O EIP-8141 torna os lotes mais explícitos com múltiplos frames. Um lote atómico agrupa ações consecutivas para que sejam bem-sucedidas ou revertam em conjunto. Se um frame relevante reverter, todas as alterações agrupadas são revertidas.
Por exemplo, aprovação de token e uma troca podem ser processados como uma sequência tudo-ou-nada, evitando aprovações não utilizadas se a troca falhar.
Esta abordagem nativa a operações multi-etapa simplifica o design da conta inteligente, objetivo central do EIP-8141.
O EIP-7702 permite que uma EOA delegue execução a código de contrato mantendo o endereço existente, criando uma ponte prática entre contas convencionais e funcionalidades de conta inteligente.
O ERC-4337 pode utilizar EOA, evitando a migração para novos endereços de contrato.
O EIP-8141 vai mais além com código padrão, conferindo um comportamento Frame Transaction à conta, mesmo sem armazenamento ou código implantado. Um frame de deployment instala ou delega código quando necessária funcionalidade adicional.
EIP-7702, ERC-4337 e EIP-8141 devem ser entendidos como etapas conectadas no caminho de migração da abstração de contas do Ethereum, e não como sistemas mutuamente exclusivos.
A integração do EIP-8141 pode reduzir a dependência de bundler e infraestrutura off-chain para operações comuns de abstração de contas.
Validação programável aproxima-se do modelo de transação ao nível do consenso, permitindo políticas de recuperação, agregação de assinaturas futura, permissões de sessão e autenticação pós-quântica.
O custo é a complexidade. Nodos públicos precisam de avaliar com segurança Frame Transaction pendente. O EIP-8141 define um prefixo de validação restrito, limita o acesso ao estado, impõe limites ao trabalho de validação e distingue paymaster canónico e não-canónico para reduzir riscos de invalidação em massa e ataques de denial-of-service.
A arquitetura mais ampla de abstração de contas do Ethereum demonstra porque a experiência das carteiras evolui de soluções ao nível da aplicação para um suporte mais profundo do protocolo.
Em síntese, o ERC-4337 constrói abstração de contas em torno do Ethereum, enquanto o EIP-8141 integra essas capacidades de forma nativa.
O ERC-4337 recorre a Carteiras de contrato inteligente, UserOperation, bundler, EntryPoint e paymaster. O EIP-8141 utiliza Frame Transaction com fases dedicadas de verificação, remetente, deployment, pagamento e execução.
O ERC-4337 permanece valioso ao fornecer uma infraestrutura madura de abstração de contas sem necessidade de upgrades de protocolo. O EIP-8141 pode tornar abstração de gas, validação programável, operações em lote e transações patrocinadas mais nativas e menos dependentes de pipelines externos.
Não, automaticamente. O ERC-4337 já suporta conta inteligente implantada e infraestrutura estabelecida. O EIP-8141 altera as capacidades nativas do Ethereum; as carteiras podem continuar a utilizar componentes ERC-4337 sempre que sejam vantajosos.
Não existe necessidade de um Contrato inteligente EntryPoint singleton para o fluxo central de Frame Transaction. Validação e execução são representadas diretamente por frames de transação, sem UserOperation encaminhadas pelo EntryPoint.
Sim. O ERC-4337 utiliza paymaster para patrocinar UserOperation. O EIP-8141 permite que a validação da transação autorize separadamente o remetente e o pagador, possibilitando que um contrato patrocinador cubra o gas.
Sim, especialmente através do EIP-7702. Uma EOA pode delegar funcionalidades de contrato inteligente mantendo o endereço, minimizando a necessidade de migração total.
Porque validação, autorização de pagamento, deployment e execução estão integrados num novo formato de transação Ethereum, não dependem primariamente de infraestrutura externa de UserOperation.
Este conteúdo destina-se exclusivamente a fins educativos. Os standards do Ethereum, upgrades de protocolo, implementações de carteiras e especificações EIP podem ser alterados.











