@Dusk_Foundation ‎Fui procurar o que realmente acontece quando uma prova de conhecimento zero do Phoenix falha na verificação, já que a maioria das explicações para em "a prova é verificada".

‎A arquitetura do Dusk confirma que a prova precisa demonstrar propriedades específicas em conjunto — a titularidade do comprovante que está sendo gasto, a integridade do saldo entre entradas e saídas e a ausência de gasto duplo — tudo codificado na mesma prova, e não verificado por meio de checagens laterais separadas. $DUSK

‎Essa é a parte que vale a pena considerar com calma. Se qualquer uma dessas propriedades não for satisfeita, a prova inteira falha como uma única unidade. Não existe um caminho de crédito parcial em que as checagens de saldo passam, mas a titularidade falha silenciosamente.

‎Rastreie o que isso significa na prática: uma prova rejeitada significa que a transação nem sequer é incluída. O runtime não tenta consertar ou processar parcialmente. A transação simplesmente não acontece, e nada da tentativa fracassada é registrado como mudança de estado. #dusk

‎O que eu ainda não confirmei, com base nos próprios materiais do Dusk, é se uma prova falha deixa algum rastro em logs da mempool que um operador de nó poderia inspecionar depois, ou se é descartada sem nenhum registro de diagnóstico.

‎Próxima coisa que eu verificaria: se as ferramentas atuais da carteira do Dusk exibem um motivo específico para uma prova falha, ou apenas uma rejeição genérica, já que essa distinção importa muito para qualquer pessoa que esteja realmente depurando uma transação que não passou.

#dusk $DUSK @Dusk