No artigo anterior caminhamos por como o SSP realmente constrói uma carteira multisig on-chain: caminhos BIP48, dois xpubs em ordem lexicográfica, um redeem script contra o qual a chain checa. Todo esse mecanismo é construído em cima de um esquema de assinatura específico — ECDSA na curva secp256k1, o mesmo esquema com o qual o Bitcoin saiu em 2009 e que a maioria das chains herdou.
Este artigo é sobre o outro esquema de assinatura — Schnorr — e o que muda quando você constrói multisig em cima dele. A mudança de manchete é que o Schnorr suporta agregação: sob o protocolo certo, n assinaturas de n cosigners podem ser combinadas em uma única assinatura que, on-chain, parece uma assinatura normal de uma única chave. A carteira se comporta como uma carteira multisig, mas a chain nunca vê a multi-natureza. Isso tem consequências reais para fees, privacidade e que tipos de multisig se tornam economicamente viáveis.
TL;DR
- ECDSA é com o que a maioria do multisig atual (incluindo o SSP hoje) assina. Cada cosigner produz uma assinatura separada; a chain checa todas. Custo e pegada escalam com
n. - Schnorr é um esquema de assinatura diferente, habilitado no Bitcoin via o upgrade Taproot de 2021. Ele tem uma propriedade matemática — linearidade — que o ECDSA não tem. A linearidade permite que múltiplas assinaturas Schnorr sejam somadas numa única assinatura válida para uma chave combinada.
- MuSig2 é o protocolo moderno e prático que transforma essa propriedade matemática num protocolo multisig usável.
ncosigners executam um protocolo interativo curto, cada um contribuindo com uma rodada de nonces e uma assinatura parcial; o resultado é uma única assinatura Schnorr indistinguível de uma de chave única. - Isso é uma vitória estrita do lado da verificação — fees, inchaço do blockchain e privacidade todos se beneficiam. Não é uma vitória de graça do lado da assinatura: a agregação precisa de manuseio cuidadoso de nonces, e uma implementação com bug pode vazar chaves privadas.
- O SSP hoje usa BIP48 + ECDSA multisig nas chains que suporta. O roadmap é adicionar caminhos Schnorr/MuSig2 onde a chain suporte, sem quebrar o modelo 2-of-2 existente que os usuários já têm.
Uma revisão rápida do que uma assinatura faz
Uma assinatura digital prova duas coisas a um verificador: esta mensagem exata foi assinada por alguém que segura a chave privada para esta chave pública. On-chain, a "mensagem" é um hash de transação, a "chave pública" é o endereço (ou o que deriva o endereço), e o "verificador" é cada nó na rede. Se a assinatura confere, a transação é válida; senão, é rejeitada.
ECDSA — o esquema que o Bitcoin e a maioria das chains EVM usam — é bem entendido, conservador e funciona bem para o caso de um único assinante. O problema é o que acontece quando você quer múltiplos assinantes autorizando a mesma transação. ECDSA não tem maneira de combinar assinaturas. Se você quer two-of-two, a chain precisa armazenar as duas assinaturas e checar as duas. Three-of-five, cinco assinaturas. A transação cresce com a contagem de cosigners.
What is multisig descreve a parte do protocolo — m de n chaves, regras de redeem, a chain impondo o limiar. O que aquele texto anterior não se demora a explicar é o custo: sob ECDSA, todas essas assinaturas vivem na transação. Uma transação P2WSH 2-of-2 é genuinamente maior e mais cara de transmitir do que uma transação single-sig com o mesmo efeito.
O que o Schnorr muda
Assinaturas Schnorr, originalmente propostas no fim dos anos 80, foram evitadas no design original do Bitcoin por incerteza de patente em torno delas naquele momento. Elas são matematicamente mais limpas que ECDSA em um aspecto específico: são lineares. Se s1 é uma assinatura válida sobre uma mensagem sob a chave P1, e s2 é uma assinatura válida sobre a mesma mensagem sob a chave P2, então s1 + s2 é uma assinatura válida sobre aquela mensagem sob P1 + P2. Tanto as chaves quanto as assinaturas somam.
Por que isso importa: de repente se torna possível combinar assinaturas antes de elas chegarem na chain. Em vez de armazenar duas assinaturas na transação, você armazena uma — a soma. O verificador checa a única assinatura contra a soma das duas chaves públicas, que ambos assinantes conseguem calcular com antecedência. Da perspectiva da chain, a transação resultante parece indistinguível de uma transação assinada por uma única chave.
ECDSA não pode fazer isso. A matemática do ECDSA envolve um inverso multiplicativo que quebra a linearidade; somas de assinaturas ECDSA não são assinaturas válidas. Por isso o multisig baseado em ECDSA precisa enviar todas as assinaturas individuais on-chain. A chain inspeciona cada uma separadamente.
O Bitcoin enviou assinaturas Schnorr (via BIP340) como parte do soft fork Taproot de 2021. As assinaturas em si são levemente menores que assinaturas ECDSA (64 bytes versus ~71), mas o negócio bem maior é o que essa linearidade habilita quando você combina com multisig.
MuSig2 — multisig que parece uma única assinatura on-chain
A versão honesta de "você pode somar assinaturas Schnorr" é que você tem que fazer isso com cuidado. A abordagem ingênua — deixar cada cosigner escolher um nonce, compartilhar sua assinatura parcial, somar tudo — vaza material da chave sob assinatura repetida e é vulnerável a uma classe de ataques de "chave rebelde". Um protocolo prático de agregação tem que se defender de ambos.
MuSig2 é o resultado de cerca de uma década de refinamento sobre esse problema. É o padrão de facto para multisig Schnorr n-of-n: no momento de assinar, os cosigners trocam duas rodadas de nonces, cada um produz uma assinatura parcial, e um deles soma as parciais numa assinatura agregada final. O resultado é uma única assinatura Schnorr, válida contra uma única chave pública agregada, indistinguível on-chain de uma assinatura de chave única.
Alguns pontos importantes sobre MuSig2:
- Atualmente é
n-of-n. Para conseguir umm-of-nverdadeiro (e.g. 2-of-3) sob agregação você precisa de maquinaria adicional — FROST é a proposta líder — e isso ainda está sendo produtivizado. Então em 2026, o que o SSP agregaria de forma limpa é o default 2-of-2. As configurações 2-of-3 e maiores do artigo seletor ainda em sua maioria usam visibilidade on-chain estilo ECDSA. - Ainda exige os dois cosigners online para assinar. A agregação não reduz o número de assinantes necessários; só comprime a saída final. A UX é a mesma de hoje — dois dispositivos assinam a mesma transação — mas a pegada on-chain do resultado é menor.
- Uma implementação MuSig2 com bug pode vazar chaves. O manuseio de nonces é sutil. Implantações em produção se apoiam em bibliotecas bem auditadas (o módulo MuSig2 do
libsecp256k1, o stackrust-bitcoin, etc.) por essa razão.
O que isso significa para o SSP hoje
O SSP hoje, em cada chain que suporta, usa multisig ECDSA derivado de BIP48. Dois dispositivos, duas chaves privadas, duas assinaturas separadas on-chain. Isso é correto, é auditado (pela Halborn — veja a referência inside-ssp-2025-halborn-audits na peça 2-of-2 existente), e é interoperável com qualquer outra carteira compatível com BIP48. A desvantagem é que você paga o custo on-chain completo do 2-of-2.
O roadmap daqui pra frente, em português claro: adicionar um caminho de código Schnorr/MuSig2 para Bitcoin (onde Taproot está ativo e estável) que assine a mesma carteira 2-of-2 usando agregação em vez disso. A semântica de limiar da carteira não muda — ambos os dispositivos ainda têm que assinar. Os bytes on-chain encolhem, e a transação resultante parece um gasto single-sig.
Para o usuário, isso apareceria sobretudo como:
- Fees do Bitcoin levemente mais baixos por transação.
- Privacidade melhorada — a carteira para de gritar "eu sou uma carteira multisig" pra analítica de chain.
- Reconciliação mais rápida pra UI da carteira (levemente menos dados pra buscar e parsear por endereço).
Não é — e vale dizer isso claramente — uma atualização de segurança. A criptografia é comparavelmente dura, só estruturada de modo diferente. A razão pra adotar é eficiência e privacidade, não segurança bruta.
O que isso significa para custo, privacidade e UX
Três lugares onde isso pousa quando a agregação está amplamente implantada numa chain:
Custo. Bitcoin cobra fees aproximadamente por tamanho de transação em vbytes. Uma transação ECDSA P2WSH 2-of-2 é notavelmente maior que a transação Taproot-MuSig2 equivalente. Para carteiras de saldo baixo enviando quantias pequenas, a economia relativa de fee pode ser de 20–30%. Para negócios de alto throughput, a economia absoluta em fees anuais é dinheiro de verdade.
Privacidade. Hoje, quando uma carteira emite um gasto P2WSH 2-of-2, esse fato é visível pra qualquer um rodando um explorador de blockchain. Firmas sofisticadas de chain-analytics agrupam endereços por padrão de gasto, e "este endereço é multisig" é um sinal forte de cluster. Um gasto Schnorr-agregado parece idêntico a um gasto single-sig. O sinal de cluster desaparece.
UX. A UX de assinatura no SSP — assine no navegador, depois confirme no celular — não muda. Os dois dispositivos continuam produzindo assinaturas parciais; a carteira só combina elas antes de transmitir em vez de transmitir as duas. Da perspectiva do usuário a única mudança visível é "a carteira parece mais barata de usar".
Tem uma vitória mais profunda de UX no horizonte, também. Uma vez que a agregação m-of-n (via FROST ou similar) esteja pronta pra produção, você poderia imaginar uma carteira SSP 2-of-3 — como o setup solo de recovery que o artigo anterior descreve — que on-chain parece uma carteira single-sig normal. A terceira chave "de recovery" é genuinamente uma terceira chave de assinatura, mas a chain nunca precisa saber.
O que isso significa para você
Três conclusões:
- Você não tem que pensar em Schnorr pra usar o SSP corretamente. O setup 2-of-2 que você tem hoje é construído em multisig ECDSA bem auditado, e ele continua assim independente de como a agregação aterrissa. O próximo artigo da série (social recovery vs multisig) deliberadamente ignora a agregação porque a pergunta de quem pode gastar é independente de como a assinatura parece on-chain.
- A agregação é um upgrade de "fees e privacidade", não de "segurança". Se você um dia vir uma carteira vendendo "MuSig2 = mais segura", desconfie. A segurança criptográfica de um MuSig2 bem implementado é comparável a um multisig ECDSA bem implementado; as vitórias estão em outra parte.
- Observe o suporte da chain, não o marketing da carteira. Schnorr está ativo no Bitcoin e sendo adotado no mundo EVM via account abstraction. As chains que o suportam bem são onde o SSP vai lançar multisig agregado primeiro; nas demais, BIP48 + ECDSA segue sendo o default certo e seguro.
O próximo artigo desta série, Social recovery vs multisig, muda o foco da criptografia pras operações: quando você vai de multisig e quando o social recovery vence? Ambos protegem contra perder chaves; eles respondem perguntas diferentes. Pra uma revisão rápida de quais dispositivos o SSP usa hoje e por quê, Meet SSP Wallet segue sendo o ponto de partida.
