Carteiras Multisig: como a aprovação M-of-N movimenta fundos

Carteiras multisig explicadas: uma carteira de múltiplas assinaturas só envia fundos quando pelo menos M de N chaves autorizadas aprovam a mesma transação, em vez de depender de uma única chave privada. Esse design transforma a custódia em um modelo operacional, com um fluxo de proposta e revisão, logística de taxas e escolhas de implementação específicas da cadeia que podem manter os fundos seguros ou deixá-los presos.

Principais Conclusões

• Uma carteira multisig requer duas ou mais chaves privadas para autorizar uma transação, tipicamente usando um limite de m de n, como 2 de 3 ou 3 de 5.
• O fluxo de trabalho central é um pipeline de aprovação: um signatário propõe uma transação, outros signatários adicionam assinaturas, a carteira verifica o limite, então a transação é transmitida.
• Multisig on-chain incorporado em um protocolo (como BitcoinP2SH) se comporta de maneira diferente de uma carteira de contrato inteligente multisig na Ethereum (como a carteira Safe), incluindo risco de contrato e compatibilidade dapp via ERC-1271.
• Multisig e mpc resolvem o “controle compartilhado” de maneira diferente: multisig deixa um rastro de aprovação on-chain vinculado a chaves distintas, enquanto o MPC produz assinaturas por meio de computação off-chain sem nunca montar uma chave completa.

Como as carteiras multisig mudam o controle de chaves

Uma carteira de assinatura única concentra a autoridade em uma chave privada, o que significa que uma comprometimento ou uma chave perdida pode ser terminal. Multisig muda essa superfície de controle dividindo a autoridade entre várias chaves e exigindo um limite de aprovações antes que os fundos se movam.

É por isso que multisig aparece com tanta frequência em discussões sobre segurança de carteiras e em conversas mais amplas sobre tipos de carteiras de cripto explicadas. Não se trata apenas de “mais chaves”. É um conjunto de regras sobre quem pode autorizar o quê.

O importante modelo mental é a governança, não a criptografia. Uma configuração de multisig codifica uma política de aprovação que corresponde ao comportamento de uma equipe, família ou DAO já existente. Se o processo real é “duas pessoas devem assinar”, um 2-de-2 corresponde à intenção, mas cria um risco de inatividade severa se qualquer um dos signatários desaparecer.

Se o processo real é “duas pessoas assinam, mas deve haver um caminho de recuperação”, 2-de-3 é o padrão comum porque tolera uma chave ausente enquanto ainda previne o controle unilateral.

O multisig também ocupa um lugar específico no espectro de custódia. Ele ainda é um modelo de carteira não custodial quando os signatários controlam as chaves e nenhum terceiro pode mover fundos unilateralmente. A diferença é que o “proprietário” agora é uma política de grupo em vez de uma única pessoa. Essa política pode ser implementada nativamente por uma cadeia ou aplicada por um contrato em cadeias de contratos inteligentes. Essa escolha de implementação é de onde vêm muitas surpresas operacionais.

O modelo M-de-N e fluxos de trabalho

A regra do limiar é o jogo todo: N é o número total de chaves autorizadas, e M é o número mínimo de assinaturas necessárias para aprovar uma transação. Configurações comuns mapeiam claramente para processos reais de aprovação: 2-de-2 para parceiros iguais, 2-de-3 para pequenas equipes com uma chave de backup, e 3-de-5 para controle em estilo de comitê que pode sobreviver a ausências.

O fluxo de trabalho importa porque o multisig é um pipeline de aprovação que roda toda vez que os fundos se movem. Um fluxo típico segue uma sequência ordenada:

1. Crie uma proposta de transação. Um signatário autorizado elabora o destino endereço, valor e qualquer dado de chamada. 2. Coletar assinaturas. Outros signatários autorizados revisam a proposta e a assinam com suas chaves privadas. 3. Verificar o limite. A carteira verifica se pelo menos M aprovações de signatários válidos estão presentes. 4. Transmitir e executar. A transação totalmente aprovada é enviada para a rede para confirmação.

Dois detalhes operacionais tendem a decidir se o multisig parece 'seguro' ou 'preso'. O primeiro é a disponibilidade do signatário: se M signatários não puderem responder dentro da janela que a organização precisa, a carteira se torna um gargalo. O segundo é o financiamento de taxas.

