Abstração de contas a partir de primeiros princípios

Se você já usou uma carteira autocustodial no Ethereum, usou uma conta de propriedade externa — uma EOA — sabendo disso ou não. A conversa sobre abstração de contas começa por entender o que é uma EOA, por que seu design limita tudo o que você pode fazer on-chain e como a abstração de contas do ERC-4337 contorna essas limitações sem tocar no protocolo base. Este artigo é a porta de entrada de uma série que leva você das limitações originais até como o SSP usa a abstração de contas para rodar seu multisig 2-de-2 em cadeias EVM.

Esta é a peça fundacional e conceitual. Para um passo a passo focado no próprio padrão ERC-4337, leia O que é abstração de contas (ERC-4337)? junto deste artigo; aqui construímos a intuição de por que o padrão existe.

A conta que o Ethereum lhe deu

O Ethereum tem dois tipos de conta. As contas de contrato são governadas por código. As EOAs — as carteiras comuns que a maioria das pessoas usa — são governadas por uma única chave privada. Quem detém essa chave pode autorizar qualquer transação a partir da conta, e o protocolo valida exatamente uma coisa: que a transação carregue uma assinatura ECDSA válida sobre a curva secp256k1, produzida pela chave que controla o endereço.

Essa regra única é elegante e também é a origem de cada limitação discutida abaixo. A validade de uma transação está cravada no protocolo. Você, dono da conta, não pode decidir o que significa "válido". O protocolo decide, e ele só sabe checar um esquema de assinatura de uma única chave.

O que esse design embute na raiz

Quatro limitações decorrem diretamente do modelo de uma chave, uma assinatura:

• Uma única chave é um ponto único de falha. Perca a chave e os fundos somem. Vaze-a e um atacante tem tudo. Não há segundo fator no nível do protocolo, nem cossignatário, nem política que pudesse ter bloqueado o roubo.
• Sem lógica de validação personalizada. Uma EOA não pode dizer "exija duas assinaturas", nem "permita este pequeno pagamento automaticamente, mas exija aprovação extra acima de um limite", nem "deixe esta chave gastar só em dias úteis". A conta não tem lógica. Ela tem uma checagem de assinatura.
• O remetente precisa ter ETH para o gas. Toda transação de uma EOA paga seu próprio gas em ETH. Um usuário novo que só tem um token ERC-20 mas nenhum ETH não consegue mover esse token, porque não pode pagar a taxa. O pagador da taxa e o remetente são forçados a ser a mesma conta.
• A UX da seed phrase não perdoa. Como a chave é a conta, a entrada significa anotar uma seed phrase e protegê-la para sempre. Não há caminho de recuperação que não envolva essa frase, e um único erro é permanente.

Não são bugs. São as consequências de a validação morar no protocolo em vez de na conta.

A ideia central: tornar a conta programável

A abstração de contas é a ideia de tirar essa lógica de validação do protocolo e colocá-la na própria conta. Em vez de a rede gravar "uma transação é válida se tiver uma assinatura ECDSA correta", uma smart account — um contrato que guarda seus fundos — decide por si só o que conta como transação válida.

Uma vez que a conta é um contrato programável, as quatro limitações se dissolvem em escolhas de design:

• Ela pode exigir duas assinaturas em vez de uma, que é exatamente como o multisig se torna possível sem suporte nativo do protocolo.
• Ela pode implementar regras de recuperação, de modo que uma chave perdida não seja mais o fim da história.
• Ela pode deixar que outra pessoa pague o gas, separando o pagador da taxa do remetente.
• Ela pode agrupar várias ações — aprovar e trocar, por exemplo — em uma única operação atômica.

A conta deixa de ser um par de chaves passivo e se torna lógica programável que você controla.

Como o ERC-4337 entrega isso sem um hard fork

A parte difícil é que mudar como o Ethereum valida transações normalmente significa mudar o protocolo base — uma atualização lenta, polêmica e que abrange toda a rede. O ERC-4337 contorna isso por completo. Ele introduz a abstração de contas como uma camada acima da rede existente, sem exigir mudanças de consenso.

O mecanismo se apoia em algumas peças:

