O que é abstração de conta e por que as frases-semente estão se tornando opcionais

Introdução

O conselho padrão para quem entra no mundo das criptomoedas não mudou em uma década: anote 12 palavras, guarde-as offline e nunca as perca. Essa instrução está correta no modelo antigo. Contas de propriedade externa (EOAs) derivam uma única chave privada dessa frase mnemônica, e quem detém a chave controla os fundos. Não há recuperação, limite de gastos ou forma de exigir uma segunda assinatura. Perdeu a frase, perdeu tudo.

A abstração de conta muda essa premissa. Em vez de acoplar a segurança da carteira a um único segredo, a AA transforma a própria carteira em um contrato inteligente, que pode impor regras arbitrárias sobre quem pode assinar, como o gás é pago e o que acontece quando uma chave é comprometida. A atualização não exige que os usuários entendam contratos inteligentes. Do lado de fora, uma carteira com chave de acesso parece fazer login em um aplicativo com impressão digital. Por baixo, a arquitetura é fundamentalmente diferente.

Este guia explica como a AA funciona no nível do protocolo, o que o ERC-4337 introduziu e por que essa mudança é importante para a autocustódia daqui para frente.

Como as carteiras Ethereum funcionavam antes da abstração de conta

Todo endereço Ethereum antes da AA era uma conta de propriedade externa. Uma EOA é controlada por uma chave privada derivada de uma frase-semente mnemônica. A conta não tem lógica on-chain. Ela pode enviar transações e assinar mensagens, mas não pode impor regras sobre essas ações. Para uma visão geral mais ampla dos tipos de carteira e seus mecanismos, veja o que são carteiras de criptomoedas.

Esse design tem três limitações estruturais:

Nenhum mecanismo de recuperação. Se a chave privada for perdida e não houver backup, a conta fica permanentemente inacessível. A Chainalysis estima que cerca de 20% de todo o Bitcoin está em carteiras cujas chaves são presumivelmente perdidas. Ethereum enfrenta o mesmo problema.

Nenhum controle de gastos. Uma EOA não pode limitar o tamanho da transação, restringir endereços de destino ou exigir múltiplas assinaturas. Uma única chave comprometida significa perda total. Organizações que precisam de controle compartilhado sobre fundos devem usar contratos multisig externos em vez de recursos nativos da conta. Para saber como esses setups multisig funcionam e onde falharam, veja como os maiores tesouros de cripto são protegidos e roubados.

O gás deve ser pago pelo remetente. Toda transação exige que a conta assinante tenha ETH para pagar o gás. Um novo usuário que recebe tokens no Ethereum não pode movê-los sem primeiro obter ETH de outro lugar. Isso cria um beco sem saída de integração que persiste desde o lançamento do Ethereum em 2015.

O que o ERC-4337 introduziu

O ERC-4337, de autoria de Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh e Shahaf Nacson, foi ao ar na mainnet do Ethereum em março de 2023. Ele entrega abstração de conta sem exigir um hard fork, o que foi uma restrição de design crítica. Propostas anteriores de AA (EIP-2938, EIP-3074) exigiam mudanças no nível do protocolo que os validadores e equipes de clientes relutavam em adotar. O ERC-4337 contorna isso operando inteiramente na camada de contrato inteligente.

O padrão introduz quatro componentes:

UserOperations. Em vez de enviar uma transação regular, os usuários enviam uma UserOperation (UserOp), uma estrutura de dados que descreve a ação pretendida. As UserOps entram em um mempool separado, não no mempool de transações padrão. Cada UserOp contém o endereço da conta inteligente do remetente, os calldata para a ação pretendida, limites de gás e um endereço de paymaster opcional.

Bundlers. Nós especializados coletam UserOps do mempool alternativo, agrupam-nas em uma única transação on-chain e enviam essa transação para a rede. O bundler paga o gás adiantado e é reembolsado pela conta inteligente ou por um paymaster. O agrupamento cria economia de gás: a sobrecarga fixa de uma transação Ethereum é paga uma vez por lote, em vez de uma vez por ação do usuário.

Contrato EntryPoint. Um contrato singleton implantado em um endereço canônico em todas as cadeias ERC-4337. Todas as UserOps agrupadas passam por esse contrato, que chama a função de validação de cada conta inteligente, executa a operação e lida com a contabilidade do gás. O contrato EntryPoint foi auditado pela OpenZeppelin e é imutável após a implantação, fornecendo uma âncora de confiança estável para todo o sistema.

