Por dentro da arquitetura de abstração de contas da SSP

A SSP é uma carteira de autocustódia construída em torno de um multisig 2-de-2. Uma chave vive na extensão de navegador SSP Wallet, a segunda vive no aplicativo móvel SSP Key, e nenhuma transação se liquida a menos que ambos os dispositivos a aprovem. Em cadeias EVM, a SSP cumpre essa garantia com a abstração de contas do ERC-4337: a carteira é um smart account cuja lógica de validação aceita uma única assinatura Schnorr agregada, construída a partir das duas chaves. Este artigo percorre essa arquitetura de ponta a ponta — cada componente, o fluxo exato de assinatura e a propriedade de segurança que ele produz.

Se a abstração de contas é nova para você, comece por Abstração de contas a partir de primeiros princípios e pelo explicador focado em ERC-4337. Aqui assumimos que você já sabe, em linhas gerais, o que são um smart account e uma UserOperation, e nos concentramos em como a SSP os conecta.

As peças das quais a SSP depende

Antes de traçar o fluxo, ajuda nomear os componentes e o que cada um faz:

• O smart account. Em cadeias EVM, sua carteira SSP não é uma EOA controlada por uma única chave. É um smart account ERC-4337 — um contrato que guarda seus fundos e contém sua própria lógica de validação. Essa lógica é o coração do projeto: ela aceita uma transação apenas quando a assinatura fornecida corresponde à chave agregada esperada da carteira.
• Os dois dispositivos. A chave 1 vive na extensão de navegador SSP Wallet. A chave 2 vive no aplicativo móvel SSP Key. Cada dispositivo guarda uma parte e produz uma assinatura parcial. Nenhuma parte pode autorizar nada sozinha.
• A UserOperation. Em vez de uma transação normal, a extensão expressa sua intenção como uma UserOperation — um objeto estruturado que descreve o que o account deve fazer e a assinatura que o autoriza.
• O bundler. Um bundler retira a UserOperation do mempool dedicado, a empacota em uma transação real on-chain e paga o gas da camada base para enviá-la.
• O EntryPoint. Um único contrato EntryPoint auditado é a entrada on-chain de toda operação ERC-4337. Ele chama o seu smart account para executar a lógica de validação daquele account e então dispara a execução se a validação passar.

Um paymaster pode, opcionalmente, cobrir o gas de uma UserOperation; esse é um tópico próprio, tratado em Patrocínio de gas e paymasters explicados.

O fluxo de assinatura exato

Eis o que acontece, passo a passo, quando você envia uma transação a partir da SSP em uma cadeia EVM:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Lido como prosa:

1. Você inicia uma transação na extensão de navegador SSP Wallet, que guarda a chave 1.
2. A extensão constrói uma UserOperation ERC-4337 descrevendo a ação.
3. A chave 1 produz uma assinatura Schnorr parcial sobre essa operação.
4. A solicitação é enviada ao aplicativo móvel SSP Key (chave 2) para aprovação.
5. A chave 2 produz sua própria assinatura parcial.
6. As duas parciais são agregadas, no estilo MuSig2 sobre secp256k1, em uma única assinatura Schnorr.
7. A UserOperation, já portando essa única assinatura agregada, está pronta para envio.
8. Ela vai a um bundler, que a empacota em uma transação e paga o gas.
9. O bundler a envia ao contrato EntryPoint, que invoca o smart account da SSP. O account valida a única assinatura agregada contra a chave agregada esperada da carteira e, se válida, executa a chamada.

Ambos os dispositivos são necessários para chegar ao passo 6, o que torna isso um verdadeiro 2-de-2. Remova qualquer uma das parciais e a agregação não conseguirá produzir uma assinatura que o contrato aceite.

Por que a cadeia só vê uma assinatura

O detalhe que torna o projeto da SSP elegante é a agregação do passo 6. A extensão e o telefone não anexam, cada um, uma assinatura separada à operação. Suas duas assinaturas Schnorr parciais se combinam — no estilo MuSig2, sobre a mesma curva secp256k1 que o Ethereum já usa — em uma única assinatura Schnorr. O smart account confere essa única assinatura contra uma única chave agregada esperada.

Isso tem duas consequências sobre as quais vale a pena se deter:

