EIP-4337: Como a Abstração de Conta Está a Reformular as Transações Ethereum

Insights de pesquisa para entender a próxima geração de gestão de contas Ethereum

A abstração de conta (AA) representa uma mudança fundamental na forma como interagimos com Ethereum. Ao desacoplar a validação de transações da execução e reimaginar a arquitetura da carteira, esta proposta aborda pontos de fricção críticos que historicamente impediram a adoção generalizada. A introdução do EIP-4337 torna essa visão prática sem exigir mudanças no protocolo central do Ethereum.

A Fundação: Compreendendo o Modelo de Conta do Ethereum

Para entender por que a abstração de contas é importante, precisamos primeiro examinar os dois tipos de contas que atualmente existem no Ethereum. Contas de propriedade externa (EOAs) são controladas por meio de chaves privadas e frases-semente— a abordagem tradicional que a maioria dos usuários emprega. Contas de contrato (CAs), por outro lado, operam sob as regras definidas por contratos inteligentes.

Este sistema binário cria limitações inerentes. As contas externas (EOAs) não conseguem executar lógica de transação sofisticada automaticamente, enquanto as carteiras de contratos inteligentes requerem taxas de gás e custos de implementação. A abstração de contas preenche essa lacuna, permitindo que a lógica de contratos inteligentes governe as EOAs, criando o que chamamos de carteiras programáveis. Isso desbloqueia possibilidades como transações em lote, esquemas de assinatura personalizados e transações patrocinadas—características que parecem padrão na finança tradicional, mas permanecem elusivas no crypto.

Porque a Comunidade Ethereum Aceitou Esta Solução

Os pontos problemáticos que a AA aborda são concretos e generalizados. Considere a fricção que os usuários enfrentam: gerenciar frases-semente, pagar taxas de gás para operações básicas, recuperar contas perdidas ou autorizar ações em lote uma transação de cada vez. A abstração de conta simplifica essas experiências ao introduzir modelos de segurança de conta personalizáveis e mecanismos flexíveis de pagamento de gás.

Para além da experiência do utilizador, os desenvolvedores ganham algo igualmente valioso: um framework programável. Em vez de construir contra restrições rígidas na cadeia, agora podem desenhar a verificação de transações e a lógica de execução adaptadas a casos de uso específicos. Esta flexibilidade representa uma expansão fundamental do que é possível no Ethereum.

A Evolução: De EIP-2938 a EIP-4337

O caminho para a abstração de conta não foi simples. Em 2020, surgiram duas propostas concorrentes:

EIP-2938 propôs elevar as contas de contrato ao status de “nível superior”, permitindo que paguem taxas e executem transações diretamente. Isso exigiria mudanças no nível do protocolo, tornando-o tecnicamente ambicioso, mas operacionalmente arriscado.

EIP-3074 introduziu dois novos códigos de operação—AUTH e AUTHCALL—permitindo que as EOAs delegassem a autoridade de transação para contratos inteligentes. Embora inovador, esta abordagem também exigiu modificações no protocolo central e enfrentou preocupações da comunidade sobre a complexidade da implementação.

Ambas as propostas foram suspensas devido ao grande esforço exigido pela camada de consenso do Ethereum. Quaisquer bugs introduzidos a este nível exigiriam um hard fork para resolver, apresentando um risco inaceitável.

A grande inovação veio com EIP-4337, que alcança a abstração de conta sem modificar a camada base do Ethereum. Em vez disso, introduz uma infraestrutura paralela para o tratamento de transações, mudando fundamentalmente a forma como o ecossistema aborda o problema.

EIP-4337: A Arquitetura Que Funciona

O brilho do EIP-4337 reside na sua implementação em camada de aplicação. Em vez de alterar as regras do protocolo central, introduz novos atores e processos que coexistem com o manuseio tradicional de transações:

UserOperation objetos representam intenções de transação de titulares de conta. Ao contrário das transações padrão, eles são criados antes de serem assinados, dando flexibilidade ao sistema em como as assinaturas são validadas e executadas.

Bundlers atuam como nós especializados que coletam várias UserOperations, agregando-as em transações em conjunto únicas. Pense neles como agregadores de transações que agrupam operações para eficiência.

O contrato de ponto de entrada serve como o centro de execução. Ele recebe operações de usuário agrupadas, valida suas assinaturas usando lógica específica da conta e aciona a execução através da função ExecuteUserOp.

As carteiras de contratos inteligentes substituem as EOAs tradicionais como a interface de conta principal. Estas são controladas por lógica programável em vez de apenas criptografia de chave privada.

Os contratos Paymaster introduzem uma flexibilidade revolucionária no pagamento de gas. Os utilizadores podem agora pagar taxas de transação utilizando qualquer token, ter taxas patrocinadas por aplicações ou usar uma lógica de taxas totalmente personalizada. Isso remove o ETH como um pré-requisito para cada interação.

Fábricas de carteiras permitem a criação eficiente de novas carteiras de contratos inteligentes, reduzindo a sobrecarga para os utilizadores que entram no ecossistema.

