Abstração de contas além do Ethereum

·7 min de leitura·Por SSP Editorial Team
Capa de Abstração de contas além do Ethereum com o selo DEFI e uma grade de ícones sobre fundo azul-escuro

Abstração de contas além do Ethereum

A abstração de contas costuma ser apresentada como uma história do Ethereum — uma forma de transformar uma wallet de chave única em um smart account programável usando ERC-4337. Mas a ideia não para no Ethereum L1. Ela se propaga por dois caminhos bem diferentes: para fora, pelas cadeias EVM que compartilham o modelo de execução do Ethereum, e de forma nativa, para cadeias projetadas com a abstração de contas embutida no protocolo desde o primeiro dia. Este artigo mapeia esse panorama mais amplo, explica como a abstração de contas nativa difere do padrão ERC-4337 sobreposto ao Ethereum e tem o cuidado de delimitar uma fronteira em particular: onde termina o ecossistema geral e onde começa o que o SSP de fato suporta.

Este é o último artigo da nossa série sobre abstração de contas. Se os conceitos centrais são novos para você, comece por Abstração de contas a partir dos primeiros princípios e depois compare os dois modelos de conta em EOA vs smart account: as diferenças que importam. Aqui presumimos que você sabe, em linhas gerais, o que é um smart account, e ampliamos o olhar para o restante do mundo cripto.

O mesmo padrão, onde quer que a EVM rode

A primeira forma pela qual a abstração de contas se espalha é a mais simples: ela viaja junto com a EVM. O ERC-4337 não é uma mudança no protocolo base. É um padrão a nível de contrato construído sobre um contrato EntryPoint, objetos UserOperation, bundlers e paymasters opcionais — nada disso exige modificações de consenso. Essa escolha de projeto tem uma consequência poderosa. Qualquer cadeia que rode a Ethereum Virtual Machine pode hospedar o mesmo EntryPoint, a mesma infraestrutura de bundlers e os mesmos contratos de smart account.

É exatamente por isso que as principais L2 e sidechains EVM suportam o ERC-4337 do mesmo jeito que o Ethereum:

  • Polygon roda a EVM, então o mesmo contrato de smart account e o mesmo EntryPoint são implantados sem modificação.
  • Base é uma L2 EVM onde a abstração de contas ERC-4337 funciona igual à da L1.
  • BNB Smart Chain é compatível com EVM e hospeda o mesmo padrão.
  • Avalanche C-Chain roda a EVM e suporta a mesma abstração de contas a nível de contrato.

Como o padrão é portável, a lógica de smart account de uma wallet escrita para o Ethereum migra para essas cadeias praticamente sem alterações. É justamente essa portabilidade que permite ao SSP rodar seu projeto em todas as cadeias EVM que ele suporta — o mesmo contrato 2-de-2 se comporta de forma idêntica, seja implantado no Ethereum, Polygon, Base, BNB Smart Chain ou Avalanche. Para a visão prática, cadeia por cadeia, de como usar o SSP nessas redes, veja Usando o SSP na Polygon, Base e outras cadeias EVM.

Abstração de contas nativa: quando ela é o protocolo, não uma camada

A segunda forma pela qual a abstração de contas se espalha é fundamentalmente diferente. Algumas cadeias não esperaram por um padrão opcional — elas embutiram a abstração de contas diretamente no protocolo, de modo que não existe qualquer distinção entre "EOA e smart account". Toda conta é um smart account por padrão.

Starknet: toda conta é um contrato

A Starknet tem abstração de contas desde o primeiro dia. Na Starknet não existem contas de propriedade externa no sentido do Ethereum; toda conta é uma conta de contrato, escrita na linguagem Cairo. Como o comportamento da conta é definido por código de contrato a nível de protocolo, esquemas de assinatura, regras de validação, multisig e lógica de taxas são propriedades da própria conta, e não recursos acoplados depois.

O contraste com o Ethereum é instrutivo. No Ethereum, a conta padrão é uma EOA com uma única verificação ECDSA fixada no código, e o ERC-4337 existe para sobrepor contas programáveis por cima sem um hard fork. Na Starknet não há nada a sobrepor — a conta programável é a base. Não há um padrão EntryPoint separado a adotar, porque a abstração de contas não é opcional. A documentação da Starknet em docs.starknet.io descreve esse modelo de conta em detalhes.

zkSync Era: AA nativa com paymasters embutidos