O EIP-86 destacou um ponto de dor concreto no início da história do Ethereum: operações de multisig podem exigir várias transações de ratificação, e os participantes podem precisar de ETH para taxas para submeter essas aprovações. Isso não é uma nota de rodapé teórica. É o tipo de atrito que aparece quando uma equipe está tentando mover fundos sob pressão de tempo e descobre que os signatários não podem nem mesmo pagar para aprovar.

multisig on-chain e contrato inteligente

O multisig estilo Bitcoin e o multisig estilo Ethereum podem parecer semelhantes por fora, mas falham de maneira diferente porque são construídos de forma diferente. O multisig on-chain é suporte nativo do protocolo, com Bitcoin P2SH como o exemplo canônico. As condições de gasto vivem nas regras de script da cadeia. A vantagem é uma área de superfície menor porque não há código de contrato separado para confiar. A desvantagem é que o conjunto de recursos é limitado pelo que o protocolo base suporta.

O multisig de contrato inteligente é um animal diferente. No Ethereum e em cadeias semelhantes, um multisig é frequentemente umacarteira de contrato inteligentecom a carteira Safe como a implementação de referência amplamente utilizada. O contrato detém ativos e impõe as regras de aprovação em código. Isso desbloqueia flexibilidade, mas introduz risco de contrato e trabalho de compatibilidade.

Compatibilidade é onde o multisig do Ethereum se torna menos sobre assinaturas e mais sobre padrões. Muitos aplicativos esperam uma mensagem assinada de uma conta de propriedade externa. Um contrato não pode produzir uma assinatura ECDSA normal porque não possui uma chave privada.

O ERC-1271 é o aperto de mão que corrige isso: ele define um método isValidSignature(hash, signature) que os aplicativos podem chamar quando o 'signatário' é um contrato, e exige retornar o valor mágico 0x1626ba7e quando a validação passa. Quando um dapp suporta o ERC-1271, ele pode tratar aprovações de uma carteira de contrato como autorização real.

Quando não suporta, o multisig pode ser bloqueado de fluxos de trabalho que dependem de mensagens assinadas, como sistemas de pedidos off-chain.

Onde o multisig é usado

Multisig aparece sempre que a necessidade real é controle compartilhado com um registro de auditoria. Tesourarias corporativas e de projetos usam multisig para forçar aprovações explícitas para transferências, de modo que nenhum operador único possa mover fundos unilateralmente. DAOs e fundos comunitários usam multisig como uma camada de controle pragmática, especialmente quando o grupo deseja responsabilidade visível sobre quem aprovou o quê.

Arranjos semelhantes a escrow são outra combinação natural. Um padrão 2-de-3 pode atribuir uma chave a um comprador, uma a um vendedor e uma a um árbitro neutro. Os fundos só se movem quando duas partes concordam, o que reduz a necessidade de confiar em um único intermediário. A mesma estrutura pode ser usada para fundos de parceria onde nenhum dos lados deseja que o outro tenha direitos de retirada unilaterais.

Configurações de segurança pessoal são o caso de uso mais discreto, e muitas vezes são mal interpretadas. Um 2-de-3 pode dividir chaves entre dispositivos e locais, ou adicionar um backup de parte confiável para recuperação. O objetivo não é criar um ritual de assinatura complicado. O objetivo é separar domínios de falha.

Se todas as chaves estão no mesmo ecossistema de dispositivos, ou todas as chaves são mantidas pela mesma pessoa "por conveniência", o rótulo multisig está fazendo trabalho de marketing, não de risco.

É também aqui que a tese do modelo operacional se torna relevante. O m de n certo é aquele que corresponde ao processo de aprovação e ao tempo de inatividade aceitável se um signatário desaparecer. Um 2-de-2 pode ser perfeito para uma conta conjunta até que uma chave seja perdida. Um 3-de-5 pode ser perfeito para continuidade até que o grupo perceba que as aprovações agora exigem agendamento.

Benefícios de segurança e trade-offs operacionais

O benefício de segurança do multisig é simples: comprometer uma chave não é suficiente para mover fundos. Isso reduz o raio de explosão de phishing, malware em um único dispositivo ou um único insider se tornando desonesto. Também cria uma responsabilidade mais clara porque as aprovações estão ligadas a chaves de signatários distintas e podem ser auditadas como parte do histórico de execução da carteira.

