A Solana planeja descontinuar os nonces duráveis, mecanismo que permite assinar transações offline e transmiti-las depois. A proposta preserva a autorização por chaves frias, mas altera os endereços que controlam os recursos envolvidos. Assim, exchanges, custodiantes e operadores de tesouraria teriam uma camada adicional entre a aprovação e a execução. A mudança também poderá manter uma autorização válida quando uma tentativa de execução falhar.

O plano de descontinuação da Solana Foundation indica o uso de programas de assinatura on-chain. Esses programas verificam uma assinatura offline e executam as instruções autorizadas. Nesse arranjo, um endereço derivado de programa, conhecido como PDA, controlaria as contas afetadas. Portanto, a chave fria deixaria de assinar diretamente a transação transmitida à rede.

A chave original continuaria autorizando as operações. Contudo, um operador online distinto enviaria a transação e pagaria a taxa da rede. Com isso, organizações precisariam migrar recursos ou permissões e adaptar seus aplicativos. As equipes de risco também teriam de aprovar o novo fluxo operacional.

Novo modelo altera o controle das contas

Os nonces duráveis resolvem um problema relacionado ao tempo de validade das transações. Em vez de usar um blockhash recente, que expira rapidamente, uma chave offline utiliza um nonce armazenado. Dessa forma, a aprovação e a transmissão podem ocorrer em momentos diferentes. O recurso atende principalmente fluxos que mantêm chaves de autorização desconectadas da internet.

A atualização da Solana que reduziu os slots para 200 milissegundos alcançou a etapa final na mainnet em 9 de outubro. Como resultado, a produção mais rápida de blocos encurta a janela para aprovações baseadas em blockhash comum. Ainda assim, a expiração depende da produção de blocos, não de um cronômetro com duração garantida.

Por enquanto, os nonces duráveis continuam disponíveis. A Solana Foundation não definiu uma data de remoção nem escolheu entre o Programmatic Signer, da Anza, e o Vector, da Blueshift. A janela estimada de seis meses dependerá de uma alternativa adequada, auditada e operacional na mainnet.

Endereço derivado exige migração separada

No Programmatic Signer, a chave fria assina uma mensagem de autorização, não a transação enviada à rede. Em seguida, um relayer inclui essa aprovação em uma transação com blockhash recente. O programa verifica a autorização e executa as instruções aprovadas. Para isso, ele utiliza o endereço derivado da chave como signatário.

O PDA não possui chave privada própria. Em vez disso, sua capacidade de agir depende da validação feita pelo programa de assinatura. Entretanto, a criação do endereço não transfere recursos nem permissões automaticamente. Cada organização precisará conduzir essas migrações em processos separados.

O guia de migração prevê mover SOL nativo para o endereço derivado. Da mesma maneira, os operadores transfeririam saldos de tokens para contas controladas pelo novo endereço. O processo também abrange permissões de emissão e congelamento. Em contas de staking, o operador poderá mover a autoridade de staking, de saque ou ambas.

As alternativas tratam o SOL nativo de formas diferentes. O Programmatic Signer usa uma conta derivada de SOL controlada pelo System Program. Já o Vector inicializa uma conta sob controle do próprio programa. Depois, ele libera o SOL por meio de saque ou encerramento autorizado.

Autorização pode sobreviver a uma execução com falha

A implementação escolhida definirá quanto a aprovação restringe a transação que a transporta. A documentação de mensagens do Programmatic Signer vincula as assinaturas frias ao executor, à conta de nonce e à mensagem incorporada. Logo, o relayer não pode alterar esses dados sem invalidar as assinaturas. Essa proteção, porém, não cobre todos os componentes externos da transação.

O relayer ainda pode escolher o pagador da taxa e o blockhash externo. Além disso, ele pode incluir instruções antes ou depois da execução autorizada. Em contrapartida, o Vector compromete o buffer de instruções de nível superior. Desse modo, todas as instruções ao redor das ações aprovadas precisam constar antes da assinatura fria.

Uma execução com falha pode deixar a aprovação fria disponível para outra tentativa. Nas transações atuais, o sistema consome o nonce durável mesmo quando a validação passa e a execução falha. Em contraste, a arquitetura do Programmatic Signer confirma juntas a mudança do nonce e as alterações no aplicativo. Caso ocorra uma falha, o sistema reverte ambas.

O Vector documenta a mesma possibilidade de repetir uma ação malsucedida. Sem um prazo obrigatório, a autorização poderá permanecer executável enquanto o nonce não mudar. Ao mesmo tempo, o Vector alerta que um relayer pode reter a transação até que as condições se alterem.

Aplicativos precisam aceitar o novo fluxo

A Solana Foundation busca simplificar o trabalho dos validadores. Atualmente, os nonces duráveis exigem regras especiais contra repetição e dificultam a execução assíncrona. Eles também tornam mais complexo o processo de filtrar transações inválidas. Ao transferir esse estado para programas comuns, os validadores processariam transações normais baseadas em blockhash.

Por outro lado, os aplicativos receberiam ações autorizadas por invocação entre programas, chamada de CPI. Isso pode conflitar com regras que exigem uma ação como instrução de nível superior. Assim, um aplicativo pode reconhecer a validade criptográfica e rejeitar a assinatura do PDA. A posição da chamada também poderá causar incompatibilidade.

O CPI Guard do Token-2022 demonstra a necessidade de avaliar cada conta. Quando a proteção está ativa, transferências e queimas por CPI exigem uma autoridade delegada. Além do mais, o mecanismo proíbe aprovações por CPI. Delegados permanentes, contudo, mantêm exceções para transferências e queimas.

Em uma discussão de 4 de março, Michael, da Fireblocks, apoiou o fim dos nonces. Todavia, ele criticou os custos de migração, a dependência de contratos e os desafios de compatibilidade com finanças descentralizadas. Na discussão pública, Michael preferiu envelopes de transação e apontou o Sudo como alternativa. Grant, da Unit 410, defendeu um programa de assinatura pequeno e auditável.

Apesar do apoio condicional, Grant rejeitou uma solução que transferisse recursos temporariamente para um signatário quente. Na avaliação dele, os fundos precisam permanecer associados ao armazenamento frio. Essa exigência faz parte do modelo sem custódia adotado pela Unit 410.

Migração ainda depende de ferramentas na mainnet

A documentação atual do Programmatic Signer informa uma implantação na devnet e auditorias em andamento. Ainda existem correções necessárias antes da versão v1 e de uma eventual estreia na mainnet. Por sua vez, a documentação de uso classifica a simulação e o envio por relay como recursos futuros.

O Vector publica o código da implementação e identificadores dos programas. No entanto, o repositório não informa o status de auditoria nem confirma uma implantação na mainnet. Enquanto isso, o kit de integração da Fireblocks continua descrevendo a injeção automática de nonces duráveis. O recurso atende integrações selecionadas do WalletConnect.

O fluxo atual inclui Jupiter e Kamino, com validade padrão de 15 minutos administrada pelo provedor. Consequentemente, qualquer substituto precisará acomodar esse método de aprovação já existente. A migração dependerá de uma alternativa auditada na mainnet, ferramentas utilizáveis e aplicativos compatíveis. Também deverá preservar os controles de aprovação definidos por cada operador.

	Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.