Account Abstraction: ERC-4337 e o Futuro da UX Cripto

Cripto tem um problema de experiência do usuário. Após mais de uma década de desenvolvimento, interagir com uma blockchain ainda requer gerenciar uma seed phrase de 12 palavras que nunca pode ser recuperada se perdida, manter um saldo de token nativo apenas para pagar taxas de gas em cada transação, e assinar mensagens hexadecimais crípticas sem contexto claro. Esses não são casos extremos -- são a experiência padrão para cada novo usuário. E representam a maior barreira individual para a adoção mainstream de blockchain.

Account abstraction é a melhoria de UX mais significativa na história do Ethereum. Substitui o modelo de conta rígido e dependente de chave por wallets de smart contract programáveis que podem implementar qualquer lógica de autenticação, patrocinar gas para usuários, recuperar acesso através de contatos confiáveis e agrupar múltiplas operações em um único clique. Este guia fornece um walkthrough técnico abrangente de como account abstraction funciona, os padrões que o tornam possível e como equipes de desenvolvimento podem construir com ele hoje.

O Problema de UX com Externally Owned Accounts

Ethereum tem dois tipos de contas: externally owned accounts (EOAs) e contract accounts. Desde que a rede foi lançada em 2015, toda interação voltada ao usuário foi iniciada por uma EOA -- uma conta controlada por uma única chave privada derivada de uma seed phrase. Este design fazia sentido como ponto de partida, mas criou um conjunto de restrições de UX que são fundamentalmente incompatíveis com a adoção mainstream.

O primeiro problema é o gerenciamento de chaves. Uma seed phrase é um ponto único de falha sem mecanismo de recuperação. Se você a perder, seus fundos desapareceram permanentemente. Se outra pessoa a obtiver, seus fundos desapareceram permanentemente. Não há reset de senha, suporte ao cliente nem recuperação de conta. Todo o modelo de segurança se baseia na premissa de que cada usuário pode armazenar com segurança e nunca perder uma sequência de 12 palavras aleatórias -- uma premissa que falha regularmente, mesmo entre usuários técnicos.

O segundo problema é o gas. Toda transação no Ethereum requer que o remetente pague gas em ETH. Isso significa que mesmo se um usuário receber USDC, um NFT ou qualquer outro token, ele não pode fazer nada com isso até também adquirir ETH. Para novos usuários, isso cria um problema do ovo e da galinha: eles precisam de ETH para usar o aplicativo, mas adquirir ETH é em si um processo de múltiplas etapas envolvendo exchanges, KYC e bridging. Aplicativos perdem usuários em cada um desses pontos de fricção.

O terceiro problema é a rigidez das transações. Uma EOA só pode executar uma operação por transação, deve assinar cada operação individualmente e não pode aplicar lógica de validação personalizada. Você não pode definir limites de gastos, exigir aprovação de múltiplas partes, automatizar pagamentos recorrentes ou delegar permissões temporárias -- todas funcionalidades que software financeiro tradicional fornece por padrão. Cada transação requer a chave privada completa para assinar, toda vez, sem exceções.

O Que Account Abstraction Realmente Significa

Account abstraction é o conceito de transformar cada conta no Ethereum em um smart contract. Em vez de contas serem controladas por uma única chave privada com verificação de assinatura ECDSA codificada, as contas se tornam programáveis -- podem definir sua própria lógica de validação, executar código arbitrário durante transações e implementar qualquer esquema de autenticação que o desenvolvedor escolher.

A palavra abstração aqui é usada no sentido da ciência da computação: separar a interface da implementação. Atualmente, o protocolo do Ethereum codifica como as contas funcionam -- assinaturas ECDSA, controle por chave única, pagamento de gas pelo remetente. Account abstraction remove essas premissas codificadas e permite que cada conta defina suas próprias regras. O protocolo se importa apenas que a conta diga que a transação é válida, não como ela determina a validade.

