Rationale & Theory

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.

2. Proof of Blind-Bid Generation.

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 although in practice, these two are a collection of gadgets added up together in order to compose the [BlindBidCircuit]:

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

Some noteworthy proofs are:

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.

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).

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

Score generation needs to be understood as a continuation of the next circuit instead of a different entity.

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.

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.

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.

Documentation

The best usage example of this library can actually be found in the Bid contract. This is the place where this lib provides all it's functionallities together with PoseidonTrees and Zero Knowledge Proofs. See: <https://github.com/dusk-network/rusk/tree/master/contracts/bid for more info and detail.>

You can also check the documentation of this crate here.

Licensing

This code is licensed under Mozilla Public License Version 2.0 (MPL-2.0). Please see LICENSE for further info.

About

Protocol & Implementation designed by the dusk team.

Contributing

• If you want to contribute to this repository/project please, check CONTRIBUTING.md
• If you want to report a bug or request a new feature addition, please open an issue on this repository.