@Dusk_Foundation Busqué qué es lo que realmente ocurre cuando una prueba de conocimiento cero de Phoenix falla en la verificación, ya que la mayoría de las explicaciones se detienen en “la prueba se comprueba”.
La arquitectura de Dusk confirma que la prueba tiene que demostrar propiedades específicas en conjunto: la propiedad del apunte que se está gastando, la integridad del saldo entre las entradas y las salidas, y que no haya doble gasto; todo codificado dentro de la misma prueba, no verificado mediante comprobaciones laterales separadas. $DUSK
Esa es la parte con la que merece la pena sentarse. Si no se cumple cualquiera de esas propiedades, toda la prueba falla como una sola unidad. No existe una vía de “crédito parcial” en la que las comprobaciones de saldo se aprueben pero la propiedad falle en silencio.
Seguí qué significa eso en la práctica: una prueba rechazada significa que la transacción ni siquiera llega a incluirse. El entorno de ejecución no intenta “salvar” la situación ni procesarla parcialmente. La transacción simplemente no ocurre y nada del intento fallido se registra como un cambio de estado. #dusk
Lo que no he confirmado con los materiales propios de Dusk es si una prueba fallida deja algún rastro en los registros del mempool que un operador de nodo pudiera inspeccionar después, o si se descarta sin ningún registro de diagnóstico.
Lo siguiente que revisaría: si las herramientas actuales de la cartera de Dusk muestran una razón específica para una prueba fallida, o solo un rechazo genérico, ya que esa distinción importa muchísimo para cualquiera que esté depurando de verdad una transacción que no llegó a pasar.
#dusk $DUSK @Dusk
La arquitectura de Dusk confirma que la prueba tiene que demostrar propiedades específicas en conjunto: la propiedad del apunte que se está gastando, la integridad del saldo entre las entradas y las salidas, y que no haya doble gasto; todo codificado dentro de la misma prueba, no verificado mediante comprobaciones laterales separadas. $DUSK
Esa es la parte con la que merece la pena sentarse. Si no se cumple cualquiera de esas propiedades, toda la prueba falla como una sola unidad. No existe una vía de “crédito parcial” en la que las comprobaciones de saldo se aprueben pero la propiedad falle en silencio.
Seguí qué significa eso en la práctica: una prueba rechazada significa que la transacción ni siquiera llega a incluirse. El entorno de ejecución no intenta “salvar” la situación ni procesarla parcialmente. La transacción simplemente no ocurre y nada del intento fallido se registra como un cambio de estado. #dusk
Lo que no he confirmado con los materiales propios de Dusk es si una prueba fallida deja algún rastro en los registros del mempool que un operador de nodo pudiera inspeccionar después, o si se descarta sin ningún registro de diagnóstico.
Lo siguiente que revisaría: si las herramientas actuales de la cartera de Dusk muestran una razón específica para una prueba fallida, o solo un rechazo genérico, ya que esa distinción importa muchísimo para cualquiera que esté depurando de verdad una transacción que no llegó a pasar.
#dusk $DUSK @Dusk