#dusk $DUSK @Dusk
Meu pai manteve dois livros-caixa separados por anos na pequena loja: um para vendas à vista e outro para contas a crédito. Eu já perguntei uma vez por que não juntá-los. Ele disse que o dinheiro precisava ser simples e imediato; o crédito precisava controlar prazos e acompanhamentos; e que obrigar um único sistema a fazer ambos pioraria o trabalho em qualquer dos dois.
Eu assumi que o Dusk eventualmente convergiria para um único modelo de transação, como a maioria das cadeias acaba adotando uma abordagem. Essa suposição caiu por terra quando eu realmente tracei por que tanto o Moonlight quanto o Phoenix existem.
O Moonlight é baseado em contas, público e direto — a documentação do Dusk o descreve como o modelo de saldos e lógica de aplicação que não precisa de blindagem. O Phoenix usa a abordagem UTXO e existe especificamente para dar suporte a fluxos orientados à privacidade: transferências blindadas, divulgação seletiva e as peças que as finanças regulamentadas realmente precisam quando a transparência total não é aceitável.
Juntar esses dois em um único modelo significaria ou forçar toda transação a passar por uma sobrecarga de privacidade desnecessária, ou remover as opções de blindagem de quem realmente precisa delas.
O verdadeiro teste para o DUSK é se manter os dois modelos realmente atende os construtores que precisam de garantias diferentes para fluxos diferentes — e não apenas adicionar complexidade conceitual que a maioria dos usuários nunca vai tocar.
O que eu não encontrei documentado em lugar nenhum é com que frequência uma aplicação única realmente precisa de ambos os modelos simultaneamente, na prática.
Meu pai manteve dois livros-caixa separados por anos na pequena loja: um para vendas à vista e outro para contas a crédito. Eu já perguntei uma vez por que não juntá-los. Ele disse que o dinheiro precisava ser simples e imediato; o crédito precisava controlar prazos e acompanhamentos; e que obrigar um único sistema a fazer ambos pioraria o trabalho em qualquer dos dois.
Eu assumi que o Dusk eventualmente convergiria para um único modelo de transação, como a maioria das cadeias acaba adotando uma abordagem. Essa suposição caiu por terra quando eu realmente tracei por que tanto o Moonlight quanto o Phoenix existem.
O Moonlight é baseado em contas, público e direto — a documentação do Dusk o descreve como o modelo de saldos e lógica de aplicação que não precisa de blindagem. O Phoenix usa a abordagem UTXO e existe especificamente para dar suporte a fluxos orientados à privacidade: transferências blindadas, divulgação seletiva e as peças que as finanças regulamentadas realmente precisam quando a transparência total não é aceitável.
Juntar esses dois em um único modelo significaria ou forçar toda transação a passar por uma sobrecarga de privacidade desnecessária, ou remover as opções de blindagem de quem realmente precisa delas.
O verdadeiro teste para o DUSK é se manter os dois modelos realmente atende os construtores que precisam de garantias diferentes para fluxos diferentes — e não apenas adicionar complexidade conceitual que a maioria dos usuários nunca vai tocar.
O que eu não encontrei documentado em lugar nenhum é com que frequência uma aplicação única realmente precisa de ambos os modelos simultaneamente, na prática.
Genuinely useful split
67%
Unnecessary overhead
33%
3 Votos • Votação encerrada