2-of-2 vs 2-of-3 vs m-of-n multisig: escolhendo o limiar certo

No artigo anterior cobrimos o que é multisig: uma regra de gasto em que m de n chaves precisam assinar antes do dinheiro se mover. O SSP te coloca por padrão num 2-of-2 — dois dispositivos, ambos exigidos, sem quórum pra discutir. Esse padrão é correto pra a maioria dos usuários solo entre "primeiros mil dólares" e "isto já é dinheiro de verdade pra mim". Não é o correto pra todo mundo.

Este artigo é o seletor. Três configurações cobrem a esmagadora maioria dos setups multisig do mundo real: 2-of-2, 2-of-3 e 3-of-5 (ou mais). Cada uma é genuinamente melhor que as outras sob condições específicas, e cada uma é genuinamente pior sob outras. Ao final deste artigo você deve conseguir responder: qual m-of-n corresponde ao que estou de fato tentando proteger?

TL;DR

• 2-of-2 é o padrão do stack pessoal. Melhor pra um usuário com dois dispositivos, baixo overhead de coordenação, valores modestos. Todo o produto SSP é construído em torno disso.
• 2-of-3 é o passo quando um usuário quer planejar pra perder uma chave — perder um celular, perder um backup, cenários de herança familiar. A versão "com redundância" do multisig solo.
• 3-of-5 ou mais alto é a resposta quando mais de uma pessoa precisa assinar, quando a geografia importa, ou quando os fundos pertencem a uma empresa / DAO / family office em vez de a uma pessoa.
• Subir m não só adiciona segurança — adiciona risco de liveness (mais chaves precisando estar disponíveis) e custo de coordenação. O m-of-n certo minimiza a soma dos dois.
• Ir acima de 2-of-3 pra um único usuário geralmente é um erro. A proteção marginal é pequena; a dor operacional é grande.

As três perguntas que decidem o m-of-n

Pule o threat modeling formal por um segundo. Na prática, três perguntas decidem qual configuração encaixa:

1. Quem precisa assinar? Uma pessoa? Duas pessoas? Um time que rotaciona? Uma organização onde signatários entram e saem?
2. Qual é a falha dominante contra a qual você está se protegendo — perda ou roubo? Multisig cuida das duas, mas a razão certa entre m e n pesa uma sobre a outra. n mais alto significa mais redundância contra perda; m mais alto (relativo a n) significa mais resistência a roubo.
3. Qual é o custo operacional de perder um signatário? Se a resposta é "não consigo acessar meu celular por um dia" o custo é leve. Se a resposta é "o CFO está num voo quando a folha tem que sair" o custo é enorme.

Essas três linhas mapeiam de forma bem limpa nas três configurações abaixo.

2-of-2: o padrão solo-com-redundância

Setup: Duas chaves existem. Ambas precisam assinar. Padrão do SSP — uma chave na sua extensão de navegador, uma chave no app móvel SSP Key.

Melhor pra: Uma pessoa, uma wallet, dois dispositivos que não compartilham superfície de ataque (um laptop Mac e um iPhone, um Android e uma máquina Windows, etc.). A proteção vem da separação de dispositivos: malware no laptop não consegue alcançar o celular, e vice-versa.

Pontos fortes:

• O custo de coordenação mais baixo de qualquer multisig. Ambos os dispositivos são seus, ambos geralmente estão no seu bolso ou na sua mesa.
• Aumenta massivamente a barra pra roubo. Um atacante que comprometeu por completo um dos seus dois dispositivos ainda não consegue mover dinheiro. Ele tem que comprometer o outro — quase sempre um OS diferente, uma cadeia de ataque diferente — pra ganhar.
• Te força a manter dois seeds, em dois lugares, com dois backups distintos. Essa é uma postura padrão muito melhor do que o típico setup de seed-única-num-papel-na-gaveta.

Pontos fracos:

• Ambas as chaves são load-bearing. Perca qualquer um dos dois dispositivos e o seed dele e a wallet morre. Por isso o checklist do Self-Custody Fundamentals põe tanto peso em fazer backup de ambos os seeds separadamente. Não é opcional em 2-of-2.
• Sem quórum pra "votar contra" um signatário ruim. Se os dois signatários são você, isso não é problema; se você um dia compartilhasse uma chave com outra pessoa num 2-of-2, ambos teriam poder de refém.

Essa é a configuração que o post existente What is 2-of-2 multisig? destrincha em detalhe. Leia depois deste pra a mecânica específica do SSP; este artigo só está calibrando quando é a escolha certa.

2-of-3: quando um usuário quer planejar pra perda

Setup: Três chaves existem. Quaisquer duas precisam assinar. Disposição comum pra um usuário solo: uma num dispositivo "quente" pra uso diário, uma numa hardware wallet guardada em casa, uma num dispositivo de recovery guardado em outro lugar (um cofre alugado, a casa de um pai, um cofre de banco — algum lugar geograficamente separado).

Melhor pra: Uma pessoa, mas alguém que cruzou pra "se qualquer objeto único pegar fogo, eu quero ainda conseguir recuperar". Usuários de self-custody entre ~$10k e ~$100k frequentemente migram pra cá.

Pontos fortes:

• Sobrevive à perda (ou destruição) de qualquer uma chave. Incêndio em casa come sua hardware wallet? Você ainda tem laptop + dispositivo remoto — suficiente pro quórum 2-of-3.
• Roubo de qualquer uma chave ainda não é o bastante — o atacante teria que comprometer duas de três. Separação geográfica torna a terceira chave muito mais difícil de alcançar.
• Fornece um caminho de herança limpo. Você pode deixar a terceira chave com um familiar ou advogado, de um jeito que eles não consigam agir unilateralmente (eles só têm uma de três) mas possam combinar com uma das suas chaves restantes pra recuperar a wallet num cenário definido.