Paymasters. Contratos opcionais que patrocinam o gás em nome dos usuários. Um paymaster pode pagar taxas em troca de tokens ERC-20, absorver custos como subsídio de dapp ou implementar qualquer outra lógica de pagamento. A função validatePaymasterUserOp do paymaster é chamada durante a validação, e o paymaster pode rejeitar operações que não atendam aos seus critérios.

O resultado: uma carteira não é mais um par de chaves. É um contrato inteligente com uma função validateUserOp programável que decide se uma determinada operação é autorizada.

O ciclo de vida do UserOperation em detalhes

Entender como um UserOp se move pelo sistema esclarece o que torna o AA diferente das transações regulares.

1. Construção. O aplicativo de carteira constrói um UserOp contendo a chamada de contrato alvo, parâmetros de gás e um nonce. Se um paymaster estiver envolvido, o endereço do paymaster e seus dados de aprovação são incluídos.
2. Assinatura. O usuário assina o UserOp. O formato da assinatura é definido pela conta inteligente, não pelo protocolo. Esta é a flexibilidade chave: a conta inteligente pode aceitar assinaturas ECDSA, assinaturas de passkey, limites de multisig ou qualquer outro esquema.
3. Submissão. O UserOp assinado é submetido a um bundler via endpoint JSON-RPC (eth_sendUserOperation). O bundler valida o UserOp fora da cadeia para garantir que não será revertido.
4. Empacotamento. O bundler agrupa múltiplos UserOps em uma única transação que chama a função handleOps do contrato EntryPoint.
5. Execução. O EntryPoint chama a função de validação de cada conta inteligente. Se a validação passar, o EntryPoint executa a operação. Se um paymaster estiver presente, o EntryPoint cobra do paymaster em vez da conta inteligente pelo gás.
6. Confirmação. A transação empacotada é incluída em um bloco. Cada UserOp dentro dela é tratado como uma ação independente que ou tem sucesso ou falha sem afetar outros UserOps no pacote.

Este ciclo de vida significa que o usuário nunca interage diretamente com o mempool do Ethereum. O bundler lida com a estimativa de gás, gerenciamento de nonce e submissão de transações. Da perspectiva do usuário, a experiência é mais próxima de enviar um formulário em um site do que de transmitir uma transação bruta de blockchain.

Carteiras passkey e o fim das frases-semente

A consequência mais visível do AA é que as carteiras agora podem autenticar usuários com passkeys em vez de frases-semente.

Uma passkey é uma credencial criptográfica armazenada no enclave seguro do dispositivo (o Secure Enclave em dispositivos Apple, Titan M em Google Pixels ou TPM em máquinas Windows). O usuário autentica com impressão digital, reconhecimento facial ou PIN do dispositivo. A chave privada nunca sai do hardware.

A Coinbase Smart Wallet, lançada em junho de 2024, usa essa abordagem. A criação de conta leva menos de 10 segundos. O usuário autentica com biometria, e a carteira implanta uma conta de contrato inteligente que reconhece essa passkey como um signatário válido. Não há frase-semente para anotar, nenhuma extensão de navegador para instalar. A Coinbase relatou ter implantado mais de 10 milhões de contas inteligentes por meio desse fluxo até o início de 2026.

A Safe (antiga Gnosis Safe) integrou a assinatura por passkey em sua estrutura de conta inteligente. Os usuários podem adicionar uma passkey como um dos múltiplos signatários em uma conta multisig, combinando a conveniência do login biométrico com a segurança das assinaturas de limite.

A desvantagem é a dependência da plataforma. Uma passkey criada em um iPhone é sincronizada através do Chaveiro do iCloud. Se um usuário perder todos os dispositivos Apple e não puder acessar o iCloud, a passkey se perde. É por isso que a recuperação social existe como uma camada complementar. As carteiras passkey são mais fortes quando combinadas com pelo menos um signatário de backup que usa um método de autenticação diferente.

Recuperação social: substituindo o backup por guardiões

A recuperação social, proposta por Vitalik Buterin em um post de blog de 2021, substitui o backup único (frase-semente) por um grupo de guardiões.

O mecanismo funciona da seguinte forma:

1. O proprietário da carteira designa um conjunto de guardiões. Os guardiões podem ser amigos, familiares, custodiantes institucionais ou até mesmo outros contratos inteligentes.
2. O proprietário define um limite. Por exemplo, 3 de 5 guardiões devem aprovar uma solicitação de recuperação.
3. Se o proprietário perder o acesso, ele inicia um processo de recuperação a partir de um novo dispositivo. Os guardiões confirmam independentemente a solicitação.
4. Uma vez que o limite é atingido, a conta inteligente substitui a chave de assinatura perdida por uma nova.