• UserOperations. Em vez de enviar uma transação normal, uma smart account expressa a intenção como uma UserOperation — um objeto estruturado que descreve o que a conta quer fazer e como deve ser validada.
• Uma mempool alternativa. As UserOperations vivem em sua própria mempool, separada das transações comuns.
• Bundlers. Um bundler coleta UserOperations dessa mempool, empacota-as juntas e as submete à cadeia como uma transação de verdade, pagando o gas da camada base.
• O contrato EntryPoint. Um único contrato EntryPoint auditado é o ponto de estrangulamento on-chain. Ele chama cada smart account para rodar a lógica de validação própria daquela conta e então executa a operação se a validação passar.
• Paymasters. Um contrato paymaster opcional pode concordar em cobrir o gas de uma UserOperation, que é o que torna possíveis os fluxos sem gas e de pagamento em token.

Juntando tudo, isso permite que qualquer contrato atue como uma conta totalmente programável, validada por suas próprias regras, enquanto o protocolo Ethereum subjacente permanece exatamente como estava. O padrão é especificado na EIP-4337, e o próprio roteiro de abstração de contas do Ethereum acompanha para onde o esforço mais amplo está caminhando.

Por que isso importa para usuários de autocustódia

Para quem guarda as próprias chaves, a abstração de contas não é um detalhe abstrato de protocolo — ela muda o que uma carteira pode fazer com segurança:

• Multisig sem suporte nativo. Uma smart account pode exigir mais de uma assinatura, então uma carteira pode requerer que dois dispositivos independentes aprovem cada transferência. Esse é o bloco de construção em que o SSP se apoia, explicado em mais detalhe em Multisig EVM do jeito da abstração de contas.
• Opções de recuperação. A validação programável abre a porta para fluxos de recuperação que não se reduzem a uma única e frágil seed phrase.
• Patrocínio de gas. Paymasters significam que a taxa pode ser desacoplada do remetente, suavizando a pior fricção da entrada.
• Agrupamento. Vários passos podem ser liquidados como uma única operação, reduzindo tanto os cliques quanto o risco de falhar no meio do caminho.

A diferença prática entre uma EOA de chave única e uma smart account programável é grande o bastante para merecer seu próprio tratamento — veja EOA versus smart account: as diferenças que importam.

Onde o SSP se encaixa

O SSP é uma carteira autocustodial construída em torno do multisig 2-de-2. Uma chave vive na extensão de navegador SSP Wallet; a segunda vive no aplicativo móvel SSP Key. Toda transação é construída na extensão e cossinada no telefone, então nenhum dispositivo sozinho consegue mover fundos.

Em cadeias EVM, o SSP entrega esse 2-de-2 usando ERC-4337. A carteira é uma smart account ERC-4337 cuja lógica de validação exige ambas as chaves, e as duas assinaturas parciais se combinam — ao estilo MuSig2 sobre secp256k1 — em uma única assinatura agregada de Schnorr que o contrato verifica on-chain. Os smart contracts do SSP foram auditados pela Halborn em 2025. O design completo é o tema de Arquitetura de abstração de contas do SSP.

Em outras palavras, a capacidade abstrata descrita acima — uma conta que impõe sua própria regra de múltiplas assinaturas — é exatamente o que o SSP transforma em uma carteira funcional no Ethereum, no Polygon, na Base e nas demais cadeias EVM suportadas.

O resto desta série

Esta peça montou o problema e a ideia central. A série constrói a partir daqui:

1. Abstração de contas a partir de primeiros princípios — este artigo: por que as EOAs são limitantes e o que significa a abstração de contas.
2. EOA versus smart account: as diferenças que importam — uma comparação direta dos dois modelos de conta.
3. Arquitetura de abstração de contas do SSP — como o SSP conecta o ERC-4337 a uma carteira 2-de-2.
4. Patrocínio de gas e paymasters explicados — como os paymasters desacoplam quem paga de quem envia.
5. Abstração de contas em cadeias que não são Ethereum — como a mesma ideia viaja para além do Ethereum.

Comece com o explicativo do ERC-4337 se quiser o padrão isoladamente, e depois volte aqui para o panorama maior. A partir daí, a conta deixa de ser uma limitação e passa a ser algo em torno do qual você pode programar.