$NEAR oferece suporte a assinaturas de contas resistentes a ataques quânticos, o que não significa que toda a cadeia já tenha concluído a migração para essa tecnologia. O tópico que ocupa atualmente o sexto lugar na praça merece uma análise mais detalhada, mas os marcos técnicos a que se refere são de julho e setembro; não se deve apresentá-lo como um novo recurso lançado hoje.
A primeira camada diz respeito à forma como uma conta autoriza transações. O nearcore 2.13.0 foi lançado em 9 de julho e anunciou a inclusão do ML-DSA-65 como um terceiro tipo de assinatura de transação e de chave de acesso, ao lado dos dois tipos existentes. Essa mudança oferece às contas uma nova opção de verificação de assinaturas, mas não troca automaticamente as chaves de todas as contas existentes nem permite concluir que todas já adotaram o novo algoritmo.
A segunda camada é a capacidade de um contrato verificar uma mensagem. A versão candidata para a testnet 2.14.0-rc.1, de 16 de setembro, adicionou a interface ml_dsa_verify para que contratos verifiquem mensagens. Essa é uma via diferente da autorização nativa de transações por conta: o fato de um contrato poder verificar uma assinatura não prova, por si só, que todas as operações que ele controla, os ativos externos ou as mensagens entre cadeias já concluíram a migração de segurança. Uma versão candidata para testes também não deve ser descrita como já implantada na mainnet.
A terceira camada diz respeito ao alcance da migração de todo o sistema. A assinatura de contas é apenas uma parte. É preciso obter evidências específicas sobre a versão do protocolo adotada pelos nós, como as chaves existentes serão atualizadas e como as demais dependências serão tratadas. Não se pode deduzir, a partir da adoção de um novo algoritmo por um módulo, que todas as camadas do sistema passaram a ter o mesmo nível de proteção.
Também é importante distinguir as datas. O registro de desenvolvimento de 2 de julho mostra uma demonstração, em ambiente sandbox, de adição de chaves e transferência; 9 de julho foi a data de lançamento da versão voltada à mainnet; essa versão também listou um plano para iniciar a votação do protocolo em 20 de julho. Uma demonstração bem-sucedida, o lançamento de uma versão, um plano de votação e a ativação efetiva na rede não representam o mesmo estágio de conclusão. Como nesta análise não verifiquei o resultado da atualização em toda a rede, não trato a data planejada como confirmação da implantação.
Para os usuários comuns, as perguntas mais concretas são: a própria conta está realmente configurada com esse tipo de chave de acesso? A carteira utilizada consegue gerá-la, armazená-la e usá-la para assinar corretamente? O aplicativo oferece suporte ao fluxo correspondente? Ver apenas uma manchete não permite concluir que a conta em uso já está protegida pelo novo esquema de assinatura. Depois de adicionar uma nova chave, também é preciso verificar nas configurações reais da conta como ficam as permissões da chave antiga.
Para os desenvolvedores, é importante distinguir as transações nativas de contas da verificação de mensagens por contratos. A primeira diz respeito a quem pode autorizar operações da conta; a segunda, a como um programa determina se uma mensagem é válida. Mesmo que a verificação da assinatura seja aprovada, isso não significa que o conteúdo da mensagem, o escopo das permissões ou a lógica de negócios sejam automaticamente corretos. Os limites de segurança precisam ser definidos no fluxo de autorização efetivamente utilizado.
O que mais me interessa são os próximos pontos verificáveis: registros de versões oficiais e de ativação do protocolo, suporte das carteiras e instruções claras de migração. O que é possível confirmar agora é que a NEAR está avançando em diferentes recursos de verificação de assinaturas para contas e contratos; o que não é possível confirmar é que todas as contas antigas, aplicações e dependências externas já concluíram a migração em conjunto. Esta é uma análise do alcance técnico, não uma previsão sobre a direção do preço da moeda baseada no nome do algoritmo.
A primeira camada diz respeito à forma como uma conta autoriza transações. O nearcore 2.13.0 foi lançado em 9 de julho e anunciou a inclusão do ML-DSA-65 como um terceiro tipo de assinatura de transação e de chave de acesso, ao lado dos dois tipos existentes. Essa mudança oferece às contas uma nova opção de verificação de assinaturas, mas não troca automaticamente as chaves de todas as contas existentes nem permite concluir que todas já adotaram o novo algoritmo.
A segunda camada é a capacidade de um contrato verificar uma mensagem. A versão candidata para a testnet 2.14.0-rc.1, de 16 de setembro, adicionou a interface ml_dsa_verify para que contratos verifiquem mensagens. Essa é uma via diferente da autorização nativa de transações por conta: o fato de um contrato poder verificar uma assinatura não prova, por si só, que todas as operações que ele controla, os ativos externos ou as mensagens entre cadeias já concluíram a migração de segurança. Uma versão candidata para testes também não deve ser descrita como já implantada na mainnet.
A terceira camada diz respeito ao alcance da migração de todo o sistema. A assinatura de contas é apenas uma parte. É preciso obter evidências específicas sobre a versão do protocolo adotada pelos nós, como as chaves existentes serão atualizadas e como as demais dependências serão tratadas. Não se pode deduzir, a partir da adoção de um novo algoritmo por um módulo, que todas as camadas do sistema passaram a ter o mesmo nível de proteção.
Também é importante distinguir as datas. O registro de desenvolvimento de 2 de julho mostra uma demonstração, em ambiente sandbox, de adição de chaves e transferência; 9 de julho foi a data de lançamento da versão voltada à mainnet; essa versão também listou um plano para iniciar a votação do protocolo em 20 de julho. Uma demonstração bem-sucedida, o lançamento de uma versão, um plano de votação e a ativação efetiva na rede não representam o mesmo estágio de conclusão. Como nesta análise não verifiquei o resultado da atualização em toda a rede, não trato a data planejada como confirmação da implantação.
Para os usuários comuns, as perguntas mais concretas são: a própria conta está realmente configurada com esse tipo de chave de acesso? A carteira utilizada consegue gerá-la, armazená-la e usá-la para assinar corretamente? O aplicativo oferece suporte ao fluxo correspondente? Ver apenas uma manchete não permite concluir que a conta em uso já está protegida pelo novo esquema de assinatura. Depois de adicionar uma nova chave, também é preciso verificar nas configurações reais da conta como ficam as permissões da chave antiga.
Para os desenvolvedores, é importante distinguir as transações nativas de contas da verificação de mensagens por contratos. A primeira diz respeito a quem pode autorizar operações da conta; a segunda, a como um programa determina se uma mensagem é válida. Mesmo que a verificação da assinatura seja aprovada, isso não significa que o conteúdo da mensagem, o escopo das permissões ou a lógica de negócios sejam automaticamente corretos. Os limites de segurança precisam ser definidos no fluxo de autorização efetivamente utilizado.
O que mais me interessa são os próximos pontos verificáveis: registros de versões oficiais e de ativação do protocolo, suporte das carteiras e instruções claras de migração. O que é possível confirmar agora é que a NEAR está avançando em diferentes recursos de verificação de assinaturas para contas e contratos; o que não é possível confirmar é que todas as contas antigas, aplicações e dependências externas já concluíram a migração em conjunto. Esta é uma análise do alcance técnico, não uma previsão sobre a direção do preço da moeda baseada no nome do algoritmo.