No início, Dusk chamou a atenção de geeks e veteranos — muitos atraídos pela sua pilha subjacente desenvolvida internamente: o runtime Rusk construído em Rust, a VM ZK nativa Piecrust e o modelo de transações Phoenix. A intenção por trás desse ecossistema desenvolvido internamente é bem clara: usar um ambiente de provas de conhecimento zero totalmente “de sangue”, com suporte nativo à confidencialidade de contratos inteligentes e divulgações seletivas a partir do nível mais baixo da máquina virtual.
Mas a realidade deu uma lição a qualquer cadeia pública que tente “reinventar a roda”: sem a base de desenvolvedores do ecossistema Ethereum, por mais elegante que seja a arquitetura desenvolvida internamente, ela vira uma ilha.
Então vimos uma grande virada na arquitetura do Dusk — de um L1 monolítico para a atual arquitetura modular em três camadas: a camada de consenso e liquidação na base (DuskDS), a camada de privacidade (DuskVM/Piecrust) e o DuskEVM, recentemente colocado no ar na testnet e impulsionado com força. A lógica oficial é tentadora: permitir que desenvolvedores implantem de forma perfeita usando Solidity e Hardhat conhecidos, ao mesmo tempo em que herdam as capacidades de privacidade e conformidade da camada subjacente.
Só que isso acaba criando um paradoxo de engenharia extremamente incômodo:
O EVM, em essência, é uma máquina de estado global totalmente transparente, enquanto o núcleo da privacidade ZK é esconder o estado.
Ao acoplar um EVM padrão à camada de liquidação, você consegue atrair rapidamente desenvolvedores externos; mas se os desenvolvedores resolverem facilitar e continuarem a escrever, no DuskEVM, aqueles contratos Solidity padrão e transparentes, a Piecrust e a camada nativa de privacidade ZK que a Dusk levou anos para lapidar não acabariam virando um simples “museu de vitrine” esvaziado?
Mais realista ainda é a complexidade da sincronização de estado entre camadas. Quando um ativo em conformidade é liquidado no DuskDS, circula no DuskEVM e ainda tenta chamar uma prova de conhecimento zero do DuskVM, de que magnitude são os custos invisíveis — em latência de execução e segurança entre camadas — impostos pelos mecanismos de compromisso de estado e de pré-validação (Pre-verifier) entre essas camadas?
Na história da evolução da infraestrutura criptográfica, vimos muitas redes públicas perderem suas características técnicas por causa da ansiedade do ecossistema: adotaram “EVM de forma abrangente” sem critério e, no fim, se nivelaram, virando apenas mais uma sidechain comum do Ethereum. A modularização em três camadas do Dusk é, de fato, extremamente ambiciosa, tentando conciliar o “jeito de desenvolver no ecossistema Ethereum” com a privacidade e conformidade nativas; mas, na prática, esse quebra-cabeça complexo realmente consegue liberar o poder das finanças em conformidade — ou vai, no fim, diluir a pureza original em concessões de engenharia?
#dusk $DUSK @Dusk
Mas a realidade deu uma lição a qualquer cadeia pública que tente “reinventar a roda”: sem a base de desenvolvedores do ecossistema Ethereum, por mais elegante que seja a arquitetura desenvolvida internamente, ela vira uma ilha.
Então vimos uma grande virada na arquitetura do Dusk — de um L1 monolítico para a atual arquitetura modular em três camadas: a camada de consenso e liquidação na base (DuskDS), a camada de privacidade (DuskVM/Piecrust) e o DuskEVM, recentemente colocado no ar na testnet e impulsionado com força. A lógica oficial é tentadora: permitir que desenvolvedores implantem de forma perfeita usando Solidity e Hardhat conhecidos, ao mesmo tempo em que herdam as capacidades de privacidade e conformidade da camada subjacente.
Só que isso acaba criando um paradoxo de engenharia extremamente incômodo:
O EVM, em essência, é uma máquina de estado global totalmente transparente, enquanto o núcleo da privacidade ZK é esconder o estado.
Ao acoplar um EVM padrão à camada de liquidação, você consegue atrair rapidamente desenvolvedores externos; mas se os desenvolvedores resolverem facilitar e continuarem a escrever, no DuskEVM, aqueles contratos Solidity padrão e transparentes, a Piecrust e a camada nativa de privacidade ZK que a Dusk levou anos para lapidar não acabariam virando um simples “museu de vitrine” esvaziado?
Mais realista ainda é a complexidade da sincronização de estado entre camadas. Quando um ativo em conformidade é liquidado no DuskDS, circula no DuskEVM e ainda tenta chamar uma prova de conhecimento zero do DuskVM, de que magnitude são os custos invisíveis — em latência de execução e segurança entre camadas — impostos pelos mecanismos de compromisso de estado e de pré-validação (Pre-verifier) entre essas camadas?
Na história da evolução da infraestrutura criptográfica, vimos muitas redes públicas perderem suas características técnicas por causa da ansiedade do ecossistema: adotaram “EVM de forma abrangente” sem critério e, no fim, se nivelaram, virando apenas mais uma sidechain comum do Ethereum. A modularização em três camadas do Dusk é, de fato, extremamente ambiciosa, tentando conciliar o “jeito de desenvolver no ecossistema Ethereum” com a privacidade e conformidade nativas; mas, na prática, esse quebra-cabeça complexo realmente consegue liberar o poder das finanças em conformidade — ou vai, no fim, diluir a pureza original em concessões de engenharia?
#dusk $DUSK @Dusk
