A parte da DuskEVM que eu não esperava não é o suporte ao Solidity — é o que acontece quando a DUSK volta para a camada nativa.
O próprio guia de testnet da Dusk diz que um saque da DuskEVM exige três ações on-chain separadas: iniciar na DuskEVM, provar na Dusk L1 e então finalizar na Dusk L1. O usuário também precisa ter DUSK suficiente não protegido (unshielded) na L1 para pagar tanto as transações de prova quanto as de finalização. A prontidão para saque depende do estado de rede publicado, da maturidade da prova e das verificações do dispute-game, em vez de um simples temporizador.
Isso me fez olhar duas vezes, porque “compatibilidade EVM” pode soar como se toda a experiência ficasse familiar por padrão. Na prática, a ponte expõe a arquitetura mais profunda: DuskEVM é um ambiente de execução EVM que liquida e publica dados via DuskDS, não sendo a mesma camada de execução que os contratos nativos em Rust/WASM da Dusk.
Eu não leio as etapas extras como automaticamente ruins. A documentação relaciona a prontidão à maturidade da prova e às verificações do dispute-game, então o atrito está, ao menos, ligado ao modelo de segurança. Mas isso cria uma pergunta real de produto para o $DUSK : apps em produção conseguem abstrair esse fluxo de prova/finalização o suficiente para que os usuários obtenham os benefícios de segurança sem sentir a complexidade entre camadas?
Parece algo mais importante de observar do que outro demo de implantação.
@Dusk_Foundation $DUSK #dusk
O próprio guia de testnet da Dusk diz que um saque da DuskEVM exige três ações on-chain separadas: iniciar na DuskEVM, provar na Dusk L1 e então finalizar na Dusk L1. O usuário também precisa ter DUSK suficiente não protegido (unshielded) na L1 para pagar tanto as transações de prova quanto as de finalização. A prontidão para saque depende do estado de rede publicado, da maturidade da prova e das verificações do dispute-game, em vez de um simples temporizador.
Isso me fez olhar duas vezes, porque “compatibilidade EVM” pode soar como se toda a experiência ficasse familiar por padrão. Na prática, a ponte expõe a arquitetura mais profunda: DuskEVM é um ambiente de execução EVM que liquida e publica dados via DuskDS, não sendo a mesma camada de execução que os contratos nativos em Rust/WASM da Dusk.
Eu não leio as etapas extras como automaticamente ruins. A documentação relaciona a prontidão à maturidade da prova e às verificações do dispute-game, então o atrito está, ao menos, ligado ao modelo de segurança. Mas isso cria uma pergunta real de produto para o $DUSK : apps em produção conseguem abstrair esse fluxo de prova/finalização o suficiente para que os usuários obtenham os benefícios de segurança sem sentir a complexidade entre camadas?
Parece algo mais importante de observar do que outro demo de implantação.
@Dusk_Foundation $DUSK #dusk