Contas Inteligentes vs Segurança EOA: Análise Honesta de Riscos

Porque é que esta pergunta é mais difícil do que parece

A proposta das contas inteligentes, por vezes chamada abstração de contas, é que o modelo de conta detida externamente (EOA) é uma relíquia. Uma EOA clássica é uma única chave privada que assina todas as transações na Ethereum. Perde-se a chave, e os ETH e tokens desaparecem. Se a chave for alvo de phishing, o resultado é o mesmo. As contas inteligentes, formalizadas no padrão ERC-4337 e em propostas relacionadas, substituem essa chave única por uma carteira de contrato inteligente. Esse contrato pode exigir várias assinaturas, permitir limites de gasto, expirar sessões, patrocinar gás e recuperar de um dispositivo perdido através de guardianes.

No papel, isto parece uma melhoria absoluta. Na prática, cada nova funcionalidade é também uma nova forma de perder dinheiro. Investigadores de segurança que auditam estes sistemas usam uma formulação direta: a abstração de contas não reduz a superfície de ataque, muda-a de lugar. Uma vulnerabilidade que costumava estar em "por favor, não percas a tua frase-semente" passa agora para "por favor, não configures mal o teu conjunto de guardianes, por favor confia que um bundler não te vai fazer front-run, por favor confia que um paymaster se mantém solvente e por favor repara numa session key comprometida antes de ser utilizada".

Este artigo percorre essa mudança de lugar com honestidade. Foi escrito para programadores que lançam integrações de contas inteligentes e para utilizadores avançados que decidem se devem mover ETH real para uma. Parte do princípio de que já sabes o que é uma frase-semente e que já ouviste o termo "abstração de contas", e não constitui aconselhamento financeiro ou de segurança. A tua configuração, o teu modelo de ameaça e a tua tolerância a novas dependências são as variáveis que importam, não os materiais de marketing.

O que é que uma EOA realmente protege, e o que não protege

Uma EOA é apenas uma chave privada, o número escalar por trás de um endereço Ethereum. O endereço é uma função unidirecional dessa chave. Assina-se uma transação, transmite-se, a rede verifica a assinatura em relação ao teu endereço e a mudança de estado acontece. Não há nenhum contrato inteligente entre ti e a cadeia. A simplicidade é o modelo de segurança: não há literalmente mais nada para falhar.

Essa simplicidade é também o modo de falha. A chave é um número inteiro de 256 bits. Um ser humano não a consegue memorizar, pelo que as carteiras a codificam como uma frase-semente, normalmente 12 ou 24 palavras de uma lista fixa. Qualquer pessoa com a frase-semente é dona da conta. Não há reposição de palavra-passe, nem apoio ao cliente, nem limite de tentativas para assinaturas inválidas. O roubo, quando acontece, é definitivo. De acordo com estimativas ao estilo da Chainalysis amplamente citadas no setor, milhares de milhões de dólares em cripto foram perdidos para roubo de frases-semente e phishing, e raramente a cadeia em si é o problema. O ser humano, a área de transferência, a extensão do navegador, o site falso, a pré-visualização maliciosa de transações, são essas as superfícies que efetivamente falham.

As carteiras hardware como a Ledger e a Trezor deslocam a chave privada para fora do computador, pelo que uma infeção por malware no teu portátil não consegue assinar uma transação que não aprovaste. Não alteram o modelo na cadeia. A tua EOA continua a ser uma única chave. As carteiras multisig como a Safe acrescentam um requisito de assinatura m-de-n, pelo que a perda de uma chave é recuperável. Isso ajuda, mas é um remendo ao nível do contrato por cima de uma cadeia exclusiva de EOAs. A camada base continua a não saber o que é uma "sessão" ou um "limite de gasto".

O que uma smart account realmente acrescenta, e o que custa

A ERC-4337, o padrão da Ethereum para account abstraction, introduz quatro novos intervenientes e um novo fluxo. Em vez de o utilizador assinar uma transação diretamente, um utilizador de smart account assina uma UserOperation, uma mensagem estruturada que descreve o que pretende fazer, incluindo pagamento de gás, assinatura e qualquer patrocínio por um paymaster. Essa UserOperation vai para um mempool, e um bundler agrupa uma ou mais delas numa transação real on-chain que chama o contrato EntryPoint, que depois chama o contrato smart-account de cada utilizador para validar e executar a operação.

Três novos elementos são relevantes para a segurança. Primeiro, o próprio contrato smart-account, tipicamente implantado a partir de uma factory como a Create2, com lógica para validar assinaturas, verificar nonces, impor session keys e gerir a recuperação. Segundo, o bundler, um serviço off-chain que decide quais UserOperations incluir, em que ordem e a que preço de gás. Terceiro, o paymaster, um contrato que pode concordar em pagar o gás em nome do utilizador sob regras que o próprio paymaster define.

