Poseidon is a hash function optimized for proof generation and validation. Poseidon is used all across the Dusk Network blockchain stack and is the most efficient zero-knowledge friendly hashing implementation.
This week we deliver the Release Candidate Library for Poseidon and Hades.
💡 The Poseidon hash function has been designed to be friendly to zero-knowledge applications. Specifically, with Poseidon, we aim to minimize the proof generation time, the proof size, and the verification time (when it varies).
👉 Interested in the nitty gritty details about Poseidon? Read the academic Poseidon Paper
Poseidon is used in applications all across Dusk Network. For example, if a Block Generator wants to prove that his bid (stake) was included in the winning bid transaction, or if a user wants to prove that she is part of a whitelist, a Merkle Tree opening proof is required. Poseidon takes care of the hashing part involved in this action, and is optimized for this job, which results in a lot of speed.
Now for a more technical description: Poseidon is the (sponge) construction that builds on the Hades permutation strategy in order to create a cryptographic hash, which has the property of producing outputs of the same length (no matter the input), is pure (from hashing the same input you always get the same output), and collision-resistant (different inputs produce different outputs)
In Dusk Network most of the operations performed by users require them to prove the inclusion of data in a Merkle tree and knowing the path (without ever leaking any data). So, having an optimized hashing algorithm to perform the Merkle Tree opening proof is of vital importance for us.
Hades is used to make sure that someone cannot take the output of a hash and use that to learn what the input has been. If this was possible, bad actors could game the system.
To put it in more technical terms: Hades provides the strategy (intended as amount of time) for applying a round function to a scalar-encoded input in order to produce an output that looks as random as possible.
This strategy is devised so as to destroy any symmetries and structural properties of the input that would lower the probability to guess the pre-image (i.e. the input).
The E2E RC Release schedule
The End-to-End Release Candidate is a feature-freeze, and signals the version of the blockchain protocol that we want to go live with. The Release Candidate includes various libraries, which together form the E2E Release Candidate.
👉 You can find the full Schedule here
Previously we released: