duskvm

Eu continuava errando uma coisa ao pensar sobre Moonlight e Phoenix: eu estava tratando a forma do estado como se ela também determinasse a finalização.
Essa suposição começou a me incomodar.
Moonlight chega em #DuskVM carregando um modelo de conta pública: Saldos, Remetente, Destinatário, Valor e Progressão do Nonce.
Phoenix é construída em torno de uma trilha completamente diferente: Notas Criptografadas, Saídas Protegidas, Anuladores e Estado Privado.
Meu primeiro instinto foi que dois sistemas tão diferentes provavelmente precisariam de dois caminhos diferentes para se tornarem finais.
Mas talvez seja aí que eu estava adicionando complexidade que na verdade não existe.
Moonlight pode permanecer com formato de conta. Phoenix pode permanecer com formato de nota. #DuskVM não precisa achatar nenhum dos dois em algum formato universal de estado só para decidir quando a execução termina.
Isso também me fez repensar #DuskDS .
Eu vinha assumindo que ele precisava criar um único estado compartilhado $DUSK por baixo dos dois modelos. Agora estou menos convencido disso.
A lógica de execução pode continuar especializada enquanto o Dusk L1 ainda fornece ao estado resultante um único limite determinístico de finalização.
E, honestamente, essa separação é mais interessante para mim do que os modelos individuais de estado.
Formas diferentes de representar o estado não necessariamente exigem respostas diferentes para a pergunta de quando aquele estado está finalmente concluído.
A questão que eu ainda estou ponderando é o quão bem essa separação se mantém à medida que Moonlight e Phoenix ficam mais complexos.

#dusk $DUSK @Dusk

#dusk $DUSK @Dusk
Pilhas Modulares da Dusk: Três Camadas, Um Único Propósito

E se a arquitetura de blockchain tratasse liquidação e execução como tarefas separadas?

@Dusk está seguindo essa abordagem com um design modular baseado em três componentes:

1. DuskDS — a base de liquidação
Ela lida com consenso, finalização, disponibilidade de dados e com os modelos nativos de transações da Dusk, incluindo Moonlight para transferências públicas e Phoenix para transferências protegidas.

2. DuskEVM — o caminho EVM
Os desenvolvedores podem usar Solidity e as ferramentas familiares do ecossistema Ethereum, enquanto as aplicações fazem a liquidação via DuskDS. Isso torna o ambiente mais acessível para DeFi baseado em EVM e aplicações de ativos tokenizados.

3. DuskVM — execução direta na L1
A DuskVM executa contratos inteligentes Rust/WASM diretamente na Dusk L1, tornando-se adequada para aplicações que precisam de acesso mais profundo aos modelos de transações da Dusk, privacidade ou recursos de zero conhecimento.

A parte interessante é a própria separação: diferentes aplicações podem escolher o ambiente de execução de que precisam sem substituir a camada de liquidação subjacente.

Para $DUSK , isso cria uma base em que compatibilidade com EVM, execução direta na L1, privacidade e liquidação determinística podem funcionar dentro da mesma arquitetura mais ampla.

#DUSK #DuskEVM #DuskVM

Enquete: 🏗️ Qual parte da arquitetura modular da Dusk mais te interessa?

@Dusk está construindo algo em DeFi e a tokenização de finanças precisará, cada vez mais, de: privacidade sem perder a conformidade. Blockchains públicas são poderosas porque as transações podem ser transparentes e verificáveis, mas os mercados financeiros regulados não podem expor publicamente todo saldo, posição, detalhe do investidor ou transação. @Dusk aborda esse desafio combinando tecnologia de zero conhecimento, transferências confidenciais, divulgação seletiva, controles de acesso e liquidação determinística. �
Dusk +1
O que torna essa abordagem interessante é a ideia de que privacidade não precisa significar ocultar tudo. Participantes autorizados podem receber as informações de que precisam, enquanto dados sensíveis permanecem protegidos contra exposição pública desnecessária. Isso pode ser especialmente relevante para títulos tokenizados, ativos do mundo real, DeFi institucional e outros fluxos financeiros em que elegibilidade, relatórios, restrições de transferência e regras de liquidação importam. �
DOCS +1
A Dusk também usa uma arquitetura modular, com #DuskDS focado em liquidação e disponibilidade de dados, #DuskVM para execução nativa em Rust/WASM e #DuskEVM para aplicações compatíveis com EVM. Isso oferece aos desenvolvedores caminhos diferentes dependendo de a aplicação priorizar privacidade nativa, ferramentas familiares do ecossistema EVM ou infraestrutura de liquidação regulada. �
DOCS
Para mim, a parte interessante da Dusk não é apenas “privacidade”. É a combinação de privacidade, conformidade e liquidação previsível em uma única infraestrutura financeira. Se mais ativos do mundo real e mercados institucionais migrarem para a cadeia, essas capacidades podem se tornar cada vez mais importantes. #dusk $DUSK