Block Generation 101: Assuring Staker Anonymity
By Mels Dees

Sep 11, 2020

A closer look at the key building blocks of our Segregated Byzantine Agreement

Proof-of-Blind-Bid is a fundamental building block of the decentralized algorithm called the Segregated Byzantine Agreement, that allows nodes (i.e. stakers) to achieve consensus within the Dusk Network. At its core, to achieve consensus means to achieve a common agreement amongst all network nodes in regards to which block of transactions gets processed at each round.

Watch the video here:

In this article, we want to provide you with a closer look at the inner workings of the SBA and, in particular, the Proof-of-Blind-Bid.

A Blockchain utilizes consensus algorithms to add new blocks to the chain. This occurs in rounds. Our Segregated Byzantine Agreement consensus algorithm foresees two different phases during each round:

One is the generation phase, where potential round leaders submit their own block of transactions to the network. The other is the block validation phase, where a committee of validators, called Provisioners, elect the winning block to be added to the blockchain in a permanent and final manner.

The Proof of Blind-Bid governs the generation phase while protecting the privacy of the generators. As such, it can be considered a cryptographic evolution of the notorious Proof-of-Stake, sharing much of its mechanics in practice but with the additional benefit of confidentiality.

The satisfaction of the confidentiality condition required an all-embracing integration of advanced Zero-Knowledge Proofs, with the capability of combining proofs of a variety of statements. Such research culminated with the release of the most advanced implementation of the PLONK proof system to date.

If you’d like to know more about the Zero-Knowledge Technology ‘PLONK’ and its role in the process, we highly recommend taking a look at our Hackernoon Compendium article. (Note: this knowledge is not a requirement for understanding the rest of this article)

The Steps Towards Confidentiality.

In order to safeguard the privacy of a stake - whilst simultaneously preventing the staker from cheating - the Proof of Blind-Bid undertakes a series of steps. Let’s walk through each step, one by one.

Step 1 - Bid Transaction

The procedure begins when a participant communicates something called a ‘Bid Transaction’. Bid Transactions include the following information:

1. The amount of Dusk to be staked

2. A string of bytes called the secret ‘K’.

In this first step we have a clear example of Dusk Network’s focus on privacy:

- The identity of the participant remains private through the creation of a stealth address.

- The amount to be staked remains private through a Pedersen commitment.

- The secret ‘K’ remains private through hashing.

The Bid Transaction is stored in the Bid Contract Storage (in a so-called Poseidon Tree, to be precise), and remains valid for a number of rounds. From this point on, the participant who communicates the Bid Transaction is able to participate in the 2nd step: the Blind Bid Lottery.

Step 2 - Blind Bid Lottery

The participant runs a non-interactive lottery by executing the `*generate_score*` procedure function. This function takes as input the amount of DUSK committed in step 1 along with a pseudonymous identity. Once this has been input, it returns a score. This score is a number that is probabilistically linked to the amount of DUSK committed.

In essence, the ‘winner’ of the lottery is the one with the highest score. The higher the initial stake, the higher the probability to obtain a higher score.

Step 3 - Zero-knowledge proof generation

The participant creates a Zero-Knowledge Proof of Blind-Bid using an algebraic circuit that requires Zero-Knowledge Proof of the following:

Proof Generation: part 1 - the score was generated at the right time

The lottery score has been generated for the current consensus step, round, and seed.

Proof Generation: part 2 - the user knows which bid to use

The bidder has knowledge of the hash of the Bid Transaction. Of course, in order to do any proof on the contents of the Bid, the bidder must first prove their knowledge of the Bid.

Proof Generation: part 3 - the bid has been accepted in the bid tree

The bidder has knowledge of the path of the Bid, to the root of the Poseidon Tree. As noted before, the Poseidon Tree (which is a Merkle Tree hashed with a Poseidon hashing algorithm) functions as Bid Contract Storage for the Bid Transaction.

Proof of knowledge of the path, without leaking the path, preserves the anonymity of the Bid and proves its inclusion into the tree. Inclusion in the tree means the Bid has been submitted and is currently valid.

Proof Generation: part 4 - the Dusk tokens bidden are within range

The Bid contains an amount of DUSK that is within the acceptable range for a Bid.

Proof Generation: part 5 - the user owns the bid

The bidder knows the secret ‘K’ embedded in the Bid. Knowing this ‘K’ proves ownership of the Bid in the same way that knowing a password proves ownership of an account or service.

Proof Generation: part 6 - the score is correctly computed

The score has been calculated correctly by inputting the `*score_generation*` function with the amount of DUSK equivalent to that staked in the Bid.

And that’s the process!

The Bidder, Verified.

In summary, the bidder must pass a checklist of requirements. This is handled through a host of algebraic circus which prove the following prerequisites:

Neither the bidder’s identity nor the content of the Bid are leaked to the committee of validators, ensuring total privacy.

Every time a consensus must be achieved, the bidder verifies whether the score produced during the iteration is greater or equal than the minimum score threshold. If it is greater, they generate a new block, a one-time stealth identity, and the Proof of Blind-Bid. They then propagate them along with the score to the nodes. The block associated with the highest score and a valid proof is considered to be the leader for the current iteration of the consensus.

Stay tuned for more deep dives into the mechanics of Dusk Network!

Share this post

Subscribe to our newsletter

Dusk on GitHub Download Whitepaper