• A pegada on-chain permanece pequena. A UserOperation carrega uma assinatura, não duas. Não há lista de signatários para armazenar ou percorrer, nem laço de verificação por signatário. O contrato faz a mesma quantidade de trabalho de validação que faria para um único signatário.
• A cadeia não consegue saber que é multisig. O que chega ao EntryPoint parece uma operação assinada comum. A imposição do 2-de-2 acontece em como a assinatura foi produzida — através de dois dispositivos — e não em alguma estrutura multipartite visível on-chain. Para um observador externo, a carteira se comporta como qualquer outro smart account.

Essa é a diferença entre a abordagem da SSP e um multisig ingênuo que posta N assinaturas separadas e verifica cada uma. A mecânica de fazer multisig dessa forma na EVM é explorada com mais detalhe em Multisig na EVM ao estilo da abstração de contas.

O que cada dispositivo realmente protege

Vale ser preciso sobre a propriedade de segurança, porque ela é o sentido inteiro da arquitetura.

• Nenhuma chave sozinha pode mover fundos. A chave 1 na extensão pode construir uma UserOperation e assinar sua metade, mas uma meia assinatura agrega-se em algo que o contrato não aceitará. A chave 2 no telefone pode aprovar e assinar sua metade, mas não pode originar nem concluir uma transferência por conta própria.
• Comprometer um dispositivo não basta. Um atacante que controle totalmente sua extensão de navegador ainda não consegue gastar, porque não consegue produzir a assinatura parcial da chave 2 sem o telefone. O inverso também vale. O modelo de ameaça que uma EOA de chave única não sobrevive — uma chave vazada, perda total — não se aplica aqui.
• A aprovação é explícita e em uma segunda tela. Como o passo 4 envia a solicitação ao aplicativo SSP Key, você vê e aprova a operação em um dispositivo fisicamente separado antes que ela possa ser agregada e enviada.

Essa é a mesma propriedade 2-de-2 descrita em O que é multisig 2-de-2?, realizada em cadeias EVM por meio de abstração de contas em vez de um opcode multisig nativo.

Os benefícios, em resumo

Reunindo os fios, a arquitetura garante aos usuários da SSP uma combinação específica difícil de obter de outra forma:

• Segurança multisig em toda cadeia EVM suportada. O mesmo projeto 2-de-2 roda no Ethereum, na Polygon, na Base, na BNB Smart Chain e na Avalanche, porque o ERC-4337 é um padrão em nível de contrato e não um recurso específico de cada cadeia.
• Uma pegada on-chain pequena. Uma única assinatura agregada significa que o smart account valida como um único signatário, mantendo a verificação enxuta.
• UX semelhante à de um único signatário. Do seu lado, parece aprovar uma transação em dois dispositivos, e não montar um comitê. Não há endereços de cossignatários para gerenciar nem um contrato multisig separado para configurar por transferência.
• Nenhuma mudança de protocolo necessária. Como tudo se apoia no ERC-4337, a SSP obtém tudo isso sem esperar que a abstração de contas na camada base seja lançada.

Uma nota sobre a auditoria

Uma arquitetura de segurança é tão confiável quanto a sua revisão. Os smart contracts da SSP foram auditados pela Halborn em 2025. Uma auditoria externa não torna nenhum sistema infalível, mas é um sinal de confiança significativo para a lógica do contrato que impõe a regra 2-de-2 descrita acima.

Para onde ir em seguida

Este artigo traçou a abstração de contas da SSP de ponta a ponta. Para aprofundar no padrão e nos conceitos ao redor:

• Abstração de contas a partir de primeiros princípios — por que as EOAs são limitantes e o que significa abstração de contas.
• O que é abstração de contas (ERC-4337)? — o padrão de forma isolada, incluindo os papéis da UserOperation, do bundler e do EntryPoint.
• Patrocínio de gas e paymasters explicados — como um paymaster pode cobrir o gas de uma UserOperation.
• Multisig na EVM ao estilo da abstração de contas — a mecânica do multisig na EVM em mais detalhe.

Para a especificação formal, veja EIP-4337; para o esforço mais amplo, o roteiro de abstração de contas do Ethereum acompanha para onde ele caminha. A lição: a SSP transforma a promessa abstrata de um account programável em uma carteira 2-de-2 concreta, onde dois dispositivos produzem uma assinatura e a cadeia simplesmente vê uma operação válida.