@Dusk Fui a ver qué garantiza realmente la «prueba PLONK
verificada» en el nivel del nodo,
ya que la mayoría de los explicadores tratan la verificación como una única compuerta de paso/fallo sin nada más que decir.
La ruta de preverificación de Dusk confirma que cada transacción de Phoenix pasa por una función
dedicada de verificación de pruebas antes de ser admitida en el mempool.
Ese es el punto de control en el que se apoya todo el modelo de privacidad:
sin prueba, no hay admisión. $DUSK
Ese es el aspecto con el que vale la pena quedarse.
Una revisión de seguridad de terceros señaló que ese punto de control tenía un hueco:
ciertas evaluaciones dentro de la verificación de PLONK
no se estaban comprobando por completo como el diseño asumía.
La corrección se incorporó como un commit específico a principios de este año.
Es un recordatorio de que «verificada con una prueba ZK» no es una
garantía fija: es tan sólida como el código
que ejecuta la verificación,
y ese código puede tener puntos ciegos que las auditorías están diseñadas para detectar.
Seguí lo que eso significa en la práctica:
el hueco no significó que las pruebas falsas estuvieran
pasando sin problema en producción, ya que el stack de Dusk
ya había pasado por múltiples auditorías previas del
sistema de pruebas y la biblioteca del nodo.
Pero sí significa que la afirmación de que
«la prueba se comprueba» se apoya en un escrutinio continuo,
no en una garantía criptográfica única
que nunca necesite volver a revisarse. #dusk
Lo que no he podido confirmar con los propios materiales de Dusk
es si las auditorías independientes de la ruta de verificación
se ejecutan con una cadencia fija hacia adelante,
o si ocurren de forma oportunista cuando una firma de seguridad decide mirar.
@Dusk #dusk $DUSK
verificada» en el nivel del nodo,
ya que la mayoría de los explicadores tratan la verificación como una única compuerta de paso/fallo sin nada más que decir.
La ruta de preverificación de Dusk confirma que cada transacción de Phoenix pasa por una función
dedicada de verificación de pruebas antes de ser admitida en el mempool.
Ese es el punto de control en el que se apoya todo el modelo de privacidad:
sin prueba, no hay admisión. $DUSK
Ese es el aspecto con el que vale la pena quedarse.
Una revisión de seguridad de terceros señaló que ese punto de control tenía un hueco:
ciertas evaluaciones dentro de la verificación de PLONK
no se estaban comprobando por completo como el diseño asumía.
La corrección se incorporó como un commit específico a principios de este año.
Es un recordatorio de que «verificada con una prueba ZK» no es una
garantía fija: es tan sólida como el código
que ejecuta la verificación,
y ese código puede tener puntos ciegos que las auditorías están diseñadas para detectar.
Seguí lo que eso significa en la práctica:
el hueco no significó que las pruebas falsas estuvieran
pasando sin problema en producción, ya que el stack de Dusk
ya había pasado por múltiples auditorías previas del
sistema de pruebas y la biblioteca del nodo.
Pero sí significa que la afirmación de que
«la prueba se comprueba» se apoya en un escrutinio continuo,
no en una garantía criptográfica única
que nunca necesite volver a revisarse. #dusk
Lo que no he podido confirmar con los propios materiales de Dusk
es si las auditorías independientes de la ruta de verificación
se ejecutan con una cadencia fija hacia adelante,
o si ocurren de forma oportunista cuando una firma de seguridad decide mirar.
@Dusk #dusk $DUSK