@Dusk_Foundation Went looking for what actually happens when a Phoenix zero-knowledge proof fails verification, since most explanations stop at "the proof gets checked."
Dusk's architecture confirms the proof has to demonstrate specific properties together — ownership of the note being spent, balance integrity across inputs and outputs, and no double-spend — all encoded inside the same proof, not verified through separate side-checks. $DUSK
That's the part worth sitting with. If any single one of those properties doesn't hold, the entire proof fails as one unit. There's no partial-credit path where balance checks pass but ownership fails silently.
I traced what that means practically: a rejected proof means the transaction never gets included at all. The runtime doesn't attempt to salvage or partially process it. The transaction simply doesn't happen, and nothing about the failed attempt gets recorded as a state change. #dusk
What I haven't confirmed from Dusk's own materials is whether a failed proof leaves any trace in mempool logs that a node operator could inspect after the fact, or whether it's discarded without any diagnostic record at all.
Next thing I'd check: whether Dusk's current wallet tooling surfaces a specific reason for a failed proof, or just a generic rejection, since that distinction matters a lot for anyone actually debugging a transaction that didn't go through.
#dusk $DUSK @Dusk
Dusk's architecture confirms the proof has to demonstrate specific properties together — ownership of the note being spent, balance integrity across inputs and outputs, and no double-spend — all encoded inside the same proof, not verified through separate side-checks. $DUSK
That's the part worth sitting with. If any single one of those properties doesn't hold, the entire proof fails as one unit. There's no partial-credit path where balance checks pass but ownership fails silently.
I traced what that means practically: a rejected proof means the transaction never gets included at all. The runtime doesn't attempt to salvage or partially process it. The transaction simply doesn't happen, and nothing about the failed attempt gets recorded as a state change. #dusk
What I haven't confirmed from Dusk's own materials is whether a failed proof leaves any trace in mempool logs that a node operator could inspect after the fact, or whether it's discarded without any diagnostic record at all.
Next thing I'd check: whether Dusk's current wallet tooling surfaces a specific reason for a failed proof, or just a generic rejection, since that distinction matters a lot for anyone actually debugging a transaction that didn't go through.
#dusk $DUSK @Dusk