Os guardiões não precisam coordenar simultaneamente. A maioria das implementações inclui um atraso de tempo (tipicamente de 24 a 48 horas) durante o qual o proprietário original pode cancelar uma tentativa de recuperação fraudulenta.

Este modelo elimina o ponto único de falha. Perder um dispositivo não significa perder fundos, desde que guardiões suficientes estejam acessíveis. Também elimina o fardo da segurança física de armazenar uma frase-semente em um cofre à prova de fogo ou caixa de depósito de segurança.

A seleção de guardiões importa significativamente. Os guardiões devem ser distribuídos por diferentes geografias, canais de comunicação e tipos de relacionamento. Se todos os guardiões estiverem no mesmo grupo de chat e esse chat for comprometido, o mecanismo de recuperação se torna um vetor de ataque. Algumas implementações permitem adicionar guardiões institucionais (como um provedor de carteira de hardware ou um serviço de custódia) junto com contatos pessoais, criando defesa em profundidade.

Patrocínio de gás e como funcionam os paymasters

Antes da AA, um novo usuário que recebesse USDC na Ethereum não poderia enviá-lo a lugar nenhum sem primeiro adquirir ETH para pagar o gás. Esse problema do ovo e da galinha tem sido uma das maiores barreiras de integração no cripto.

Os paymasters resolvem isso. Um paymaster é um contrato inteligente que concorda em cobrir os custos de gás de uma UserOperation, sujeito às suas próprias regras.

Três modelos comuns de paymaster surgiram:

Gás patrocinado pela dapp. O aplicativo paga todo o gás para seus usuários. A dapp deposita ETH no contrato do paymaster e autoriza UserOps de seus usuários. Da perspectiva do usuário, as transações são gratuitas. As dapps tratam o gás como um custo de aquisição de clientes, semelhante ao frete grátis no comércio eletrônico. Esse modelo é particularmente eficaz em redes de Camada 2, onde os custos de gás são frações de centavo por transação.

Pagamento de gás com ERC-20. O paymaster aceita um token ERC-20 (USDC, DAI) em vez de ETH. O usuário paga pelo gás, mas em um token que já possui. O paymaster troca o token por ETH para reembolsar o bundler. Isso elimina a necessidade de os usuários manterem dois tokens separados (o ativo que desejam usar mais ETH para o gás).

Baseado em assinatura ou sessão. O paymaster autoriza um lote de operações dentro de uma janela de tempo ou limite de gastos. Uma dapp de jogos pode patrocinar 100 transações por dia por usuário, por exemplo. As chaves de sessão estendem esse conceito ainda mais: o usuário assina uma única transação que concede a uma chave temporária o direito de executar ações específicas (como movimentos em um jogo) sem exigir aprovação para cada uma.

Pimlico, Alchemy e Stackup operam infraestrutura de paymaster que as dapps podem integrar com algumas chamadas de API. Somente a Alchemy facilitou mais de um milhão de implantações de contas inteligentes por meio de seus serviços de paymaster e bundler. A economia é direta: em redes de Camada 2, onde os custos de gás são centavos, patrocinar transações de usuários é trivialmente barato.

EIP-7702 e o caminho para a abstração de conta nativa

O ERC-4337 funciona sem mudanças de protocolo, mas não é o estado final. O roteiro da Ethereum inclui o EIP-7702 (de autoria de Vitalik Buterin e Sam Wilson), que foi incluído na atualização Pectra.

O EIP-7702 introduz um novo tipo de transação que permite que uma EOA aponte temporariamente para o código de um contrato inteligente durante a duração de uma única transação. A EOA não se torna permanentemente um contrato inteligente. Em vez disso, ela pode se comportar como um quando necessário, ganhando acesso a chamadas em lote, gás patrocinado e lógica de validação personalizada, e depois reverter para o comportamento padrão de EOA.

Isso importa por dois motivos. Primeiro, permite que os detentores de EOA existentes (qualquer pessoa com uma carteira MetaMask hoje) acessem os recursos de AA sem migrar para uma nova conta. A migração tem sido um grande ponto de atrito: os usuários não querem mover todos os seus ativos, permissões e histórico on-chain para um novo endereço. Segundo, reduz os custos de gás porque a sobrecarga de implantação permanente de conta inteligente é evitada para usuários que só precisam de recursos de AA ocasionalmente.

