#dusk $DUSK Hoje eu estava lendo o documento do modelo de transações de @Dusk ; eu achava que o Dusk era uma “blockchain de privacidade” — em que todas as transações são anonimizadas por padrão, como Monero ou Zcash. Mas no DuskDS rodam dois modelos de transação ao mesmo tempo: Moonlight é público e baseado em conta; Phoenix é oculto e usa UTXO + provas de conhecimento zero. Ambos os modelos usam o mesmo token $DUSK e seguem o mesmo contrato de Transfer.
Esse design, no começo, me pareceu contraditório: por que uma blockchain de privacidade manter um modelo público? Só que, pensando melhor, vi que a existência do Moonlight é justamente para garantir conformidade. Em finanças tradicionais, as instituições fazem transações com exigências de fiscalização: o regulador precisa ver saldos e registros das contas; numa blockchain totalmente privada, nem mesmo um auditor consegue conferir as contas — e então não passa nas exigências de compliance. O Moonlight oferece uma experiência transparente parecida com a de uma conta bancária tradicional: endereços de conta, saldo e histórico de transações.
O Phoenix segue outro caminho: modelo UTXO + prova de conhecimento zero, em que o valor da transação e as partes envolvidas podem ficar ocultos, mas o auditor que possui a View Key ainda consegue verificar as informações. É como os livros contábeis de uma empresa: o que é divulgado ao público é um resumo do relatório anual, mas o auditor, com a chave, consegue ver os detalhes.
Eu vejo como um exemplo em que não é uma estrada só com a opção de “totalmente transparente” ou “totalmente anônima”; é como um prédio que tem tanto uma sala de reuniões de vidro quanto uma sala de negociações com isolamento acústico. Para divulgação externa e declarações regulatórias, usa-se a sala de vidro (Moonlight); para negociações comerciais e liquidação entre instituições, usa-se a sala com isolamento (Phoenix). Mesmo prédio, salas diferentes para cenários diferentes.
Mas ter dois modelos também traz complexidade. O usuário precisa transferir DUSK manualmente entre as contas Moonlight e Phoenix, porque ainda não há roteamento automático. Se um dApp só suportar o Moonlight, usuários que detêm ativos ocultados no Phoenix precisam fazer uma transferência entre modelos antes — ou seja, mais uma operação, e mais uma taxa de gas.
Então, ao olhar o sistema de contas de #dusk , meu foco não é só “há ou não há privacidade”, mas também para qual modelo desenvolvedores e usuários tendem a ir na prática, e se o atrito da transferência entre modelos pode ser absorvido pela camada do wallet. A eficiência de circulação do $DUSK , no fim, depende do custo de alternar entre esses dois modelos. @Dusk
Esse design, no começo, me pareceu contraditório: por que uma blockchain de privacidade manter um modelo público? Só que, pensando melhor, vi que a existência do Moonlight é justamente para garantir conformidade. Em finanças tradicionais, as instituições fazem transações com exigências de fiscalização: o regulador precisa ver saldos e registros das contas; numa blockchain totalmente privada, nem mesmo um auditor consegue conferir as contas — e então não passa nas exigências de compliance. O Moonlight oferece uma experiência transparente parecida com a de uma conta bancária tradicional: endereços de conta, saldo e histórico de transações.
O Phoenix segue outro caminho: modelo UTXO + prova de conhecimento zero, em que o valor da transação e as partes envolvidas podem ficar ocultos, mas o auditor que possui a View Key ainda consegue verificar as informações. É como os livros contábeis de uma empresa: o que é divulgado ao público é um resumo do relatório anual, mas o auditor, com a chave, consegue ver os detalhes.
Eu vejo como um exemplo em que não é uma estrada só com a opção de “totalmente transparente” ou “totalmente anônima”; é como um prédio que tem tanto uma sala de reuniões de vidro quanto uma sala de negociações com isolamento acústico. Para divulgação externa e declarações regulatórias, usa-se a sala de vidro (Moonlight); para negociações comerciais e liquidação entre instituições, usa-se a sala com isolamento (Phoenix). Mesmo prédio, salas diferentes para cenários diferentes.
Mas ter dois modelos também traz complexidade. O usuário precisa transferir DUSK manualmente entre as contas Moonlight e Phoenix, porque ainda não há roteamento automático. Se um dApp só suportar o Moonlight, usuários que detêm ativos ocultados no Phoenix precisam fazer uma transferência entre modelos antes — ou seja, mais uma operação, e mais uma taxa de gas.
Então, ao olhar o sistema de contas de #dusk , meu foco não é só “há ou não há privacidade”, mas também para qual modelo desenvolvedores e usuários tendem a ir na prática, e se o atrito da transferência entre modelos pode ser absorvido pela camada do wallet. A eficiência de circulação do $DUSK , no fim, depende do custo de alternar entre esses dois modelos. @Dusk
双模型设计很聪明,兼顾合规和隐私
0%
切换太麻烦,钱包应该自动处理
0%
0 Votos • Votação encerrada