Muitas pessoas reclamam que o EVM #dusk é “dar marcha-ré”, mas eu acho justamente que isso mostra que o time finalmente entendeu uma coisa: compatibilidade não é concessão, é controle de custos.
Criar do zero um ambiente de execução totalmente novo, tecnicamente talvez não fique atrás do Ethereum, mas o preço é que todas as estruturas de suporte precisam crescer de novo — as empresas de auditoria têm que aprender uma linguagem nova para produzir relatórios, o time de carteiras precisa reescrever a lógica de assinatura, e os serviços de indexação precisam se adaptar novamente. Esses custos, no fim, acabam sendo repassados às instituições que realmente topam colocar na blockchain. E, ao escolher tecnologia, essas instituições normalmente olham primeiro “se meu time atual consegue colocar a mão direto” e não “quão elegante é o design dessa linguagem”.
O EVM @Dusk tem um ponto inteligente: ele separa a camada de execução das capacidades da base. Os desenvolvedores continuam usando as ferramentas já conhecidas para implantar contratos, mas, se quiserem, podem chamar os recursos nativos de liquidação confidencial e verificação de conformidade. É como oferecer uma opção ao desenvolvedor, em vez de forçar um único caminho sem alternativa. Times que já tokenizaram no Ethereum, em teoria, conseguem reduzir bastante a necessidade de derrubar e reescrever código, e conectar a lógica de liquidação diretamente a uma blockchain que foi projetada desde o início para cenários regulados.
Mas eu não vou supervalorizá-lo só por causa desse design. Ter mais uma camada de compatibilidade é também assumir mais uma camada de premissas de confiança. Em pontos como comunicação entre camadas e sincronização de estado, historicamente os acidentes não foram menos — não dá para dizer que foi “menos perigoso” do que falhas em contratos. O risco mais realista é outro: se a maioria dos desenvolvedores apenas mover projetos antigos intactos, com o objetivo de aproveitar a conveniência do ecossistema EVM, então a capacidade realmente diferenciadora — a liquidação confidencial — fica de lado. Aí o EVM $DUSK não fica tão diferente de uma sidechain EVM comum.
Por isso, não dou tanta importância aos números animados de implantação de contratos. Eu só quero saber, nesses contratos, quantos realmente usam os módulos nativos de privacidade e conformidade. Se essa proporção não subir, a história de diferenciação que o DuskEVM conta vira apenas uma opção — não vira fato.
Criar do zero um ambiente de execução totalmente novo, tecnicamente talvez não fique atrás do Ethereum, mas o preço é que todas as estruturas de suporte precisam crescer de novo — as empresas de auditoria têm que aprender uma linguagem nova para produzir relatórios, o time de carteiras precisa reescrever a lógica de assinatura, e os serviços de indexação precisam se adaptar novamente. Esses custos, no fim, acabam sendo repassados às instituições que realmente topam colocar na blockchain. E, ao escolher tecnologia, essas instituições normalmente olham primeiro “se meu time atual consegue colocar a mão direto” e não “quão elegante é o design dessa linguagem”.
O EVM @Dusk tem um ponto inteligente: ele separa a camada de execução das capacidades da base. Os desenvolvedores continuam usando as ferramentas já conhecidas para implantar contratos, mas, se quiserem, podem chamar os recursos nativos de liquidação confidencial e verificação de conformidade. É como oferecer uma opção ao desenvolvedor, em vez de forçar um único caminho sem alternativa. Times que já tokenizaram no Ethereum, em teoria, conseguem reduzir bastante a necessidade de derrubar e reescrever código, e conectar a lógica de liquidação diretamente a uma blockchain que foi projetada desde o início para cenários regulados.
Mas eu não vou supervalorizá-lo só por causa desse design. Ter mais uma camada de compatibilidade é também assumir mais uma camada de premissas de confiança. Em pontos como comunicação entre camadas e sincronização de estado, historicamente os acidentes não foram menos — não dá para dizer que foi “menos perigoso” do que falhas em contratos. O risco mais realista é outro: se a maioria dos desenvolvedores apenas mover projetos antigos intactos, com o objetivo de aproveitar a conveniência do ecossistema EVM, então a capacidade realmente diferenciadora — a liquidação confidencial — fica de lado. Aí o EVM $DUSK não fica tão diferente de uma sidechain EVM comum.
Por isso, não dou tanta importância aos números animados de implantação de contratos. Eu só quero saber, nesses contratos, quantos realmente usam os módulos nativos de privacidade e conformidade. Se essa proporção não subir, a história de diferenciação que o DuskEVM conta vira apenas uma opção — não vira fato.