Isso não é uma melhoria menor. É uma mudança arquitetural que transforma o que uma conta blockchain pode ser. Uma smart contract account pode verificar assinaturas de qualquer esquema -- ECDSA, Ed25519, BLS, passkeys ou multisig. Pode implementar recuperação social através de endereços guardiões. Pode agrupar múltiplas operações em uma única transação atômica. Pode delegar permissões com session keys que expiram. E pode ter seu gas pago por terceiros, para que os usuários nunca precisem ter ETH.

O Caminho até o ERC-4337: Um Breve Histórico

Account abstraction não é uma ideia nova. A comunidade Ethereum tem trabalhado nessa direção desde os primeiros dias da rede, mas o caminho tem sido longo e complexo porque as implementações óbvias requeriam mudanças no protocolo central do Ethereum -- mudanças difíceis de coordenar e arriscadas de implantar.

O EIP-86, proposto por Vitalik Buterin em 2017, foi uma das primeiras propostas formais. Sugeria permitir que transações se originassem de qualquer endereço (não apenas EOAs) e que contratos pagassem seu próprio gas. No entanto, requeria mudanças profundas no formato de transação e no pipeline de validação, tornando-o muito arriscado para um hard fork. O EIP-2938, proposto em 2020, refinou a abordagem introduzindo um novo tipo de transação especificamente para account abstraction, mas ainda requeria mudanças na camada de consenso e enfrentava os mesmos desafios de implantação.

O ERC-4337, de autoria de Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh e Shahaf Nacson, adotou uma abordagem fundamentalmente diferente. Publicado em 2021 e implantado na mainnet do Ethereum em março de 2023, ele alcança account abstraction inteiramente na camada de aplicação -- sem nenhuma mudança de protocolo. Faz isso introduzindo um sistema de transações de nível superior que roda em cima da infraestrutura existente do Ethereum, usando um mempool separado, atores especializados chamados bundlers e um smart contract singleton chamado EntryPoint.

Arquitetura ERC-4337 em Profundidade

Entender o ERC-4337 requer entender seus cinco componentes centrais: UserOperations, o mempool alternativo, Bundlers, o contrato EntryPoint e Paymasters. Cada um desempenha um papel distinto no sistema, e juntos eles replicam a funcionalidade do pipeline nativo de transações do Ethereum -- mas com contas programáveis em vez de EOAs.

UserOperations

Uma UserOperation (ou UserOp) é o equivalente do ERC-4337 a uma transação. É uma estrutura de dados que descreve o que uma smart contract account quer fazer. Diferente de uma transação tradicional, que é assinada por uma chave privada e enviada diretamente ao mempool do Ethereum, uma UserOp é enviada a um mempool alternativo onde bundlers a coletam para processamento.

Uma UserOp contém campos análogos a uma transação regular -- sender, nonce, calldata, limites de gas -- mais campos adicionais específicos para account abstraction: initCode (para implantar a conta no primeiro uso), paymasterAndData (para patrocínio de gas) e signature (que pode ser qualquer formato que o contrato da conta espere, não necessariamente ECDSA). O campo sender é o endereço da smart contract account, não de um detentor de chave privada.

Bundlers

Bundlers são atores off-chain que monitoram o mempool de UserOperations, coletam UserOps válidas e as agrupam em uma única transação regular do Ethereum. O bundler chama a função handleOps do contrato EntryPoint, passando um array de UserOps. Do ponto de vista do protocolo Ethereum, esta é uma transação padrão enviada pela EOA do bundler -- o protocolo não tem conhecimento de account abstraction.

Bundlers desempenham um papel análogo aos block builders no pipeline de transações existente do Ethereum. Eles validam UserOps, simulam a execução, ordenam operações e submetem o bundle on-chain. São compensados através de reembolsos de gas e gorjetas opcionais. Qualquer um pode operar um bundler, e múltiplos serviços de bundler existem -- do Rundler da Alchemy ao Stackup, Pimlico e Biconomy.

O Contrato EntryPoint

O EntryPoint é um smart contract singleton implantado em um endereço canônico em toda chain EVM. É o coordenador central de todo o sistema ERC-4337. Quando um bundler submete um lote de UserOps, o EntryPoint processa cada uma através de um modelo de execução em duas fases.