A zkSync Era adota uma abordagem nativa semelhante. A abstração de contas faz parte do protocolo em vez de ser um complemento, e o sistema inclui suporte a paymaster embutido a nível de protocolo. No Ethereum, um paymaster é um contrato definido pelo padrão ERC-4337 e roteado através do EntryPoint; na zkSync Era, a funcionalidade de paymaster é um recurso de primeira classe da própria cadeia, então patrocinar taxas ou pagar gas em outro token faz parte de como a rede foi projetada para funcionar. A documentação da zkSync cobre sua abstração de contas nativa e seu modelo de paymaster.

AA nativa vs ERC-4337: a diferença central

Vale enunciar a distinção com clareza, porque ela é o coração conceitual deste artigo:

  • O ERC-4337 é um padrão opcional sobreposto a um protocolo inalterado. A camada base do Ethereum ainda só entende, de forma nativa, EOAs e sua única assinatura ECDSA. Os smart accounts existem porque os desenvolvedores concordaram com um conjunto comum de componentes on-chain e off-chain — o EntryPoint, o mempool alternativo, os bundlers — que simulam a abstração de contas a nível de protocolo sem uma mudança de consenso. É genial justamente porque não exigiu nenhum hard fork, e é portável para toda cadeia EVM pelo mesmo motivo.
  • A abstração de contas nativa é embutida no protocolo. Na Starknet e na zkSync Era, a própria cadeia trata cada conta como programável. Não há opção, nenhum padrão separado a adotar, nem distinção entre uma conta "normal" e uma inteligente — o smart account é a conta.

Ambas entregam os mesmos benefícios ao usuário final: múltiplos signatários, validação personalizada, lógica de recuperação e gas flexível. Elas simplesmente chegam por direções opostas — uma como uma camada cuidadosamente projetada, a outra como uma decisão fundacional de protocolo. Se você quer a especificação formal da abordagem em camada, o EIP-4337 é a referência canônica.

Onde o SSP se encaixa — e onde não

Esta é a fronteira a ser precisa. O SSP é uma wallet autocustodial construída em torno de um multisig 2-de-2: uma chave na extensão de navegador SSP Wallet e a segunda no app móvel SSP Key, sem que nenhum dispositivo consiga mover fundos sozinho. Em cadeias EVM, o SSP implementa isso como um smart account ERC-4337 cuja lógica de validação verifica uma única assinatura Schnorr agregada construída a partir das duas chaves. Os smart contracts do SSP foram auditados pela Halborn em 2025.

Como o ERC-4337 é portável por toda a EVM, a abordagem do SSP se estende às cadeias EVM que ele suporta: Ethereum, Polygon, Base, BNB Smart Chain e Avalanche C-Chain. O mesmo contrato de smart account 2-de-2 roda em todas elas.

Starknet e zkSync Era aparecem neste artigo como parte do ecossistema mais amplo — exemplos de cadeias onde a abstração de contas é nativa do protocolo. Elas não fazem parte do conjunto de cadeias suportadas pelo SSP. O SSP traz a abstração de contas ERC-4337 para as cadeias EVM listadas acima; ele não roda na Starknet, na zkSync Era ou em outras cadeias não EVM. Quando você ler sobre AA nativa em outros pontos do mundo cripto, trate isso como contexto de quão difundido o modelo de smart account se tornou, não como uma afirmação sobre onde o SSP opera.

Por que isso importa

Dando um passo atrás, o padrão fica claro: a experiência de smart account está se tornando o padrão em boa parte do mundo cripto, e não um recurso de nicho para usuários avançados.

  • Na EVM, o ERC-4337 leva contas programáveis ao Ethereum e a toda cadeia compatível sem um hard fork, o que é o que permite a uma wallet como o SSP oferecer na Polygon, Base, BNB Smart Chain e Avalanche a mesma segurança 2-de-2 que oferece no Ethereum.
  • Nas cadeias com abstração nativa, a pergunta "isto é uma EOA ou um smart account?" simplesmente não surge, porque há apenas um tipo de conta e ela é programável.

Para um usuário de autocustódia, a conclusão é que o rígido modelo de chave única já não é a única opção e, cada vez mais, não é a opção padrão. Quer a abstração de contas chegue como um padrão em camada, quer como um recurso nativo de protocolo, o destino é o mesmo: contas que você pode programar, com regras de segurança — como o multisig de dois dispositivos do SSP — que uma única chave privada jamais conseguiria impor sozinha. Para rever como esse modelo se compara à conta original do Ethereum, veja EOA vs smart account: as diferenças que importam, e para o padrão isoladamente, O que é abstração de contas (ERC-4337)?.

Compartilhar este artigo

Artigos relacionados