O que de fato barra uma transação
Todo produto de custódia tem uma página de recursos listando controles: listas brancas, limites de gasto, travas de tempo, fluxos de aprovação, restrições de IP. Todos são reais e todos são úteis. Mas não são todos o mesmo tipo de coisa, e tratá-los como intercambiáveis é como organizações acabam com um modelo de segurança mais fraco do que o marketing sugeria.
Há uma pergunta que os separa com clareza: se todo software do sistema estivesse errado ou hostil, esse controle ainda se sustentaria?
Para a maior parte da lista, a resposta é não. Para exatamente um, a resposta é sim. Este artigo é sobre saber diferenciá-los.
Três camadas, não uma
Entre alguém querer mover fundos e os fundos de fato se moverem, a SSP Enterprise tem três barreiras distintas. Elas falham de formas diferentes, e saber qual é qual é o ponto inteiro.
As camadas não estão ordenadas por utilidade. Estão ordenadas pelo que é preciso para derrotá-las.
Camada 1: a camada de coordenação
É o motor de políticas, e é ali que mora a maioria dos recursos. A SSP Enterprise suporta listas brancas de endereços, restrições por tipo de destino, travas de tempo que atrasam transações acima de um limiar de valor, regras exigindo aprovação de admin a partir de certo valor, e restrições de IP no acesso à organização. Modelos de política dão predefinições sensatas que depois se materializam como regras reais e editáveis.
Esses controles fazem trabalho de verdade. Uma lista branca impede que um endereço digitado errado chegue a virar proposta. Uma trava de tempo dá ao time de tesouraria uma janela para notar algo errado. Uma regra de aprovação transforma uma transferência grande numa conversa de duas pessoas em vez da tarde de uma só.
O que eles não são é imposição de custódia. Essas regras moram no software da SSP e são avaliadas pelos servidores da SSP. Não fazem parte do endereço do cofre, e a blockchain nunca ouviu falar delas. Se o motor de políticas fosse contornado — por um bug, um servidor comprometido ou um operador hostil — as regras simplesmente não se aplicariam.
Dizemos isso com clareza porque a alternativa é pior. Um time que acredita que sua lista branca é uma garantia de custódia vai dimensionar o limiar de acordo, e é exatamente esse o erro que transforma um incidente sobrevivível num insobrevivível.
Camada 2: seus dispositivos
A segunda barreira é o par de dispositivos que cada signatário carrega, e ela é mais forte que a primeira num ponto importante: também não confia na SSP.
Quando uma proposta chega a um signatário, os dispositivos dele decodificam localmente os bytes crus da transação e comparam o resultado com o que está sendo exibido. Destinatário, valor, token — lidos dos bytes, não retirados da descrição do servidor. Na Solana essa comparação é explícita e implacável: se os bytes decodificados contradizem o conteúdo exibido, a assinatura é bloqueada de forma dura em vez de apenas avisada, porque uma divergência ali indica ataque em andamento, não falha de renderização.
Os dispositivos também impõem um teto independente próprio sobre reembolsos de taxa. O relay propõe a taxa; a carteira se recusa a assinar uma acima de um máximo fixado em código, não importa o que o relay alegue, o que limita qualquer drenagem via taxas mesmo se o relay for totalmente hostil. A simulação também roda antes da aprovação, executando a proposta contra o estado atual da rede para que a tela de revisão possa mostrar o que a transação realmente faria; isso chegou com a simulação de transações e avisos de risco.
Esta camada derrota um servidor comprometido. O que ela não derrota é um dispositivo comprometido, ou um signatário que aprova sem ler. Ela também exige os dois dispositivos do signatário, e é por isso que o 2-de-2 por signatário importa: a camada 2 é tão forte quanto o mais fraco dos dois dispositivos, e eles são deliberadamente tipos diferentes de hardware.
Camada 3: a rede
A terceira barreira é a única que se sustenta quando todo o resto falhou.
O endereço de um cofre é derivado do conjunto de signatários e do limiar de aprovação. Uma transação que não carregue o número exigido de assinaturas válidas não é uma transação recusada — é uma transação inválida. Cada nó da rede chega independentemente à mesma conclusão, e nenhum grau de acesso à infraestrutura da SSP muda essa aritmética.
É por isso que o limiar é o número que merece mais reflexão quando você cria um cofre, e por isso ele não pode ser editado depois. Configurando seu primeiro cofre empresarial cobre a mecânica; 2-de-2 x 2-de-3 x m-de-n cobre como escolher o número.
Onde cada camada falha
Colocar os modos de falha lado a lado deixa o trabalho de projeto óbvio.
| Cenário | Camada de coordenação | Seus dispositivos | A rede |
|---|---|---|---|
| Um signatário digita um endereço errado | Barra | Barra se ele ler | Não se importa |
| Um signatário é enganado e aprova | Barra se não estiver na lista branca | Mostra a verdade; ele pode aprovar mesmo assim | Não se importa |
| O relay da SSP é comprometido | Falha | Aguenta — os bytes são decodificados localmente | Aguenta |
| O motor de políticas da SSP tem um bug | Falha | Aguenta | Aguenta |
| O notebook de um signatário é comprometido | Não foi feita para isso | Em parte — o celular ainda confere | Aguenta |
| Um atacante controla menos de M signatários | Não foi feita para isso | Aguenta | Aguenta |
| Um atacante controla M signatários ou mais | Falha | Falha | Falha |
A última linha é o fundo honesto do modelo. Multisig protege contra a minoria dos seus signatários ser comprometida. Não protege contra a maioria, e nenhum produto pode afirmar o contrário sem mentir. É por isso que o limiar e a independência dos seus signatários importam mais do que qualquer lista de recursos.
O que isso significa para a sua montagem
Projete o cofre para ser seguro só com a camada 3. Escolha o limiar e o conjunto de signatários como se o motor de políticas não existisse. Se a resposta te deixa desconfortável, o conserto é outro limiar ou outros signatários — não mais políticas.
Depois acrescente políticas pelo que políticas fazem bem. Listas brancas pegam erro humano. Travas de tempo compram tempo de reação. Regras de aprovação criam um segundo par de olhos sobre valores grandes. São melhorias de processo e reduzem incidentes de verdade; só não são o que fica entre um atacante e sua tesouraria.
Mantenha seus signatários genuinamente independentes. Dois signatários no mesmo notebook, no mesmo prédio, com o mesmo arranjo de recuperação, estão mais perto de um signatário do que de dois. A força da camada 3 vem da dificuldade de comprometer M pessoas separadas com M pares de dispositivos separados.
Faça os signatários realmente lerem a tela de revisão. A camada 2 é a única barreira capaz de pegar uma proposta com cara de legítima mas errada, e ela só funciona se um humano se engajar com o que o dispositivo dele decodificou. Uma ida e volta ensaiada na criação do cofre ajuda a construir esse hábito enquanto nada está em jogo.
Faça a mesma pergunta a outros provedores de custódia. Use a SSP ou não, esse enquadramento é portátil: para cada controle na página de recursos, pergunte se ele sobrevive ao software do próprio fornecedor estar errado. As respostas costumam ser instrutivas, e um fornecedor que responde com clareza está te dizendo algo bom sobre como pensa.
Sobre as formas como um arranjo de várias chaves é minado na prática, modos de falha do multisig e como a SSP os mitiga percorre uma a uma, e SSP Enterprise: cofres multisig para equipes é a visão geral de como as peças se encaixam.
