#dusk $DUSK @Dusk
Estaba leyendo los recientes cambios de ingeniería de Dusk y esperaba que la parte interesante fuera otra mejora del sistema de pruebas.
En cambio, seguí volviendo a algo mucho menos glamoroso: lo que ocurre antes de que una prueba incluso se procese..
Un cambio reciente relacionado con Plonk se centró en rechazar antes los datos del probador malformados. Al principio, eso suena a una limpieza de rutina.
Pero cuanto más lo pensaba, más importante se volvía.
Hay una diferencia entre romper la criptografía y alimentar datos incorrectos dentro de una infraestructura criptográfica.
Una prueba puede ser matemáticamente válida mientras que los datos que la rodean estén malformados, serializados incorrectamente o estructurados de una forma que el sistema nunca esperaba. Si esas entradas se permiten viajar más adentro del proceso de pruebas, la falla eventual se vuelve más difícil de aislar y posiblemente más costosa de manejar.
Así que la mejora real no necesariamente trata de matemáticas más fuertes.
Se trata de mover el punto de rechazo más cerca de la fuente.
Eso importa a nivel operativo.
En una infraestructura de pruebas de una red en vivo, no funciona en aislamiento. Tiene que lidiar con la serialización y decodificación de entradas, rutas de ejecución y memoria, y todos los casos límite extraños que aparecen cuando el software se enfrenta a datos del mundo real.
La criptografía puede estar bien, mientras que la implementación que la rodea aún tenga suposiciones débiles.
Por eso encuentro estos cambios más pequeños más reveladores que los anuncios de características.
Muestran en qué está invirtiendo tiempo el equipo de ingeniería al reducir la cantidad de cosas que el sistema está dispuesto a procesar a ciegas.
Para Dusk, creo que esta es una dirección importante: no solo demostrar que funciona con datos válidos, sino lograr que los datos inválidos fallen antes, de manera más limpia y más cerca de donde comienza el error.
La aburrida capa de validación puede terminar diciéndonos más sobre la preparación para producción que la criptografía llamativa jamás lo hará.
Estaba leyendo los recientes cambios de ingeniería de Dusk y esperaba que la parte interesante fuera otra mejora del sistema de pruebas.
En cambio, seguí volviendo a algo mucho menos glamoroso: lo que ocurre antes de que una prueba incluso se procese..
Un cambio reciente relacionado con Plonk se centró en rechazar antes los datos del probador malformados. Al principio, eso suena a una limpieza de rutina.
Pero cuanto más lo pensaba, más importante se volvía.
Hay una diferencia entre romper la criptografía y alimentar datos incorrectos dentro de una infraestructura criptográfica.
Una prueba puede ser matemáticamente válida mientras que los datos que la rodean estén malformados, serializados incorrectamente o estructurados de una forma que el sistema nunca esperaba. Si esas entradas se permiten viajar más adentro del proceso de pruebas, la falla eventual se vuelve más difícil de aislar y posiblemente más costosa de manejar.
Así que la mejora real no necesariamente trata de matemáticas más fuertes.
Se trata de mover el punto de rechazo más cerca de la fuente.
Eso importa a nivel operativo.
En una infraestructura de pruebas de una red en vivo, no funciona en aislamiento. Tiene que lidiar con la serialización y decodificación de entradas, rutas de ejecución y memoria, y todos los casos límite extraños que aparecen cuando el software se enfrenta a datos del mundo real.
La criptografía puede estar bien, mientras que la implementación que la rodea aún tenga suposiciones débiles.
Por eso encuentro estos cambios más pequeños más reveladores que los anuncios de características.
Muestran en qué está invirtiendo tiempo el equipo de ingeniería al reducir la cantidad de cosas que el sistema está dispuesto a procesar a ciegas.
Para Dusk, creo que esta es una dirección importante: no solo demostrar que funciona con datos válidos, sino lograr que los datos inválidos fallen antes, de manera más limpia y más cerca de donde comienza el error.
La aburrida capa de validación puede terminar diciéndonos más sobre la preparación para producción que la criptografía llamativa jamás lo hará.
