Carteiras MPC x multisig

Tanto as carteiras MPC quanto as multisig prometem a mesma manchete: nenhum ponto único de comprometimento. As duas cumprem. Mas chegam lá por caminhos diferentes, e os caminhos têm consequências diferentes para o que acontece quando as coisas dão errado — o único momento em que um modelo de segurança de fato importa.

Este artigo é o duelo técnico. Se você quiser primeiro o panorama das escolhas de autocustódia, comparando opções de autocustódia cobre o campo inteiro, inclusive carteiras de hardware e frases semente simples.

Duas respostas diferentes para o mesmo problema

O problema é enunciado do mesmo jeito nos dois casos: um segredo só controlando tudo é inaceitável, então distribua a autoridade.

O MPC divide a chave. Conceitualmente existe uma chave privada, mas ela nunca é montada em lugar algum. Em vez disso, partes dela vivem em lugares diferentes, e um protocolo criptográfico permite que essas partes cooperem para produzir uma assinatura sem que nenhuma delas conheça a chave inteira.

O multisig exige várias chaves. Existem de fato várias chaves privadas independentes. O endereço codifica uma regra — tantas destas chaves precisam assinar — e a blockchain impõe a regra ao validar a transação.

A distinção soa acadêmica. Não é. Uma é um fato sobre criptografia; a outra é um fato sobre a blockchain. O que a rede sabe determina o que acontece quando uma peça do sistema falha.

Como o MPC funciona de verdade

MPC — computação multipartes, aqui em geral esquemas de assinatura de limiar — permite que várias partes calculem juntas uma assinatura sobre uma mensagem enquanto cada uma guarda apenas uma parte da chave de assinatura. O NIST mantém um projeto de criptografia de limiar se você quiser o tratamento formal.

A saída é uma assinatura única e comum. On-chain, a transação de uma carteira MPC é indistinguível de uma assinada por uma pessoa com uma chave. Isso traz vantagens reais: funciona em toda rede, custa o mesmo que uma transação de assinatura única e não revela nada do seu arranjo de segurança a quem observa a rede.

A consequência dessa mesma propriedade é onde é preciso cuidado. Como a rede vê uma assinatura normal, a rede também não impõe nada sobre a sua política. Quantas partes existem, quem as guarda e quantas precisam cooperar são fatos sobre o software e os servidores, não sobre o registro. Mude o software e você muda a política.

A segunda coisa a olhar é a guarda das partes. Muitas carteiras MPC de consumo mantêm uma parte na infraestrutura do fornecedor. Muitas vezes é isso que torna possível a recuperação sem atrito — e também significa que a existência e a cooperação continuadas do fornecedor são peças estruturais do seu arranjo. Alguns projetos mitigam bem isso, com partes exportáveis ou caminhos de backup independentes. A pergunta não é se MPC pode ser bem-feito; é se o produto específico que você está considerando o fez de um jeito que você consegue verificar.

Como o multisig funciona de verdade

No multisig, a política faz parte do endereço. No Bitcoin e em outras redes UTXO, o endereço deriva de um script que nomeia as chaves públicas e o limiar; um gasto que não carregue assinaturas válidas suficientes é simplesmente inválido, e todo nó da rede o rejeita. Em redes com contratos inteligentes, o equivalente é uma conta cujo código não age sem as aprovações exigidas.

Ninguém precisa ser confiável para aplicar a regra, porque aplicar a regra é o que a rede faz. Se todo software de carteira envolvido sumisse amanhã, a regra continuaria valendo, e qualquer um com as chaves e uma ferramenta compatível ainda poderia gastar.

Os custos também são reais. Você gerencia várias chaves em vez de uma, os backups ficam mais complicados e a transação é maior — no Bitcoin, mais assinaturas significa mais bytes e uma taxa um pouco maior. Sua política também é visível on-chain, o que é uma consideração de privacidade: um observador vê que um endereço é 2-de-3 mesmo sem ver quem guarda o quê.

O que é multisig e por que importa trata do modelo com mais profundidade.

Onde a SSP se encaixa, com precisão

A SSP é um multisig 2-de-2, mas a honestidade exige um detalhe aqui, porque a implementação não é idêntica em toda rede.

No Bitcoin e nas demais redes UTXO, é multisig nativo no nível do script via BIP-48. Duas chaves, um script, imposto pelo consenso.

No Ethereum e em outras redes EVM não existe script nativo equivalente, então a SSP usa uma conta inteligente que verifica uma assinatura Schnorr agregada produzida a partir das duas chaves. Seus dois dispositivos executam um protocolo no estilo MuSig2 e a rede vê uma assinatura — mecanicamente, isso lembra mais, em formato, o MPC do que um script multisig do Bitcoin.

