#dusk $DUSK @Dusk I seguí volviendo a una cosa en el desarrollo reciente de Dusk, y no es la criptografía en sí.
Es el esfuerzo por hacer que la misma criptografía funcione mejor.
El trabajo de rendimiento de PLONK no reemplazó las matemáticas subyacentes, el transcripto ni el formato de la prueba. En cambio, Dusk fue tras el trabajo desperdiciado alrededor de ellos: almacenar en caché datos deterministas, agrupar inversiones y operaciones de MSM, paralelizar tareas independientes de FFT y evitar cómputos repetidos.
El resultado me llamó la atención: el tiempo de prueba bajó 58%, aproximadamente 2.4x el rendimiento de pruebas, la verificación fue 44% más rápida y la compilación 25% más rápida.
Pero, honestamente, los números son casi secundarios.
Lo que me interesa es lo que revelan sobre el siguiente problema.
La privacidad puede ser matemáticamente sólida y aun así volverse poco práctica si la generación, la verificación o la ejecución no logran seguir el ritmo.
Veo una pregunta similar en las pruebas de DuskEVM × DuskDS. Se están empujando diferentes modelos de ejecución y de estado a través de cargas de trabajo mixtas en lugar de juzgarlos por separado.
Eso se siente más cercano al desafío real: no si cada pieza funciona, sino si siguen funcionando juntas cuando el sistema se pone ocupado.
Así que empiezo a preguntarme si el problema de ingeniería más difícil de Dusk ya no es hacer que funcione la privacidad.
Es lograr que la privacidad, la ejecución y la coordinación se sientan casi invisibles para el usuario.
Probablemente esa sea la prueba más interesante.
#dusk
Es el esfuerzo por hacer que la misma criptografía funcione mejor.
El trabajo de rendimiento de PLONK no reemplazó las matemáticas subyacentes, el transcripto ni el formato de la prueba. En cambio, Dusk fue tras el trabajo desperdiciado alrededor de ellos: almacenar en caché datos deterministas, agrupar inversiones y operaciones de MSM, paralelizar tareas independientes de FFT y evitar cómputos repetidos.
El resultado me llamó la atención: el tiempo de prueba bajó 58%, aproximadamente 2.4x el rendimiento de pruebas, la verificación fue 44% más rápida y la compilación 25% más rápida.
Pero, honestamente, los números son casi secundarios.
Lo que me interesa es lo que revelan sobre el siguiente problema.
La privacidad puede ser matemáticamente sólida y aun así volverse poco práctica si la generación, la verificación o la ejecución no logran seguir el ritmo.
Veo una pregunta similar en las pruebas de DuskEVM × DuskDS. Se están empujando diferentes modelos de ejecución y de estado a través de cargas de trabajo mixtas en lugar de juzgarlos por separado.
Eso se siente más cercano al desafío real: no si cada pieza funciona, sino si siguen funcionando juntas cuando el sistema se pone ocupado.
Así que empiezo a preguntarme si el problema de ingeniería más difícil de Dusk ya no es hacer que funcione la privacidad.
Es lograr que la privacidad, la ejecución y la coordinación se sientan casi invisibles para el usuario.
Probablemente esa sea la prueba más interesante.
#dusk