How it's made: Privacy in Consensus (Proof-of-Blind Bid)
By Mels Dees

Jul 09, 2020

At Dusk Network we are serious about privacy. In this article we describe how Block Generators retain their anonymity by obfuscating their stakes and identity. This added layer of privacy is made possible by the Blind Bid contract, one of four Dusk Network Genesis Contracts.

Key takeaways

  • There are 2 node types in the SBA consensus: Block Generators & Provisioners.
  • Block Generators compete for a slot to produce a candidate block.
  • Proof-of-Blind Bid is a mechanism that runs every consensus round and extracts the winner.
  • Block Generators run the Proof-of-Blind Bid to prove that they have a valid Bid, that the score generation procedure was computed correctly, and in order to compete with the other Block Generators. All to win a portion of the round’s block reward.


The Blind Bid contract was one of the most challenging implementations inside the Dusk Network. Not only is there no other project to compare with, but the amount of zero-knowledge (ZK) technology that goes into the creation of the Proof-of-Blind Bid required various breakthroughs in the ZK-field.

In this Blog post and Demo video we explain why we have created the Blind Bid contract, and how the Proof-of-Blind Bid procedure brings anonymity and privacy to Block Generators that partake in the consensus.

For our loyal readers, you may have noticed that this article marks an end to the genesis contract series. With the four genesis contracts completed, the biggest hurdles are out of the way. There is still some more PLONK-integration related work remaining, but the path is laid out for us. For those that missed out and are interested, we have included the full genesis reading list at the bottom.

Blind Bid in our technical framework

As usual, we start with a bird’s-eye view of the Dusk Network technical framework. Two things are important. Firstly, the Blind Bid Contract ‘lives inside’ the consensus and interacts with the RUSK Virtual Machine (VM). Secondly, there is both a Blind Bid Contract and a Staking Contract. Allow us to briefly explain the difference (below).

The Dusk Network Technical Framework below is an attempt to explain concisely how all of the components tie together. You can explore more here.

Recap: Staking or Blind Bidding

At Dusk Network we’ve created an entirely new consensus mechanism called SBA, short for Segregated Byzantine Agreement. SBA has many interesting features, important for this article is the awareness that SBA is Proof-of-Stake-based, and has a dual node structure. SBA is also a permission-less protocol, anyone can participate in its consensus, and participation is possible either as a Block Generator, or as a Provisioner. So it could very well be that you run either of them in the near future

What do Block Generators do? They compete to produce a candidate block through a novel mechanism called Proof-of-Blind Bid (PoBB).

And how does this work? We’ll take you through this process step-by-step, right now.

A Step-By-Step Proof-of-Blind Bid Guide

In order to participate in the SBA consensus, Block generators have to submit a bid in DUSK. As long as their bid is active - and their full-node is connected with the internet and running- they are participating in the consensus rounds.

Essentially, every time a consensus round is run, the Block Generator software generates a comprehensive zero-knowledge proof, and executes various steps in order to generate a valid candidate block, and compete with the other Block Generators for a chance to become the winner of the consensus round.

Below we describe the three main processes that happen every consensus round. Please note that 1 and 2 are run as part of the same algorithm.

1: Score generation. Block Generators obtain a score from a lottery by executing the Score Generation Function. The score is positively influenced by the amount of DUSK that the Block Generator bids. In other words, the higher the bid, the better the chance to generate a high score. This is important to guarantee Sybil attack protection. Without this link a bad actor could subvert the reputation system by creating multiple identities.

Also note: there are minimum and maximum thresholds that determine the minimum and maximum size of the bid.

Tip: “Bid/Staking is different terminology to prevent confusion. Block Generators bid, and Provisioners stake, and while bids are obfuscated (privacy), stakes are transparent.”

2. Proof of Blind-Bid Generation. The blind-bid circuit is used by Block Generators to compute the blind-bid proof. The blind-bid circuit includes the score generation circuit (mentioned at step 1). In order to compute the blind-bid proof, multiple proofs of knowledge and range-proofs are performed:

