Passei tempo demais na noite passada vasculhando a documentação de arquitetura da Dusk. Não vou mentir, meu cérebro ficou travando numa coisa.
Eles têm o Zedger (estilo UTXO, focado em privacidade para valores mobiliários) e o DuskEVM (EVM do OP Stack para devs de Solidity). Em teoria, está tudo bem organizado—lógica de liquidação separada da lógica da aplicação.
Mas o Zedger tem um recurso específico, bem legal: o recebedor precisa aprovar explicitamente uma transferência antes que ela realmente seja finalizada. Isso é enorme para ativos regulamentados. Seu token de segurança não pode simplesmente ser “varrido” para uma carteira aleatória.
Agora imagine que você encapsula esse ativo e o leva para o lado da EVM. A EVM não tem esse estado nativo de "aprovação pendente"—ela só tem transições de estado padrão.
Então quem aplica essa regra quando está do outro lado?
A documentação pública não detalha muito bem os mecanismos da ponte aqui. Talvez eles levem esse contexto de conformidade junto, mas, sinceramente, isso parece que você estaria reconstruindo a lógica do Zedger dentro do Solidity de qualquer forma. Então por que manter tudo separado?
Provavelmente é por isso que o DuskVM (a camada de privacidade em WASM) está sendo extraído como um componente à parte—para manter o que é realmente regulamentado isolado do “far west” da EVM.
Três runtimes. Duas pontes. É ambicioso, mas eu estou aqui pensando se essas junções são realmente estanques. Parece que pode haver algumas inconsistências de estado estranhas quando um ativo muda de camada.
Não estou tentando espalhar medo (FUD)—eu realmente gosto da abordagem. Só estou genuinamente curioso para saber se alguém sabe como eles planejam manter a sincronização de estado entre camadas bem firme na prática.
@Dusk #dusk #DUSK $DUSK
Eles têm o Zedger (estilo UTXO, focado em privacidade para valores mobiliários) e o DuskEVM (EVM do OP Stack para devs de Solidity). Em teoria, está tudo bem organizado—lógica de liquidação separada da lógica da aplicação.
Mas o Zedger tem um recurso específico, bem legal: o recebedor precisa aprovar explicitamente uma transferência antes que ela realmente seja finalizada. Isso é enorme para ativos regulamentados. Seu token de segurança não pode simplesmente ser “varrido” para uma carteira aleatória.
Agora imagine que você encapsula esse ativo e o leva para o lado da EVM. A EVM não tem esse estado nativo de "aprovação pendente"—ela só tem transições de estado padrão.
Então quem aplica essa regra quando está do outro lado?
A documentação pública não detalha muito bem os mecanismos da ponte aqui. Talvez eles levem esse contexto de conformidade junto, mas, sinceramente, isso parece que você estaria reconstruindo a lógica do Zedger dentro do Solidity de qualquer forma. Então por que manter tudo separado?
Provavelmente é por isso que o DuskVM (a camada de privacidade em WASM) está sendo extraído como um componente à parte—para manter o que é realmente regulamentado isolado do “far west” da EVM.
Três runtimes. Duas pontes. É ambicioso, mas eu estou aqui pensando se essas junções são realmente estanques. Parece que pode haver algumas inconsistências de estado estranhas quando um ativo muda de camada.
Não estou tentando espalhar medo (FUD)—eu realmente gosto da abordagem. Só estou genuinamente curioso para saber se alguém sabe como eles planejam manter a sincronização de estado entre camadas bem firme na prática.
@Dusk #dusk #DUSK $DUSK
