A arquitetura atual do Dusk tem um traço bem evidente — ela está, de propósito, “desmontando”.
Ao contrário da maioria das blockchains públicas, que empilham consenso, execução e liquidação em uma única pilha monolítica, o Dusk separa essas três coisas. Na camada mais baixa está o DuskDS, que cuida do consenso, da disponibilidade de dados e da liquidação; no meio fica um DuskEVM, totalmente compatível com Solidity, para que desenvolvedores migrando de Ethereum quase não precisem alterar o código; no topo ainda existe uma camada DuskVM, dedicada a executar aplicações nativas de privacidade. As três camadas cuidam de partes diferentes, mas tudo é interligado pelo mesmo token DUSK.
Motivação para essa escolha não é difícil de entender. Construir uma cadeia que seja um ecossistema próprio tem como maior custo fazer com que os desenvolvedores precisem aprender novamente a toolchain, e a aceleração da adoção do ecossistema fica bem lenta. Ao colocar a camada EVM, Solidity, Hardhat e MetaMask passam a ser usados diretamente, e a fricção para recrutar desenvolvedores diminui.
Mas o custo dessa escolha também é bem direto — a complexidade aumenta, e aumenta exatamente onde é mais perigoso.
O fluxo entre camadas implica novas suposições de confiança e novas superfícies de ataque. Para que os ativos circulem entre o DuskDS e o DuskEVM, é necessário um mecanismo nativo de ponte; embora não seja preciso embrulhar ativos nem confiar em custodiantes, o próprio fato de atravessar camadas introduz etapas extras de verificação. Nos últimos anos, os incidentes causados por designs de ponte entre camadas foram muito mais numerosos do que os incidentes causados pelo próprio virtual machine.
Existe ainda um problema que é fácil de ignorar — a distribuição dos nós. O Dusk utiliza consenso SBA, o que requer que os nós permaneçam online de forma contínua e com a configuração bem feita. Esses requisitos, mesmo garantindo segurança da rede, também significam que o custo de hardware e de operação para participantes comuns manterem nós rodando por muito tempo não é baixo. Se, com o tempo, os nós forem se concentrando nas mãos de poucos grandes detentores, mesmo a melhor arquitetura perde o valor.
Então, quando olho para o Dusk agora, o foco não é quantas camadas ele tem nem quantos TPS ele suporta. Eu olho para duas coisas: primeiro, se o estado dos ativos e os limites de privacidade entre camadas foram explicados com clareza; segundo, o tipo de aplicações que aparecem na camada EVM — se forem todas apenas protocolos genéricos migrados, a modularidade só muda a forma de “captar” clientes; se houver aplicações realmente chamando capacidades confidenciais da camada inferior (por exemplo, usando o livro de ordens criptografado do Hedger ou títulos sigilosos do padrão XSC), então isso mostra que a diferenciação desse design está sendo usada de verdade.
Com a arquitetura montada, agora é ver o que ela consegue fazer crescer por cima.
#dusk $DUSK @Dusk
Ao contrário da maioria das blockchains públicas, que empilham consenso, execução e liquidação em uma única pilha monolítica, o Dusk separa essas três coisas. Na camada mais baixa está o DuskDS, que cuida do consenso, da disponibilidade de dados e da liquidação; no meio fica um DuskEVM, totalmente compatível com Solidity, para que desenvolvedores migrando de Ethereum quase não precisem alterar o código; no topo ainda existe uma camada DuskVM, dedicada a executar aplicações nativas de privacidade. As três camadas cuidam de partes diferentes, mas tudo é interligado pelo mesmo token DUSK.
Motivação para essa escolha não é difícil de entender. Construir uma cadeia que seja um ecossistema próprio tem como maior custo fazer com que os desenvolvedores precisem aprender novamente a toolchain, e a aceleração da adoção do ecossistema fica bem lenta. Ao colocar a camada EVM, Solidity, Hardhat e MetaMask passam a ser usados diretamente, e a fricção para recrutar desenvolvedores diminui.
Mas o custo dessa escolha também é bem direto — a complexidade aumenta, e aumenta exatamente onde é mais perigoso.
O fluxo entre camadas implica novas suposições de confiança e novas superfícies de ataque. Para que os ativos circulem entre o DuskDS e o DuskEVM, é necessário um mecanismo nativo de ponte; embora não seja preciso embrulhar ativos nem confiar em custodiantes, o próprio fato de atravessar camadas introduz etapas extras de verificação. Nos últimos anos, os incidentes causados por designs de ponte entre camadas foram muito mais numerosos do que os incidentes causados pelo próprio virtual machine.
Existe ainda um problema que é fácil de ignorar — a distribuição dos nós. O Dusk utiliza consenso SBA, o que requer que os nós permaneçam online de forma contínua e com a configuração bem feita. Esses requisitos, mesmo garantindo segurança da rede, também significam que o custo de hardware e de operação para participantes comuns manterem nós rodando por muito tempo não é baixo. Se, com o tempo, os nós forem se concentrando nas mãos de poucos grandes detentores, mesmo a melhor arquitetura perde o valor.
Então, quando olho para o Dusk agora, o foco não é quantas camadas ele tem nem quantos TPS ele suporta. Eu olho para duas coisas: primeiro, se o estado dos ativos e os limites de privacidade entre camadas foram explicados com clareza; segundo, o tipo de aplicações que aparecem na camada EVM — se forem todas apenas protocolos genéricos migrados, a modularidade só muda a forma de “captar” clientes; se houver aplicações realmente chamando capacidades confidenciais da camada inferior (por exemplo, usando o livro de ordens criptografado do Hedger ou títulos sigilosos do padrão XSC), então isso mostra que a diferenciação desse design está sendo usada de verdade.
Com a arquitetura montada, agora é ver o que ela consegue fazer crescer por cima.
#dusk $DUSK @Dusk