A visão de longo prazo, discutida em várias postagens do roteiro da Ethereum Foundation, é que toda conta na Ethereum se torne uma conta inteligente por padrão. StarkNet e zkSync já implementam isso: nessas redes, toda conta é um contrato inteligente desde a criação. O EIP-7702 é a ponte que move a base de usuários existente da Ethereum em direção a esse modelo sem quebrar a compatibilidade retroativa.

Onde a abstração de conta está implantada hoje

A adoção de AA está concentrada em redes de Camada 2, onde os custos de gás tornam a experimentação barata.

Base tem a maior densidade de contas inteligentes, impulsionada pela Coinbase Smart Wallet. Até meados de 2026, a Base processou mais de 30 milhões de UserOperations. Os custos de gás abaixo de um centavo da rede tornam o patrocínio do paymaster economicamente trivial.

Polygon integrou AA cedo e oferece abstração de conta nativa no nível do protocolo em seu rollup zkEVM. O foco da Polygon em jogos e aplicações sociais alinha-se bem com o modelo de chave de sessão, onde os usuários precisam de muitas transações de baixo valor sem prompts de aprovação repetidos.

Arbitrum e Optimism suportam ERC-4337 através do contrato padrão EntryPoint. Os principais dapps em ambas as cadeias começaram a migrar os fluxos de integração para contas inteligentes, especialmente protocolos DeFi que querem oferecer primeiras negociações sem gás. Para contexto sobre como as atualizações do Ethereum permitiram que carteiras operassem como contratos inteligentes, a linha do tempo começa com a implantação do EntryPoint do ERC-4337.

Mainnet do Ethereum suporta ERC-4337, mas os custos de gás mais altos significam que o patrocínio do paymaster é mais caro. A maioria do uso de AA na mainnet vem de carteiras multi-assinatura de alto valor (Safe) em vez de dapps de consumo. A Safe gerencia mais de US$ 100 bilhões em ativos em suas implantações de contas inteligentes.

StarkNet e zkSync implementam abstração de conta nativa no nível do protocolo, o que significa que toda conta é um contrato inteligente por padrão. Esta é a direção para a qual o roteiro de longo prazo do Ethereum aponta.

O que isto não cobre

Este guia foca no mecanismo de abstração de conta e suas consequências imediatas para o design de carteiras. Ele não cobre:

• Comparação detalhada de implementações específicas de contas inteligentes (Safe, Kernel, Biconomy, ZeroDev)
• As implicações de MEV do mempool de UserOperation (para mecânicas de MEV, veja o que é MEV)
• Auditorias formais de segurança de contratos paymaster individuais
• Abstração de conta entre cadeias e como contas inteligentes interagem com pontes

Verificações práticas para avaliar uma carteira AA

Antes de confiar fundos a uma carteira de conta inteligente, considere estas perguntas:

O contrato inteligente é auditado? Verifique se a implementação da conta inteligente da carteira passou por auditorias de segurança de terceiros. Os contratos da Safe estão entre os mais auditados no DeFi. Implementações mais novas podem não ter o mesmo histórico.

O que acontece se o provedor encerrar as atividades? Uma carteira com chave de acesso vinculada a um único fornecedor cria uma nova forma de dependência. Procure carteiras que permitam adicionar vários signatários, incluindo uma chave privada tradicional como backup.

Onde a chave de acesso é armazenada? Entenda se a chave de acesso está vinculada ao dispositivo ou sincronizada por meio de um provedor de nuvem. O Chaveiro do iCloud e o Gerenciador de Senhas do Google sincronizam chaves de acesso, o que é conveniente, mas expande a superfície de ataque para incluir a segurança da conta na nuvem.

A carteira suporta recuperação social? Se o único método de autenticação for uma chave de acesso e ela for perdida, os fundos podem ser irrecuperáveis. A recuperação social adiciona uma rede de segurança. Verifique quantos guardiões a carteira suporta e se o processo de recuperação foi testado.

Em quais cadeias a conta inteligente funciona? Uma conta inteligente na mainnet do Ethereum tem um endereço diferente da mesma conta na Arbitrum, a menos que a carteira use implantação determinística CREATE2. Verifique a compatibilidade entre cadeias antes de depositar fundos em várias redes.

Qual é o caminho de upgrade? Algumas implementações de contas inteligentes são atualizáveis (a lógica do contrato pode ser alterada pelo proprietário). Isso é poderoso, mas introduz risco: uma chave de upgrade comprometida pode reescrever a lógica de validação da carteira. Verifique se os upgrades exigem atraso de tempo ou aprovação multipartidária.