#dusk $DUSK @Dusk Dusk's confidentiality setup na prática funciona em dois fluxos separados. No DuskDS, o modelo Phoenix representa valor como notas comprometidas em uma árvore Merkle — gastar uma nota não aponta para qual nota está sendo gasta. Em vez disso, o remetente publica um nullifier e uma prova de conhecimento zero mostrando que o gasto é válido, que a posse é real e que nenhum valor foi criado do nada, sem revelar a nota subjacente. Além disso, o Moonlight é executado como um modelo transparente, baseado em contas, na mesma cadeia.
No DuskEVM, porém, a privacidade vem de um conjunto de ferramentas completamente diferente — um módulo chamado Hedger, que combina criptografia homomórfica baseada em ElGamal com provas de conhecimento zero, além de uma estrutura híbrida UTXO/conta. Aqui, um usuário interage com contratos por meio de um endereço EVM padrão, enquanto um endereço Hedger separado gerencia saldos criptografados, com conformidade imposta via allowlisting.
Essas não são duas versões da mesma ideia. Phoenix é um sistema de provas baseado em notas; Hedger calcula diretamente em saldos criptografados, verificados por meio de provas de conhecimento zero. A razão provável da divisão é que a privacidade baseada em notas não se encaixa naturalmente em uma estrutura EVM baseada em contas, então foi necessário um caminho diferente.
Rodar duas pilhas independentes de privacidade criptográfica em paralelo significa uma superfície de ataque maior e um encargo de auditoria mais pesado. Também não está claro como a garantia de privacidade é preservada quando o valor se move entre as duas camadas.
Manter dois motores de confidencialidade separados multiplica a auditoria proporcionalmente, ou a dependência compartilhada em provas de conhecimento zero faz com que o custo incremental do segundo motor seja, na verdade, menor do que parece?
No DuskEVM, porém, a privacidade vem de um conjunto de ferramentas completamente diferente — um módulo chamado Hedger, que combina criptografia homomórfica baseada em ElGamal com provas de conhecimento zero, além de uma estrutura híbrida UTXO/conta. Aqui, um usuário interage com contratos por meio de um endereço EVM padrão, enquanto um endereço Hedger separado gerencia saldos criptografados, com conformidade imposta via allowlisting.
Essas não são duas versões da mesma ideia. Phoenix é um sistema de provas baseado em notas; Hedger calcula diretamente em saldos criptografados, verificados por meio de provas de conhecimento zero. A razão provável da divisão é que a privacidade baseada em notas não se encaixa naturalmente em uma estrutura EVM baseada em contas, então foi necessário um caminho diferente.
Rodar duas pilhas independentes de privacidade criptográfica em paralelo significa uma superfície de ataque maior e um encargo de auditoria mais pesado. Também não está claro como a garantia de privacidade é preservada quando o valor se move entre as duas camadas.
Manter dois motores de confidencialidade separados multiplica a auditoria proporcionalmente, ou a dependência compartilhada em provas de conhecimento zero faz com que o custo incremental do segundo motor seja, na verdade, menor do que parece?