O que uma carteira multisig faz realmente, e porque uma só chave raramente chega
Uma carteira cripto padrão é uma única chave privada que assina todas as transações. Quem controla essa chave controla os fundos, ponto final. Se a perder, o dinheiro desaparece; se lha roubarem, o dinheiro desaparece. Não há linha de apoio, reposição de palavra-passe nem departamento antifraude. Para algumas centenas de dólares em ativos pessoais, esse compromisso é aceitável. Para a tesouraria de uma DAO, reservas hot de uma exchange, a carteira operacional de um fundo ou o armazenamento cold de longo prazo de um family office, não é.
Uma carteira multisig divide essa autoridade por N chaves independentes e exige que M delas assinem qualquer transação. Uma configuração 3 de 5, por exemplo, precisa de quaisquer três dos cinco signatários para aprovar antes de os fundos serem movimentados. Se perder duas chaves, a carteira continua a poder gastar. Se uma chave for roubada, o ladrão não consegue mover nada sozinho. O desenho é mais antigo do que as criptomoedas; aparece em contas escrow bancárias, sistemas de tesouraria empresarial e até esquemas de autenticação de dois fatores. On-chain, a lógica vive dentro de um smart contract, não num banco.
A ideia central é que multisig não é uma funcionalidade que se ativa; é um sistema operacional que se gere. O smart contract aplica a regra M de N ao nível do protocolo, mas as pessoas, dispositivos, localizações e hábitos que o rodeiam determinam se ele realmente o protege. Um 3 de 5 em que as cinco chaves estão em dispositivos no mesmo escritório, assinadas por uma pessoa que por acaso sabe as palavras-passe de todos, é pouco mais seguro do que uma hot wallet de chave única. Um 2 de 3 em que os três signatários estão espalhados por três continentes, em carteiras hardware de três fornecedores diferentes, é significativamente mais difícil de atacar, embora ambas as carteiras passem tecnicamente no teste de “é multisig?”.
Os riscos reais antes de começar (leia isto duas vezes)
Multisig introduz riscos que uma carteira de chave única não tem. O primeiro é o risco de bloqueio: se definir 3 de 5 e três signatários perderem as chaves em simultâneo, os fundos ficam matematicamente irrecuperáveis. Não há porta dos fundos. Pesquise na web por “parity wallet frozen” e encontrará um incidente de 2017 em que um bug numa biblioteca multisig bloqueou acidentalmente mais de 500 000 ETH num único contrato. O bug foi um erro de programação, não um hack, e o dinheiro continua lá. A lição é que o risco de smart contract é real, mesmo em código auditado e amplamente utilizado.
O segundo risco é o problema das pessoas. Multisig pressupõe que os seus signatários não vão conspirar, não vão cair em phishing ao mesmo tempo e não vão estar todos no mesmo aeroporto quando a alfândega decidir fazer uma imagem dos portáteis. Se dois dos seus três signatários forem cofundadores que viajam juntos, tem um 2 de 3 no nome e um 1,5 de 3 na prática. O terceiro risco é operacional: cada signatário deve seguir sempre o mesmo procedimento. Um signatário que “apenas clica para avançar” nos detalhes da transação é um ponto único de falha para toda a carteira.
O quarto risco é a capacidade de atualização do contrato. Algumas implementações multisig, incluindo certas versões do Safe, permitem que a lógica do contrato seja atualizada por votação dos próprios signatários. Isso é conveniente para correções de bugs, mas significa que uma maioria hostil dos seus signatários pode alterar as regras. Se pretende imutabilidade, deve verificar que a versão que implementa não é atualizável. O quinto risco é específico da cadeia: a maior parte deste guia aplica-se a cadeias EVM (Ethereum, Arbitrum, Base, Optimism, Polygon, BNB Chain), onde o Safe domina. Bitcoin multisig existe, mas funciona de forma diferente e não é abordado aqui. Solana e outras cadeias não EVM têm os seus próprios padrões multisig, cada um com as suas particularidades.
Passo 1: defina quem são os signatários, onde estão e o que detêm
Antes de abrir qualquer software, escreva numa única página a resposta a quatro perguntas. Primeiro, quantos signatários existem no total (N)? Segundo, quantos têm de assinar cada transação (M)? Terceiro, onde está fisicamente localizado cada signatário? Quarto, que dispositivo e que fornecedor usa cada signatário?
N situa-se normalmente entre 3 e 7. Abaixo de 3, há redundância a menos. Acima de 7, a sobrecarga de coordenação aumenta e cresce a probabilidade de um signatário estar ausente num momento crítico. M é o número mais difícil. Um padrão comum é 3-de-5, que tolera dois signatários perdidos ou comprometidos, mas ainda exige três pessoas para atuar nas operações normais. Um 2-de-3 é mais rápido de operar, mas só tolera uma falha. Um 4-de-7 é conservador e comum em DAOs maiores, mas lento. A matemática é implacável: com N chaves, pode perder até N menos M chaves e continuar a operar, mas se perder mais do que isso fica bloqueado para sempre.
A geografia é importante devido ao risco correlacionado. É pouco provável que um signatário em Singapura, um signatário em Lisboa, um signatário em Buenos Aires e um signatário em Toronto sejam afetados pelo mesmo furacão, pela mesma interrupção da internet ou pela mesma ação das autoridades ao mesmo tempo. O fornecedor de hardware importa pela mesma razão: uma vulnerabilidade descoberta no firmware de um fornecedor não deve comprometer todos os seus signatários em simultâneo. Misture Ledger, Trezor, GridPlus e Keystone se puder; não use cinco signatários em cinco dispositivos idênticos do mesmo lote.
Por fim, decida quem são realmente as pessoas. Para uma carteira pessoal, pode usar as suas próprias chaves em dispositivos que controla em diferentes localizações físicas. Para uma DAO, os signatários são normalmente um subconjunto da equipa principal, possivelmente com um consultor de segurança. Para um family office, os signatários podem ser o titular principal, um responsável de operações de confiança e a chave de um custodiante terceiro. Sejam quem forem, todos os signatários têm de compreender que não podem perder o dispositivo, partilhar a seed phrase ou assinar transações sem as ler.
Passo 2: implemente um Safe na cadeia que pretende usar
Safe (anteriormente Gnosis Safe) é o multisig mais amplamente implementado em cadeias EVM. Está ativo desde 2018, guarda milhares de milhões de dólares em fundos de tesouraria em milhares de DAOs e equipas, e foi auditado e bifurcado muitas vezes. Para a maioria dos utilizadores de EVM, Safe é a referência por defeito. Dito isto, "mais usado" não é o mesmo que "seguro para o seu caso específico". Leia os relatórios de auditoria, verifique a versão atual e confirme que o endereço do contrato a partir do qual está a implementar corresponde ao endereço oficial publicado pela Safe.
Abra a app oficial da Safe em app.safe.global (não confie em links de emails, tweets ou anúncios de pesquisa). Ligue primeiro uma carteira só de leitura para explorar; não precisa de ligar uma carteira de assinatura até ao momento em que for realmente implementar. Escolha a rede pretendida. A mainnet Ethereum é a mais segura, mas cara para a configuração; redes Layer 2 como Arbitrum, Base e Optimism são mais baratas e ainda herdam a segurança da Ethereum para liquidação. Escolha a cadeia que corresponde ao local onde a sua tesouraria opera de facto.
Clique em "Create new Safe". Escolha o seu limiar (M) e adicione os endereços das suas N carteiras de signatário. Estes são endereços EVM normais gerados por MetaMask, Rabby, Frame, carteiras de hardware ou qualquer outra carteira EVM; o Safe não se preocupa com a forma como a chave subjacente foi criada, apenas com o endereço que tem. Confirme. Assine a transação de implementação com o signatário ligado e pague a taxa da rede. O Safe irá implementar uma nova carteira de smart contract num endereço novo; esse endereço é o seu multisig.
Anote o endereço do Safe. Envie uma pequena transação de teste (uma pequena quantia do token nativo, como 0,001 ETH) para confirmar que o endereço está correto. Teste uma transação do Safe de volta para o seu próprio endereço. Assine-a com o número necessário de signatários e execute-a. Só depois de este teste completo ser bem-sucedido deve considerar enviar fundos reais da tesouraria.
Passo 3: distribua as chaves dos signatários por dispositivos, fornecedores e localizações
Agora que o Safe existe, tem de garantir que cada signatário está realmente preparado. Um signatário não é apenas um endereço; é uma pessoa com um dispositivo, uma cópia de segurança e um processo. Para cada signatário, gere a chave numa carteira de hardware (Ledger, Trezor, GridPlus, Keystone ou outro fornecedor reputado). Escreva a seed phrase em papel ou metal; não a guarde num gestor de palavras-passe, unidade na cloud, email ou fotografia. Guarde a cópia de segurança numa localização fisicamente separada do dispositivo.
A distribuição geográfica tem duas camadas. A primeira camada é onde o dispositivo normalmente fica: um cofre em casa, um cofre no escritório, um cofre bancário. A segunda camada é onde fica a cópia de segurança. Estes locais não devem ser o mesmo edifício. Um incêndio, uma inundação ou um assalto que leve o dispositivo não deve também levar a frase de recuperação.
A diversidade de fornecedores é inegociável para tesourarias sérias. Não use três dispositivos Ledger, dois Trezor e um GridPlus, porque isso continua a ser três de um só fornecedor. O objetivo é tornar impossível que um único erro de firmware ou ataque à cadeia de fornecimento comprometa M dos seus N signatários. Dois ou três fornecedores é um mínimo sensato. Note que a diversidade de fornecedores não é apenas paranoia; é também uma proteção contra o dia em que se descubra que um fornecedor tem uma backdoor deliberada, como alguns utilizadores da Ledger recearam após a fuga de dados de 2020 e os debates subsequentes sobre funcionalidades do produto.
Documente cada signatário com um registo de uma página: endereço, modelo da carteira de hardware e versão do firmware, localização física do dispositivo, localização física da cópia de segurança da seed, contacto principal e um suplente designado que saiba como recuperar esse signatário se o principal estiver inacessível. Guarde este documento numa localização encriptada à qual cada signatário possa aceder, mas que não esteja no mesmo dispositivo que qualquer signatário.
Passo 4: escreva o plano de recuperação antes de financiar o Safe
A recuperação é a parte que as pessoas saltam, e é a parte que determina se um multisig é um sistema de segurança ou uma bomba-relógio em câmara lenta. Três cenários precisam de planos explícitos: um único signatário perde o dispositivo, a seed phrase de um único signatário é comprometida, e dois ou mais signatários ficam simultaneamente inacessíveis.
Para um único dispositivo perdido, a resposta é simples: os restantes N menos 1 signatários continuam acima do limiar, por isso a carteira continua a funcionar. O signatário perdido tem de ser substituído. Isso significa gerar uma nova chave numa carteira de hardware nova, e adicionar o novo endereço ao Safe enquanto remove o antigo. Isto é, em si, uma transação do Safe, assinada por M dos signatários existentes, e é a operação de recuperação mais importante que irá executar. Pratique-a num Safe de teste antes de a fazer a sério.
Para uma única seed comprometida, a situação é mais urgente. Transfira imediatamente os fundos do Safe para um novo Safe com novos signatários, assinado pelos signatários não comprometidos. O tempo é importante porque o atacante tem agora uma das M chaves necessárias. Se o seu limiar era 3-de-5 e apenas um signatário está comprometido, ainda pode mover os fundos, mas tem de o fazer antes de o atacante reunir os outros dois. Trate o comprometimento da seed como um incêndio.
Para dois ou mais signatários inacessíveis, está a testar o limite da sua redundância N menos M. Se o seu limiar for 3-de-5 e dois signatários tiverem desaparecido, a carteira ainda funciona usando os três restantes. Se três tiverem desaparecido, a carteira fica bloqueada. É por isso que o problema de recuperação é, na verdade, um problema de conceção antes do lançamento. Ou escolheu um M que lhe dá redundância suficiente para sobreviver a perdas realistas, ou não escolheu. Nenhum software consegue corrigir isto depois do facto.
Algumas equipas acrescentam uma camada de "guardian" ou recuperação social por cima do multisig, em que um conjunto separado de partes de confiança pode ajudar a recuperar o acesso após um período de atraso. Trata-se de uma conceção diferente e que vale a pena considerar para carteiras pessoais, mas para tesourarias organizacionais a disciplina de um multisig puro costuma superar a complexidade dos esquemas híbridos.
Passo 5: crie um runbook operacional e pratique a assinatura
O multisig só o protege se os seus signatários fizerem realmente a coisa certa em todas as ocasiões. Isso exige um runbook escrito que abranja: como uma transação é proposta, como é analisada, como cada signatário a verifica no seu dispositivo, como assina, como é executada e como o resultado é registado. Todos os signatários devem ler o runbook antes da sua primeira transação e relê-lo anualmente.
A análise da transação é o passo mais subestimado. Todos os signatários devem observar o destino real on-chain, o montante real, o contrato real que está a ser chamado e o seletor de função real. A maioria dos exploits de Safe dos últimos anos não foram hacks ao protocolo. Foram ataques de engenharia social em que um signatário aprovou uma transação maliciosa porque confiou no proponente ou leu a interface da carteira na diagonal. As hardware wallets mostram os endereços de destino e os montantes nos seus próprios ecrãs, o que é a funcionalidade de segurança mais útil para multisig: o próprio dispositivo, não o portátil, é a fonte da verdade.
Faça exercícios de assinatura. Proponha uma transação sem efeito ou uma pequena transação de teste todos os trimestres e percorra todo o fluxo M-de-N. Isto parece pedante, mas revela problemas que, de outra forma, só descobriria durante uma emergência: um signatário cujo firmware do dispositivo está desatualizado, um signatário que está a viajar sem a sua hardware wallet, um signatário que nunca aprendeu o procedimento. Os exercícios também criam memória muscular para que, sob stress (um hack em curso, uma queda do mercado, um prazo), a equipa consiga executar rapidamente sem erros.
Checklist de pré-lançamento: tudo o que tem de estar confirmado antes de financiar o Safe
- Limiar e conjunto de signatários: M e N são escolhidos, registados por escrito e acordados por todos os signatários.
- Independência dos signatários: cada signatário é uma pessoa diferente, usa um fornecedor de hardware diferente, está numa localização física diferente e tem cópias de segurança num edifício diferente.
- Armazenamento da seed: a seed phrase de cada signatário está em papel ou metal, não em qualquer sistema digital, com pelo menos uma cópia fora do local.
- Implementação do Safe: o endereço do contrato é verificado na lista oficial de implementações da Safe para a blockchain e a versão escolhidas.
- Teste de ponta a ponta: um pequeno depósito e um pequeno levantamento foram assinados pelos M signatários necessários e executados com sucesso.
- Exercício de recuperação: num Safe de teste, um signatário foi substituído através do procedimento padrão da Safe, provando que a equipa consegue fazer rotação de signatários sem complicações.
- Runbook escrito: um único documento descreve como propor, analisar, assinar e executar transações, e todos os signatários já o leram.
- Plano de comprometimento: a equipa acordou antecipadamente como reagir a uma única seed comprometida, incluindo o endereço de um Safe de “saída de emergência” pré-implementado.
- Canais de comunicação: são acordados canais seguros fora de banda (Signal, Keybase, presencialmente) para coordenação de emergência, para que um email comprometido não possa ser usado para aplicar engenharia social aos signatários.
Como acompanhar notícias sobre multisig de forma inteligente
As configurações multisig são duradouras, mas o ecossistema à sua volta muda rapidamente: a Safe lança atualizações, os fornecedores de hardware enviam atualizações de firmware, novas vulnerabilidades de contratos são divulgadas e as práticas de governação de DAO evoluem. Acompanhar tudo isto manualmente é uma batalha perdida. O Zippfeed destaca manchetes sobre multisig e autocustódia com classificação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa detetar alterações de governação, conclusões de auditorias e exploits importantes antes de afetarem a sua tesouraria.
