DuskEVM 这东西，我 recentemente翻了翻，发现一个挺关键的问题——"EVM compatível" 其实只解决了一半问题。Solidity、Foundry、Hardhat 这些工具链确实能直接用，但金融场景里还有一个更棘手的问题：机构真的愿意把余额、头寸和交易金额全部公开吗？
A solução da Dusk é a Hedger — introduzindo criptografia homomórfica e provas de conhecimento zero no fluxo de trabalho da EVM. A primeira permite que os dados participem do cálculo ainda no estado criptografado; a segunda prova que o resultado atende às regras. Assim, os dados não precisam ser públicos, mas a execução continua verificável. Market makers conseguem ocultar exposições sensíveis, saldos ficam em sigilo e, quando for preciso auditar, é possível autorizar a divulgação.
O problema é que a Hedger não é um plugin que “é só adicionar e funciona”. Ela combina criptografia homomórfica, provas de conhecimento zero e um modelo híbrido de UTXO/conta — totalmente diferente da lógica de armazenamento padrão do ERC-20. “EVM compatível” resolve como os desenvolvedores entram; a Hedger precisa resolver quais dados, depois que as instituições entram, simplesmente não deveriam ser divulgados.
A documentação oficial é bem clara: DuskEVM é baseado no OP Stack e executa um ambiente de execução equivalente à EVM, usando a toolchain familiar. Mas a ponte entre camadas que está conectada hoje ainda liga apenas em testnet e suporta apenas moedas de teste. A ferramenta convida as pessoas para dentro; só conta como “deixar” quando rodar uma aplicação real.
Se você rodar um fork do Uniswap no DuskEVM, a camada do pool de shielding precisa ser reescrita. A lógica central de AMM ao bater na camada de privacidade exige refazer tudo — não é “migração perfeita”.
EVM compatível resolve o problema da toolchain; Hedger resolve se os dados financeiros devem ou não ser públicos. O ponto-chave é: o DuskEVM consegue fazer rodar um workflow confidencial de EVM? Isso é onde ele realmente cria diferenciação. Agora a Hedger ainda está sendo aprimorada no testnet; quando ela virar mainnet, voltaremos a olhar essas questões de migração.
#dusk $DUSK @Dusk
A solução da Dusk é a Hedger — introduzindo criptografia homomórfica e provas de conhecimento zero no fluxo de trabalho da EVM. A primeira permite que os dados participem do cálculo ainda no estado criptografado; a segunda prova que o resultado atende às regras. Assim, os dados não precisam ser públicos, mas a execução continua verificável. Market makers conseguem ocultar exposições sensíveis, saldos ficam em sigilo e, quando for preciso auditar, é possível autorizar a divulgação.
O problema é que a Hedger não é um plugin que “é só adicionar e funciona”. Ela combina criptografia homomórfica, provas de conhecimento zero e um modelo híbrido de UTXO/conta — totalmente diferente da lógica de armazenamento padrão do ERC-20. “EVM compatível” resolve como os desenvolvedores entram; a Hedger precisa resolver quais dados, depois que as instituições entram, simplesmente não deveriam ser divulgados.
A documentação oficial é bem clara: DuskEVM é baseado no OP Stack e executa um ambiente de execução equivalente à EVM, usando a toolchain familiar. Mas a ponte entre camadas que está conectada hoje ainda liga apenas em testnet e suporta apenas moedas de teste. A ferramenta convida as pessoas para dentro; só conta como “deixar” quando rodar uma aplicação real.
Se você rodar um fork do Uniswap no DuskEVM, a camada do pool de shielding precisa ser reescrita. A lógica central de AMM ao bater na camada de privacidade exige refazer tudo — não é “migração perfeita”.
EVM compatível resolve o problema da toolchain; Hedger resolve se os dados financeiros devem ou não ser públicos. O ponto-chave é: o DuskEVM consegue fazer rodar um workflow confidencial de EVM? Isso é onde ele realmente cria diferenciação. Agora a Hedger ainda está sendo aprimorada no testnet; quando ela virar mainnet, voltaremos a olhar essas questões de migração.
#dusk $DUSK @Dusk
