#dusk $DUSK @Dusk I continuei voltando a uma coisa no desenvolvimento recente da Dusk, e não é a criptografia em si.
É o esforço para fazer a mesma criptografia trabalhar mais.
O trabalho de desempenho do PLONK não substituiu a matemática subjacente, o transcript ou o formato de prova. Em vez disso, a Dusk atacou o trabalho desperdiçado ao redor deles: cacheando dados determinísticos, fazendo batch de inversões e operações de MSM, paralelizando tarefas independentes de FFT e evitando cálculos repetidos.
O resultado me chamou a atenção: tempo de prover reduzido em 58%, cerca de 2,4x mais throughput de prova, verificação 44% mais rápida e compilação 25% mais rápida.
Mas, honestamente, os números são quase secundários.
O que me interessa é o que eles revelam sobre o próximo problema.
A privacidade pode ser matematicamente forte e ainda assim se tornar impraticável se a prova, a verificação ou a execução não conseguirem acompanhar.
Vejo uma pergunta semelhante nos testes DuskEVM × DuskDS. Modelos diferentes de execução e estado estão sendo empurrados através de cargas de trabalho mistas, em vez de serem julgados separadamente.
Isso parece mais próximo do desafio real: não se cada parte funciona, mas se elas continuam funcionando juntas quando o sistema fica ocupado.
Então estou começando a me perguntar se o problema de engenharia mais difícil da Dusk não é mais fazer a privacidade funcionar.
É fazer com que privacidade, execução e coordenação pareçam quase invisíveis para o usuário.
Esse provavelmente é o teste mais interessante.
#dusk
É o esforço para fazer a mesma criptografia trabalhar mais.
O trabalho de desempenho do PLONK não substituiu a matemática subjacente, o transcript ou o formato de prova. Em vez disso, a Dusk atacou o trabalho desperdiçado ao redor deles: cacheando dados determinísticos, fazendo batch de inversões e operações de MSM, paralelizando tarefas independentes de FFT e evitando cálculos repetidos.
O resultado me chamou a atenção: tempo de prover reduzido em 58%, cerca de 2,4x mais throughput de prova, verificação 44% mais rápida e compilação 25% mais rápida.
Mas, honestamente, os números são quase secundários.
O que me interessa é o que eles revelam sobre o próximo problema.
A privacidade pode ser matematicamente forte e ainda assim se tornar impraticável se a prova, a verificação ou a execução não conseguirem acompanhar.
Vejo uma pergunta semelhante nos testes DuskEVM × DuskDS. Modelos diferentes de execução e estado estão sendo empurrados através de cargas de trabalho mistas, em vez de serem julgados separadamente.
Isso parece mais próximo do desafio real: não se cada parte funciona, mas se elas continuam funcionando juntas quando o sistema fica ocupado.
Então estou começando a me perguntar se o problema de engenharia mais difícil da Dusk não é mais fazer a privacidade funcionar.
É fazer com que privacidade, execução e coordenação pareçam quase invisíveis para o usuário.
Esse provavelmente é o teste mais interessante.
#dusk