A prova de conhecimento zero significa automaticamente 100% sem confiança?
Parece que sim. Ninguém vê o segredo, e a matemática verifica a prova.
Mas o próprio artigo da Dusk sobre a Citadel aponta para uma camada menos confortável por baixo do PLONK: a configuração confiável (trusted setup).
A implementação do PLONK da Dusk roda sobre BLS12-381 e usa o KZG10 como seu esquema padrão de compromisso polinomial. O KZG precisa de uma Common Reference String gerada a partir de aleatoriedade secreta. Se esse “resíduo tóxico” sobreviver e chegar a um atacante, a suposição de solidez pode falhar.
O artigo da Citadel diz isso de forma bem direta: aleatoriedade comprometida na configuração pode permitir transações falsas e “grandes perdas de dinheiro”. Para a Citadel, diz que a consequência seria personificação de usuários e uso de licenças de outras pessoas.
Então o que “trusted setup” realmente significa?
Não é confiar uma única empresa com uma senha mestre.
Uma cerimônia permite que múltiplos participantes adicionem sequencialmente sua própria aleatoriedade. Cada um destrói sua contribuição privada depois. A propriedade-chave é que a configuração permanece segura se ao menos um participante foi honesto e descartou permanentemente o seu segredo.
Isso me fez perguntar: quem participou da cerimônia da Dusk?
Na verdade, isso é mais documentado do que eu esperava.
O repositório público de trusted setup da Dusk diz que começou a partir da resposta do Powers-of-Tau do Zcash verificada #87 e, então, adicionou 15 contribuintes da Dusk listados. O repositório expõe registros de contribuição e etapas de verificação, enquanto a Dusk afirmou que os resultados seriam públicos para que outros verificassem.
Isso não prova todas as suposições operacionais para sempre. Eu ainda gostaria de saber se os parâmetros de produção correspondem à transcrição publicada e como essa ligação foi verificada de forma independente na prática hoje.
Então a pergunta justa se torna mais específica: consigo rastrear os parâmetros criptográficos em execução até a cerimônia publicamente verificável?
Quando um projeto admite abertamente uma fraqueza criptográfica em seu próprio artigo, isso cria mais confiança por meio da transparência — ou só faz você querer saber exatamente o quanto esse risco ainda é real?
#dusk $DUSK @Dusk
Parece que sim. Ninguém vê o segredo, e a matemática verifica a prova.
Mas o próprio artigo da Dusk sobre a Citadel aponta para uma camada menos confortável por baixo do PLONK: a configuração confiável (trusted setup).
A implementação do PLONK da Dusk roda sobre BLS12-381 e usa o KZG10 como seu esquema padrão de compromisso polinomial. O KZG precisa de uma Common Reference String gerada a partir de aleatoriedade secreta. Se esse “resíduo tóxico” sobreviver e chegar a um atacante, a suposição de solidez pode falhar.
O artigo da Citadel diz isso de forma bem direta: aleatoriedade comprometida na configuração pode permitir transações falsas e “grandes perdas de dinheiro”. Para a Citadel, diz que a consequência seria personificação de usuários e uso de licenças de outras pessoas.
Então o que “trusted setup” realmente significa?
Não é confiar uma única empresa com uma senha mestre.
Uma cerimônia permite que múltiplos participantes adicionem sequencialmente sua própria aleatoriedade. Cada um destrói sua contribuição privada depois. A propriedade-chave é que a configuração permanece segura se ao menos um participante foi honesto e descartou permanentemente o seu segredo.
Isso me fez perguntar: quem participou da cerimônia da Dusk?
Na verdade, isso é mais documentado do que eu esperava.
O repositório público de trusted setup da Dusk diz que começou a partir da resposta do Powers-of-Tau do Zcash verificada #87 e, então, adicionou 15 contribuintes da Dusk listados. O repositório expõe registros de contribuição e etapas de verificação, enquanto a Dusk afirmou que os resultados seriam públicos para que outros verificassem.
Isso não prova todas as suposições operacionais para sempre. Eu ainda gostaria de saber se os parâmetros de produção correspondem à transcrição publicada e como essa ligação foi verificada de forma independente na prática hoje.
Então a pergunta justa se torna mais específica: consigo rastrear os parâmetros criptográficos em execução até a cerimônia publicamente verificável?
Quando um projeto admite abertamente uma fraqueza criptográfica em seu próprio artigo, isso cria mais confiança por meio da transparência — ou só faz você querer saber exatamente o quanto esse risco ainda é real?
#dusk $DUSK @Dusk