O custo é o grafo de dependências. Passa a confiar no código do seu contrato de conta, no código do EntryPoint, no comportamento de ordenação do bundler e na solvência e nas regras do paymaster. Uma EOA tradicional confia numa única peça de criptografia. Uma smart account confia numa stack. Essa stack é auditável, mas também é uma stack, com todas as formas de falha que as stacks trazem: drift de versões, factories abandonadas, versões de EntryPoint descontinuadas, paymasters que desaparecem com fundos dos utilizadores e bundlers que são hackeados ou sancionados.

Session keys: a funcionalidade que amplia silenciosamente o seu raio de impacto

As session keys são uma das funcionalidades de smart account mais úteis e uma das mais fáceis de usar de forma incorreta. Uma session key é uma chave temporária, frequentemente limitada a um contrato específico, com um teto de gasto e uma janela temporal, que permite a uma dapp assinar UserOperations em seu nome sem lhe pedir uma assinatura completa a cada vez. Estúdios de jogos e aplicações de trading utilizam-nas porque ninguém quer assinar uma transação para cada movimento on-chain num loop rápido.

O risco é estrutural. Na prática, criou uma nova EOA, financiou-a com uma allowance limitada e entregou-a a uma dapp. Se o frontend da dapp for comprometido, o atacante passa a deter essa chave limitada. Se a session key estiver mal delimitada, a allowance pode ser esvaziada dentro da janela. Se a revogação exigir que detete a fuga e submeta uma UserOperation de revogação, o atacante tem de perder uma corrida contra si e o bundler tem de estar disposto a incluir a sua revogação antes do drain do atacante.

Vários incidentes reais demonstraram este padrão ainda antes de a ERC-4337 se tornar generalizada. No final de 2023, uma versão maliciosa do Ledger Connect Kit, distribuída através de uma conta de editor npm sequestrada, injetou brevemente um drainer em dapps como a SushiSwap e a Zapper. Utilizadores com EOAs que assinaram a transação maliciosa perderam fundos da sua conta principal. Utilizadores cujas smart accounts tinham concedido session allowances amplas enfrentaram um drain semelhante dentro de qualquer âmbito que o atacante conseguisse explorar. O raio de impacto foi determinado inteiramente pelo que o utilizador tinha assinado previamente, e não pela distinção EOA versus smart account.

Do lado da smart account, a lição é que a revogação tem de ser barata, rápida e, idealmente, pré-armada. Revogar uma sessão não deve exigir um paymaster disposto a patrocinar o gás, um bundler disposto a incluir a sua transação ou um guardian para co-assinar. Se alguma destas peças estiver degradada, a revogação pode estagnar e o drain vence.

Paymasters e bundlers: nova confiança, nova censura

Um paymaster é um contrato que paga o gás de UserOperations em nome dos utilizadores. A narrativa de produto diz que os utilizadores podem transacionar sem deter ETH, uma verdadeira vitória de UX. A narrativa de segurança diz que é o paymaster que define as regras. Pode rejeitar a sua UserOperation, colocar o seu endereço numa lista negra ou recusar patrocinar certos tipos de chamada. Também pode ficar sem fundos e paralisar o seu fluxo a meio da sessão. Um paymaster que não opera é uma contraparte que não tinha com uma EOA.

Os bundlers são a contraparte equivalente para a inclusão. Com uma EOA, pode sempre submeter uma transação diretamente à rede, pagar a taxa base e ser incluído (sujando-se à censura ao nível da camada base, que é um tema à parte). Com a ERC-4337, depende de um bundler que recolhe a sua UserOperation. O bundler escolhe a ordem, e é nessa ordem que vive o MEV. Um bundler malicioso ou comprometido pode fazer front-running da sua operação, fazer um sandwich attack ao seu swap ou simplesmente ignorá-lo.

Existem bundlers com confiança minimizada, incluindo redes descentralizadas que revezam os proponentes e utilizam esquemas commit-reveal para reduzir o front-running. Não são gratuitos. Acrescentam latência, custo e complexidade operacional. Um bundler individual que corre por si é o mais próximo das suposições de confiança de uma EOA, mas também é um ponto único de falha que agora tem de operar, monitorizar e atualizar. O resumo honesto é que a ERC-4337 é um sistema multi-parte, e cada nova parte é uma nova forma de o sistema falhar ou censurar.

Incidentes em stacks adjacentes reforçam o padrão. Relays MEV-Boost já foram observados a censurar endereços sancionados pela OFAC, e o conjunto de relayers teve de ser diversificado. A mesma dinâmica aplica-se aos bundlers. Um mercado de bundlers pequeno significa uma superfície de censura pequena, e uma superfície pequena que um único ator pode dominar. O sistema é, em teoria, mais resistente à censura, mas apenas se o conjunto de bundlers for grande, descentralizado e ativamente monitorizado.

Recuperação social: um alvo quando mal configurada