Os trade-offs são principalmente operacionais, e aparecem como modos de falha. A coordenação é a mais óbvia, mas os problemas mais caros geralmente são procedimentais. Revisões informais levam a assinar a carga errada, enviar para o destino errado ou aprovar o nonce errado. O multisig facilita a construção de uma cultura de lista de verificação, mas não impõe uma por padrão.

A logística de taxas é a outra armadilha recorrente. O EIP-86 destacou explicitamente que o multisig pode exigir várias transações de ratificação e que os participantes podem precisar de ETH para taxas. Isso cria uma questão de política que todo grupo multisig deve responder: quem é responsável por manter os signatários financiados para aprovações, e o que acontece quando não estão.

As abordagens de contrato de conta foram motivadas em parte pelo desejo de que o contrato mantenha ETH e pague taxas, precisamente porque "todo signatário precisa de gás" é uma suposição operacional frágil.

A escolha do limiar é o último trade-off, e não é resolvido adicionando mais signatários. Um 2-de-2 maximiza o controle mútuo, mas pode congelar permanentemente os fundos se uma chave for perdida. Um 2-de-3 é popular porque incorpora redundância através de uma chave de backup. Um 3-de-5 é de nível de governança quando a continuidade durante ausências é mais importante do que a velocidade.

Um N maior pode aumentar a falha de coordenação, o que significa que "mais signatários" pode reduzir a probabilidade de que a carteira possa agir quando necessário.

Como o multisig se compara com o MPC

Multisig e mpc têm como objetivo reduzir o risco de chave única, mas o fazem com diferentes propriedades de responsabilidade e operação. Multisig utiliza várias chaves completas mantidas por diferentes signatários, e a carteira combina aprovações on-chain para autorizar uma transação.

A trilha de aprovação é explícita e ligada a identidades de signatários distintas, razão pela qual o multisig é frequentemente preferido quando transparência e auditabilidade são requisitos.

MPC divide uma chave de assinatura em fragmentos e gera assinaturas por meio de computação off-chain, sem que nenhuma parte possua a chave completa. Essa arquitetura pode suportar uma automação mais suave e pode ser mais agnóstica em relação à blockchain, o que é importante para operações multi-chain. A troca é que o processo de aprovação não é inerentemente uma trilha de auditoria on-chain, signatário por signatário, da maneira que o multisig é.

A estrutura de decisão não é 'qual é mais seguro' como uma afirmação universal. É 'o que precisa ser provável on-chain, e o que precisa ser rápido e operacionalmente suave.' Se o requisito é governança e clara responsabilidade pelas aprovações, o multisig se encaixa naturalmente. Se o requisito é throughput operacional em muitas chains com automação orientada por políticas, o MPC frequentemente se encaixa melhor.

É também aqui que os detalhes de implementação importam. Um multisig em uma chain com suporte nativo se comporta de maneira diferente de um multisig baseado em contrato que depende da compatibilidade ERC-1271 para fluxos de trabalho de mensagens assinadas. Essa diferença faz parte dos tipos de carteira explicados, e é por isso que dois produtos podem ser chamados de 'multisig' enquanto falham de maneiras completamente diferentes.

A Conclusão

Eu vi equipes tratarem o multisig como uma caixa de seleção, e depois descobrirem que construíram um pipeline de aprovação frágil. O momento caro não é o dia em que a carteira é criada. É o dia em que um signatário está viajando, um dispositivo está morto, e o grupo percebe que o limite que escolheram implica em um orçamento de inatividade muito real.

A postura limpa é projetar o multisig como um sistema de controle de mesa: proposta, revisão, assinaturas, verificação de limite, transmissão, com responsabilidade pelo financiamento de taxas e um plano para o desaparecimento do signatário. 2-de-2 é controle máximo e propenso a congelamento, 2-de-3 é o padrão prático porque tem um caminho de recuperação, e 3-de-5 é o que é usado quando a continuidade importa mais do que a velocidade. O número de signatários não é a característica. O modelo operacional é.

Fontes

• Cobo
• Ethereum Improvement Proposals
• Propostas de Melhoria do Ethereum
• Médio