Construir uma blockchain como uma pilha monolítica é mais simples de explicar e mais simples de lançar. Consenso, execução e liquidação vivem no mesmo caminho de código, e uma mudança em qualquer parte afeta todas as outras. A Dusk Network escolheu o caminho mais difícil, separando a DuskDS — a camada de consenso e liquidação — dos ambientes que de fato executam contratos inteligentes.
A DuskDS trata de Assinaturas de Atestado Sucinto, finalização, disponibilidade de dados e dos modelos de transação Moonlight e Phoenix. Ela não executa lógica de aplicação por conta própria. Essa tarefa pertence à DuskVM, um ambiente baseado em Wasmtime para contratos em Rust e WASM, com acesso direto às ferramentas nativas de privacidade da Dusk, ou à DuskEVM, um ambiente de execução do OP Stack para aplicações em Solidity que liquida de volta através da DuskDS com DUSK como gás. O Rusk, a implementação do nó, une tudo e expõe as interfaces que carteiras e indexadores realmente usam.
Por que passar por todo esse trabalho? Porque as garantias de liquidação e a experiência do desenvolvedor mudam em ritmos completamente diferentes. Instituições que emitem valores mobiliários tokenizados precisam de regras de finalização e controles de acesso que permaneçam estáveis por anos. Desenvolvedores que constroem aplicações precisam de ferramentas que continuem melhorando, novos SDKs, melhor compatibilidade com EVM, iterações mais rápidas. Atrelar essas duas necessidades a uma única camada significa que você congela a inovação para proteger a estabilidade, ou quebra a estabilidade ao perseguir conveniência para o desenvolvedor. Separá-las permite que a DuskDS continue “chata” e confiável, enquanto a DuskVM e a DuskEVM evoluem por baixo, ou por cima, dependendo de como você olha.
É uma decisão que troca simplicidade de curto prazo por flexibilidade de longo prazo, e, seis anos depois neste projeto, eu acho que essa troca está começando a valer a pena, mesmo que tenha tornado a arquitetura inicial mais difícil de explicar para quem é novo. O que ainda quero ver testado é o custo de coordenação quando a própria DuskDS precisa mudar, já que uma camada de liquidação compartilhada por dois ambientes de execução não consegue evoluir tão livremente quanto qualquer um deles poderia por conta própria — e essa restrição só fica mais evidente conforme ambos os ambientes passam a carregar mais valor real#dusk $DUSK @Dusk
A DuskDS trata de Assinaturas de Atestado Sucinto, finalização, disponibilidade de dados e dos modelos de transação Moonlight e Phoenix. Ela não executa lógica de aplicação por conta própria. Essa tarefa pertence à DuskVM, um ambiente baseado em Wasmtime para contratos em Rust e WASM, com acesso direto às ferramentas nativas de privacidade da Dusk, ou à DuskEVM, um ambiente de execução do OP Stack para aplicações em Solidity que liquida de volta através da DuskDS com DUSK como gás. O Rusk, a implementação do nó, une tudo e expõe as interfaces que carteiras e indexadores realmente usam.
Por que passar por todo esse trabalho? Porque as garantias de liquidação e a experiência do desenvolvedor mudam em ritmos completamente diferentes. Instituições que emitem valores mobiliários tokenizados precisam de regras de finalização e controles de acesso que permaneçam estáveis por anos. Desenvolvedores que constroem aplicações precisam de ferramentas que continuem melhorando, novos SDKs, melhor compatibilidade com EVM, iterações mais rápidas. Atrelar essas duas necessidades a uma única camada significa que você congela a inovação para proteger a estabilidade, ou quebra a estabilidade ao perseguir conveniência para o desenvolvedor. Separá-las permite que a DuskDS continue “chata” e confiável, enquanto a DuskVM e a DuskEVM evoluem por baixo, ou por cima, dependendo de como você olha.
É uma decisão que troca simplicidade de curto prazo por flexibilidade de longo prazo, e, seis anos depois neste projeto, eu acho que essa troca está começando a valer a pena, mesmo que tenha tornado a arquitetura inicial mais difícil de explicar para quem é novo. O que ainda quero ver testado é o custo de coordenação quando a própria DuskDS precisa mudar, já que uma camada de liquidação compartilhada por dois ambientes de execução não consegue evoluir tão livremente quanto qualquer um deles poderia por conta própria — e essa restrição só fica mais evidente conforme ambos os ambientes passam a carregar mais valor real#dusk $DUSK @Dusk