Pontos fracos:

• Mais chaves pra provisionar, fazer backup, testar. Cada uma precisa de um seed único e de um local de armazenamento único. Seed phrase best practices é leitura necessária antes de fazer isso.
• Superfície de ataque ligeiramente maior — três chaves significam três lugares onde um atacante pode tentar comprometer, mesmo que ele precise comprometer duas.
• Ensaio de recuperação mais complexo. Você deveria testar periodicamente que consegue de fato combinar duas das três chaves pra gastar. É uma tarefa operacional.

Um atalho mental útil: 2-of-2 te protege contra ataque ao custo de ser frágil à perda. 2-of-3 te protege contra os dois, ao custo de mais chaves pra administrar.

3-of-5 (e mais alto): quando times e tesourarias entram em cena

Setup: Cinco chaves existem, quaisquer três precisam assinar. Usado por empresas, partnerships, DAOs, family offices. As cinco chaves geralmente estão distribuídas entre pessoas, papéis e geografias.

Melhor pra: Fundos que não pertencem a um único humano. Em qualquer lugar onde duas ou mais pessoas legitimamente precisam autorizar gasto, e onde o cenário de "o único signatário está de férias" não deveria poder congelar operações.

Pontos fortes:

• Nenhuma pessoa sozinha controla o dinheiro. Dois signatários comprometidos ou rebeldes ainda não conseguem mover fundos.
• Continuidade operacional. Qualquer pessoa pode estar indisponível (doente, viajando, demitida) e os outros quatro ainda têm quórum.
• Suporta naturalmente separação de funções — um controller, um CFO, um CEO, um auditor externo e um signatário quente podem ser todos papéis distintos. O limiar pode ser sintonizado pra corresponder à governança da firma.

Pontos fracos:

• O overhead de coordenação é real. Conseguir que três de cinco humanos efetivamente assinem uma transação numa janela definida é genuinamente mais difícil do que conseguir que um ou dois dispositivos assinem no seu próprio bolso.
• Cada novo signatário adiciona superfície de ataque. Cinco chaves significam cinco dispositivos separados, cinco procedimentos de backup separados, cinco planos de sucessão separados pra quando um signatário sai.
• Workflows custom. A maioria das wallets de consumo não traz 3-of-5 de fábrica; você normalmente migra pra ferramentas especialistas (Safe, Casa, setups multisig custom) quando cruza esse limiar. O SSP Wave 1 é construído em torno de 2-of-2 e não é o lugar certo pra essa escala.

Uma variante comum — 2-of-3 com signatários sociais — fica entre 2-of-3 solo e 3-of-5 corporativo. Você fica com duas chaves; um familiar de confiança ou advogado fica com a terceira. Eles não conseguem gastar sozinhos (uma chave não basta), mas podem te ajudar a recuperar se você perder uma das suas.

O que o tamanho — e o que ele não — resolve

Ir de 2-of-2 pra 2-of-3 pra 3-of-5 não é um slider linear de "mais segurança". Algumas propriedades melhoram; outras pioram.

Subir em n ajuda com:

• Resiliência à perda (mais chaves significam mais redundância).
• Planejamento de herança.
• Disponibilidade operacional com múltiplos humanos.

Subir em n atrapalha:

• A quantidade de trabalho de higiene de seed-phrase que você tem que continuar fazendo pra sempre.
• O número de lugares onde um atacante tem que falhar em atacar, mas também o número de lugares onde ele tem que ter sucesso — que às vezes é pior se as chaves não são verdadeiramente independentes.

Subir em m (o limiar) ajuda com:

• Resistência a roubo (um atacante precisa de mais chaves).
• Minimização de confiança entre signatários (qualquer subconjunto abaixo de m não consegue agir).

Subir em m atrapalha:

• Liveness. Se m chaves têm que estar disponíveis pra gastar, então ter n - m + 1 chaves offline congela a wallet. Um 4-of-5 que exige quatro humanos se coordenando é famoso por ser frágil.

A arte está em escolher m e n de forma que o custo de disponibilidade de precisar de m signatários case com o benefício de segurança de precisar de m signatários. Pra maioria dos usuários solo, 2-of-2 cai no ponto ideal. Pra maioria dos times, 3-of-5. O caso intermediário — 2-of-3 pra usuário solo planejando pra perda — é a configuração mais subutilizada no self-custody retail.

O que isso significa pra você

Três conclusões:

1. Padrão pra 2-of-2 em uso solo abaixo de cinco dígitos. É pra isso que o SSP foi construído, é o que Meet SSP Wallet explica, e o setup de menor fricção que materialmente eleva sua postura de segurança.
2. Vá pra 2-of-3 quando o custo de perder uma chave exceder o custo de administrar três. Aproximadamente: quando você cruzou pra "isto é riqueza de verdade", quando você tem uma pergunta clara de herança, ou quando você já passou por um susto próximo de recovery.
3. Não pegue 3-of-5+ a menos que esteja protegendo fundos que pertencem a mais de uma pessoa. É a resposta certa pra orgs e não realmente pra indivíduos — mesmo os de alto patrimônio tendem a usar 2-of-3 com um ajudante custodial em vez de 3-of-5 completo.

O próximo artigo desta série, BIP48 explained: the derivation path behind SSP, entra em como uma wallet 2-of-2 (ou 2-of-3) é de fato construída on-chain — o padrão que permite que múltiplas chaves cooperem e a razão pela qual a maioria das wallets multisig modernas é interoperável.