Solana avalia substituir nonces duradouros por signers onchain

A Solana está a considerar retirar os nonces duradouros em favor de programas de assinatura onchain que preservem a aprovação offline por chave fria depois de uma transação falhar. O plano da Foundation para outubro não define uma data de remoção e mantém condicional a janela de migração de cerca de seis meses, dependente de uma substituição auditada e pronta para a mainnet. O Programmatic Signer da Anza e o Vector da Blueshift continuam a ser as duas propostas concorrentes.

Por que é importante

Os nonces duradouros resolvem um problema de temporização ao permitirem que um assinante offline aprove uma transação que pode ser transmitida mais tarde, em vez de depender de um hash de bloco recente que expira rapidamente. A arquitetura proposta altera o local onde reside a autoridade. Um endereço derivado de um programa, ou PDA, controlaria as contas afetadas, enquanto a chave fria original continuaria a autorizar as ações e um relayer online as submeteria e pagaria a taxa de rede.

Isto é uma reformulação da custódia, não uma simples atualização de software. Exchanges, custodians e operadores de tesouraria teriam de transferir SOL, saldos de tokens e determinadas autoridades para contas controladas pelo programa de assinatura. As permissões de staking, levantamento, emissão e congelamento podem exigir transferências separadas. As aplicações também teriam de aceitar ações aprovadas através de invocação entre programas, em vez de instruções diretas de nível superior.

Impacto no mercado

A alteração representa sobretudo um risco de infraestrutura e operacional para os utilizadores institucionais da Solana. Uma assinatura válida por chave fria não tornaria automaticamente uma aplicação compatível com o novo percurso. Os protocolos que rejeitem ações de PDA, inspecionem apenas instruções de nível superior ou restrinjam CPI podem exigir trabalho de integração separado, enquanto os controlos do Token-2022 acrescentam questões de compatibilidade ao nível das contas.

As duas propostas impõem restrições de execução diferentes. O Programmatic Signer associa o executor, a conta de nonce e a mensagem de execução incorporada, permitindo ao mesmo tempo que um relayer acrescente instruções envolventes. O Vector compromete todo o buffer de instruções de nível superior, pelo que as instruções envolventes têm de ser aprovadas antes da assinatura. Ambos os modelos podem preservar uma aprovação após uma execução falhada, mas os operadores podem precisar de prazos assinados ou de avanços separados do nonce para limitar o risco de replay. A migração continua dependente de auditorias, ferramentas utilizáveis e uma implementação em produção.