Eu estava rastreando como o Phoenix impede o double spending e esperava a história usual de UTXO: verificar a entrada, marcá-la como gasta e seguir em frente. Não é exatamente isso que acontece.
Cada nota que o Dusk acompanha vive como um hash em uma árvore de Merkle. Quando você gasta uma, você não aponta diretamente para ela; você gera um nullifier, um valor calculado a partir da sua chave secreta e da nota. Ele é determinístico o bastante para bloquear reutilização, mas suficientemente inlinkável para que nenhum observador consiga rastreá-lo de volta até qual folha da árvore ele veio.
Essa é a parte inteligente. Mas isso significa que a rede não consegue verificar um gasto do jeito que uma cadeia transparente faz, simplesmente conferindo um registro específico. Ela precisa confiar em uma única prova ZK agregada que prova, simultaneamente, tudo o que envolve propriedade, não-double-spend e saldo. Não existe como inspecionar reivindicações individuais depois do fato, por design.
Então a mesma inlinkabilidade que te dá privacidade também é o que faz a correção do sistema depender inteiramente do próprio sistema de provas, e não de um estado auditável. Privacidade e verificabilidade acabam entrando em tensão, não em adição.
Isso me faz pensar como a abordagem do Dusk para revisão de circuitos escala à medida que o Phoenix vê mais volume institucional.
#dusk $DUSK @Dusk
Cada nota que o Dusk acompanha vive como um hash em uma árvore de Merkle. Quando você gasta uma, você não aponta diretamente para ela; você gera um nullifier, um valor calculado a partir da sua chave secreta e da nota. Ele é determinístico o bastante para bloquear reutilização, mas suficientemente inlinkável para que nenhum observador consiga rastreá-lo de volta até qual folha da árvore ele veio.
Essa é a parte inteligente. Mas isso significa que a rede não consegue verificar um gasto do jeito que uma cadeia transparente faz, simplesmente conferindo um registro específico. Ela precisa confiar em uma única prova ZK agregada que prova, simultaneamente, tudo o que envolve propriedade, não-double-spend e saldo. Não existe como inspecionar reivindicações individuais depois do fato, por design.
Então a mesma inlinkabilidade que te dá privacidade também é o que faz a correção do sistema depender inteiramente do próprio sistema de provas, e não de um estado auditável. Privacidade e verificabilidade acabam entrando em tensão, não em adição.
Isso me faz pensar como a abordagem do Dusk para revisão de circuitos escala à medida que o Phoenix vê mais volume institucional.
#dusk $DUSK @Dusk
