#dusk Hoje, seguindo a explicação do Phoenix do @Dusk , fui procurando até parar na camada do nó Prover. Muita gente entende transações de privacidade como algo em que só o saldo e os participantes na cadeia ficam ocultos, mas quase ninguém pergunta quem calcula a prova, ou onde recai a carga computacional. Provas de conhecimento zero não aparecem do nada: a Dusk atribui esse tipo de recálculo ao Prover; o Provisioner também inclui capacidade de prova, e o usuário ainda pode colocar o processo de prova localmente, reduzindo a necessidade de enviar dados sensíveis de transações para um serviço remoto.$DUSK
A configuração mínima para um Prover independente, listada oficialmente, é 4 núcleos, 8 GB de memória, 20 GB de armazenamento e rede de 20 Mbps. E a recomendação enfatiza especialmente o desempenho de um único núcleo, porque a tarefa de gerar a prova é executada em uma única thread; aumentar workers depende principalmente de mais núcleos processando em paralelo, e não de simplesmente dividir uma prova em muitas threads aleatoriamente. Isso mostra que o custo do caminho de privacidade não se resume apenas ao Gas — também aparece no tempo de espera, na performance da máquina e na disponibilidade do serviço de prova.
A inversão aqui também é bem direta. A prova local diminui a exposição a terceiros, mas transfere para o usuário as atualizações do software, o consumo de recursos e as tentativas de repetição em caso de falha; já a prova remota é mais conveniente, mas exige entender o que é exposto na requisição, se o serviço registra dados e se dá para alternar em caso de queda. Se no futuro o volume de transações de privacidade aumentar de forma significativa, a falta de capacidade do Prover pode primeiro se manifestar como atraso e instabilidade de experiência, e não como uma parada imediata do consenso.
Por isso, acho que a capacidade de privacidade da Dusk não será avaliada apenas pelo nome criptográfico e pelas três palavras “pode ocultar”. O que é mais observável, de forma mais concreta, é o tempo de geração da prova, a taxa de sucesso em dispositivos comuns, a distribuição dos provedores de prova remotos, o caminho de fallback após falhas e se a carteira explica previamente o custo. Fazer privacidade é uma camada; manter o uso contínuo por parte dos usuários é outra.
A configuração mínima para um Prover independente, listada oficialmente, é 4 núcleos, 8 GB de memória, 20 GB de armazenamento e rede de 20 Mbps. E a recomendação enfatiza especialmente o desempenho de um único núcleo, porque a tarefa de gerar a prova é executada em uma única thread; aumentar workers depende principalmente de mais núcleos processando em paralelo, e não de simplesmente dividir uma prova em muitas threads aleatoriamente. Isso mostra que o custo do caminho de privacidade não se resume apenas ao Gas — também aparece no tempo de espera, na performance da máquina e na disponibilidade do serviço de prova.
A inversão aqui também é bem direta. A prova local diminui a exposição a terceiros, mas transfere para o usuário as atualizações do software, o consumo de recursos e as tentativas de repetição em caso de falha; já a prova remota é mais conveniente, mas exige entender o que é exposto na requisição, se o serviço registra dados e se dá para alternar em caso de queda. Se no futuro o volume de transações de privacidade aumentar de forma significativa, a falta de capacidade do Prover pode primeiro se manifestar como atraso e instabilidade de experiência, e não como uma parada imediata do consenso.
Por isso, acho que a capacidade de privacidade da Dusk não será avaliada apenas pelo nome criptográfico e pelas três palavras “pode ocultar”. O que é mais observável, de forma mais concreta, é o tempo de geração da prova, a taxa de sucesso em dispositivos comuns, a distribuição dos provedores de prova remotos, o caminho de fallback após falhas e se a carteira explica previamente o custo. Fazer privacidade é uma camada; manter o uso contínuo por parte dos usuários é outra.
