@Dusk $DUSK #dusk
Eu estava lendo a documentação do Dusk, e uma coisa ficava me puxando de volta.
No começo, achei que a parte mais interessante era simplesmente o fato de que ele tenta trazer privacidade para aplicações financeiras. Mas, à medida que eu fui me aprofundando na arquitetura, menos “blockchain de privacidade” parecia uma descrição completa.
O Dusk tem diferentes componentes que lidam com diferentes tipos de atividade. Existe o Moonlight para o lado mais familiar baseado em conta, o Phoenix para transações UTXO com shield, e depois o design XSC/Hedger para coisas como ativos regulados e regras financeiras.
Isso me fez parar por um segundo.
Porque, com ativos financeiros, ocultar uma transação é apenas uma parte do problema.
Você também pode precisar de regras sobre quem pode deter algo, quem pode transferir, que informações outra parte tem permissão para ver, ou ainda se uma transferência específica é válida.
A documentação fala sobre coisas como divulgação seletiva, credenciais de identidade e restrições no nível do ativo. Isso faz com que o modelo de privacidade pareça menos “deixar tudo invisível” e mais “revelar apenas o que a aplicação realmente precisa revelar”.
Acredito que essa diferença seja fácil de passar despercebida.
Outro detalhe que achei interessante é que o Dusk tem tanto o DuskVM quanto o DuskEVM. A VM nativa dá aos contratos acesso às capacidades de privacidade e ZK do próprio Dusk, enquanto o lado EVM existe para tornar possível o desenvolvimento em Solidity/Vyper e as ferramentas mais familiares.
Então agora fico pensando em algo um pouco diferente.
Se, eventualmente, uma aplicação precisar da flexibilidade do desenvolvimento em EVM, mas também depender fortemente das funcionalidades nativas de privacidade do Dusk, onde esse limite fica mais perceptível na prática?
A documentação apresenta uma visão bem clara de por que esses dois caminhos existem.
Estou mais interessado em como é, de verdade, construir atravessando esse limite.
Eu estava lendo a documentação do Dusk, e uma coisa ficava me puxando de volta.
No começo, achei que a parte mais interessante era simplesmente o fato de que ele tenta trazer privacidade para aplicações financeiras. Mas, à medida que eu fui me aprofundando na arquitetura, menos “blockchain de privacidade” parecia uma descrição completa.
O Dusk tem diferentes componentes que lidam com diferentes tipos de atividade. Existe o Moonlight para o lado mais familiar baseado em conta, o Phoenix para transações UTXO com shield, e depois o design XSC/Hedger para coisas como ativos regulados e regras financeiras.
Isso me fez parar por um segundo.
Porque, com ativos financeiros, ocultar uma transação é apenas uma parte do problema.
Você também pode precisar de regras sobre quem pode deter algo, quem pode transferir, que informações outra parte tem permissão para ver, ou ainda se uma transferência específica é válida.
A documentação fala sobre coisas como divulgação seletiva, credenciais de identidade e restrições no nível do ativo. Isso faz com que o modelo de privacidade pareça menos “deixar tudo invisível” e mais “revelar apenas o que a aplicação realmente precisa revelar”.
Acredito que essa diferença seja fácil de passar despercebida.
Outro detalhe que achei interessante é que o Dusk tem tanto o DuskVM quanto o DuskEVM. A VM nativa dá aos contratos acesso às capacidades de privacidade e ZK do próprio Dusk, enquanto o lado EVM existe para tornar possível o desenvolvimento em Solidity/Vyper e as ferramentas mais familiares.
Então agora fico pensando em algo um pouco diferente.
Se, eventualmente, uma aplicação precisar da flexibilidade do desenvolvimento em EVM, mas também depender fortemente das funcionalidades nativas de privacidade do Dusk, onde esse limite fica mais perceptível na prática?
A documentação apresenta uma visão bem clara de por que esses dois caminhos existem.
Estou mais interessado em como é, de verdade, construir atravessando esse limite.
