#dusk $DUSK gastei a última noite relendo a seção do whitepaper do dusk sobre plonk e algo clicou que eu perdi...
nas duas primeiras vezes.
o esquema da prova não apenas esconde valores; ele separa o que é provado do que é revelado. as entradas públicas vão por um caminho, as privadas ficam.
bloqueado e o verificador só aprende se a afirmação é verdadeira.
três propriedades precisam ser satisfeitas para isso significar alguma coisa: completude, solidez (soundness) e zero.
conhecimento (knowledgeness). se pular uma, toda a alegação de privacidade desmorona.
o que é interessante é que isso não é apenas acoplado à função de transição de estado depois do fato.
isso é nativo da rusk vm. cada caminho de execução pode carregar uma
prova de correção sem expor a computação em si.
não consigo resolver totalmente como o custo de geração de prova escala à medida que a lógica do contrato fica mais
complexa. embora seja complexo. é a parte que eu continuo voltando.
fiquei curioso se alguém mais já se aprofundou na configuração da chave do verificador aqui??
#dusk @Dusk $DUSK
nas duas primeiras vezes.
o esquema da prova não apenas esconde valores; ele separa o que é provado do que é revelado. as entradas públicas vão por um caminho, as privadas ficam.
bloqueado e o verificador só aprende se a afirmação é verdadeira.
três propriedades precisam ser satisfeitas para isso significar alguma coisa: completude, solidez (soundness) e zero.
conhecimento (knowledgeness). se pular uma, toda a alegação de privacidade desmorona.
o que é interessante é que isso não é apenas acoplado à função de transição de estado depois do fato.
isso é nativo da rusk vm. cada caminho de execução pode carregar uma
prova de correção sem expor a computação em si.
não consigo resolver totalmente como o custo de geração de prova escala à medida que a lógica do contrato fica mais
complexa. embora seja complexo. é a parte que eu continuo voltando.
fiquei curioso se alguém mais já se aprofundou na configuração da chave do verificador aqui??
#dusk @Dusk $DUSK