Algo pequeno tem me incomodado desde que comecei a ler como o Dusk gera provas.
Provar com conhecimento zero é caro. Seu telefone não quer fazer isso. Então o Dusk te dá uma saída: o wallet-core permite delegar a geração de provas para um Prover externo, e o Prover é um tipo de nó documentado que você pode realmente executar, junto com Provisioner e Archive.
Isso é uma resposta sensata de engenharia. A atualização de engenharia que introduziu isso menciona especificamente que a delegação foi projetada para evitar maleabilidade, então o prover não pode alterar silenciosamente o que você pediu.
Mas delegação sempre responde uma pergunta e abre outra. Maleabilidade é sobre se o prover pode mudar sua transação. Não é a mesma pergunta sobre o que o prover consegue ver enquanto constrói a prova para você.
Agora coloque o Hedger ao lado. O argumento do Hedger para o lado da EVM vai totalmente na direção oposta — circuitos leves, geração de prova no lado do cliente em menos de dois segundos, no navegador. Nenhuma terceira máquina envolvida.
Então @Dusk tem as duas formas na mesma pilha. Um caminho de prova delegada para circuitos nativos pesados, e um caminho de prova local para a camada EVM confidencial.
Eu não acho que qualquer um deles esteja errado. Prova local é mais limpa para privacidade e pior para dispositivos fracos. Prova delegada é o contrário. A maioria das cadeias escolhe uma e para de falar sobre isso.
O que eu ainda não consigo determinar nas documentações é como um usuário comum deveria saber qual delas está usando em qualquer momento. É a parte que eu gostaria de ver explicada antes de um banco colocar um cliente nisso.
Se um serviço oferecesse para gerar sua prova de privacidade para você, mais rápido e de graça — você usaria, ou isso tiraria o sentido para você?
#dusk $DUSK @Dusk
Provar com conhecimento zero é caro. Seu telefone não quer fazer isso. Então o Dusk te dá uma saída: o wallet-core permite delegar a geração de provas para um Prover externo, e o Prover é um tipo de nó documentado que você pode realmente executar, junto com Provisioner e Archive.
Isso é uma resposta sensata de engenharia. A atualização de engenharia que introduziu isso menciona especificamente que a delegação foi projetada para evitar maleabilidade, então o prover não pode alterar silenciosamente o que você pediu.
Mas delegação sempre responde uma pergunta e abre outra. Maleabilidade é sobre se o prover pode mudar sua transação. Não é a mesma pergunta sobre o que o prover consegue ver enquanto constrói a prova para você.
Agora coloque o Hedger ao lado. O argumento do Hedger para o lado da EVM vai totalmente na direção oposta — circuitos leves, geração de prova no lado do cliente em menos de dois segundos, no navegador. Nenhuma terceira máquina envolvida.
Então @Dusk tem as duas formas na mesma pilha. Um caminho de prova delegada para circuitos nativos pesados, e um caminho de prova local para a camada EVM confidencial.
Eu não acho que qualquer um deles esteja errado. Prova local é mais limpa para privacidade e pior para dispositivos fracos. Prova delegada é o contrário. A maioria das cadeias escolhe uma e para de falar sobre isso.
O que eu ainda não consigo determinar nas documentações é como um usuário comum deveria saber qual delas está usando em qualquer momento. É a parte que eu gostaria de ver explicada antes de um banco colocar um cliente nisso.
Se um serviço oferecesse para gerar sua prova de privacidade para você, mais rápido e de graça — você usaria, ou isso tiraria o sentido para você?
#dusk $DUSK @Dusk
