EIP-8141 vs. ERC-4337: Qual é a diferença?

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.

Principais conclusões

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.

EIP-8141 vs. ERC-4337 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.

Funcionamento das Carteiras de contrato inteligente ERC-4337

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.

Como a Frame Transaction do EIP-8141 altera o modelo

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.

Pagamentos e contabilização de gas

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.

Transações em lote e operações múltiplas

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.

EIP-7702 e o caminho de migração para EOA

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.

Abstração nativa de contas: o que muda na camada do protocolo?

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.

Conclusão

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.

Perguntas frequentes

O EIP-8141 substitui o ERC-4337?

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.

O EIP-8141 requer um contrato EntryPoint?

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.

Ambos os sistemas suportam pagamentos de gas patrocinados?

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.

O ERC-4337 pode suportar EOA?

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 é que o EIP-8141 é considerado abstração nativa de contas?

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.