Agregadores validam pacotes de assinaturas, permitindo otimizações criptográficas que reduzem os custos de verificação na cadeia.

Como as Transações Fluem em um Ethereum Habilitado para AA

Vamos traçar um exemplo concreto de como uma transação opera sob o EIP-4337:

Passo 1: Expressando Intenção O utilizador cria uma UserOperation especificando os detalhes da sua transação, incluindo as taxas máximas (maxFeePerGas, maxPriorityFee), a interação com o contrato-alvo e os dados da assinatura. Importante, a assinatura ainda não foi aplicada - o sistema determina como interpretá-la com base nas regras do contrato da carteira.

Passo 2: Transmissão do Mempool A UserOperation entra em um pool de memória dedicado, separado das transações padrão do Ethereum. Este mempool especializado permite que os bundlers apliquem lógica personalizada para ordenação e seleção.

Passo 3: Agrupamento Os agrupadores escaneiam o mempool de UserOperation, selecionam operações e as agregam. Em seguida, chamam a função handleOps do contrato de ponto de entrada com o pacote. Se o agrupador também operar como um construtor de blocos, pode incluí-lo diretamente no próximo bloco. Caso contrário, trabalham através de infraestrutura como MEV-Boost ou protocolos de separação de proponentes-construtores para garantir a inclusão.

Passo 4: Validação O contrato de ponto de entrada utiliza validateUserOp para verificar a assinatura de cada operação de acordo com as regras do contrato da conta. Após a validação, os bundlers colocam o contrato de ponto de entrada na lista branca, estabelecendo uma relação de confiança.

Passo 5: Execução A função ExecuteUserOp do contrato da carteira é acionada, realizando a lógica da transação real. O pacote está agora completo e incluído na blockchain Ethereum.

Comparando Arquiteturas de Carteira: EOA vs. MPC vs. AA

Por que o EIP-3074 foi deixado de lado

Antes de o EIP-4337 ganhar tração, o EIP-3074 representava a principal alternativa para a abstração de contas. Ele introduziu os mesmos códigos de operação AUTH e AUTHCALL que mencionamos anteriormente. Aqui está o motivo pelo qual não prosseguiu:

O Problema da Mudança de Protocolo: O EIP-3074 exigiu modificações na camada de consenso, o que significa que os nós principais do Ethereum precisariam adotar um novo comportamento. Se surgissem erros de implementação, o único remédio seria um hard fork disruptivo afetando toda a rede.

Flexibilidade Limitada: Embora a EIP-3074 tenha permitido que os EOAs atuassem como contratos inteligentes, preservou a ECDSA como o mecanismo de assinatura fixo. Isso impediu os desenvolvedores de experimentar abordagens criptográficas novas ou implementar lógicas de verificação mais sofisticadas.

A Vantagem: A força central do EIP-3074 era a elegância—qualquer EOA poderia ganhar capacidades semelhantes a contratos inteligentes sem implantar contratos. No entanto, essa simplicidade teve um custo em termos de personalização limitada.

Em contraste, o EIP-4337 aceita processos on-chain mais complexos para evitar riscos a nível de protocolo, um compromisso que a comunidade considerou válido.

A Ponte: EIP-5003 e Evolução da Carteira

Embora o EIP-3074 continue em espera, a conversa não terminou. O EIP-5003 introduz o código de operação AUTHUSURP, que funciona juntamente com o EIP-3074 para permitir que as EOAs existentes evoluam para contas de contrato inteligente.

Aqui está um cenário prático: a EOA de Alice autoriza o endereço de Bob a agir em seu nome sob o EIP-3074. Usando o AUTHUSURP, o endereço de Bob pode então implantar código no endereço de Alice, efetivamente atualizando sua conta de uma EOA para uma CA. Esta migração concede a Alice acesso a esquemas de assinatura personalizados e segurança aprimorada sem abandonar seu endereço original ou chave privada.

Este padrão de design sugere um caminho de migração gradual para o ecossistema em vez de uma transição abrupta.

O Impacto Prático: Barreiras Mais Baixas, Segurança Mais Forte

À medida que o Ethereum continua a buscar a adoção mainstream, a abstração de conta do EIP-4337 aborda obstáculos tangíveis. Os usuários não precisam mais acumular ETH para pagamentos de gás ou memorizar frases semente como seu principal mecanismo de segurança. Os desenvolvedores podem projetar carteiras que incorporam mecanismos de recuperação, operações em lote e lógica de autorização personalizada. As aplicações podem patrocinar transações de usuários, reduzindo a fricção para a integração.

A segurança também melhora. As carteiras de contrato inteligente podem implementar validação de múltiplas assinaturas, operações bloqueadas por tempo, limites de gasto e outras salvaguardas além da criptografia básica de chave privada.

A evolução do ecossistema Ethereum em direção à abstração de contas não representa uma atualização técnica menor, mas uma reinvenção fundamental de como as contas funcionam—uma que aproxima as interações em cripto da experiência fluida que os usuários esperam de aplicações modernas.