zk proofs alone can prove a statement is true without revealing why. thats usually enough for privacy. so why does Hedger, Dusk's confidentiality module for the EVM, bother pairing zk proofs with homomorphic encryption on top instead of just using zk by itself.
the answer comes down to what each tool is actually good at. a zk proof can prove a transaction is valid, balances are correct, no funds were created out of nothing, without revealing the amounts involved. but proving validity isnt the same as letting encrypted values still be computed on. thats where homomorphic encryption comes in, specifically an ElGamal construction over elliptic curves. it lets balances stay encrypted while still being added, subtracted, updated directly in that encrypted form, no decryption step needed just to update a balance after a transfer.
put together, the roles split cleanly. ZK proves that whatever operation just happened on those encrypted values was legitimate, without exposing the underlying numbers to prove it. neither one covers both jobs alone, so Dusk isnt choosing one over the other, its using each for the specific thing it does well.
whats notable is the performance angle this seems built around. the docs highlight proof generation happening client-side, in-browser, in under two seconds. thats not a small technical detail, thats the difference between confidential transactions feeling usable in a live financial application versus feeling like something only batch settlement could tolerate.
but stacking two different cryptographic primitives together instead of relying on one unified system raises its own question. every additional primitive is additional surface area, additional assumptions that both need to hold simultaneously for the whole thing to stay secure.
so is combining HE and ZK actually the more resilient design because each covers the other's blind spot, or does layering two separate cryptographic systems just mean theres now two places instead of one where something could eventually go wrong.
#dusk @Dusk $DUSK
the answer comes down to what each tool is actually good at. a zk proof can prove a transaction is valid, balances are correct, no funds were created out of nothing, without revealing the amounts involved. but proving validity isnt the same as letting encrypted values still be computed on. thats where homomorphic encryption comes in, specifically an ElGamal construction over elliptic curves. it lets balances stay encrypted while still being added, subtracted, updated directly in that encrypted form, no decryption step needed just to update a balance after a transfer.
put together, the roles split cleanly. ZK proves that whatever operation just happened on those encrypted values was legitimate, without exposing the underlying numbers to prove it. neither one covers both jobs alone, so Dusk isnt choosing one over the other, its using each for the specific thing it does well.
whats notable is the performance angle this seems built around. the docs highlight proof generation happening client-side, in-browser, in under two seconds. thats not a small technical detail, thats the difference between confidential transactions feeling usable in a live financial application versus feeling like something only batch settlement could tolerate.
but stacking two different cryptographic primitives together instead of relying on one unified system raises its own question. every additional primitive is additional surface area, additional assumptions that both need to hold simultaneously for the whole thing to stay secure.
so is combining HE and ZK actually the more resilient design because each covers the other's blind spot, or does layering two separate cryptographic systems just mean theres now two places instead of one where something could eventually go wrong.
#dusk @Dusk $DUSK