Nonces duráveis: assinatura com dois dispositivos no Solana
O SSP é uma carteira 2 de 2. Cada transação precisa de duas assinaturas: uma da Wallet, a extensão de navegador no seu computador, e outra do SSP Key no seu celular. Esse design é o ponto central de tudo — um ladrão que rouba um dispositivo ainda assim não consegue mover seus fundos. Mas ele introduz um problema muito humano. O computador constrói e assina uma transação em uma fração de segundo. O celular pode levar mais dois ou três minutos para coassinar, porque uma pessoa precisa pegar o aparelho, olhar a solicitação e tocar em aprovar.
No Solana, esse intervalo é um problema. Este artigo explica por quê, e como o SSP resolve isso sem guardar nada frágil.
O blockhash que expira
Toda transação normal do Solana carrega um dado chamado blockhash recente. É a impressão digital de um bloco recente da cadeia, e cumpre duas funções ao mesmo tempo. Prova que a transação foi criada há pouco e impede que a mesma transação assinada seja repetida para sempre.
O detalhe está na palavra recente. Um blockhash só é válido por cerca de 150 blocos. No Solana os blocos chegam rápido, então 150 blocos são apenas cerca de 60 a 90 segundos. Passada essa janela, a rede rejeita a transação de imediato — não porque haja algo errado com as assinaturas, mas porque o blockhash está vencido.
Agora coloque o fluxo de assinatura do SSP contra esse relógio. A Wallet constrói a transação, fixa um blockhash novo e assina. Em seguida, o usuário é notificado no celular. Se ele responder em 90 segundos, ótimo. Se estiver em uma reunião, o celular estiver em outro cômodo, ou ele simplesmente quiser ler a transação com calma, o blockhash morre em silêncio. A assinatura da Wallet continua criptograficamente válida, mas a transação a que ela estava anexada agora não vale nada. Tudo precisa ser reconstruído e reassinado do zero.
Para uma carteira de um único assinante que assina e transmite num só fôlego, a janela de 90 segundos é generosa. Para uma carteira 2 de 2 onde um humano está entre as duas assinaturas, é uma corrida que o usuário não para de perder.
O que é um nonce durável
O Solana tem uma resposta embutida para isso, e ela é anterior ao SSP: o nonce durável. A ideia é substituir o blockhash que expira por um valor que não expira.
Um nonce durável vive em sua própria pequena conta na cadeia — uma conta de nonce. Essa conta pertence ao sistema, guarda apenas 80 bytes de dados, e um desses dados é o próprio valor do nonce: um substituto de longa vida para um blockhash. Uma transação pode ser construída para usar o valor da conta de nonce no lugar de um blockhash recente. Como esse valor não envelhece, a transação permanece válida pelo tempo que for preciso — minutos, horas, dias.
Nada é de graça, porém, e um nonce precisa de uma proteção contra repetição. Essa proteção é uma regra: toda transação que usa um nonce durável deve carregar uma instrução específica, nonceAdvance, como sua primeira instrução. Quando a transação finalmente é confirmada, nonceAdvance consome o valor atual do nonce e rotaciona a conta para um novo. O nonce é de uso único. A transação que você assinou na segunda pode esperar até a quarta, mas, uma vez executada, aquele nonce exato nunca poderá autorizar outra transação. Se quiser ler a própria descrição do mecanismo feita pelo Solana, a documentação de nonces de transação duráveis é a fonte primária.
Assim, um nonce durável compra tempo sem comprar um risco de repetição. Essa é exatamente a propriedade de que uma carteira de dois dispositivos precisa.
A virada do SSP: uma conta de nonce que você nunca precisa guardar
Uma conta de nonce durável continua sendo uma conta, e no Solana toda conta tem um endereço. A abordagem ingênua é criar uma conta de nonce em algum endereço aleatório e depois lembrar cuidadosamente desse endereço para sempre — escrevê-lo no armazenamento local da carteira, fazer backup, torcer para que sobreviva a uma redefinição do dispositivo. É mais uma coisa frágil para perder.
O SSP se recusa a guardá-lo. Em vez disso, o programa multisig do SSP para Solana inclui uma instrução chamada provision_nonce, e ela cria a conta de nonce em um endereço derivado. O endereço vem de uma receita determinística: é calculado a partir da própria conta multisig, do rótulo de texto fixo "nonce" e do Programa de Sistema do Solana. O mesmo multisig na entrada, o mesmo endereço de nonce na saída — toda vez.
Isso importa por causa do que o restante desta série já estabeleceu. O multisig do SSP para Solana deriva o endereço do multisig do conjunto de membros, e deriva o endereço do cofre do multisig. (Se essas derivações forem novas para você, o artigo multisig autoiniciável do Solana percorre cada uma.) A conta de nonce agora se junta à mesma família: ela também é uma derivação pura. Qualquer dispositivo SSP — seu computador, seu celular, uma carteira recém-reinstalada — pode recalcular o endereço da conta de nonce do zero. Não há endereço secreto para perder, porque não há endereço algum guardado.
Algumas observações práticas decorrem do design. provision_nonce é permissionless: qualquer um pode pagar o pequeno aluguel (cerca de 0,00144 SOL) para fazer a conta de nonce existir, e quem paga se torna sua autoridade inicial — na prática, o paymaster do relay do SSP. Essa autoridade pode ser reatribuída depois sem que o endereço da conta jamais mude, então o endereço que você deriva hoje continua correto mesmo que a chave operacional por trás dele seja rotacionada. A localização da conta de nonce está ancorada ao seu multisig, não a quem porventura a financiou.
O fluxo de assinatura tranquilo
Junte as peças e a corrida desaparece. A Wallet constrói uma transação que usa a conta de nonce derivada em vez de um blockhash recente, coloca nonceAdvance como primeira instrução e assina. Uma notificação push vai para o celular. O usuário aprova quando estiver pronto — não há relógio correndo contra ele. O SSP Key adiciona a segunda assinatura, e a transação totalmente assinada é transmitida. Como foi construída sobre um nonce durável, ela continua válida, e nonceAdvance rotaciona o nonce para que a transação não possa ser repetida.
Há mais uma restrição que vale a pena nomear. O Solana limita uma única transação a 1232 bytes. Uma transação multisig precisa caber a lista de membros e as instruções de gasto dentro desse limite, e é por isso que o SSP usa o formato compacto de transação versionada do Solana e passa os dados da forma mais enxuta possível. O nonce durável não muda o orçamento de tamanho; ele só muda o orçamento de tempo.
Derivar tudo, guardar nada
Esse é o fio que atravessa toda a série Multisig no Solana, do jeito SSP. O endereço do multisig, o cofre que guarda seus fundos e agora a conta de nonce que dá a dois dispositivos tempo para concordar — nenhum deles é um valor que o SSP precise salvar e proteger. Cada um é recalculado sob demanda a partir de entradas que a carteira já conhece. Há menos para fazer backup, menos para vazar e menos para dar errado em uma redefinição de dispositivo. Designs de multisig que se apoiam nessa ideia, como a abordagem de multisig de assinante único do SSP, costumam ser os que têm menos peças móveis para quebrar.
Uma observação final no mesmo espírito de honestidade do restante da série: o programa multisig do SSP para Solana está atualmente implantado apenas na devnet, e aguarda uma auditoria de segurança externa antes de qualquer lançamento na mainnet. O design descrito aqui — incluindo provision_nonce e sua conta de nonce derivada — é real e pode ser lido no programa de código aberto, mas ainda não é infraestrutura de produção. Se o próprio modelo de dois dispositivos do SSP for novo para você, o artigo introdutório o que é multisig 2 de 2 é o lugar para começar.
O nonce durável é uma peça pequena e antiga do encanamento do Solana. A contribuição do SSP é tornar o endereço dele mais uma coisa de que você nunca precisa lembrar.
