Por que as contas Ethereum tradicionais mostram suas limitações
O tema dá continuidade à discussão sobre wallets multisig e proteção por meio de várias chaves. Uma conta de propriedade externa, ou EOA, depende tradicionalmente de uma chave privada. A mesma assinatura autoriza as transações, enquanto o protocolo impõe 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.
Uma smart account coloca a lógica de validação em um contrato. Ela 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.
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, coleta 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 pagamentos 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.
Recursos que se tornam possíveis
A recuperação social permite que guardiões aprovem uma mudança de chave após um período. Os guardiões podem ser dispositivos, pessoas próximas ou instituições. Uma boa configuração evita que uma única pessoa recupere 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: approval, swap e depósito podem ocorrer em uma única operação lógica. Esse recurso reduz o número de etapas, mas o usuário ainda precisa compreender o efeito geral.
O pagamento do gas em tokens ou por meio de 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, taxas ou condições comerciais.
Smart account, multisig e wallet custodial
Uma multisig exige várias aprovações de acordo com uma regra. Uma smart account pode incluir esse recurso e muitos outros. As categorias, portanto, se sobrepõem.
Uma wallet custodial mantém as chaves para o usuário e pode redefinir o acesso segundo seu procedimento interno. Uma smart account non-custodial mantém as regras on-chain e os signatários sob controle do usuário, mesmo que uma interface ou serviço ajude a utilizá-los.
Algumas soluções mantêm uma chave de 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 “non-custodial”.
A melhor escolha depende do valor, da frequência de uso, da equipe e da capacidade de manter 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 após o lançamento às vezes têm permissões poderosas. A auditoria deve abranger sua interação com o núcleo.
A 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 enfrentam restrições 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 aumenta a resiliência.
Um paymaster pode censurar uma operação ou aplicar limites. Se a conta não tiver ETH e depender inteiramente desse serviço, uma falha poderá bloquear uma ação urgente.
Recuperação social: útil, mas exige preparação
Escolha guardiões independentes que não compartilhem o mesmo dispositivo, e-mail ou operadora. Três guardiões controlados por uma única conta na nuvem não criam três barreiras.
Defina um limite que resista a um comprometimento sem tornar a recuperação impossível. Dois de 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 praticado pode falhar no dia em que a chave principal desaparecer. Documente as etapas sem armazenar 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 é mais resistente a phishing do que uma senha ou um código SMS. Sua integração a uma smart account, porém, exige uma verificação compatível com a rede.
A sincronização em nuvem simplifica a troca de dispositivo, mas transfere parte do risco para a conta Apple, Google ou para 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 o acesso sem depender da empresa. Uma dependência proprietária pode se tornar problemática se o serviço for encerrado.
Para valores altos, combine passkey, chave de hardware 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 deve 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 revogue as que não forem mais necessárias com a ajuda do guia sobre approvals em cripto.
Uma falha do paymaster não deve tornar os fundos inacessíveis. Verifique se uma operação convencional paga em ETH ou outro paymaster pode assumir o controle.
Sessões, delegações e limites de gastos
Uma chave de sessão autoriza um conjunto limitado de ações durante 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 provedor 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 rede e do EntryPoint, conforme 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 blocos. Essa disciplina reduz o período 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 recompensas por bugs e incidentes. Uma auditoria não substitui uma análise das permissões.
Liste signatários, guardiões, módulos, bundlers e paymasters. Pergunte o que acontece se cada um desaparecer. A conta permite trocar de provedor 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 a smart account usando a documentação oficial. Adicione os métodos de recuperação e teste uma pequena transação. Confirme que é possível usar uma segunda interface ou chamar o contrato diretamente.
Depois, transfira um valor limitado. Teste um swap, uma approval, um saque e uma recuperação simulada. Monitore as taxas e os prazos do bundler.
Não exclua 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, faça com que a política seja aprovada por 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: seleciona aquelas que respondem a um risco específico e continua utilizável quando o provedor principal sofre uma falha.
