Ontem à noite, revisitei a documentação do Dusk, concentrando-me em compreender o papel real $DUSK desempenha dentro do protocolo — sua função técnica, e não a história movida pelo mercado.
A primeira coisa que precisei desembaraçar foram os dois modelos de transação do DuskDS. Moonlight é a rota familiar: contas públicas, saldos visíveis, remetente, destinatário, valor. Phoenix trabalha com “anotações” criptografadas. Para gastar uma, o usuário fornece uma prova de conhecimento zero que mostra que as regras de propriedade e de saldo são válidas. Pense em entregar a um atendente um envelope lacrado cuja vedação comprova que cada item obrigatório foi verificado, sem expor o conteúdo. Um nullifier então permite que a rede rejeite um segundo gasto sem identificar qual nota, na árvore pública, foi usada. Eu releio essa parte duas vezes — então uma notificação me puxou para fora — porque privacidade não significa “nada é verificado”. Significa que a rede verifica uma prova em vez dos detalhes da transação oculta. Chaves de visualização podem revelar informações de forma seletiva.
O consenso exigiu outra rodada de leitura. A Dusk chama isso de Acusação (Attestation) Enxuta: stakers, ou provisioners, bloqueiam DUSK; uma seleção determinística ponderada por stake escolhe um proponente de bloco, depois um comitê valida e outro ratifica. Assinaturas agregadas viram uma atestação de que um quórum concordou. Assim, $DUSK é tanto o “gás” quanto o stake por trás da participação.
A parte que eu examinaria em seguida é a concentração. A seleção é permissionless, mas o quão distribuídos são, na prática, os créditos efetivos de comitê? Nas páginas que li, não consegui encontrar um relato claro sobre quem altera parâmetros globais. talvez eu tenha perdido isso.
Que evidências mostrariam que o poder do comitê é de fato disperso? Como as chaves de visualização são governadas em implantações reais? quem pode alterar parâmetros do protocolo e por meio de qual processo?
#dusk $DUSK @Dusk
A primeira coisa que precisei desembaraçar foram os dois modelos de transação do DuskDS. Moonlight é a rota familiar: contas públicas, saldos visíveis, remetente, destinatário, valor. Phoenix trabalha com “anotações” criptografadas. Para gastar uma, o usuário fornece uma prova de conhecimento zero que mostra que as regras de propriedade e de saldo são válidas. Pense em entregar a um atendente um envelope lacrado cuja vedação comprova que cada item obrigatório foi verificado, sem expor o conteúdo. Um nullifier então permite que a rede rejeite um segundo gasto sem identificar qual nota, na árvore pública, foi usada. Eu releio essa parte duas vezes — então uma notificação me puxou para fora — porque privacidade não significa “nada é verificado”. Significa que a rede verifica uma prova em vez dos detalhes da transação oculta. Chaves de visualização podem revelar informações de forma seletiva.
O consenso exigiu outra rodada de leitura. A Dusk chama isso de Acusação (Attestation) Enxuta: stakers, ou provisioners, bloqueiam DUSK; uma seleção determinística ponderada por stake escolhe um proponente de bloco, depois um comitê valida e outro ratifica. Assinaturas agregadas viram uma atestação de que um quórum concordou. Assim, $DUSK é tanto o “gás” quanto o stake por trás da participação.
A parte que eu examinaria em seguida é a concentração. A seleção é permissionless, mas o quão distribuídos são, na prática, os créditos efetivos de comitê? Nas páginas que li, não consegui encontrar um relato claro sobre quem altera parâmetros globais. talvez eu tenha perdido isso.
Que evidências mostrariam que o poder do comitê é de fato disperso? Como as chaves de visualização são governadas em implantações reais? quem pode alterar parâmetros do protocolo e por meio de qual processo?
#dusk $DUSK @Dusk
