Ir para o conteúdo
Financial Context Wiki

Carteira com múltiplas assinaturas

Entenda como uma carteira multisig M-of-N distribui a autoridade sobre transações, como diferem multisigs de script e de contrato inteligente e quais riscos de signatários, execução, módulos e recuperação permanecem.

Atualizado

Somente para fins educacionais; não constitui orientação de investimento, custódia, jurídica ou de segurança. Uma multisig ainda pode perder fundos ou ficar inutilizável por signatários comprometidos, transações maliciosas, módulos inseguros, falhas no contrato ou perda do quórum. Transações com ativos digitais podem ser irreversíveis.

Resposta direta

Uma carteira com múltiplas assinaturas, ou multisig, controla uma conta ou saída gastável com uma regra que exige pelo menos M aprovações de N chaves públicas ou contas proprietárias autorizadas. Uma regra 2-of-3, por exemplo, aceita quaisquer duas autoridades válidas de um conjunto de três. Isso elimina uma única chave privada como ponto exclusivo de controle, mas não torna segura toda transação aprovada.

A multisig convencional não divide uma chave privada entre os signatários. Cada signatário normalmente controla uma chave ou conta separada, e o script ou contrato verifica várias aprovações. Sistemas de assinatura por limiar ou MPC podem, em vez disso, produzir uma assinatura a partir de partes distribuídas de uma chave; sua aparência on-chain e modelo de confiança são diferentes.

A implementação importa. O Bitcoin pode impor condições de gasto multifirma em scripts de transação. Na Ethereum e em redes programáveis semelhantes, uma multisig comum é uma conta de contrato cujo código define proprietários, limiar, regras de execução e extensões opcionais. Ao contrário de uma conta de propriedade externa, a conta de contrato é controlada pelo código, e não por uma única chave privada.

O limiar M-of-N expressa limites de comprometimento e disponibilidade. Uma configuração 3-of-5 continua funcionando quando duas autoridades estão indisponíveis, mas quaisquer três autoridades válidas podem aprovar gastos. Endereços distintos não são independentes quando uma pessoa, administrador de dispositivos, conta na nuvem, local de backup ou custodiante controla uma quantidade suficiente deles.

Como funciona

  1. Verifique a autoridade antes da proposta. Confirme a rede e a conta ou saída; examine o script ou contrato implantado, proprietários, limiar, regras de nonce ou sequência e cada módulo, guard, fallback handler, caminho de recuperação e autoridade de atualização capaz de executar ou bloquear transações.
  2. Construa e decodifique a solicitação exata. Confira destino, ativo, valor, calldata ou script, tipo de operação, nonce, taxas e conteúdo de lotes. Simule chamadas complexas com ferramentas confiáveis e garanta que cada signatário analise o que a assinatura realmente autoriza, em vez de um rótulo da interface.
  3. Colete aprovações em domínios de controle independentes. Os signatários verificam o mesmo resumo da transação em dispositivos confiáveis e se comunicam por canais autenticados. Nenhum processo legítimo exige revelar uma frase-semente ou chave privada.
  4. Execute a solicitação aprovada. Atingir o limiar pode apenas tornar a proposta executável. Um executor ainda precisa transmiti-la ou enviá-la e talvez pagar uma taxa de rede. Nonce desatualizado, proposta concorrente, estado alterado, taxa insuficiente ou chamada com falha podem impedir a execução.
  5. Verifique a conclusão pelo estado da blockchain. Aguarde a política de confirmação exigida, examine o payload executado e o resultado e confirme saldos, configuração dos proprietários e eventos quando apropriado. Reavalie propostas pendentes após mudar proprietários, limiar, módulos ou políticas.

Exemplo

Uma tesouraria usa uma multisig de conta inteligente 3-of-5 com proprietários A, B, C, D e E em domínios de controle separados. Para um pagamento de 10,000 USDC, a proposta registra rede, conta, destinatário, contrato do token, valor, calldata, nonce e política de taxas corretos. A, C e E decodificam de forma independente a mesma solicitação antes de aprová-la.

As aprovações por si só não movem os fundos. Um executor envia a transação; após a confirmação, a equipe verifica o resultado e o saldo da tesouraria, em vez de confiar em uma notificação da interface. Proposta, aprovações, hash e evidências de revisão são mantidos como trilha de auditoria.

Se depois houver suspeita de comprometimento da chave de B, o quórum restante não comprometido segue o procedimento de rotação de proprietários da conta implantada e verifica on-chain o conjunto final. A equipe também revisa propostas pendentes, módulos, allowances, permissões de recuperação e outras blockchains, pois remover B não reverte transações anteriores nem revoga autoridade concedida por outro caminho.

Riscos e controles

  • Custódia correlacionada. Várias chaves podem falhar juntas se compartilham pessoa, dispositivo, cofre de senhas, administrador, local, provedor ou segredo de recuperação. Mapeie os domínios e teste a recuperação sem centralizar autoridade suficiente para atingir o limiar.
  • Payload malicioso ou mal compreendido. Um quórum válido pode aprovar fielmente endereço de atacante, aprovação ilimitada de tokens, delegate call ou lote nocivo. Decodifique e verifique de forma independente toda a solicitação; use simulação como evidência auxiliar, não garantia.
  • Perda e atraso do quórum. Chaves perdidas, pessoas indisponíveis, disputas, interrupções de rede ou limiar alto demais podem bloquear ações urgentes ou travar ativos para sempre. Mantenha contatos autenticados, sucessão documentada, backups testados e um projeto explícito de recuperação.
  • Autoridade oculta ou alternativa. Módulos, guards, fallback handlers, session keys, relayers, contratos de recuperação e administradores de atualização podem contornar o limiar comum ou impedir a execução. Inventarie esses caminhos e trate toda mudança de permissão como transação de alto risco.
  • Risco de contrato e implantação. Bugs, inicialização insegura, erros de proxy ou atualização e implantação na rede errada podem frustrar a política pretendida. Verifique endereços e código, avalie auditorias no contexto, reduza extensões e monitore configurações.
  • Corrida após comprometimento e desligamento incompleto. Um signatário comprometido pode agir antes da confirmação de sua remoção; retirar um proprietário não desfaz ações nem permissões externas. Use um plano de incidente, monitore continuamente e revogue separadamente acessos organizacionais e on-chain.

Equívocos comuns

  • “Mais signatários sempre significa mais segurança.” Um conjunto maior pode reduzir a concentração, mas aumenta riscos de coordenação, phishing e disponibilidade. Escolha proprietários e limiar com base no modelo de ameaças e na capacidade operacional.
  • “Uma carteira 3-of-5 é controlada por cinco pessoas independentes.” A blockchain conta chaves ou contas proprietárias válidas, não pessoas. Dispositivos, backups, administradores ou custodiantes compartilhados podem transformar proprietários nominalmente separados em um domínio.
  • “Multisig equivale a autenticação de dois fatores ou MPC.” Todos podem distribuir controle, mas diferem em credenciais, caminhos de verificação, evidências on-chain e premissas de recuperação.
  • “Quando o limiar aprova, a transferência está concluída.” Aprovação, executabilidade, envio, inclusão e confirmação são estados distintos. A solicitação pode permanecer pendente ou falhar.
  • “Multisig impede roubos e explorações de contratos.” Ela limita apenas os caminhos de autoridade codificados na implementação. Quórum válido, módulo privilegiado, contrato vulnerável ou recuperação insegura ainda podem causar perdas irreversíveis.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...