Estaba revisando el trabajo de ingeniería reciente de Dusk y esperaba que la parte interesante fuera otra mejora al sistema de verificación.
En cambio, me quedé atascado con algo mucho menos emocionante:
cómo el sistema maneja los datos malos del verificador antes de que se adentre más en el pipeline..
Un cambio reciente relacionado con Plonk se centró en rechazar los datos malformados del verificador antes.
A simple vista, eso suena a ingeniería rutinaria.
Pero hay una distinción importante aquí.
Una prueba criptográfica puede estar matemáticamente bien mientras los datos que la transportan o que la rodean estén mal formados, incorrectamente serializados, o simplemente fuera de lo que la implementación espera.
Si esos datos llegan demasiado lejos en el pipeline de pruebas, las fallas se vuelven más difíciles de aislar y potencialmente más costosas de resolver.
Así que la mejora no necesariamente tiene que ver con hacer la criptografía más fuerte.
Se trata de hacer que el sistema confíe menos en las entradas ciegamente.
Eso importa muchísimo más cuando un sistema de pruebas se ejecuta como infraestructura de producción, en lugar de solo demostrar que las matemáticas subyacentes funcionan.
Los sistemas reales tienen que lidiar con serialización, decodificación, manejo de memoria, rutas de ejecución y entradas inesperadas.
Las matemáticas pueden ser correctas mientras que el software que las rodea sigue teniendo suposiciones débiles.
Por eso estos cambios de ingeniería más pequeños captan mi atención.
Los anuncios de funciones muestran lo que un protocolo quiere construir…
Cambios como este muestran lo que el equipo está aprendiendo sobre qué es realmente posible que salga mal.
Para Dusk, sacar datos inválidos antes se siente como un cambio pequeño con una implicación mucho mayor:
la infraestructura ZK de nivel producción no solo se trata de probar cosas válidas correctamente.
También se trata de hacer que las cosas inválidas fallen de manera segura, predecible y lo antes posible.
#dusk @Dusk $DUSK
$TUT
$UAI
En cambio, me quedé atascado con algo mucho menos emocionante:
cómo el sistema maneja los datos malos del verificador antes de que se adentre más en el pipeline..
Un cambio reciente relacionado con Plonk se centró en rechazar los datos malformados del verificador antes.
A simple vista, eso suena a ingeniería rutinaria.
Pero hay una distinción importante aquí.
Una prueba criptográfica puede estar matemáticamente bien mientras los datos que la transportan o que la rodean estén mal formados, incorrectamente serializados, o simplemente fuera de lo que la implementación espera.
Si esos datos llegan demasiado lejos en el pipeline de pruebas, las fallas se vuelven más difíciles de aislar y potencialmente más costosas de resolver.
Así que la mejora no necesariamente tiene que ver con hacer la criptografía más fuerte.
Se trata de hacer que el sistema confíe menos en las entradas ciegamente.
Eso importa muchísimo más cuando un sistema de pruebas se ejecuta como infraestructura de producción, en lugar de solo demostrar que las matemáticas subyacentes funcionan.
Los sistemas reales tienen que lidiar con serialización, decodificación, manejo de memoria, rutas de ejecución y entradas inesperadas.
Las matemáticas pueden ser correctas mientras que el software que las rodea sigue teniendo suposiciones débiles.
Por eso estos cambios de ingeniería más pequeños captan mi atención.
Los anuncios de funciones muestran lo que un protocolo quiere construir…
Cambios como este muestran lo que el equipo está aprendiendo sobre qué es realmente posible que salga mal.
Para Dusk, sacar datos inválidos antes se siente como un cambio pequeño con una implicación mucho mayor:
la infraestructura ZK de nivel producción no solo se trata de probar cosas válidas correctamente.
También se trata de hacer que las cosas inválidas fallen de manera segura, predecible y lo antes posible.
#dusk @Dusk $DUSK
$TUT
$UAI