A privacidade do Dusk só é realmente confiável quando a rede está sob stress
O que me fez mudar a forma de ver a Phoenix foi perceber que não ver não significa que não se possa verificar
Com transações shielded, um observador público não vê sender, receiver ou amount como no Moonlight, mas a transação ainda precisa ser verificada pela rede antes que o estado seja aceito. O DuskDS então envia o bloco por proposal, validation e ratification para alcançar finalidade determinística.
Em condições normais, esse modelo é bem compacto. O que eu quero observar com mais cuidado é justamente quando a rede está congestionada.
Se transações public e confidential pressionarem o sistema ao mesmo tempo, o comitê muda continuamente e alguns provisioners começam a perder o ritmo; a privacidade deixa de ser a única questão. A rede ainda precisa manter liveness e finality sem reduzir o padrão de verificação.
O ponto que considero adequado é que o Dusk não trata todos os erros como iguais. Provisioners que falharem a tarefa podem sofrer soft penalty, enquanto condutas que possam ser comprovadamente erradas, como voto inválido ou assinatura em conflito, podem levar a hard penalty.
Para mim, esse é o tipo de teste mais interessante do que apenas ver uma transação privada rodar lisinha.
Um bom sistema de privacidade não precisa apenas ocultar dados quando tudo está normal. Ele deve preservar a capacidade de verificação quando os nós ficam defasados, quando o comitê gira e quando a carga da rede aumenta muito.
Se o Dusk conseguir manter esse limite, então a privacidade passa a ser de fato uma propriedade da infraestrutura, não apenas uma experiência no nível da carteira.
@Dusk $DUSK #dusk
$RICE $BTW
O que me fez mudar a forma de ver a Phoenix foi perceber que não ver não significa que não se possa verificar
Com transações shielded, um observador público não vê sender, receiver ou amount como no Moonlight, mas a transação ainda precisa ser verificada pela rede antes que o estado seja aceito. O DuskDS então envia o bloco por proposal, validation e ratification para alcançar finalidade determinística.
Em condições normais, esse modelo é bem compacto. O que eu quero observar com mais cuidado é justamente quando a rede está congestionada.
Se transações public e confidential pressionarem o sistema ao mesmo tempo, o comitê muda continuamente e alguns provisioners começam a perder o ritmo; a privacidade deixa de ser a única questão. A rede ainda precisa manter liveness e finality sem reduzir o padrão de verificação.
O ponto que considero adequado é que o Dusk não trata todos os erros como iguais. Provisioners que falharem a tarefa podem sofrer soft penalty, enquanto condutas que possam ser comprovadamente erradas, como voto inválido ou assinatura em conflito, podem levar a hard penalty.
Para mim, esse é o tipo de teste mais interessante do que apenas ver uma transação privada rodar lisinha.
Um bom sistema de privacidade não precisa apenas ocultar dados quando tudo está normal. Ele deve preservar a capacidade de verificação quando os nós ficam defasados, quando o comitê gira e quando a carga da rede aumenta muito.
Se o Dusk conseguir manter esse limite, então a privacidade passa a ser de fato uma propriedade da infraestrutura, não apenas uma experiência no nível da carteira.
@Dusk $DUSK #dusk
$RICE $BTW
