Tentei rastrear onde a privacidade realmente começa dentro de uma aplicação em Solidity em @Dusk .
Assumi que um contrato implantado na DuskEVM de algum modo herdaria a privacidade da Dusk, porque seus dados e liquidação eventualmente passam pelo DuskDS.
Não é bem assim que a pilha funciona.
A DuskEVM oferece aos desenvolvedores uma execução EVM familiar. Eles podem usar Solidity, Hardhat, Foundry e carteiras existentes. O DuskDS fica por baixo, como base de liquidação e de disponibilidade de dados.
Mas um contrato Solidity comum ainda pode publicar seu estado como qualquer outra aplicação EVM.
A confidencialidade precisa ser projetada na aplicação por meio do Hedger, ou ser tratada mais perto do caminho nativo de privacidade da Dusk via DuskVM e Phoenix. Ela não é adicionada automaticamente só porque o contrato roda dentro do ecossistema da Dusk.
Esse limite me fez parar.
Imagine um mercado de títulos tokenizados.
O preço do mercado talvez precise permanecer público.
A elegibilidade do investidor só precisa ser comprovada.
Os saldos dos detentores provavelmente devem permanecer privados.
O emissor ou regulador pode exigir acesso controlado a registros específicos.
Essas quatro partes não podem simplesmente ser colocadas dentro do mesmo estado público em Solidity.
O Hedger existe para resolver parte disso, mantendo valores criptografados enquanto provas de conhecimento zero verificam que a transação seguiu suas regras. Mas o desenvolvedor ainda precisa decidir o que entra no fluxo criptografado, o que permanece público e quem recebe direitos de divulgação.
Uma escolha ruim de design pode expor dados financeiros sensíveis antes que qualquer criptografia tenha chance de protegê-los.
Então eu estou menos focado em quantas primitivas criptográficas a Dusk suporta.
Estou observando se as ferramentas dela deixam a fronteira entre público/privado clara o suficiente para equipes comuns de Solidity usarem corretamente.
A Dusk pode fornecer as rotas de privacidade. Ela não pode tomar essa decisão de arquitetura para cada aplicação.
#dusk $DUSK
Assumi que um contrato implantado na DuskEVM de algum modo herdaria a privacidade da Dusk, porque seus dados e liquidação eventualmente passam pelo DuskDS.
Não é bem assim que a pilha funciona.
A DuskEVM oferece aos desenvolvedores uma execução EVM familiar. Eles podem usar Solidity, Hardhat, Foundry e carteiras existentes. O DuskDS fica por baixo, como base de liquidação e de disponibilidade de dados.
Mas um contrato Solidity comum ainda pode publicar seu estado como qualquer outra aplicação EVM.
A confidencialidade precisa ser projetada na aplicação por meio do Hedger, ou ser tratada mais perto do caminho nativo de privacidade da Dusk via DuskVM e Phoenix. Ela não é adicionada automaticamente só porque o contrato roda dentro do ecossistema da Dusk.
Esse limite me fez parar.
Imagine um mercado de títulos tokenizados.
O preço do mercado talvez precise permanecer público.
A elegibilidade do investidor só precisa ser comprovada.
Os saldos dos detentores provavelmente devem permanecer privados.
O emissor ou regulador pode exigir acesso controlado a registros específicos.
Essas quatro partes não podem simplesmente ser colocadas dentro do mesmo estado público em Solidity.
O Hedger existe para resolver parte disso, mantendo valores criptografados enquanto provas de conhecimento zero verificam que a transação seguiu suas regras. Mas o desenvolvedor ainda precisa decidir o que entra no fluxo criptografado, o que permanece público e quem recebe direitos de divulgação.
Uma escolha ruim de design pode expor dados financeiros sensíveis antes que qualquer criptografia tenha chance de protegê-los.
Então eu estou menos focado em quantas primitivas criptográficas a Dusk suporta.
Estou observando se as ferramentas dela deixam a fronteira entre público/privado clara o suficiente para equipes comuns de Solidity usarem corretamente.
A Dusk pode fornecer as rotas de privacidade. Ela não pode tomar essa decisão de arquitetura para cada aplicação.
#dusk $DUSK
