A proposta de assinaturas quânticas da TRON pode criar uma situação incomum para algumas contas migradas. Elas continuariam realizando pagamentos, mas não conseguiriam substituir suas chaves. Esse cenário ocorreria se a governança desativasse o mecanismo de assinatura usado na permissão de proprietário.

Ainda assim, determinadas contas poderiam movimentar fundos por meio de uma permissão ativa separada. A recuperação dependeria de chaves sobreviventes com peso suficiente para atingir o limite da permissão de proprietário. Entretanto, uma chave reserva autorizada somente para pagamentos não permitiria alterar as permissões da conta.

Em 8 de agosto de 2026, Justin Sun afirmou no X que pretendia tornar a TRON a primeira blockchain resistente a computadores quânticos. Ele também mencionou testes conduzidos na rede Nile. Nesse contexto, o modelo de migração permite que a governança retire posteriormente a aprovação de um esquema de assinatura.

Governança da TRON controla a ativação dos esquemas

Em 12 de setembro, a TIP-899 continuava classificada como rascunho. A atualização da Nile, publicada em 30 de junho, incluiu FN-DSA-512, baseado em Falcon, e ML-DSA-44. Cada implementação depende de um parâmetro próprio de ativação e da aprovação da governança.

Na consulta de 12 de setembro, o endpoint de parâmetros da Nile retornou o valor 1 para getAllowFnDsa512. Por outro lado, a configuração do ML-DSA apareceu sem valor, o que não confirmou sua ativação. A resposta da mainnet não apresentou nenhuma das duas configurações.

Durante a reunião de 15 de julho, os desenvolvedores disseram que o cronograma da mainnet permanecia indefinido. Portanto, as verificações na Nile não comprovam uma ativação na rede principal. A TIP-899 também permite habilitar ou desabilitar cada esquema de forma independente.

Códigos identificam propostas, mas não garantem ativação

Os 27 Super Representatives eleitos conduzem a governança da TRON por propostas on-chain, conforme a documentação da rede. Além disso, os desenvolvedores renumeraram os códigos de ativação. A TIP-899 e a implementação da Nile usam 1000 e 1001, enquanto uma discussão anterior apresentava 99 e 100.

A reunião de desenvolvedores de 1º de julho explicou o uso dos números maiores. Segundo o registro, a mudança evitaria conflitos com futuras numerações da mainnet. Contudo, esses códigos apenas identificam os ajustes, pois a ativação exige uma decisão independente da governança.

Permissões determinam a possibilidade de recuperação

A TRON atribui pesos às chaves de cada conta e define um limite para autorizar operações. Assim, os signatários válidos precisam alcançar ou superar o limite da permissão utilizada. O caminho proposto para assinaturas quânticas aplica esse mesmo cálculo.

O verificador de transações de referência apresenta um detalhe importante. Uma assinatura vinculada a um mecanismo desativado causa a rejeição da transação. Dessa forma, uma alternativa precisa usar apenas assinaturas aceitas, mesmo quando as chaves restantes possuem peso suficiente.

Desativar um esquema pode eliminar uma rota de assinatura sem modificar o limite definido pela conta. Com isso, a mudança não transfere automaticamente a autoridade ausente para outra chave. A documentação de multisig também separa a permissão de proprietário das permissões ativas.

A permissão de proprietário pode autorizar qualquer tipo de contrato e modificar as permissões da conta. Já uma permissão ativa fica limitada às operações atribuídas, como transferências. Logo, a atualização das permissões depende das assinaturas exigidas pela configuração de proprietário existente.

Limites podem bloquear a troca de chaves

Uma conta cujo proprietário usa somente Falcon, com peso 1 e limite 1, perderia essa autorização após a desativação do esquema. Porém, uma permissão ativa separada ainda poderia permitir determinadas transações. Isso não significa que toda conta ficaria necessariamente incapaz de movimentar fundos.

Manter uma chave ECDSA ao lado da Falcon também não garante acesso. Caso cada uma tenha peso 1 e o limite seja 2, ambas serão necessárias. Após a desativação do Falcon, a ECDSA isolada não alcançará o limite exigido.

Segunda assinatura só ajuda quando possui autoridade

Os exemplos são hipotéticos e aplicam as regras propostas de permissão e verificação. Eles não resultam de um bloqueio observado nem de um teste de reversão executado. As hipóteses consideram Falcon desativado e ML-DSA previamente configurado, habilitado, seguro e acessível ao titular.

Uma configuração com Falcon e ML-DSA preserva uma rota resistente a computadores quânticos quando qualquer chave alcança sozinha o limite do proprietário. Em contrapartida, exigir ambas cria uma dependência da disponibilidade simultânea dos dois esquemas. Desse modo, o limite da permissão define a capacidade real de recuperação.

Uma rota clássica não mantém o mesmo objetivo de segurança. Conforme a proposta, adicionar uma chave resistente não garante proteção quando um conjunto formado apenas por ECDSA ainda alcança o limite. Da mesma maneira, uma rota ECDSA de proprietário pode substituir uma permissão ativa protegida por assinaturas quânticas.

Nesse sentido, a análise precisa considerar a autoridade de proprietário e todas as rotas ativas que movimentam recursos. Uma configuração alternativa também não protege contra um esquema comprometido enquanto ele continua habilitado e autorizado. Por isso, a chave usada em pagamentos cotidianos representa apenas uma parte da estrutura.

Auditorias e adaptações de carteiras seguem pendentes

O estágio dos padrões ajuda a explicar a inclusão do ML-DSA. O NIST finalizou o FIPS 204, que especifica o ML-DSA, em 13 de agosto de 2024. Enquanto isso, o instituto mantém a padronização do Falcon em andamento.

A TIP-899 apresenta o ML-DSA como alternativa diante dos riscos de padronização e auditoria do Falcon. Apesar disso, outro algoritmo não cria automaticamente uma permissão de recuperação. A proposta também solicita auditorias externas, materiais públicos e cobertura de um programa de recompensas antes da ativação na mainnet.

Os materiais analisados não incluem um relatório concluído de auditoria independente. A proposta e a discussão de 15 de julho indicam adaptações necessárias em derivação de carteiras, keystores, SDKs e carteiras de hardware. Portanto, a implementação na testnet não comprova que consumidores ou custodiantes já consigam executar toda a migração e recuperação.

Um teste útil na testnet desativaria o esquema e montaria uma transação somente com assinaturas sobreviventes. Em seguida, o processo mostraria quais transferências permanecem autorizadas e se o proprietário consegue substituir as chaves afetadas. O resultado também precisaria corresponder às configurações realmente mantidas pelos usuários.

Se ambos os esquemas fossem desativados, nenhum conjunto válido poderia atingir os limites relevantes em determinadas contas. Nesse caso, não haveria uma rota comum imediata para gastar fundos ou trocar chaves. Contudo, uma reativação pela governança ou uma futura alteração do protocolo representaria uma rota distinta.

Canais emergenciais mais rápidos e propostas de recuperação com provas de conhecimento zero permanecem fora do escopo atual. Para carteiras e custodiantes, manter pagamentos não resolve sozinho o problema da recuperação. A migração precisa preservar uma rota de proprietário capaz de substituir chaves sem abandonar a resistência a computadores quânticos.