Na fase de verificação, o EntryPoint chama a função validateUserOp na smart contract account do remetente. A conta pode implementar qualquer lógica de validação -- verificar uma assinatura ECDSA, validar um limiar de multi-sig, validar uma assertion de passkey ou qualquer esquema personalizado. Se a validação for bem-sucedida, o EntryPoint prossegue para a fase de execução, onde chama o contrato da conta para executar a operação real descrita no calldata da UserOp. Este modelo em duas fases garante que a validação é separada da execução, prevenindo que contas maliciosas manipulem o bundler.

Paymasters

Paymasters são o componente que habilita transações sem gas -- a melhoria de UX mais impactante em account abstraction. Um Paymaster é um smart contract que concorda em pagar os custos de gas de uma UserOperation em nome do usuário. Quando uma UserOp inclui um campo paymasterAndData, o EntryPoint chama a função validatePaymasterUserOp do Paymaster para confirmar que ele vai patrocinar o gas.

Os modelos de negócio para Paymasters são diversos. Um aplicativo pode patrocinar gas para todos os usuários para remover fricção (como aplicativos web não cobram usuários por requisições HTTP). Um Paymaster pode aceitar tokens ERC-20 como pagamento, então usuários pagam gas em USDC ou DAI em vez de ETH. Um Paymaster pode implementar modelos de assinatura, planos gratuitos ou patrocínio condicional baseado no comportamento do usuário. O insight chave é que o pagamento de gas é desacoplado do usuário inteiramente -- outra pessoa pode pagar, e a experiência do usuário se torna indistinguível de um aplicativo web tradicional.

Aggregators

Aggregators são um componente opcional mas poderoso para escala. Eles permitem que múltiplas UserOperations que usam o mesmo esquema de assinatura tenham suas assinaturas agregadas em uma única prova compacta. Para assinaturas BLS, por exemplo, centenas de assinaturas individuais podem ser combinadas em uma, reduzindo dramaticamente os dados on-chain e o custo de gas por UserOp. Embora não sejam amplamente adotados ainda, aggregators se tornam cada vez mais importantes conforme account abstraction escala para milhões de usuários.

Capacidades Chave Desbloqueadas por Account Abstraction

A arquitetura descrita acima não é apenas uma refatoração técnica -- ela habilita experiências de usuário inteiramente novas que eram anteriormente impossíveis com EOAs.

• Transações sem gas: Paymasters permitem que aplicativos patrocinem gas, deixando os usuários interagirem com dApps sem nunca adquirir ETH. Essa única mudança remove a barreira de onboarding mais comum em cripto.
• Recuperação social: Em vez de depender de uma seed phrase, usuários podem designar endereços guardiões -- amigos, familiares ou custodiantes institucionais -- que podem coletivamente autorizar uma rotação de chave se o usuário perder o acesso. Nenhum guardião individual pode agir sozinho, e o usuário mantém controle total em operação normal.
• Session keys: Smart accounts podem emitir chaves temporárias com permissões limitadas que permitem que um aplicativo submeta transações em nome do usuário sem exigir uma assinatura para cada uma. Um aplicativo de jogos pode solicitar uma session key válida por 30 minutos com um limite de gastos, habilitando gameplay fluido sem popups constantes da wallet.
• Transações em lote: Múltiplas operações podem ser agrupadas em uma única transação atômica. Um usuário de DeFi pode aprovar um token, trocá-lo e fazer stake do resultado em um clique em vez de três transações separadas, cada uma requerendo confirmação e pagamento de gas.
• Multi-assinatura com UX melhor: Smart accounts podem exigir que múltiplas partes aprovem uma transação enquanto apresentam uma interface simples. Tesouros corporativos podem aplicar políticas de aprovação dois-de-três, limites de gastos e endereços permitidos -- tudo aplicado pelo contrato da conta em si.
• Lógica de validação personalizada: Contas podem usar qualquer método de autenticação -- passkeys WebAuthn (autenticação biométrica via impressão digital ou Face ID), módulos de segurança de hardware, aprovações com time-lock, restrições geográficas ou qualquer combinação. A conta define sua própria política de segurança.

Implementações no Mundo Real

Account abstraction não é teórica -- está implantada na mainnet e usada por milhões de contas em todo o ecossistema EVM. Várias implementações importantes surgiram, cada uma com foco e público-alvo diferentes.

