A carteira multisig de Solana onde o endereço é o conjunto de membros
Uma carteira multisig precisa de duas ou mais chaves para aprovar qualquer gasto. No Bitcoin, o endereço da carteira é simplesmente um hash de suas próprias regras: a lista de chaves públicas e o número de "quantas assinaturas são exigidas". Você pode calcular esse endereço em um bloco de notas, distribuí-lo e receber fundos muito antes de alguém tocar a blockchain.
Solana, tradicionalmente, não consegue fazer isso. Como explica o primeiro artigo desta série, as multisig dominantes de Solana pedem que você execute uma transação de criação com aleatoriedade escolhida pelo criador antes que o endereço da carteira sequer exista. O próprio programa multisig de Solana da SSP adota a abordagem do Bitcoin. Ele é auto-inicializável: o endereço da carteira é o conjunto de membros.
Uma observação de antemão: o programa multisig de Solana da SSP é de código aberto (RunOnFlux/Solana-Multisig) e atualmente funciona apenas na devnet, a rede de testes de Solana. Uma implantação na mainnet depende de uma auditoria de segurança externa.
Dois endereços: a multisig e o vault
O design da SSP usa dois endereços separados para cada carteira multisig.
O endereço multisig guarda as regras: a lista ordenada de chaves de membros, o limiar (o M de "M-de-N") e um contador de transações propostas. Ele pertence ao programa da SSP.
O endereço do vault guarda o dinheiro: SOL e tokens SPL. Ele pertence ao System Program embutido de Solana e não armazena dados próprios. O vault é o endereço de depósito: aquele que você entrega a quem quiser pagar você.
Ambos são um Program Derived Address, ou PDA: um endereço sem chave privada, deliberadamente colocado fora da curva criptográfica para que nenhuma chave possa controlá-lo. Apenas o programa que o derivou pode autorizar movimentações a partir dele. Esse detalhe importa no final.
Como o endereço é calculado a partir dos membros
Esta é a parte que torna a carteira auto-inicializável. Para derivar o endereço multisig, em linguagem simples: pegue o rótulo literal multisig, um hash SHA-256 da lista ordenada de membros e o limiar; depois alimente isso, junto com o ID de programa da SSP, na função de derivação de endereços de Solana. Três detalhes merecem atenção.
Os membros são ordenados e deduplicados primeiro. Uma carteira 2-de-3 com os membros A, B, C produz o mesmo endereço quer você os liste como C, A, B ou B, C, A. A ordem não importa; importa apenas o conjunto.
É usado o hash completo de 32 bytes, nunca uma versão encurtada. Truncar o hash abriria um ataque real: um atacante poderia procurar um conjunto de membros diferente que produza o mesmo valor encurtado, depois registrar seus próprios membros no seu endereço e drenar quaisquer fundos que você tivesse pré-carregado. O hash completo de 32 bytes torna essa busca astronomicamente cara, então isso nunca acontece.
O limiar faz parte do endereço. Uma carteira 2-de-3 e uma 3-de-3 com exatamente os mesmos membros são carteiras diferentes em endereços diferentes. As regras estão gravadas na identidade.
O endereço do vault é então derivado do endereço multisig mais um pequeno número de índice (a SSP sempre usa o índice 0), de modo que o vault também fica totalmente determinado pelo conjunto de membros e pelo limiar.
O resultado prático: qualquer pessoa pode calcular ambos os endereços offline, antes de enviar uma única transação. Você pode distribuir o endereço do vault e receber fundos em uma carteira que, na cadeia, ainda não existe — a propriedade do Bitcoin, trazida para Solana.
Registro sem permissão: qualquer um pode ativá-la
O endereço da carteira existe no momento em que você conhece os membros. Mas para gastar a partir dela, as regras precisam, em algum momento, ser escritas na cadeia — o programa chama essa etapa de initialize.
Na maioria das multisig de Solana, apenas um criador privilegiado pode fazer a etapa equivalente. No programa da SSP, a inicialização é sem permissão: qualquer pessoa pode fazê-la. Sem conta de criador, sem assinatura de membro, sem permissão especial. Normalmente o serviço de relay da SSP paga a pequena taxa de aluguel e ativa a carteira, mas realmente não importa quem o faz.
Isso parece alarmante até você ver a verificação de segurança. Quando alguém inicializa a carteira, o programa recalcula o hash SHA-256 da lista de membros fornecida e rejeita a transação a menos que esse hash coincida com o gravado no endereço. O framework de contas de Solana vincula de forma independente o endereço a esse mesmo hash. Juntas, essas duas verificações significam que o endereço canônico só pode conter o conjunto canônico de membros. Ninguém pode registrar seu endereço com uma lista de membros de sua escolha — o hash não coincidiria e a transação falha.
Por que um desconhecido inicializando sua carteira não pode prejudicá-lo
Veja o que um atacante poderia de fato tentar.
Ele inicializa com um conjunto de membros diferente. Um conjunto diferente gera um hash diferente, que deriva um endereço diferente. O atacante simplesmente criou sua própria carteira não relacionada em outro lugar de Solana — sem conexão com o seu vault, sem reivindicação sobre os seus fundos.
Ele inicializa com o seu conjunto de membros. O hash coincide, então a transação tem êxito, mas tudo o que ele fez foi pagar a sua taxa de aluguel por você. A carteira agora está registrada exatamente com as regras que você esperava, e o atacante não é membro, então ele não pode propor, aprovar ou executar nada. O dinheiro nunca fica no endereço multisig em si — fica no vault, que pertence ao sistema e não pode ser sequestrado. Quem quer que inicialize a carteira, e quando o fizer, o resultado é a mesma carteira canônica com as regras corretas.
O limiar é verificado quando você gasta, não quando registra
Este é o mesmo modelo que a multisig P2WSH do Bitcoin usa, e vale dizer claramente: o limiar M-de-N é aplicado apenas quando os fundos se movem — nunca no registro.
O registro apenas anota "estes são os membros, este é o limiar". Ele não pede assinaturas porque não pode causar dano algum. A verdadeira barreira é o fluxo de gasto, onde o programa conta as aprovações e se recusa a agir até que membros suficientes tenham concordado. O endereço é o hash das regras; qualquer um pode financiá-lo; apenas assinaturas válidas podem gastar. Para revisar o que "M-de-N" significa, veja 2-de-2 vs 2-de-3 vs M-de-N multisig.
O ciclo de vida completo, do início ao fim
Juntando as peças, a vida de uma carteira multisig de Solana da SSP:
- Derivar. Qualquer pessoa calcula os endereços multisig e do vault offline a partir dos membros e do limiar. Sem blockchain, sem custo.
- Pré-financiar. Qualquer pessoa envia SOL ou tokens para o endereço do vault — isso funciona mesmo antes de a carteira ser registrada.
- Inicializar. Qualquer pessoa, normalmente o relay da SSP, envia a transação de registro sem permissão. O programa verifica o hash dos membros e escreve as regras canônicas na cadeia.
- Propor. Um membro cria uma proposta de transação, armazenada de forma compacta em uma conta de proposta dedicada.
- Aprovar. Cada membro aprova a proposta, uma vez cada um. As aprovações se acumulam na cadeia.
- Executar. Quando as aprovações alcançam o limiar, qualquer pessoa pode acionar a execução. O programa primeiro marca a proposta como executada — uma proteção deliberada para que ela nunca seja executada duas vezes — e então realiza cada instrução, com o próprio vault atuando como assinante.
Essa última etapa é onde o endereço do vault sem chave compensa. Como o vault é um PDA sem chave privada, nenhum humano e nenhum programa pode mover seus fundos assinando da maneira comum. A única saída é o programa da SSP executar uma proposta aprovada que atingiu o limiar — ele "assina" pelo vault apresentando a receita de derivação do vault ao runtime de Solana, uma permissão que ele obtém puramente porque é o dono do endereço.
Sem criador, sem admin, sem rotação de chaves no lugar
Duas propriedades finais amarram o design.
O conjunto de membros e o limiar são imutáveis. Uma vez que a carteira é inicializada, nenhuma instrução do programa pode mudar seus membros ou seu limiar — não existe caminho de código para isso. Para mudar quem controla uma carteira — o que outros sistemas chamam vagamente de "rotacionar chaves" — você cria uma multisig nova com o novo conjunto de membros e move os fundos para ela. O endereço antigo mantém suas regras antigas para sempre.
Não há papel de criador nem chave de admin, nunca. Muitos designs de multisig mantêm uma conta privilegiada que pode anular os membros ou mudar a configuração. O programa da SSP não tem nenhuma — nada para comprometer, nenhuma chave de admin para clonar via phishing, nenhum criador para coagir. Os membros e o limiar são a história toda.
Esse minimalismo é uma escolha deliberada: a SSP construiu uma primitiva pequena e determinística em vez de uma plataforma de governança rica em recursos. O próximo artigo, A multisig de Solana da SSP vs Squads, compara este design com honestidade com o Squads V4 — a multisig de Solana madura, auditada e dominante. Para o contexto do produto, o anúncio de lançamento do suporte a Solana cobre o que chegou na SSP Wallet v1.39.0.
A ideia central é pequena o suficiente para caber na cabeça: na multisig de Solana da SSP, o endereço da carteira é uma impressão digital de suas próprias regras. Conheça os membros e o limiar, e você conhece o endereço. Nada mais é necessário, e nada mais é confiado.
