Depois de ler a documentação de desenvolvimento completa do @Dusk , percebi que o mais valioso agora não é nenhum slogan de TPS, e sim o fato de terem dividido o ponto de entrada de desenvolvimento em dois ambientes: DuskVM e DuskEVM. À primeira vista parece repetir a roda; por trás disso, porém, está a tentativa de resolver o problema de que “capacidades nativas de privacidade” e “ecossistema de desenvolvimento pronto” não conseguem ser atendidos em um único passo.
O DuskVM permite que contratos Rust/WASM sejam executados diretamente na L1, ficando mais próximo da Phoenix ao ocultar transações, capacidades de zero conhecimento e o modelo de ativos nativos; já o DuskEVM é baseado no OP Stack: os desenvolvedores podem continuar usando Solidity, Hardhat, Foundry e ferramentas de carteira já conhecidas, e o resultado da execução é então liquidado e garantida a disponibilidade dos dados via DuskDS. Em poucas palavras: o primeiro é como um laboratório dedicado — profundo em capacidades, mas com alta barreira de aprendizado; o segundo é como uma interface padrão — integração rápida, mas exige lidar com a coordenação entre camadas.
Essa rota é, de fato, pragmática. Muitas tecnologias de cadeias de privacidade ficam pesadas e, no fim, emperram porque ninguém sabe como desenvolvê-las; por outro lado, as ferramentas padrão de cadeias EVM estão completas, mas é difícil tratar de forma nativa ativos regulados que exigem confidencialidade e divulgação seletiva. A Dusk mantém os dois tipos de desenvolvedores, evitando pelo menos o velho problema de “tecnologia correta, ecossistema vazio”.
Mas os benefícios de dois ambientes não são “grátis”. Onde o contrato fica, como os ativos atravessam camadas e qual camada responde por falhas — tudo isso aumenta a complexidade de engenharia. Especialmente no DuskEVM, que depende da DuskDS para liquidação e disponibilidade de dados: o usuário vê uma interface EVM familiar, mas por baixo não é uma simples sidechain comum do Ethereum. Se a documentação, o navegador e as mensagens de estado entre camadas não acompanharem, a compatibilidade pode, na verdade, criar um novo custo de entendimento.
Eu não vou tirar conclusões sobre o crescimento dos desenvolvedores de #dusk apenas com base em “suporta Solidity”. O que vale observar agora é: a quantidade real de contratos na mainnet, se os caminhos de ativos entre camadas são suaves e quando capacidades de privacidade como a Hedger se transformarão em componentes reutilizáveis. $DUSK , como ativos de segurança e de Gas dentro dos dois ambientes, também precisa provar seu valor pela quantidade real de chamadas — não por um loop automático movido por diagramas de arquitetura.
O que você acha: esse modelo de execução dupla é uma divisão inteligente do trabalho, ou é ampliar a dificuldade de manutenção? Fique à vontade para deixar sua opinião.
$BTW $ETH
O DuskVM permite que contratos Rust/WASM sejam executados diretamente na L1, ficando mais próximo da Phoenix ao ocultar transações, capacidades de zero conhecimento e o modelo de ativos nativos; já o DuskEVM é baseado no OP Stack: os desenvolvedores podem continuar usando Solidity, Hardhat, Foundry e ferramentas de carteira já conhecidas, e o resultado da execução é então liquidado e garantida a disponibilidade dos dados via DuskDS. Em poucas palavras: o primeiro é como um laboratório dedicado — profundo em capacidades, mas com alta barreira de aprendizado; o segundo é como uma interface padrão — integração rápida, mas exige lidar com a coordenação entre camadas.
Essa rota é, de fato, pragmática. Muitas tecnologias de cadeias de privacidade ficam pesadas e, no fim, emperram porque ninguém sabe como desenvolvê-las; por outro lado, as ferramentas padrão de cadeias EVM estão completas, mas é difícil tratar de forma nativa ativos regulados que exigem confidencialidade e divulgação seletiva. A Dusk mantém os dois tipos de desenvolvedores, evitando pelo menos o velho problema de “tecnologia correta, ecossistema vazio”.
Mas os benefícios de dois ambientes não são “grátis”. Onde o contrato fica, como os ativos atravessam camadas e qual camada responde por falhas — tudo isso aumenta a complexidade de engenharia. Especialmente no DuskEVM, que depende da DuskDS para liquidação e disponibilidade de dados: o usuário vê uma interface EVM familiar, mas por baixo não é uma simples sidechain comum do Ethereum. Se a documentação, o navegador e as mensagens de estado entre camadas não acompanharem, a compatibilidade pode, na verdade, criar um novo custo de entendimento.
Eu não vou tirar conclusões sobre o crescimento dos desenvolvedores de #dusk apenas com base em “suporta Solidity”. O que vale observar agora é: a quantidade real de contratos na mainnet, se os caminhos de ativos entre camadas são suaves e quando capacidades de privacidade como a Hedger se transformarão em componentes reutilizáveis. $DUSK , como ativos de segurança e de Gas dentro dos dois ambientes, também precisa provar seu valor pela quantidade real de chamadas — não por um loop automático movido por diagramas de arquitetura.
O que você acha: esse modelo de execução dupla é uma divisão inteligente do trabalho, ou é ampliar a dificuldade de manutenção? Fique à vontade para deixar sua opinião.
$BTW $ETH