Safe (anteriormente Gnosis Safe) é a wallet de smart contract mais testada em batalha, protegendo mais de US$ 100 bilhões em ativos. Originalmente projetada para wallets multi-assinatura, a Safe adotou compatibilidade com ERC-4337, permitindo que sua arquitetura modular se integre com bundlers e paymasters. O sistema de módulos da Safe permite que desenvolvedores estendam a funcionalidade da wallet adicionando módulos para recuperação social, políticas de gastos, estratégias automatizadas de DeFi e mais -- tudo sem modificar o contrato central da wallet.

ZeroDev fornece um SDK focado em desenvolvedores construído sobre a smart account Kernel, uma conta ERC-4337 leve e modular. A arquitetura kernel do ZeroDev usa validators (para verificação de assinatura personalizada), executors (para lógica de transação estendida) e hooks (para verificações pré/pós execução). Seu SDK abstrai a complexidade de UserOps, bundlers e paymasters em chamadas de API simples, tornando direto para desenvolvedores integrar account abstraction em aplicativos existentes.

Biconomy oferece uma plataforma de account abstraction full-stack com sua smart account Nexus, infraestrutura de bundler e serviço de Paymaster. Seu SDK suporta session keys, transações em lote e operações cross-chain prontas para uso. A Biconomy focou pesadamente na experiência do desenvolvedor, fornecendo React hooks plug-and-play e um dashboard para gerenciar políticas de patrocínio de gas.

O Account Kit da Alchemy fornece uma camada de infraestrutura completa que combina uma implementação de smart account (Modular Account), um bundler de alto desempenho (Rundler, escrito em Rust) e APIs de gerenciamento de gas. Sua solução de wallet embarcada integra login por email e social com smart accounts, criando uma experiência de onboarding onde usuários criam uma conta blockchain usando suas credenciais do Google sem nunca ver uma seed phrase ou taxa de gas.

ERC-7702 e a Atualização Pectra: Account Abstraction Nativo

Enquanto o ERC-4337 alcança account abstraction na camada de aplicação, o ERC-7702 -- incluído na atualização Pectra do Ethereum -- traz account abstraction nativo ao nível do protocolo. Proposto por Vitalik Buterin e Sam Wilson, o ERC-7702 introduz um novo tipo de transação que permite a uma EOA delegar temporariamente sua lógica de execução a um smart contract pela duração de uma transação.

O mecanismo é elegantemente simples. Um novo tipo de transação inclui uma lista de autorização -- um conjunto de pares (endereço do contrato, assinatura). Quando a transação é processada, o campo de código da EOA é temporariamente definido como um designador de delegação apontando para o contrato especificado. Para aquela transação, a EOA se comporta como se fosse um smart contract, ganhando acesso a execução em lote, gas patrocinado e lógica de validação personalizada. Após a transação ser concluída, a delegação persiste até ser explicitamente revogada.

Isso é significativo porque resolve o problema de migração. Com o ERC-4337, os usuários devem implantar uma nova smart contract account e migrar seus ativos de sua EOA existente -- um ponto de fricção que desacelerou a adoção. O ERC-7702 permite que EOAs existentes ganhem capacidades de smart account no local, sem mover fundos ou mudar endereços. Os bilhões de dólares mantidos em EOAs em todo o Ethereum podem ser atualizados sem uma única transferência.

O ERC-7702 e o ERC-4337 são complementares, não concorrentes. O ERC-7702 lida com a atualização de conta no nível do protocolo, enquanto a infraestrutura do ERC-4337 -- bundlers, paymasters e o mempool de UserOperations -- continua fornecendo a camada de coordenação off-chain. Juntos, criam uma stack completa de account abstraction que funciona tanto para novas smart accounts quanto para EOAs atualizadas.

Impacto Através dos Setores

O impacto de account abstraction se estende muito além de melhorias na UX de wallets. Ele muda fundamentalmente o que é possível em cada setor que toca blockchain.

DeFi: Composabilidade com Um Clique

