Un pequeño cambio en Rusk dice mucho sobre cómo Dusk trata la verificación criptográfica en las mejoras de protocolo.
Un resultado en caché ya no está ligado únicamente a la prueba y a sus entradas. Dusk también vincula ese resultado a las reglas de verificación que estaban activas cuando se realizó la comprobación.
Eso importa porque los datos de prueba idénticos no siempre significan un contexto de verificación idéntico. Una mejora de protocolo puede cambiar el verificador o la política de ejecución sin cambiar los bytes de la prueba.
Para la red Dusk, esto se vuelve especialmente relevante a medida que construye privacidad programable para mercados regulados, donde las pruebas criptográficas deben seguir siendo confiables a través de las mejoras de protocolo.
Lo que aún no sé es si Dusk ha aislado esas reglas específicas de versión lo suficientemente bien como para que un resultado en caché no pueda superar nunca la vigencia de la semántica que lo hizo válido.
Los detalles que vale la pena vigilar son el contexto de políticas de ejecución incluido en las claves de la caché, los cambios del verificador como la activación de PLONK V3 y qué ocurre cuando futuras mejoras cambian nuevamente el comportamiento de verificación.
Los bytes de prueba coincidentes son una evidencia útil de que dos comprobaciones parecen iguales. Son una evidencia más débil de que el mismo resultado en caché sea seguro para reutilizarse.
Me preocuparía más de si el contexto activo del verificador sigue coincidiendo que de cuánto trabajo de verificación logra Dusk almacenar en caché.
La idea más profunda es que la verificación determinista depende de más que fijar la entrada. Las reglas usadas para interpretar esa entrada también deben fijarse.
La pregunta es si Dusk puede seguir optimizando la verificación sin permitir que la antigua semántica de protocolo cruce un límite de mejora a través de la caché.
Estoy observando cómo los cambios futuros del verificador se reflejan en ese contexto de políticas de ejecución.
#dusk $DUSK @Dusk
Un resultado en caché ya no está ligado únicamente a la prueba y a sus entradas. Dusk también vincula ese resultado a las reglas de verificación que estaban activas cuando se realizó la comprobación.
Eso importa porque los datos de prueba idénticos no siempre significan un contexto de verificación idéntico. Una mejora de protocolo puede cambiar el verificador o la política de ejecución sin cambiar los bytes de la prueba.
Para la red Dusk, esto se vuelve especialmente relevante a medida que construye privacidad programable para mercados regulados, donde las pruebas criptográficas deben seguir siendo confiables a través de las mejoras de protocolo.
Lo que aún no sé es si Dusk ha aislado esas reglas específicas de versión lo suficientemente bien como para que un resultado en caché no pueda superar nunca la vigencia de la semántica que lo hizo válido.
Los detalles que vale la pena vigilar son el contexto de políticas de ejecución incluido en las claves de la caché, los cambios del verificador como la activación de PLONK V3 y qué ocurre cuando futuras mejoras cambian nuevamente el comportamiento de verificación.
Los bytes de prueba coincidentes son una evidencia útil de que dos comprobaciones parecen iguales. Son una evidencia más débil de que el mismo resultado en caché sea seguro para reutilizarse.
Me preocuparía más de si el contexto activo del verificador sigue coincidiendo que de cuánto trabajo de verificación logra Dusk almacenar en caché.
La idea más profunda es que la verificación determinista depende de más que fijar la entrada. Las reglas usadas para interpretar esa entrada también deben fijarse.
La pregunta es si Dusk puede seguir optimizando la verificación sin permitir que la antigua semántica de protocolo cruce un límite de mejora a través de la caché.
Estoy observando cómo los cambios futuros del verificador se reflejan en ese contexto de políticas de ejecución.
#dusk $DUSK @Dusk
