Something small has been bothering me since I started reading how Dusk generates proofs.
Zero-knowledge proving is expensive. Your phone doesn't want to do it. So Dusk gives you a way out: wallet-core supports delegating proof generation to an external Prover, and Prover is a documented node type you can actually run, alongside Provisioner and Archive.
That's a sensible engineering answer. The engineering update that introduced it specifically mentions the delegation is designed to avoid malleability, so the prover can't quietly alter what you asked for.
But delegation always answers one question and opens another. Malleability is about whether the prover can change your transaction. It isn't the same question as what the prover gets to see while building the proof for you.
Now put Hedger next to it. Hedger's pitch for the EVM side goes the other direction entirely — lightweight circuits, client-side proof generation in under two seconds, in the browser. No third machine involved.
So @Dusk has both shapes in the same stack. A delegated proving path for heavy native circuits, and a local proving path for the confidential EVM layer.
I don't think either is wrong. Local proving is cleaner for privacy and worse for weak devices. Delegated proving is the opposite. Most chains just pick one and stop talking about it.
What I can't tell yet from the docs is how a normal user is supposed to know which one they're using at any given moment. That's the part I'd want spelled out before a bank puts a client on it.
If a service offered to generate your privacy proof for you, faster and free — would you use it, or would that defeat the point for you?
#dusk $DUSK @Dusk
Zero-knowledge proving is expensive. Your phone doesn't want to do it. So Dusk gives you a way out: wallet-core supports delegating proof generation to an external Prover, and Prover is a documented node type you can actually run, alongside Provisioner and Archive.
That's a sensible engineering answer. The engineering update that introduced it specifically mentions the delegation is designed to avoid malleability, so the prover can't quietly alter what you asked for.
But delegation always answers one question and opens another. Malleability is about whether the prover can change your transaction. It isn't the same question as what the prover gets to see while building the proof for you.
Now put Hedger next to it. Hedger's pitch for the EVM side goes the other direction entirely — lightweight circuits, client-side proof generation in under two seconds, in the browser. No third machine involved.
So @Dusk has both shapes in the same stack. A delegated proving path for heavy native circuits, and a local proving path for the confidential EVM layer.
I don't think either is wrong. Local proving is cleaner for privacy and worse for weak devices. Delegated proving is the opposite. Most chains just pick one and stop talking about it.
What I can't tell yet from the docs is how a normal user is supposed to know which one they're using at any given moment. That's the part I'd want spelled out before a bank puts a client on it.
If a service offered to generate your privacy proof for you, faster and free — would you use it, or would that defeat the point for you?
#dusk $DUSK @Dusk
