Há alguns dias, enquanto eu rolava o X, me deparei com uma postagem sobre a testnet DuskEVM, e um detalhe chamou minha atenção. Em 10 de agosto, a testnet DuskEVM entrou no ar, Solidity e Hardhat estavam funcionando sem problemas, mas o Hedger, o motor principal de contratos confidenciais, vem sendo executado separadamente na testnet Ethereum Sepolia desde novembro de 2025. A equipe oficial ainda não anunciou quando os dois serão fundidos.
Quando as pessoas veem essa lacuna de 9 meses, a primeira reação é preocupação. Uma blockchain focada em privacidade, que tenha sua camada de privacidade e sua camada EVM testadas separadamente, pode parecer incomum.
Mas depois de ler a documentação técnica, comecei a pensar que esses testes em dois trilhos poderiam ser uma escolha subestimada na arquitetura da Dusk. A pilha da Dusk é em camadas. #Dusk cuida do liquidação e da disponibilidade de dados, DuskEVM é a camada EVM, e Hedger é a camada de privacidade usando criptografia homomórfica e provas de conhecimento zero.
Se as três camadas fossem testadas juntas, um bug de criptografia e um bug de contrato poderiam se tornar difíceis de distinguir. Testá-las separadamente permite que a equipe faça a camada EVM funcionar primeiro, deixe os desenvolvedores implantarem aplicações, depois valide o Hedger separadamente na Sepolia e, por fim, faça a fusão de volta em $DUSK . Isso torna o processo de depuração muito mais claro.
Não tenho certeza se esse julgamento está correto. Também é possível que conflitos de protocolo surjam durante a fusão final e exijam que algum trabalho anterior seja refeito. Modularidade parece boa, mas a engenharia sempre traz custos de coordenação.
Mas por outro ângulo, clientes institucionais temem mais algo quebrar do que ficar lento. Uma implantação faseada pode ser mais confiável do que colocar tudo de uma vez e depois ter de voltar atrás.
Lançar a EVM primeiro e fundir o Hedger após validação adequada poderia simplesmente ser uma forma de garantir que a base seja sólida.
O que vocês acham dessa estratégia de testes em dois trilhos? Quero ouvir a opinião de todos.@Dusk
Quando as pessoas veem essa lacuna de 9 meses, a primeira reação é preocupação. Uma blockchain focada em privacidade, que tenha sua camada de privacidade e sua camada EVM testadas separadamente, pode parecer incomum.
Mas depois de ler a documentação técnica, comecei a pensar que esses testes em dois trilhos poderiam ser uma escolha subestimada na arquitetura da Dusk. A pilha da Dusk é em camadas. #Dusk cuida do liquidação e da disponibilidade de dados, DuskEVM é a camada EVM, e Hedger é a camada de privacidade usando criptografia homomórfica e provas de conhecimento zero.
Se as três camadas fossem testadas juntas, um bug de criptografia e um bug de contrato poderiam se tornar difíceis de distinguir. Testá-las separadamente permite que a equipe faça a camada EVM funcionar primeiro, deixe os desenvolvedores implantarem aplicações, depois valide o Hedger separadamente na Sepolia e, por fim, faça a fusão de volta em $DUSK . Isso torna o processo de depuração muito mais claro.
Não tenho certeza se esse julgamento está correto. Também é possível que conflitos de protocolo surjam durante a fusão final e exijam que algum trabalho anterior seja refeito. Modularidade parece boa, mas a engenharia sempre traz custos de coordenação.
Mas por outro ângulo, clientes institucionais temem mais algo quebrar do que ficar lento. Uma implantação faseada pode ser mais confiável do que colocar tudo de uma vez e depois ter de voltar atrás.
Lançar a EVM primeiro e fundir o Hedger após validação adequada poderia simplesmente ser uma forma de garantir que a base seja sólida.
O que vocês acham dessa estratégia de testes em dois trilhos? Quero ouvir a opinião de todos.@Dusk
