Multisig em EVM ao estilo da abstração de contas

Multisig é simples de descrever — exigir mais de uma assinatura para mover fundos — mas a forma como é construído difere bastante entre blockchains. No Bitcoin, o multisig está embutido no próprio protocolo. No Ethereum e em outras cadeias EVM, não está, e esse único fato molda como funciona toda carteira multisig séria no Ethereum, incluindo a SSP. Este artigo explica por que o multisig em EVM é diferente, faz um passeio em linguagem simples pelas ferramentas de account abstraction que o tornam possível e mostra exatamente como a SSP entrega um verdadeiro 2-de-2 no Ethereum.

Se você chegou aqui a partir do início da série EVM, Ethereum na SSP estabelece a base; este artigo é o mergulho profundo na mecânica de segurança que está por baixo. O nível de leitura aqui sobe um degrau — intermediário — porque fazer justiça ao tema significa abordar ERC-4337 e a agregação de assinaturas com honestidade, sem rodeios.

Por que o multisig em EVM difere do multisig no Bitcoin

A maneira mais clara de entender a SSP no Ethereum é primeiro perceber por que a abordagem do Bitcoin não pode ser simplesmente copiada.

O Bitcoin tem multisig de script nativo. O protocolo inclui um opcode que permite travar fundos atrás de uma regra como "duas quaisquer destas três chaves públicas precisam assinar". Um endereço multisig no Bitcoin é apenas um endereço com essa regra de gasto anexada, e a rede a aplica diretamente. A SSP usa isso no Bitcoin e nas demais cadeias UTXO por meio do multisig de script BIP-48: duas chaves, um script, ambas as assinaturas exigidas. Se esse modelo base é novo para você, o que é o multisig 2-de-2 é o ponto de partida.

O Ethereum não tem um equivalente. Em uma cadeia EVM existem apenas dois tipos de contas. A primeira é uma EOA — uma conta de propriedade externa, controlada por exatamente uma chave privada. Uma chave, um signatário, ponto final; não há nenhum opcode nativo para exigir duas assinaturas em uma EOA. A segunda é uma conta de contrato inteligente, que tem código em vez de uma única chave de controle e faz o que esse código mandar.

Portanto, no Ethereum, "multisig" sempre significou uma carteira de contrato inteligente: um contrato programado para liberar fundos apenas quando sua regra de múltiplas assinaturas é satisfeita. Esse é o modelo que carteiras como a Gnosis Safe / Safe pioneiraram, e funciona bem. A contrapartida é que os contratos multisig clássicos on-chain costumam armazenar a assinatura de cada proprietário e verificá-las uma a uma na cadeia, o que custa gas e cresce com o número de signatários. A account abstraction oferece um caminho mais limpo, e é esse o caminho que a SSP toma.

Um resumo curto e honesto do ERC-4337

A account abstraction é a ideia de que sua carteira deveria ser um contrato inteligente — uma conta programável — em vez de um simples par de chaves. O ERC-4337 é o padrão que entrega isso no Ethereum sem alterar o protocolo base. Você não precisa dominá-lo para usar a SSP, mas alguns termos fazem o restante deste artigo encaixar. Para o tratamento completo, leia o que é account abstraction (ERC-4337); aqui vai o mapa em nível de usuário.

• Smart account. Seus fundos vivem em um smart account cujo código define o que conta como uma transação válida. Por ser código, a conta pode aplicar regras personalizadas — incluindo "exigir uma assinatura 2-de-2 válida".
• UserOperation. Em vez de submeter uma transação normal, um smart account expressa sua intenção como uma UserOperation: uma solicitação estruturada que diz o que ele quer fazer e carrega os dados de assinatura que a autorizam.
• Bundler. Um bundler é um serviço que reúne UserOperations, as embrulha em uma transação real on-chain e as submete. Ele paga o gas antecipadamente e é reembolsado; nunca obtém a capacidade de mover seus fundos.
• EntryPoint. Um único contrato EntryPoint auditado é o coordenador confiável on-chain. Ele recebe as UserOperations agrupadas e chama cada smart account para validar e então executar sua operação.
• Paymaster. Um contrato paymaster opcional pode patrocinar o gas ou permitir que as taxas sejam pagas em um token em vez da moeda nativa. Ele é opcional e independente do próprio multisig.

A percepção-chave: com um smart account, a regra de "quem pode autorizar uma transação" é software que você controla, não um comportamento fixo do protocolo. Essa é exatamente a liberdade de que o multisig precisa em uma cadeia que não tem multisig nativo.

Como a SSP faz o 2-de-2 em EVM

A SSP mantém a mesma promessa em cada cadeia que suporta: duas chaves em dois dispositivos, e nenhum deles sozinho consegue mover seu dinheiro. A chave 1 vive na extensão de navegador SSP Wallet; a chave 2 vive no app móvel SSP Key. Você constrói e assina uma transação na extensão e depois a aprova no seu telefone via um push — ambas as assinaturas são exigidas.