Em DeFi, account abstraction habilita swaps com um clique que combinam aprovação de token e execução em uma única transação. Estratégias de yield farming que requerem múltiplas operações sequenciais -- depositar, fazer stake, reivindicar recompensas, reinvestir -- podem ser agrupadas em um clique. Rebalanceamento automático de portfólio pode ser delegado a uma session key com limites de gastos rígidos, removendo a necessidade do usuário aprovar manualmente cada rebalanceamento. E Paymasters podem aceitar o token sendo negociado como pagamento de gas, então um usuário trocando USDC por WBTC paga a taxa de gas em USDC em vez de precisar de ETH.

Gaming: Blockchain Invisível

Para jogos blockchain, account abstraction torna a blockchain invisível para o jogador. Session keys permitem que um jogo submeta transações -- mover personagens, criar itens, completar missões -- sem um popup de wallet em cada ação. O jogo solicita uma session key no login com um limite de tempo e teto de gastos, e o jogador interage como faria com qualquer jogo tradicional. O gas é patrocinado pelo desenvolvedor do jogo através de um Paymaster, então o jogador nunca pensa sobre ETH. A blockchain se torna infraestrutura, não interface.

Enterprise: Wallets com Políticas Aplicadas

A adoção empresarial de blockchain foi prejudicada pela falta de controles de acesso e funcionalidades de compliance em EOAs. Account abstraction resolve isso diretamente. Um tesouro corporativo pode implementar uma smart account com controle de acesso baseado em papéis -- funcionários juniores podem iniciar transferências até um limite, funcionários seniores podem aprovar valores maiores, e o CFO pode autorizar qualquer coisa. Endereços de destino permitidos previnem transferências não autorizadas. Operações com time-lock adicionam um período de revisão antes que transações grandes sejam executadas. Esses não são controles no nível do aplicativo que podem ser contornados -- são aplicados pelo contrato da conta em si, on-chain e imutáveis.

Considerações de Segurança

Wallets de smart contract introduzem um modelo de segurança diferente das EOAs, e equipes construindo com account abstraction devem entender os trade-offs.

O risco de smart contract é a preocupação mais fundamental. A segurança de uma EOA depende apenas da chave privada -- o algoritmo ECDSA é bem compreendido e não tem vulnerabilidades conhecidas. A segurança de uma smart contract account depende da correção do seu código. Um bug no contrato da wallet, seus módulos ou seu mecanismo de upgrade pode comprometer cada conta usando aquela implementação. É por isso que implementações testadas em batalha como Safe, que protegeu mais de US$ 100 bilhões sem um exploit no nível do contrato, são fortemente preferidas sobre implementações personalizadas.

Mecanismos de upgrade requerem design cuidadoso. A maioria das implementações de smart account suporta upgrades para que novas funcionalidades possam ser adicionadas e bugs corrigidos. No entanto, um caminho de upgrade irrestrito significa que quem controla a autoridade de upgrade pode substituir toda a lógica da wallet. Boas práticas incluem upgrades com time-lock (dando aos usuários tempo para sair antes que mudanças entrem em vigor), upgrades controlados por governança e a opção para usuários optarem por não participar de upgrades congelando sua implementação de conta.

O gerenciamento de guardiões para recuperação social deve ser pensado cuidadosamente. Guardiões devem ser diversos -- não todos da mesma plataforma ou região geográfica. O limiar para recuperação deve ser alto o suficiente para prevenir conluio mas baixo o suficiente para permanecer prático. A rotação de guardiões deve ser direta, e deve haver um atraso de tempo nas ações de recuperação para dar ao proprietário legítimo tempo para intervir se um atacante comprometer um subconjunto de guardiões.

• Use implementações de smart account estabelecidas e auditadas em vez de construir contratos de wallet personalizados
• Implemente upgrades com time-lock com um período mínimo de atraso que dê aos usuários a capacidade de revisar e sair
• Projete conjuntos de guardiões com diversidade em mente -- diferentes dispositivos, plataformas, localizações geográficas e relações de confiança
• Defina permissões de session keys para o escopo mínimo necessário e a duração prática mais curta
• Monitore padrões incomuns no comportamento do bundler e consumo de gas do paymaster
• Realize auditorias de segurança regulares de quaisquer módulos ou lógica de validação personalizados adicionados à conta base

