10 de agosto @Dusk entrou na rede de testes do DuskEVM. Desenvolvedores conseguem implantar usando Solidity e Hardhat. Minha primeira reação foi achar isso um pouco estranho.
Estranho por quê? @Dusk passou mais de sete anos construindo um privacy L1 nativo. O DuskVM roda Rust e WASM; a privacidade nasce da camada de transição de estado, e essa é a diferença mais forte dele. Agora colocaram mais uma camada de compatibilidade com EVM — em outras palavras, está como se admitissem: “as ferramentas que vocês deveriam usar são as mesmas de Ethereum”. Parece um acordo.
Depois mudei de ideia. Porque a verdade é dura, mas é real: sem vantagem técnica dos desenvolvedores, não é vantagem.
O grupo de desenvolvedores Solidity e o pessoal que faz Rust com WASM não tem, em escala, o mesmo tamanho. Fazer uma equipe que já integrou o Aave precisar reaprender Rust, reescrever o processo de auditoria, trocar as ferramentas de teste por causa das suas capacidades de privacidade — a maior parte simplesmente vai desistir. Se você não entra no fluxo de trabalho dos outros, então é zero.
O DuskEVM usa o OP Stack, e o settlement e a disponibilidade de dados voltam para o DuskDS. A divisão é clara: a camada de baixo cuida das invariantes de privacidade e da finalidade; a camada de cima cuida da experiência do desenvolvedor. O que realmente me preocupa é a “fenda” entre as duas camadas.
Contratos escritos em Solidity conseguem acessar quanta capacidade de privacidade? Fica na mesma categoria dos contratos nativos do DuskEVM, ou é uma versão “com desconto”? Ainda mais importante: e os ativos entre camadas — títulos tokenizados que foram negociados na camada EVM. Eles ainda reconhecem as white lists, limites de holdings e restrições de jurisdição que foram codificados na camada nativa?
Se uma cadeia incorpora conformidade dentro dos ativos na L1, mas a camada de execução na L2 não consegue expressar isso, é como abrir um caminho para contornar. Isso não é um problema exclusivo do Dusk, mas para uma cadeia que vende “nativo com conformidade”, isso é especialmente crucial.
Referência de dados: a mainnet subiu em 7 de janeiro de 2025; o TVL do Sozu é de cerca de quarenta e três milhões; a taxa anualizada é de 33%. O acima é um resumo de canais públicos, não um teste prático on-chain.
Pensando com calma: o DuskEVM ainda está em rede de testes; nenhum aplicativo real em nível de instituição rodou de fato. Se a camada de compatibilidade é boa ou não, só dá para saber quando alguém usar isso de verdade para construir coisas complexas.
Se você fosse desenvolvedor, trocaria a linguagem e a toolchain pela capacidade de privacidade de uma cadeia, ou esperaria ela pavimentar o caminho da rota do EVM para então decidir? Falando a verdade.
#dusk $DUSK @Dusk
Estranho por quê? @Dusk passou mais de sete anos construindo um privacy L1 nativo. O DuskVM roda Rust e WASM; a privacidade nasce da camada de transição de estado, e essa é a diferença mais forte dele. Agora colocaram mais uma camada de compatibilidade com EVM — em outras palavras, está como se admitissem: “as ferramentas que vocês deveriam usar são as mesmas de Ethereum”. Parece um acordo.
Depois mudei de ideia. Porque a verdade é dura, mas é real: sem vantagem técnica dos desenvolvedores, não é vantagem.
O grupo de desenvolvedores Solidity e o pessoal que faz Rust com WASM não tem, em escala, o mesmo tamanho. Fazer uma equipe que já integrou o Aave precisar reaprender Rust, reescrever o processo de auditoria, trocar as ferramentas de teste por causa das suas capacidades de privacidade — a maior parte simplesmente vai desistir. Se você não entra no fluxo de trabalho dos outros, então é zero.
O DuskEVM usa o OP Stack, e o settlement e a disponibilidade de dados voltam para o DuskDS. A divisão é clara: a camada de baixo cuida das invariantes de privacidade e da finalidade; a camada de cima cuida da experiência do desenvolvedor. O que realmente me preocupa é a “fenda” entre as duas camadas.
Contratos escritos em Solidity conseguem acessar quanta capacidade de privacidade? Fica na mesma categoria dos contratos nativos do DuskEVM, ou é uma versão “com desconto”? Ainda mais importante: e os ativos entre camadas — títulos tokenizados que foram negociados na camada EVM. Eles ainda reconhecem as white lists, limites de holdings e restrições de jurisdição que foram codificados na camada nativa?
Se uma cadeia incorpora conformidade dentro dos ativos na L1, mas a camada de execução na L2 não consegue expressar isso, é como abrir um caminho para contornar. Isso não é um problema exclusivo do Dusk, mas para uma cadeia que vende “nativo com conformidade”, isso é especialmente crucial.
Referência de dados: a mainnet subiu em 7 de janeiro de 2025; o TVL do Sozu é de cerca de quarenta e três milhões; a taxa anualizada é de 33%. O acima é um resumo de canais públicos, não um teste prático on-chain.
Pensando com calma: o DuskEVM ainda está em rede de testes; nenhum aplicativo real em nível de instituição rodou de fato. Se a camada de compatibilidade é boa ou não, só dá para saber quando alguém usar isso de verdade para construir coisas complexas.
Se você fosse desenvolvedor, trocaria a linguagem e a toolchain pela capacidade de privacidade de uma cadeia, ou esperaria ela pavimentar o caminho da rota do EVM para então decidir? Falando a verdade.
#dusk $DUSK @Dusk