No Bitcoin essa garantia vem do multisig de script BIP-48. Nas cadeias EVM, a SSP a recria como um smart account ERC-4337 que verifica uma assinatura 2-de-2 agregada de Schnorr. Aqui está a ideia em alto nível, mantida genérica onde os detalhes internos exatos do contrato não são o ponto.

Cada uma das suas duas chaves produz uma assinatura parcial sobre a transação. Em vez de enviar ambas as assinaturas à cadeia separadamente, os dois dispositivos as combinam — usando agregação de assinaturas ao estilo MuSig2 — em uma única assinatura compacta. O smart account é programado para aceitar uma UserOperation apenas quando essa assinatura agregada é verificada contra a chave esperada da carteira. A cadeia, portanto, vê uma assinatura de aparência comum, e ainda assim essa assinatura é matematicamente impossível de produzir sem a participação de ambas as chaves.

Esse desenho tem vantagens reais frente a armazenar e checar N assinaturas separadas on-chain:

• Menor pegada on-chain. Uma assinatura agregada é mais barata de verificar e armazenar do que duas independentes, o que tende a significar menos gas pela segurança que você obtém.
• UX idêntica à de uma carteira de signatário único. Como a cadeia valida uma única assinatura, seu smart account se comporta como qualquer conta normal do ponto de vista da rede. Enviar ETH, mover tokens ERC-20 ou interagir com DeFi têm a mesma sensação — a segunda assinatura acontece discretamente entre seus dois dispositivos.
• O mesmo modelo em todo lugar. Schnorr e essa abordagem de agregação se apoiam em criptografia bem estudada sobre secp256k1, e o mesmo desenho de smart account se estende às cadeias EVM que a SSP suporta, incluindo Ethereum, Polygon, Base, BNB Smart Chain e Avalanche.

Os contratos inteligentes da SSP por trás disso foram auditados pela Halborn em 2025. Para a mecânica mais profunda da account abstraction — como o EntryPoint, o bundler e a etapa de validação se encaixam — recorra ao artigo sobre account abstraction (ERC-4337) em vez de tratar qualquer detalhe isolado de contrato aqui como canônico.

O que isso significa para você como usuário

A criptografia é interessante, mas o que importa no dia a dia é a proteção que ela compra.

• Ambos os dispositivos são exigidos para mover fundos. Uma transação só é válida depois que a extensão e a SSP Key contribuíram, cada uma, com sua parte. Possuir um dispositivo — ou uma chave — não é suficiente.
• Perder um dispositivo não é perder seu dinheiro. Como nenhum dispositivo isolado consegue assinar sozinho, um telefone perdido ou apagado ou um navegador reinstalado não entregam a ninguém o controle dos seus fundos. Restaurar o acesso é um tema à parte, com suas próprias salvaguardas; a recuperação é coberta em guias próprios, não aqui.
• Uma única chave comprometida não é um único ponto de falha. Se malware ou phishing capturar o que está em um dispositivo, ainda assim ele não consegue produzir a assinatura 2-de-2 agregada que o smart account exige. Um atacante precisaria comprometer ambos os seus dispositivos ao mesmo tempo — uma barreira muito mais alta do que esvaziar uma carteira de chave única.

Estas são proteções gerais, não garantias absolutas; boa higiene da frase-semente e segurança do dispositivo continuam importando. Mas o ponto estrutural permanece: dois fatores independentes precisam concordar antes de o valor se mover.

Um contraste neutro com carteiras EOA de chave única

A maioria das carteiras Ethereum são EOAs de chave única. São simples e amplamente suportadas, e para muitos usuários são suficientes. A contrapartida é que uma chave privada é a história inteira: quem a detém pode mover tudo, então uma única frase-semente vazada ou uma máquina comprometida podem ser fatais.

Um multisig de contrato inteligente muda esse perfil de risco ao exigir concordância entre duas chaves em vez de confiar em uma. Existem outras carteiras multisig de contrato inteligente — a Safe é um exemplo bem conhecido — e elas resolvem o mesmo problema central à sua maneira. A escolha específica da SSP é entregar o 2-de-2 por meio do ERC-4337 com uma assinatura de Schnorr agregada, de modo que você obtém a segurança do multisig com a pegada on-chain e a sensação cotidiana de uma conta de signatário único.

Para onde ir em seguida

Se você quer a base conceitual, leia o que é account abstraction (ERC-4337) e o fundamental o que é o multisig 2-de-2. Para ver como isso se encaixa no panorama mais amplo do Ethereum na SSP, volte a Ethereum na SSP. E quanto ao padrão em si, as fontes canônicas são a especificação do ERC-4337 e a visão geral da account abstraction da Ethereum Foundation. O fio condutor é o mesmo que percorre cada cadeia que a SSP suporta: duas chaves, dois dispositivos, uma assinatura — e você no controle.