Essentially, during the Score-Proof - as outlined in (1) - the Block Generator proves that he had ownership of the bid that was used to generate the score, and that the procedure for score generation was correctly executed. During (2), the Block Generator proves that he owns the bid, that he is eligible for this consensus round, and that the value of the bid is between the accepted min and max staking-thresholds.

3. Propagation. During each consensus round, the Block Generator checks the score that he produced, and verifies whether it is greater than the minimum score threshold. If it is indeed greater, then the Block Generator generates the aforementioned proofs and propagates the score obtained, the zero-knowledge proof computed and various other elements alongside the Block Candidate to his peers in the network. The Block Generator that computed the highest score is considered to be the leader of the current iteration of the consensus.

Note: it commonly occurs that multiple Block Generators compute a score higher than the minimum score threshold, in which case the highest score wins.


Congratulations, you are now an expert on the basics of Proof-of-Blind Bid, below we continue our journey into the technicalities.


PLONK circuits - time to get technical

In general computing science, a circuit is a computational model through which input values proceed through a sequence of gates, each of which computes a specific function. In our case, the circuits perform the logical checks with public and private inputs to make sure that the generated Blind Bid proofs are generated by the rules of the game. For explanatory reasons, we define two circuits:

  1. Blind Bid circuit;
  2. Score Generation circuit.

Below we describe the Blind Bid circuit and the score generation circuit, who together form the pillars of the Proof-of-Blind Bid procedure.

Blind Bid Circuit
In the circuit version used at the time of the demo, we use a vast 43.942 gates (or constraints) to create consensus’ privacy and exclude the ability of anyone to game the systems mechanics. Some noteworthy proofs are:

  1. Opening Proof: this is generated to check where the Bid has been stored on the merkle-tree (you could see this as a ledger where values are stored) that contains all of the bids. This proof checks that the Bid has indeed been made, and can be trusted.

  2. Pre-image check of the Bid: this is a consistency check that aims to make it impossible to cheat during the computation of the bid. If a bad actor attempts to cheat, the opening proof will not be the same and therefore not consistent.

It goes both ways. If you try to cheat on the pre-image check, the Opening Proof will fail as a result. And if you try to cheat on the Opening Proof, the pre-image would be impossible to compute because there are 2^256 different possibilities. To put that in perspective, even with all the time in the universe, you would not be able to check all of them (note that a consensus round also only takes ~10 seconds).

Fig. 1. shows the constraints in the Blind Bid Circuit.

In Fig 1. you can see that in step 3. & 4 we perform range checks to make sure that the Bid is valid and eligible during the current consensus round and steps. Finally, in proofs 7. & 8. we check the hash of the secret (H(k)) and the prover ID (i), asking for proof that the block generator - who we assume has posted the bid -, indeed is the owner of the bid.

Once the process above has been completed we move to Score Generation.

Score Generation Circuit
The final step is to check if the Score in the Blind Bid is correct. This step is important, as the Score determines the winner of an election round. By making use of 1.087 constraints (or gates) in the PLONK proof system, it is basically impossible to cheat;

The prover ID (y) is directly connected to the secret (k) and pre-image hash of the Bid (H(bidi)), meaning that any changes to the score will automatically result in a different prover ID, and thus a failed constraint on line 1. of the Score Generation Circuit.

Fig 2. The Score Generation Circuit checks if the generated Score in the Bid is correct.

Tech demo
In the demo video developer Carlos explains in more detail how the Proof-of-Blind Bid works, while he also demonstrates that the system will catch you if you attempt to cheat.

Github repository:

Concluding remarks
With the inclusion of PLONK zero knowledge circuits we have managed to create a truly privacy compliant consensus mechanism. By obfuscating the stakes of block generators, we make it impossible to predict their identities. On the other hand, the same proof circuits make it impossible to cheat your way into becoming the next Block Generator.

Reading List - Previous Genesis Contract articles

About Dusk Network

Dusk Network is a privacy blockchain for financial applications. You can use Dusk Network to create zero-knowledge smart contracts that control digital assets and securities.

Share this post

Subscribe to our newsletter

Dusk on GitHub Download Whitepaper