Ao revisar novamente o registro mais recente de upgrade de rede do @Dusk , notei uma mudança ainda mais importante do que a de uma versão comum: após o upgrade do Boreas, a mainnet do Dusk já parou de receber e executar novas transações do Phoenix.
O Boreas chegou junto com o Rusk 1.7, e a mainnet foi reiniciada em 10 de junho de 2026 usando o bloco 4.414.095 como limite de reinício. O Phoenix foi desabilitado na reinicialização da mainnet, enquanto a testnet parou depois de atingir a altura 4.000.000 em 7 de agosto. As novas transações atuais principalmente usam o modelo Moonlight.
Mas “parar novas transações” não significa “apagar o Phoenix”. Os nós ainda mantêm a capacidade de decodificar as antigas transações do Phoenix, executar o histórico e sincronizar o estado da cadeia, porque o Archive Node precisa conseguir reenviar (replay) blocos antigos. Em linguagem bem direta: quando o banco para de abrir um certo tipo de conta antiga, isso não quer dizer que o fluxo passado possa ser removido do livro-razão.
O Boreas também introduziu o processamento de transações versionadas, regras determinísticas de cobrança da VM, marcações de Reverted Event e ajustou a ordem de execução do Slash para antes das transações comuns. Isso indica que o foco do upgrade não é apenas trocar o modelo de transferência, mas sim restringir os limites de interpretação da mesma transação por diferentes tipos de nós.
O ponto que realmente precisa ser investigado é: qual rota de privacidade do Dusk vem em seguida? O Moonlight é um modelo de contas públicas, e o DuskEVM descreve o Hedger como o próximo caminho de privacidade. No futuro, devemos acompanhar a entrega do Hedger, migração de carteiras, tratamento de saldos antigos do Phoenix e se a documentação foi atualizada de forma unificada.
O mais perigoso ao pesquisar projetos de privacidade não são as mudanças técnicas, mas sim usar a arquitetura antiga para explicar uma nova rede. #dusk $DUSK
O Boreas chegou junto com o Rusk 1.7, e a mainnet foi reiniciada em 10 de junho de 2026 usando o bloco 4.414.095 como limite de reinício. O Phoenix foi desabilitado na reinicialização da mainnet, enquanto a testnet parou depois de atingir a altura 4.000.000 em 7 de agosto. As novas transações atuais principalmente usam o modelo Moonlight.
Mas “parar novas transações” não significa “apagar o Phoenix”. Os nós ainda mantêm a capacidade de decodificar as antigas transações do Phoenix, executar o histórico e sincronizar o estado da cadeia, porque o Archive Node precisa conseguir reenviar (replay) blocos antigos. Em linguagem bem direta: quando o banco para de abrir um certo tipo de conta antiga, isso não quer dizer que o fluxo passado possa ser removido do livro-razão.
O Boreas também introduziu o processamento de transações versionadas, regras determinísticas de cobrança da VM, marcações de Reverted Event e ajustou a ordem de execução do Slash para antes das transações comuns. Isso indica que o foco do upgrade não é apenas trocar o modelo de transferência, mas sim restringir os limites de interpretação da mesma transação por diferentes tipos de nós.
O ponto que realmente precisa ser investigado é: qual rota de privacidade do Dusk vem em seguida? O Moonlight é um modelo de contas públicas, e o DuskEVM descreve o Hedger como o próximo caminho de privacidade. No futuro, devemos acompanhar a entrega do Hedger, migração de carteiras, tratamento de saldos antigos do Phoenix e se a documentação foi atualizada de forma unificada.
O mais perigoso ao pesquisar projetos de privacidade não são as mudanças técnicas, mas sim usar a arquitetura antiga para explicar uma nova rede. #dusk $DUSK