Antes eu misturei Dusk Trade, DuskEVM e DuskDS ao analisar tudo junto e tive a impressão de que havia muitos termos. Depois que eu separei de novo, a lógica ficou mais clara.
O DuskDS fica responsável pelo consenso, pelo resultado final determinístico, pela disponibilidade de dados e pelos modelos de transação Moonlight e Phoenix; o DuskVM permite que contratos em Rust/WASM sejam executados diretamente na camada 1 nativa; o DuskEVM oferece o ambiente de aplicações Solidity; e o Dusk Trade transforma, de forma que o usuário consiga operar, o controle de acesso, a compra e a venda e a liquidação.
Isso se parece com um mercado de valores: o DuskDS é o livro razão e o centro de liquidação; o DuskVM e o DuskEVM são duas trilhas de desenvolvimento de negócios; e o Dusk Trade é o balcão de transações voltado para os investidores.
O balcão pode ser atualizado, mas o livro-razão subjacente precisa ser estável.
Essa abordagem em camadas me ajudou a entender por que o Dusk insiste tanto em settlement determinístico.
Ativos regulados não podem aceitar “talvez não dê rollback por probabilidade”; o mercado precisa de um estado final inequívoco.
Minhas dúvidas também mudaram: uma arquitetura em múltiplas camadas pode acabar transferindo o risco do desempenho de uma única cadeia para a complexidade de mensagens entre camadas, pontes e operação/manutenção? Ter a finalização na camada de baixo é uma vantagem, mas só quando as camadas superiores a herdam corretamente é que o usuário realmente obtém uma liquidação mais limpa.
#dusk $DUSK @Dusk
O DuskDS fica responsável pelo consenso, pelo resultado final determinístico, pela disponibilidade de dados e pelos modelos de transação Moonlight e Phoenix; o DuskVM permite que contratos em Rust/WASM sejam executados diretamente na camada 1 nativa; o DuskEVM oferece o ambiente de aplicações Solidity; e o Dusk Trade transforma, de forma que o usuário consiga operar, o controle de acesso, a compra e a venda e a liquidação.
Isso se parece com um mercado de valores: o DuskDS é o livro razão e o centro de liquidação; o DuskVM e o DuskEVM são duas trilhas de desenvolvimento de negócios; e o Dusk Trade é o balcão de transações voltado para os investidores.
O balcão pode ser atualizado, mas o livro-razão subjacente precisa ser estável.
Essa abordagem em camadas me ajudou a entender por que o Dusk insiste tanto em settlement determinístico.
Ativos regulados não podem aceitar “talvez não dê rollback por probabilidade”; o mercado precisa de um estado final inequívoco.
Minhas dúvidas também mudaram: uma arquitetura em múltiplas camadas pode acabar transferindo o risco do desempenho de uma única cadeia para a complexidade de mensagens entre camadas, pontes e operação/manutenção? Ter a finalização na camada de baixo é uma vantagem, mas só quando as camadas superiores a herdam corretamente é que o usuário realmente obtém uma liquidação mais limpa.
#dusk $DUSK @Dusk