A distinção que importa não é "agregada ou não". São estes dois fatos, válidos em toda rede suportada pela SSP:

• As duas chaves são geradas nos seus dispositivos e guardadas só por você. A SSP não guarda parte alguma, chave alguma nem segredo parcial algum. Não existe parte nos nossos servidores para perder, requisitar ou manter como refém.
• A exigência está on-chain. No EVM, o código da conta inteligente não autoriza transação sem uma assinatura que só as suas duas chaves conseguem produzir. Esse código está implantado, é público e foi auditado — não é uma política que nosso software escolhe aplicar.

Na Solana, é um programa on-chain sem criador e sem chave de admin, em que o endereço do cofre é ele mesmo uma impressão digital do conjunto de membros e do limiar. Mecanismo diferente, mesma garantia.

Se a criptografia da agregação lhe interessa, assinaturas Schnorr e agregação multisig explica como uma assinatura pode exigir duas chaves.

Modos de falha lado a lado

Modelos de segurança se comparam melhor perguntando o que quebra.

Um dispositivo é comprometido. Os dois modelos sobrevivem. O atacante tem uma parte ou uma chave e não consegue assinar sozinho.

O fornecedor desaparece. O multisig sobrevive — as chaves e a regra on-chain são tudo o que se precisa. O MPC sobrevive só se você conseguir obter e usar suas partes sem o software do fornecedor, o que depende inteiramente do projeto.

O fornecedor é compelido a agir. Se um fornecedor guarda uma parte, essa parte pode potencialmente ser produzida sob compulsão legal e, dependendo do esquema, isso somado a outra parte pode bastar para mover fundos. Se o fornecedor não guarda nada — como na SSP, onde as duas chaves são suas — não há o que compelir.

Você perde uma chave ou parte. Isso depende do limiar, não da tecnologia. Um arranjo 2-de-3 de qualquer um dos tipos tolera uma perda; um 2-de-2 de qualquer um dos tipos, não. O que acontece se uma das suas chaves for comprometida percorre o caso da SSP em específico.

O software da carteira mente sobre o que você está assinando. Aqui nenhum modelo ajuda, e vale dizer isso com clareza. Distribuir autoridade protege contra chave roubada; não protege contra aprovar a transação errada. Por isso a pergunta interessante para os dois modelos é o que seus dispositivos verificam de forma independente antes de assinar — decodificar a transação crua em vez de confiar na descrição de um servidor.

Onde cada um ganha

O MPC ganha em redes sem boas primitivas de multisig, em tamanho de transação e taxas, em privacidade do arranjo e muitas vezes em experiência de uso — em especial na recuperação, onde um produto MPC bem desenhado pode ser muito mais amigável que malabarismo com vários backups de semente.

O multisig ganha em verificabilidade. A regra está no registro. Você não precisa confiar numa descrição do modelo de segurança; pode ler o endereço ou o contrato e ver a política. Ganha também em independência: um arranjo multisig com chaves que você guarda não tem empresa alguma no seu modelo de confiança.

Não há contradição em preferir respostas diferentes para propósitos diferentes. Um saldo pequeno do dia a dia numa carteira MPC bem construída e uma posição de longo prazo num multisig com chaves guardadas em separado é um arranjo perfeitamente coerente.

O que perguntar antes de se comprometer

Para qualquer lado que você penda, estas quatro perguntas separam uma boa implementação de uma ruim.

1. Quem guarda cada chave ou parte, e consigo obter todas? Se a resposta honesta inclui "o fornecedor, e não", você escolheu um modelo com contraparte.
2. O que acontece se o fornecedor sumir amanhã? Deve existir um caminho documentado que não passe por ele. Teste antes de precisar.
3. Onde mora a política? Num script ou contrato on-chain, ou em software? As duas coisas podem servir, mas só uma sobrevive à mudança do software.
4. O que cada dispositivo verifica antes de assinar? Uma segunda chave não acrescenta nada se os dois dispositivos assinam às cegas o que um servidor manda. Modos de falha do multisig e como a SSP os mitiga percorre esse e os demais jeitos pelos quais um arranjo de várias chaves pode ser minado na prática.

Se quiser o modelo sobre o qual a SSP é construída explicado desde o começo, comece por o que é multisig 2-de-2. E se a preocupação que trouxe você aqui é perder uma chave em vez de perder o controle de uma, recuperação social x multisig cobre a outra família de respostas.