Análise: substituição de nonces na Solana preservaria aprovações após transações malsucedidas

O plano de outubro da Solana Foundation propõe substituir nonces duráveis por programas de assinatura on-chain que verificam assinaturas offline e executam instruções aprovadas. Um endereço derivado de programa, ou PDA, controlaria as contas afetadas, enquanto a chave original aprovaria as ações e um operador online separado enviaria as transações e pagaria as taxas da rede. Bolsas, custodiante e operadores de tesouraria precisariam migrar ativos ou permissões, garantir que as aplicações aceitem o novo fluxo de execução e obter aprovação das equipes de risco.

Nonces duráveis continuam disponíveis, e a Foundation ainda não definiu uma data para removê-los nem escolheu entre o Programmatic Signer, da Anza, e o Vector, da Blueshift. A janela de migração de cerca de seis meses depende de uma substituição adequada estar pronta, auditada e ativa na rede principal. Nonces duráveis permitem aprovar offline e transmitir depois, usando um nonce armazenado em vez de um blockhash recente, que expira rapidamente. A atualização separada de slots de 200 ms da Solana chegou à etapa final na rede principal em 9 de outubro, reduzindo o tempo normal de aprovação, embora a expiração dependa da produção de blocos, e não de um cronômetro garantido.

No Programmatic Signer, a chave offline assina uma mensagem de autorização que um retransmissor envia em uma transação com um blockhash recente para verificação e execução por meio do endereço derivado. O PDA não tem chave privada; sua autoridade deriva da verificação da aprovação da chave original, e são necessárias transferências separadas de ativos ou permissões. O guia de migração descreve a transferência de SOL nativo, saldos de tokens, permissões de emissão ou congelamento e a autoridade de operador, de retirada ou ambas, em contas de staking, para o endereço derivado. A Foundation propõe concluir essas transferências separadas enquanto os nonces duráveis legados ainda funcionam, com as mudanças necessárias determinadas pelo inventário de contas e pelas permissões de chave existentes de cada tesouraria. A conta de SOL derivada do Programmatic Signer pertence ao programa System e pode enviar SOL por meio de uma transferência comum aprovada. Já o Vector inicializa uma conta pertencente a um programa e libera SOL por meio de uma operação autorizada de retirada ou encerramento.

A documentação de mensagens do Programmatic Signer diz que as assinaturas da chave offline vinculam o executor, a conta nonce e a mensagem de execução incorporada, impedindo que um retransmissor altere esses dados autorizados. O retransmissor pode escolher o pagador da taxa da transação externa e o blockhash, além de adicionar instruções antes ou depois do envio. O Vector vincula o buffer de instruções de nível superior, incluindo dados e contas de chamadas aprovadas a outros programas, impedindo a inserção, remoção ou reordenação posterior de instruções ao redor. O Programmatic Signer permite montar o contexto de execução em torno de uma ação aprovada, enquanto o Vector exige aprovação prévia da sequência ao redor; nenhum dos dois permite que os pagadores de taxas reescrevam ações assinadas.

Uma transação atual com nonce durável consome o nonce se a validação for bem-sucedida, mas a execução falhar. O Programmatic Signer confirma o avanço do nonce e as alterações da aplicação em conjunto ou reverte ambos. O Vector documenta a mesma possibilidade de nova tentativa: uma tentativa malsucedida pode deixar uma aprovação executável posteriormente enquanto o nonce permanece inalterado e não há prazo de validade. O Vector alerta que um retransmissor poderia reter uma transação até que as condições mudassem, ou que uma assinatura exposta em uma tentativa malsucedida poderia ser executada mais tarde. Um limite de tempo nas instruções assinadas pode rejeitar a execução após um prazo. A revogação exige que um avanço de nonce autorizado separadamente seja registrado com sucesso. Uma rejeição por prazo não consome o nonce quando as alterações do nonce são revertidas junto com a transação malsucedida.

A justificativa da Foundation é simplificar o tratamento pelos validadores, pois nonces duráveis exigem regras especiais de prevenção a repetição, complicam a execução assíncrona e dificultam a filtragem de transações inválidas. Transferir a aprovação e o estado de prevenção a repetição para programas comuns deixa os validadores processando transações normais com blockhash, enquanto as aplicações recebem ações aprovadas por meio de invocação entre programas, ou CPI. Aplicações que exigem ações de nível superior podem rejeitar esse fluxo, e verificações limitadas a instruções de nível superior de pagamento ou verificação de assinatura podem deixar passar ações aninhadas no programa de assinatura. Uma profundidade maior de chamadas não resolve regras que rejeitam a posição de uma chamada ou não conseguem inspecionar instruções aninhadas. A Foundation sugere dar suporte a programas de assinatura conhecidos ou oferecer outro fluxo de execução. A aceitação, por uma aplicação, de uma assinatura de PDA é distinta da validade criptográfica da aprovação offline.

Com o CPI Guard do Token-2022 ativado, transferências e queimas por CPI exigem autoridade de delegado, aprovações por CPI são proibidas e mudanças de proprietário são proibidas mesmo fora de CPI. Delegados permanentes têm exceções para transferências e queimas, e uma possível rota de transferência baseada em delegado exige decisões separadas sobre permissões e políticas de custódia. Na discussão de 4 de março, um participante que se identificou como Michael, da Fireblocks, apoiou a descontinuação dos nonces, mas se opôs aos encargos de migração, dependência de contratos e compatibilidade com DeFi do CPI Passthrough. Michael defendeu envelopes de transação, com Sudo como alternativa, em vez do fluxo de assinatura baseado em CPI proposto. Grant, que se identificou como integrante da Unit 410, disse no mesmo dia que um programa de assinatura pequeno e auditável poderia tornar aceitável a migração de autoridade. Grant rejeitou transferir temporariamente os ativos para um assinante online, mesmo de forma atômica, porque os fundos precisam permanecer associados à custódia offline no modelo não custodial da Unit 410.

A documentação do Programmatic Signer informa que ele foi implantado na devnet e está passando por auditorias, exige a correção de problemas antes do lançamento da versão 1 e de qualquer implantação na rede principal, e alerta que as interfaces podem mudar. A documentação de uso do Programmatic Signer indica que a simulação e o envio por retransmissor estarão disponíveis em breve, enquanto o guia de migração também deixa várias operações incompletas. O Vector publica código de implementação e IDs de programas, mas seu README não informa o status de auditoria ou implantação na rede principal. O atual kit de integração de protocolos da Fireblocks descreve a injeção automática de nonces duráveis em integrações selecionadas do WalletConnect, incluindo Jupiter e Kamino, com uma janela de validade padrão de 15 minutos gerenciada pelo provedor, à qual uma substituição precisará se adequar.