Por que o Dusk mantém deliberadamente as transações públicas?
Uma rede focada em privacidade deliberadamente mantendo um modelo de transações transparente soa como uma contradição. A DuskDS faz exatamente isso. O Moonlight usa saldos públicos baseados em contas; o Phoenix usa transferências protegidas, baseadas em notas, com provas de conhecimento zero. Ambos, no fim, são liquidados na mesma cadeia da Dusk.
Esse design sugere uma visão diferente de privacidade: não um interruptor em toda a cadeia, mas uma escolha no nível da transação. O Moonlight se encaixa em fluxos em que saldos e transferências precisam ser observáveis. O Phoenix oculta valores transferidos e participantes enquanto ainda prova que o gasto é válido.
A chave está no contrato de Transfer. No nível da DuskDS, ele aceita cargas (payloads) tanto no estilo Moonlight quanto Phoenix, direciona cada uma para a lógica de verificação apropriada e mantém o estado global consistente. Assim, o Dusk não precisa de um sistema de liquidação separado toda vez que a exigência de visibilidade muda.
A implicação de segunda ordem é que a transparência se torna uma capacidade intencional, não uma falha de privacidade. As próprias carteiras do Dusk suportam tanto DUSK público quanto protegido, então a arquitetura pode expor informações quando a observabilidade for útil e protegê-las quando uma divulgação ampla não for necessária.
Isso reformula o debate usual sobre cadeias de privacidade. A pergunta melhor não é “Quanto o Dusk consegue esconder?” mas “Que informações um fluxo financeiro deve revelar, para quem, e em qual camada?” Para mercados regulados, poder escolher o modelo de visibilidade sem sair da mesma base de liquidação pode ser mais importante do que maximizar o sigilo em todo lugar.
@Dusk $DUSK #dusk $BTW $MAGMA
Uma rede focada em privacidade deliberadamente mantendo um modelo de transações transparente soa como uma contradição. A DuskDS faz exatamente isso. O Moonlight usa saldos públicos baseados em contas; o Phoenix usa transferências protegidas, baseadas em notas, com provas de conhecimento zero. Ambos, no fim, são liquidados na mesma cadeia da Dusk.
Esse design sugere uma visão diferente de privacidade: não um interruptor em toda a cadeia, mas uma escolha no nível da transação. O Moonlight se encaixa em fluxos em que saldos e transferências precisam ser observáveis. O Phoenix oculta valores transferidos e participantes enquanto ainda prova que o gasto é válido.
A chave está no contrato de Transfer. No nível da DuskDS, ele aceita cargas (payloads) tanto no estilo Moonlight quanto Phoenix, direciona cada uma para a lógica de verificação apropriada e mantém o estado global consistente. Assim, o Dusk não precisa de um sistema de liquidação separado toda vez que a exigência de visibilidade muda.
A implicação de segunda ordem é que a transparência se torna uma capacidade intencional, não uma falha de privacidade. As próprias carteiras do Dusk suportam tanto DUSK público quanto protegido, então a arquitetura pode expor informações quando a observabilidade for útil e protegê-las quando uma divulgação ampla não for necessária.
Isso reformula o debate usual sobre cadeias de privacidade. A pergunta melhor não é “Quanto o Dusk consegue esconder?” mas “Que informações um fluxo financeiro deve revelar, para quem, e em qual camada?” Para mercados regulados, poder escolher o modelo de visibilidade sem sair da mesma base de liquidação pode ser mais importante do que maximizar o sigilo em todo lugar.
@Dusk $DUSK #dusk $BTW $MAGMA
