Por que as contas Ethereum tradicionais mostram suas limitações
O tema dá continuidade ao conteúdo sobre backup e recuperação de uma seed phrase. Uma conta externa, ou EOA, tradicionalmente depende de uma chave privada. A mesma assinatura autoriza as transações, enquanto o protocolo determina o formato de validação.
Essa simplicidade oferece um modelo claro, mas torna a recuperação difícil. Uma chave perdida não pode ser substituída. Um novo usuário também precisa ter o token nativo para pagar o gas, mesmo que receba outro ativo.
Um smart account coloca a lógica de validação em um contrato. Ele pode exigir duas assinaturas acima de determinado valor, aceitar uma passkey, limitar uma sessão ou permitir a recuperação após um período de espera.
A programação não elimina as chaves. Ela permite organizar sua função e substituição segundo regras verificáveis. A segurança passa a depender do contrato e de sua configuração.
Como funciona a ERC-4337
A ERC-4337 descreve uma account abstraction sem mudanças na camada de consenso. O usuário cria uma UserOperation semelhante a uma transação, com destino, dados, limites de gas, nonce e assinatura.
Essa operação entra em um mempool separado. Os bundlers agrupam várias UserOperations e chamam o contrato EntryPoint em uma transação Ethereum. O EntryPoint verifica as contas, cobra as taxas e executa as ações válidas.
Um paymaster pode financiar o gas de acordo com suas próprias regras. Assim, uma aplicação pode patrocinar uma primeira operação ou aceitar um pagamento em tokens. Essa conveniência cria uma dependência: o paymaster pode recusar a operação, ficar sem depósito ou aplicar uma política restritiva.
O bundler não mantém os fundos da conta. Ele transmite a operação e paga primeiro o gas da transação agrupada, recuperando depois o valor conforme o mecanismo previsto. Uma falha pode atrasar a execução sem necessariamente comprometer os ativos.
Funções que se tornam possíveis
A recuperação social permite que guardiões aprovem uma mudança de chave após um período de espera. Os guardiões podem ser dispositivos, pessoas próximas ou instituições. Uma boa configuração evita que uma única pessoa consiga recuperar a conta.
Os limites de gastos estabelecem um teto diário ou restringem determinados destinos. Uma chave de sessão pode autorizar um jogo a executar ações específicas durante um período definido, sem exigir uma assinatura completa a cada clique.
O batching reúne várias ações: aprovação, swap e depósito podem ocorrer na mesma operação lógica. Esse recurso reduz o número de etapas, mas o usuário ainda precisa entender o efeito geral.
O pagamento do gas em tokens ou por um patrocinador facilita a entrada de iniciantes. Isso não torna a transação gratuita: alguém paga, e o custo pode aparecer em um spread, em taxas ou em condições comerciais.
Smart account, multisig e wallet custodial
Uma multisig exige várias aprovações conforme uma determinada regra. Um smart account pode incluir essa função, além de muitas outras. Por isso, as categorias se sobrepõem.
Uma wallet custodial mantém as chaves para o usuário e pode redefinir o acesso segundo seu procedimento interno. Um smart account não custodial mantém as regras on-chain e os signatários sob controle do usuário, ainda que uma interface ou um serviço ajude a utilizá-los.
Algumas soluções mantêm uma chave em servidor, um serviço de recuperação ou um paymaster obrigatório. Elas continuam sendo programáveis, mas acrescentam uma camada de confiança operacional. Leia o modelo real em vez de confiar no rótulo “não custodial”.
A melhor escolha depende do valor, da frequência de uso, da equipe e da capacidade de manter os backups. Uma conta muito complexa pode ser mais difícil de recuperar do que uma wallet simples.
Os novos riscos de segurança
Um bug na lógica de validação poderia autorizar uma operação sem assinatura ou bloquear a conta. Os módulos adicionados depois do lançamento às vezes têm permissões amplas. A auditoria deve abranger a interação desses módulos com o núcleo.
A possibilidade de atualização cria outra questão: quem pode alterar a implementação? Uma chave de administrador comprometida poderia substituir o código. Um timelock e uma multisig reduzem esse risco, mas não o eliminam.
Os bundlers estão sujeitos a mecanismos antispam e simulam as operações. Uma UserOperation válida para o usuário pode ser recusada por uma infraestrutura específica. A possibilidade de trocar de bundler melhora a resiliência.
Um paymaster pode censurar uma operação ou aplicar limites. Se a conta não tiver ETH e depender totalmente desse serviço, uma falha poderá bloquear uma ação urgente.
Recuperação social: útil, mas precisa ser preparada
Escolha guardiões independentes que não compartilhem o mesmo dispositivo, e-mail ou operadora. Três guardiões controlados por uma única conta de nuvem não criam três barreiras.
Defina um limite que resista ao comprometimento sem tornar a recuperação impossível. Dois entre três podem ser adequados para uma pessoa física; uma organização pode exigir uma política mais estruturada.
Adicione um período de espera e uma possibilidade de cancelamento. Assim, o titular pode detectar uma recuperação fraudulenta. Os alertas devem ser enviados por vários canais.
Teste o processo com uma conta pequena. Um procedimento nunca repetido pode falhar no dia em que a chave principal desaparecer. Documente as etapas sem guardar todos os segredos no mesmo local.
Passkeys e autenticação moderna
Uma passkey usa um par criptográfico vinculado a um domínio ou aplicativo. Ela oferece mais resistência a phishing do que uma senha ou um código por SMS. Sua integração a um smart account, porém, exige uma verificação compatível com a blockchain.
A sincronização em nuvem simplifica a troca de dispositivo, mas transfere parte do risco para a conta da Apple, do Google ou de um gerenciador. Uma passkey vinculada apenas a um dispositivo exige um backup separado.
Verifique se a wallet permite exportar, adicionar um segundo autenticador e recuperar a conta sem a empresa responsável pelo serviço. Uma dependência proprietária pode se tornar problemática se o serviço for encerrado.
Para valores elevados, combine passkey, chave física e uma regra multisig, em vez de esperar que um único fator cubra todos os cenários.
Gas patrocinado e pagamento em tokens
O paymaster valida uma UserOperation antes de financiar seu gas. Ele pode exigir uma assinatura do serviço, uma assinatura, um token específico ou uma ação autorizada. Seu contrato precisa ter um depósito suficiente junto ao EntryPoint.
Uma aplicação pode oferecer algumas transações para facilitar o cadastro. Também pode converter um token do usuário para cobrir as taxas. Compare o custo implícito com o preço normal do gas da Ethereum.
O patrocinador não deveria receber uma autorização ilimitada sem justificativa. Leia as permissões e use o método para examinar um smart contract sem programar.
Uma falha do paymaster não deve tornar os fundos inacessíveis. Verifique se uma operação tradicional paga em ETH ou outro paymaster pode assumir o lugar do serviço.
Sessões, delegações e limites de gastos
Uma chave de sessão autoriza um conjunto restrito de ações por determinado período. Um jogo pode permitir movimentações internas sem expor o direito de transferir fundos para um endereço arbitrário. Uma aplicação profissional pode limitar um colaborador a determinados contratos e a um valor diário.
O escopo deve permanecer claro antes da assinatura: destinos, funções, tokens, limite e data de expiração. Uma delegação vaga equivale quase a entregar a chave principal. As interfaces deveriam mostrar as sessões ativas e permitir sua revogação sem depender do fornecedor que as criou.
O nonce e as regras antirreplay impedem a reutilização de uma autorização já consumida. As assinaturas também devem depender da blockchain e do EntryPoint, como especifica a ERC-4337. Sem esse contexto, uma operação poderia produzir um efeito inesperado em outro ambiente.
Depois de um teste, revogue a sessão e confirme o evento em um explorador de blockchain. Essa disciplina reduz o tempo de exposição de um dispositivo secundário ou de um aplicativo de jogos.
Como avaliar uma wallet baseada em account abstraction
Identifique o contrato da conta, sua versão e seu mecanismo de atualização. Consulte auditorias, programas de bug bounty e incidentes. Uma auditoria não substitui uma análise das permissões.
Liste os signatários, guardiões, módulos, bundlers e paymasters. Pergunte o que acontece se cada um deles desaparecer. A conta permite trocar de fornecedor por meio de uma interface alternativa?
Verifique a recuperação e os períodos de espera. Uma promessa como “nenhum risco de perda” muitas vezes esconde um terceiro capaz de restabelecer o acesso. Entenda as condições exatas.
Confira a compatibilidade com as aplicações utilizadas. Alguns protocolos tratam smart accounts, assinaturas ou mensagens off-chain de maneira diferente. Faça testes antes de transferir uma quantia elevada.
Migre sem expor todos os seus fundos
Primeiro, crie o smart account a partir da documentação oficial. Adicione os métodos de recuperação e faça uma pequena transação de teste. Confirme que é possível usar uma segunda interface ou chamar o contrato diretamente.
Em seguida, transfira um valor limitado. Teste um swap, uma aprovação, um saque e uma recuperação simulada. Monitore as taxas e os prazos do bundler.
Não apague a wallet antiga antes de validar os backups. Uma migração gradual reduz o impacto de um bug de configuração. Em uma organização, submeta a política à aprovação de vários responsáveis.
A account abstraction aproxima a wallet de uma conta programável adaptada aos usos modernos. Ela pode reduzir erros no onboarding, melhorar a recuperação e distribuir a autoridade. Em troca, acrescenta contratos, módulos e serviços. A melhor configuração não multiplica funções: mantém aquelas que respondem a um risco específico e continua utilizável quando o principal fornecedor fica fora do ar.
