
O account abstraction (AA) tornou-se um dos avanços mais transformadores no universo Ethereum, revolucionando a forma como os utilizadores gerem as suas contas e interagem com a blockchain. Este guia detalhado explica os mecanismos, as vantagens e a implementação do account abstraction, focando-se especialmente na EIP-4337 – a proposta mais recente que possibilita a AA sem necessidade de alterações ao protocolo central do Ethereum.
O account abstraction representa uma mudança disruptiva na gestão de contas no Ethereum. Para compreender plenamente a AA, importa distinguir os dois tipos de contas existentes na rede: externally owned accounts (EOA) e contract accounts (CA). As EOA são contas convencionais controladas por chaves privadas e frases-semente, o que obriga os utilizadores a proteger os seus dados criptográficos. Por oposição, as contract accounts são reguladas por código de smart contract, permitindo uma lógica programável e flexível na gestão das contas.
Account abstraction é o processo que separa as origens das transações das assinaturas e transforma as EOA para funcionarem de modo semelhante às CA. Graças a esta evolução, os smart contracts podem assumir o controlo das EOA, dando origem às smart contract wallets. O resultado é um sistema de gestão de contas mais flexível e intuitivo, que elimina muitas das limitações das EOA tradicionais. Ao permitir esta transição, a AA abre portas a novas possibilidades para os utilizadores: mecanismos de segurança avançados, autorizações de transações flexíveis e uma experiência de utilização significativamente melhorada.
A adoção do account abstraction pela comunidade Ethereum reflete o seu potencial para simplificar e melhorar o processo de gestão de contas. O principal benefício é a flexibilidade acrescida nas operações on-chain. Enquanto as EOA tradicionais são limitadas, a AA permite aos utilizadores incorporar lógica programável nas contas, adaptando-se a múltiplos cenários.
A segurança é outra vantagem determinante da AA. Os utilizadores podem recorrer a esquemas de multiassinatura, métodos de recuperação social e outras funcionalidades avançadas que antes não estavam acessíveis aos titulares de EOA. Isto reduz substancialmente o risco de perda permanente de fundos devido ao extravio de chaves privadas ou frases-semente. A AA resolve também problemas recorrentes na experiência do utilizador, como a obrigatoriedade de deter ETH para pagar taxas de gás e a impossibilidade de agrupar transações. No conjunto, estas inovações facilitam a entrada de utilizadores não especializados em cripto, tornando o Ethereum mais próximo do público em geral.
O desenvolvimento do account abstraction no Ethereum foi marcado por várias Ethereum Improvement Proposals (EIP) decisivas, cada uma delas contribuindo para o estado atual da AA. Compreender este percurso histórico é essencial para perceber a importância da EIP-4337.
A EIP-2938 foi uma das primeiras tentativas de implementar a AA, tornando as contract accounts entidades 'top-level' capazes de pagar taxas e executar transações autonomamente. Já a EIP-3074 propôs dois novos OpCodes, AUTH e AUTHCALL, permitindo às EOA delegar ações a contratos. Esta proposta conferia aos programadores uma estrutura mais flexível para desenhar transações e mecanismos de verificação.
O conceito de account abstraction ganhou notoriedade com as EIP-2938 e EIP-3074. Contudo, ambas implicavam alterações profundas ao protocolo Ethereum ao nível do consenso, com riscos e desafios de implementação consideráveis. Como tal, ficaram suspensas. A EIP-4337 assinala um ponto de viragem ao permitir a AA sem alterações ao protocolo base, tornando-se uma solução mais pragmática e de baixo risco para a adoção do account abstraction.
Ao avaliar várias soluções de AA, percebe-se porque a EIP-4337 se tornou a escolha predominante. Apesar de a EIP-3074 apresentar funcionalidades inovadoras, exigia a introdução de dois novos op codes ao nível do consenso, implicando hard forks e alterações profundas ao núcleo do Ethereum – desafios técnicos e de coordenação significativos.
Por contraste, a EIP-4337 concretiza a account abstraction numa camada superior, sem necessidade de mexer no consenso da rede. Isto reduz drasticamente o risco de implementação e facilita ajustes futuros. O reverso da medalha é a maior complexidade, nomeadamente com a introdução de componentes como bundlers e paymasters. Ainda assim, estes operam fora do protocolo central e podem ser atualizados sem consenso global na rede.
A EIP-4337 apresenta um ecossistema sofisticado de componentes colaborativos para viabilizar o account abstraction. Conhecer estes elementos é fundamental para entender o funcionamento da proposta. Os principais são:
UserOperation: estes objetos são a base do sistema EIP-4337. Diferem das transações tradicionais; são objetos pseudo-transacionais com toda a informação necessária para executar operações em nome do utilizador. São criados por quem deseja realizar transações, mas ainda não estão assinados de forma convencional.
Entry point: smart contract único que coordena a execução das UserOperations agrupadas. Valida e processa as user ops, garantindo que cumprem os requisitos antes da execução.
Bundlers: nós especializados que recolhem UserOperations de um memory pool dedicado e as convertem em transações bundle. Podem ser geridos por block builders ou integrar-se com infraestruturas já existentes. São essenciais para a inclusão das UserOperations em blocos e para a sua validação.
Wallet contracts: smart contracts detidos pelos utilizadores, que validam assinaturas e executam transações com base em UserOperations.
Wallet factories: smart contracts que criam novas smart contract wallets sob pedido, permitindo aos utilizadores gerar as suas carteiras sempre que necessário.
Aggregators: contratos auxiliares opcionais que podem validar assinaturas agregadas, reduzindo custos de gás quando várias operações carecem de validação.
Paymasters: um dos elementos mais inovadores da EIP-4337, pois permitem opções flexíveis de pagamento de gás. Podem patrocinar transações, aceitar pagamentos em tokens ERC-20 ou aplicar lógica personalizada, melhorando substancialmente a experiência do utilizador.
O fluxo de transações na EIP-4337 marca uma rutura em relação ao modelo tradicional do Ethereum. Compreender esta dinâmica é essencial para dominar a AA em contexto prático. O processo divide-se em várias fases, todas fundamentais para o ciclo de vida da transação.
Quando um utilizador inicia uma transação no sistema EIP-4337, começa por criar um objeto UserOperation. Este contém toda a informação relevante: endereço de origem, parâmetros de gás (maxFeePerGas, maxPriorityFee) e dados específicos da operação. Importa notar que o campo de assinatura é tratado de forma distinta das transações convencionais – a validação depende da implementação da conta, não do protocolo.
Após a criação, a UserOperation é enviada para um memory pool dedicado, distinto do memory pool de transações tradicionais. Esta separação permite um processamento especializado das UserOperations sem interferir com o funcionamento habitual da rede Ethereum.
Depois de inseridas no memory pool, os bundlers – validadores especializados – processam as UserOperations. Agrupam várias UserOperations em transações bundle. Quando atuam como block builders, podem inserir diretamente estas bundles nos blocos, desde que as transações de entry point permaneçam válidas. Bundlers que não sejam block builders podem usar infraestruturas como mev-boost, mecanismos de proposer-builder separation ou APIs experimentais como eth_sendRawTransactionConditional.
Este agrupamento é vital para a eficiência do sistema, pois permite processar múltiplas UserOperations numa só transação, reduzindo custos e aumentando a capacidade de processamento.
Quando as UserOperations agrupadas chegam ao contract de entry point, inicia-se o processo de validação. O contract executa os bundles, validando cada operação. Para uma UserOperation ser aceite, o bundler invoca a função validateUserOp, que verifica assinatura e critérios específicos da wallet implementada.
Os bundlers mantêm uma whitelist de contracts de entry point fiáveis, garantindo que apenas processam UserOperations por intermédio de contratos auditados. Esta etapa é essencial para a segurança, prevenindo a execução de operações maliciosas ou inválidas.
Na fase final, a smart contract wallet executa efetivamente a UserOperation através da função ExecuteUserOp. Os bundlers agrupam UserOperations e iniciam a chamada à função handleOps do EntryPoint, que é incluída num bloco, concluindo o processo.
Este fluxo em várias etapas garante a validação e execução seguras das UserOperations, tirando partido das funcionalidades flexíveis do account abstraction.
Para perceber o valor das carteiras AA, é importante compará-las com as alternativas. As carteiras EOA (tradicionais) são contas externally owned com custos reduzidos e taxas de gás baixas, mas oferecem funcionalidade limitada e a segurança depende inteiramente da proteção das chaves privadas pelo utilizador – sem mecanismos internos de recuperação.
As carteiras MPC (Multi-Party Computation) também recorrem a EOA, mas distribuem a gestão das chaves por várias partes, eliminando pontos únicos de falha. Oferecem maior segurança face às EOA convencionais, mas continuam dependentes de assinaturas ECDSA e têm compatibilidade restrita. Requerem cuidados acrescidos nas políticas de autorização off-chain e na transparência.
As carteiras AA, construídas sobre contract accounts, são a opção mais avançada. Apesar dos custos de criação e taxas de gás mais elevados, permitem pagamentos de gás multimoeda, agrupamento de transações, métodos de assinatura variados e mecanismos de recuperação embutidos. Dispensam a gestão tradicional de chaves privadas e garantem segurança ao nível da rede. Exigem, contudo, auditorias rigorosas e a evolução contínua da compatibilidade com o ecossistema.
Compreender as diferenças entre EIP-3074 e EIP-4337 é fundamental para perceber porque a comunidade Ethereum converge para a EIP-4337. A EIP-3074 foi suspensa sobretudo por exigir alterações ao consenso, tornando-a uma EIP "nuclear". Propunha a introdução de dois novos OpCodes para dotar as EOA de funcionalidades de contrato – uma abordagem com vantagens, mas também constrangimentos significativos.
A EIP-3074 permite delegar o controlo da EOA a um contrato, facultando aos programadores um quadro flexível para criar transações inovadoras. Possibilita negociação em lote, agrupamento de operações e opções flexíveis de pagamento de gás, sem obrigar os utilizadores a implementar novos contratos.
O uso de contratos invocadores permite aceitar pagamentos em tokens distintos de ETH. Estes intermediários trustless facilitam transações entre patrocinadores e patrocinados, tornando o pagamento de gás mais acessível. A EIP-3074 permitiria ainda que qualquer EOA existente beneficiasse de funcionalidades de smart contract wallet sem perder compatibilidade com o ecossistema já implementado.
O maior obstáculo da EIP-3074 reside na necessidade de alterações ao consenso, com risco de hard fork em caso de falha. Isto representa um risco elevado para a rede Ethereum e exige coordenação alargada.
Além disso, embora a EIP-3074 dote as EOA de algumas características das contract accounts, permanece dependente das assinaturas ECDSA, bloqueando o acesso a métodos de assinatura mais avançados, eficientes e seguros. Esta limitação restringe a flexibilidade que a AA pretende introduzir.
A EIP-3074 foi suspensa, mas as suas ideias evoluíram. A EIP-5003 expande a EIP-3074 com o OpCode AUTHUSURP, que permite instalar código em endereços autorizados pela EIP-3074. Em conjunto com a EIP-3607, abre caminho à migração de EOA para contract accounts.
Com a EIP-5003, uma EOA que autorize outro endereço através da EIP-3074 pode permitir que esta entidade use o AUTHUSURP para definir o código da conta, convertendo-a numa contract account e permitindo métodos de assinatura mais sofisticados. Esta via de migração pode constituir uma ponte entre o ecossistema EOA existente e o futuro do account abstraction, embora o processo ainda esteja a ser desenvolvido.
O account abstraction, com destaque para a EIP-4337, representa uma evolução decisiva na relação dos utilizadores com a blockchain Ethereum. Ao separar as origens das transações das assinaturas e permitir o controlo das contas por smart contracts, a AA elimina vários entraves históricos à adoção em larga escala. Os benefícios incluem: segurança reforçada graças à lógica programável, pagamentos de gás flexíveis (multimoeda e patrocinados), agrupamento de transações e mecanismos de recuperação incorporados, eliminando o risco de perda de chaves privadas.
A EIP-4337 distingue-se pela implementação da AA sem alterar o consenso, tornando-se uma solução pragmática e de baixo risco face à EIP-3074. Apesar da maior complexidade (bundlers, paymasters, memory pool dedicado), estes elementos operam fora do protocolo central e podem ser ajustados sem consenso global. À medida que o ecossistema Ethereum se desenvolve, a integração da AA via EIP-4337 deverá reduzir barreiras de entrada e proporcionar aos utilizadores avançados ferramentas inovadoras para gerir as suas operações on-chain. A massificação das carteiras AA será, muito provavelmente, um passo determinante para a adoção generalizada do Ethereum.
A EIP-4337 é um standard Ethereum para account abstraction, que permite smart contract wallets com autenticação social e transações sem taxas de gás. Utiliza UserOperations, Bundlers, EntryPoint e Contract Accounts para melhorar a experiência do utilizador.
A EIP-4337 é um toolkit para criar funcionalidades de account abstraction, enquanto a EIP-7702 permite aplicar essas funcionalidades a externally owned accounts já existentes.
O ERC-4337 é um standard Ethereum para account abstraction, permitindo que smart contracts gerem contas e transações de utilizadores sem recorrer a wallet keys tradicionais. O objetivo é reforçar a segurança e a facilidade de utilização.
Não, EIP e ERC são distintos. EIP (Ethereum Improvement Proposal) incide sobre alterações ao protocolo, enquanto ERC (Ethereum Request for Comment) define standards para tokens e smart contracts.








