Tenho estado a investigar o desenvolvimento recente da Dusk, e um detalhe tem continuado a incomodar-me de uma boa forma: o trabalho de performance do @PLONK.
Uma queda de 58% no tempo de proving é impressionante, mas o número não foi o que me prendeu.
Foi a forma como eles chegaram lá.
Fazer cache de dados determinísticos de prover/verifier, agrupar inversões e termos de MSM, paralelizar trabalho de FFT independente e reduzir alocações repetidas empurrou o throughput de proving para cerca de 2,4×. A verificação melhorou 44%, enquanto a compilação do circuito ficou 25% mais rápida.
Mas a parte importante é o que ficou inalterado.
As matemáticas subjacentes, o transcript e o formato da prova não mudaram.
Então isto parece menos “Better Cryptography” e mais remover esforço desperdiçado de uma Criptografia que já funciona.
Depois olhei para os testes DuskEM × DuskDS e reparei num tema semelhante. Modelos diferentes de Execution e de estado estão a ser testados sob cargas mistas.
Isso importa porque sistemas raramente ficam difíceis quando cada componente funciona sozinho. O atrito normalmente aparece quando eles precisam funcionar em conjunto.
E talvez seja essa a parte pela qual eu esteja a começar a me importar mais nas redes de privacidade.
A criptografia forte pode estabelecer privacidade.
Mas se o proving é lento, a verificação é dispendiosa, ou a execução fica imprevisível, os utilizadores ainda sentem a complexidade.
Posso estar errado, mas talvez o verdadeiro desafio da Dusk não seja provar que a privacidade funciona.
É tornar a maquinaria por trás da privacidade rápida o suficiente para que ninguém tenha de pensar nisso.

#dusk @Dusk $DUSK