#dusk $DUSK @Dusk
Privacy protocols get discussed mostly in terms of what they hide. What I hadn't paid attention to until recently is what makes hiding something computationally cheap enough to be usable in the first place — and on Dusk, that comes down to two fairly unglamorous choices: PLONK as the proof system, and Poseidon as the hash function used inside its circuits.
PLONK is what actually generates and verifies the zero-knowledge proofs behind Phoenix transactions, Citadel's identity claims, and other private operations on the network. What's notable about it isn't just that it works, but that it supports custom, reusable circuits — meaning different privacy-preserving features across the protocol can share the same underlying proving machinery instead of each one reinventing its own cryptographic wheel.
Poseidon is the quieter piece. It's a hash function specifically designed to be efficient inside zero-knowledge circuits, which matters because general-purpose hash functions like SHA-256 are expensive to compute inside a ZK proof — every bit of computation inside a circuit adds to how long a proof takes to generate. Using a hash function built for that environment directly affects whether "private and verifiable" stays fast enough to be usable at real transaction volumes, or becomes a feature that's technically possible but too slow to matter in practice.
proof generation speed is often the actual bottleneck standing between a working demo and something that scales to real usage.
The tradeoff worth sitting with is that ZK-friendly primitives like Poseidon are newer and less battle-tested than something like SHA-256, which has survived decades of cryptanalysis. Efficiency and track record pull in different directions here, and it's a genuine open question in applied cryptography more broadly, not something unique to Dusk. Whether that tradeoff ages well is something only time and continued scrutiny can really answer.
Privacy protocols get discussed mostly in terms of what they hide. What I hadn't paid attention to until recently is what makes hiding something computationally cheap enough to be usable in the first place — and on Dusk, that comes down to two fairly unglamorous choices: PLONK as the proof system, and Poseidon as the hash function used inside its circuits.
PLONK is what actually generates and verifies the zero-knowledge proofs behind Phoenix transactions, Citadel's identity claims, and other private operations on the network. What's notable about it isn't just that it works, but that it supports custom, reusable circuits — meaning different privacy-preserving features across the protocol can share the same underlying proving machinery instead of each one reinventing its own cryptographic wheel.
Poseidon is the quieter piece. It's a hash function specifically designed to be efficient inside zero-knowledge circuits, which matters because general-purpose hash functions like SHA-256 are expensive to compute inside a ZK proof — every bit of computation inside a circuit adds to how long a proof takes to generate. Using a hash function built for that environment directly affects whether "private and verifiable" stays fast enough to be usable at real transaction volumes, or becomes a feature that's technically possible but too slow to matter in practice.
proof generation speed is often the actual bottleneck standing between a working demo and something that scales to real usage.
The tradeoff worth sitting with is that ZK-friendly primitives like Poseidon are newer and less battle-tested than something like SHA-256, which has survived decades of cryptanalysis. Efficiency and track record pull in different directions here, and it's a genuine open question in applied cryptography more broadly, not something unique to Dusk. Whether that tradeoff ages well is something only time and continued scrutiny can really answer.