A recuperação social substitui 'perde a seed phrase, perde tudo' por 'perde o dispositivo, pede aos seus guardiões que o restaurem'. Uma smart account pode designar N guardiões e exigir um quórum, por exemplo 3 de 5, para rodar a chave de assinatura. Soa como uma melhoria clara. Em termos de modelo de ameaça, altera quem pode tomar conta da sua conta, de 'qualquer pessoa que roube a seed' para 'qualquer quórum de guardiões que um atacante consiga comprometer'.

Uma recuperação social mal configurada desfaz a propriedade de segurança. Se os cinco guardiões forem familiares na mesma conta iCloud, uma Apple ID comprometida é uma tomada de conta. Se três dos cinco forem hot wallets num telemóvel que também usa para entrar em exchanges, o atacante que fizer phishing do login da sua exchange tem agora dois de três votos. Se um guardião for um smart contract que o utilizador não compreende totalmente, um caminho de upgrade nesse contrato de guardião é um caminho de rotação na sua conta. A segurança do fluxo de recuperação é a segurança do guardião mais fraco mais a segurança do limiar de quórum menos um.

Ataques reais já atingiram esta camada. Em 2017, o bug da biblioteca Parity Wallet congelou centenas de milhões de dólares em ETH ao matar o contrato de biblioteca de que as carteiras multisig dependiam. Não foi um incidente de 'recuperação social' no sentido da ERC-4337, mas tem a mesma forma: um smart contract que controla a recuperação torna-se um ponto único de falha. Em 2024 e 2025, vários incidentes envolvendo frontends comprometidos e editores de npm ou extensões de navegador sequestrados mostraram que a cadeia de abastecimento da qual um guardião depende faz parte do modelo de ameaça. Se o seu guardião for uma hardware wallet, também tem de confiar no fabricante, no caminho de atualização de firmware e na cadeia de abastecimento que a entregou.

A disciplina operacional é a mesma do multisig: diversidade de guardiões entre classes de dispositivos, jurisdições geográficas e legais, e idealmente entre famílias de fornecedores. O tempo de recuperação, medido em dias, é a métrica que importa. Uma recuperação que demora duas semanas é uma recuperação que um atacante pode ultrapassar em paciência ou contornar por engenharia social, especialmente se o atacante puder pressionar diretamente os guardiões.

O que isto significa para programadores e utilizadores avançados

Se está a construir sobre smart accounts, as implicações práticas decorrem dos modos de falha acima. Defina as session keys com o menor âmbito possível e a vida útil mais curta possível. Torne a revogação uma ação de um clique que não dependa da cooperação do paymaster ou do bundler. Trate o paymaster como uma contraparte contratual no seu modelo de ameaça, incluindo a sua solvência e a sua política de listas negras. Documente os pressupostos sobre o bundler que a sua aplicação assume e execute o seu próprio bundler se os seus utilizadores não tolerarem front-running.

Para auditorias, a stack de smart accounts tem mais locais onde pode falhar do que uma integração com EOA. O próprio contrato da conta, a versão do EntryPoint que utiliza, a factory a partir da qual faz deploy, a lógica do paymaster, a escolha do bundler, a validação das session keys, o conjunto de guardiões e o fluxo de recuperação precisam todos de uma análise separada. Tratar «usamos ERC-4337» como a história de segurança é o equivalente a tratar «usamos HTTPS» como a história de segurança numa aplicação web de 2010. É um ponto de partida, não uma resposta.

Para utilizadores avançados que detêm ETH real, a decisão não é «smart account ou EOA». É «a que riscos estou atualmente exposto e que conjunto de novos riscos é menor para mim». Um utilizador que guarda uma hardware wallet num cofre e nunca interage com dapps tem um perfil de risco pequeno e bem compreendido. Um utilizador que negoceia em DEXs diariamente, assina session allowances e faz bridges entre chains tem um perfil de risco muito maior e mais caótico, e pode genuinamente beneficiar de funcionalidades de smart account como sessões com âmbito definido e patrocínio de gas, aceitando ao mesmo tempo as novas dependências. O erro é assumir que a migração é uma atualização gratuita. É uma realocação de risco, e os novos riscos exigem as suas próprias mitigações.

Acompanhe o risco das smart accounts da forma inteligente

A segurança das smart accounts evolui rapidamente, e o mesmo acontece com as notícias em torno dela. Acompanhar rug-pulls de paymasters, falhas de bundlers, exploits de session keys e divulgações de auditorias manualmente é um jogo perdido. A Zippfeed destaca manchetes de segurança sobre smart accounts e Ethereum com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa detetar mudanças reais de risco antes que estas atinjam a sua wallet. Trate o feed de notícias como um alerta precoce, não como um sinal de trade, e combine-o com o modelo de ameaça apresentado neste artigo. smart account security vs eoa é exatamente o tipo de pergunta em que o sinal está nos relatórios de incidentes, não no marketing.