Construindo com Account Abstraction Hoje

Para equipes de desenvolvimento prontas para integrar account abstraction, o ecossistema oferece ferramentas e infraestrutura maduras. A escolha de SDK e provedor de infraestrutura depende das necessidades específicas do seu aplicativo -- se você prioriza modularidade, experiência do desenvolvedor ou controle de infraestrutura.

Comece escolhendo uma implementação de smart account. A arquitetura modular da Safe é ideal para aplicativos que precisam de multi-sig, permissões complexas ou módulos composáveis. A conta Kernel do ZeroDev é leve e altamente personalizável, tornando-a uma forte escolha para aplicativos com requisitos específicos de lógica de validação. A Nexus da Biconomy e a Modular Account da Alchemy fornecem soluções full-stack opinativas que minimizam a complexidade de integração.

Em seguida, selecione sua infraestrutura de bundler. Você pode operar seu próprio bundler para máximo controle, ou usar serviços hospedados da Alchemy, Pimlico, Stackup ou Biconomy. Para desenvolvimento e testes, bundlers locais como os fornecidos pela implementação de referência Infinitism permitem desenvolver e testar fluxos de UserOp sem depender de serviços externos.

Configure sua estratégia de Paymaster com base no seu modelo de negócio. Patrocinar todo o gas durante beta ou para novos usuários reduz a fricção de onboarding dramaticamente. Aceitar tokens ERC-20 como pagamento de gas permite que usuários avançados paguem em seu token preferido. Patrocínio condicional -- patrocinar gas para ações específicas mas não outras -- dá controle granular sobre seu orçamento de subsídio.

• Use permissionless.js ou os módulos de account abstraction do viem para desenvolvimento TypeScript-first com controle granular sobre a construção de UserOps
• Aproveite o aa-sdk da Alchemy ou o SDK da Biconomy para abstrações de nível mais alto que lidam com comunicação do bundler e integração do paymaster automaticamente
• Teste no Sepolia ou outras testnets onde o EntryPoint está implantado e serviços de bundler estão disponíveis
• Implemente ERC-4337 incrementalmente -- comece com transações sem gas via Paymasters, depois adicione session keys e agrupamento conforme as necessidades dos seus usuários evoluem
• Monitore o rollout do ERC-7702 e planeje sua estratégia de migração para que usuários EOA existentes possam atualizar no local quando o Pectra for ativado
• Use ferramentas como userop.js, a suíte de testes do Bundler e os métodos de simulação do EntryPoint para validar UserOps localmente antes de submeter a um bundler ativo

O Caminho Adiante

Account abstraction representa uma mudança fundamental em como os usuários interagem com blockchain. A combinação da infraestrutura de camada de aplicação do ERC-4337 e das atualizações de EOA no nível do protocolo do ERC-7702 cria um caminho claro para um futuro onde contas blockchain são tão flexíveis e amigáveis quanto contas em qualquer sistema de software tradicional -- mas com a autocustódia e resistência à censura que tornam blockchain valioso em primeiro lugar.

A tecnologia está pronta para produção hoje. Wallets importantes, provedores de infraestrutura e aplicativos adotaram o ERC-4337. Redes L2 como Base, Arbitrum e Optimism veem milhões de transações de smart accounts mensalmente. As ferramentas estão maduras, os padrões estão estáveis e o histórico de segurança está crescendo. Para equipes de desenvolvimento construindo aplicativos blockchain, não há mais razão para forçar os usuários pela experiência de EOA. Account abstraction é como cripto se torna utilizável para todos.

Na Xcapit, nossa equipe de desenvolvimento blockchain tem profunda experiência construindo wallets de smart contract, protocolos DeFi e infraestrutura Web3. Se você está integrando ERC-4337 em um aplicativo existente, projetando um novo produto com account abstraction desde o primeiro dia, ou planejando sua estratégia de migração ERC-7702, podemos ajudá-lo a navegar as decisões de arquitetura e entregar uma implementação pronta para produção. Saiba mais sobre nossos serviços de desenvolvimento blockchain.