Quando os engenheiros da Dusk Network tiveram de decidir como os contratos realmente seriam executados, não recorreram ao atalho óbvio. A maioria das novas Layer-1 lançadas nos últimos anos chegou compatível com EVM desde o primeiro dia, apostando que a familiaridade com Solidity superaria qualquer custo técnico. A Dusk Network criou primeiro sua própria máquina virtual: Piecrust, um runtime baseado em WASM com suporte nativo para operações de conhecimento zero como verificação de PLONK e Groth16, além de um modelo de estado baseado em delta que só persiste o que realmente mudou em vez de reescrever o estado completo a cada bloco.
Esse é um caminho mais difícil e mais lento. Também é o único caminho que permitiu que os contratos da Dusk Network fossem nativos de zero conhecimento, e não apenas “adjacentes” a zero conhecimento, já que ambientes EVM padrão não foram projetados com a verificação de provas confidenciais como uma operação de primeira classe. A troca foi a familiaridade do desenvolvedor: a maioria dos engenheiros conhece Solidity, bem poucos conhecem Rust e as macros de contrato da Dusk Network — e esse foi um custo real que a equipe aceitou conscientemente.
O interessante é que a Dusk Network não ficou presa a essa troca para sempre. O DuskEVM chegou como um segundo ambiente de execução, totalmente equivalente a EVM, assentando na mesma camada subjacente da DuskDS que os contratos baseados em Piecrust utilizam, com uma ponte nativa sem necessidade de confiança e ferramentas padrão que os desenvolvedores já conhecem. Em vez de escolher 1 modelo de execução e forçar todos os casos de uso por ele, a Dusk Network separou completamente liquidação de execução, permitindo que aplicações nativas em privacidade vivam no Piecrust e equipes nativas em Ethereum vivam no DuskEVM, ambos herdando as mesmas garantias de consenso e finalização na base.
Acredito que essa ordem de execução foi a decisão certa: construir primeiro a coisa mais difícil e mais diferenciada e, depois, adicionar a porta de entrada familiar quando a base já existisse. Se 2 ambientes de execução fragmentam liquidez e atenção em vez de adicionar flexibilidade é uma questão de design em aberto que ainda ninguém fora da Dusk Network consegue responder completamente.
#dusk $DUSK @Dusk
Esse é um caminho mais difícil e mais lento. Também é o único caminho que permitiu que os contratos da Dusk Network fossem nativos de zero conhecimento, e não apenas “adjacentes” a zero conhecimento, já que ambientes EVM padrão não foram projetados com a verificação de provas confidenciais como uma operação de primeira classe. A troca foi a familiaridade do desenvolvedor: a maioria dos engenheiros conhece Solidity, bem poucos conhecem Rust e as macros de contrato da Dusk Network — e esse foi um custo real que a equipe aceitou conscientemente.
O interessante é que a Dusk Network não ficou presa a essa troca para sempre. O DuskEVM chegou como um segundo ambiente de execução, totalmente equivalente a EVM, assentando na mesma camada subjacente da DuskDS que os contratos baseados em Piecrust utilizam, com uma ponte nativa sem necessidade de confiança e ferramentas padrão que os desenvolvedores já conhecem. Em vez de escolher 1 modelo de execução e forçar todos os casos de uso por ele, a Dusk Network separou completamente liquidação de execução, permitindo que aplicações nativas em privacidade vivam no Piecrust e equipes nativas em Ethereum vivam no DuskEVM, ambos herdando as mesmas garantias de consenso e finalização na base.
Acredito que essa ordem de execução foi a decisão certa: construir primeiro a coisa mais difícil e mais diferenciada e, depois, adicionar a porta de entrada familiar quando a base já existisse. Se 2 ambientes de execução fragmentam liquidez e atenção em vez de adicionar flexibilidade é uma questão de design em aberto que ainda ninguém fora da Dusk Network consegue responder completamente.
#dusk $DUSK @Dusk
