Deep dive into the Auction mechanisms

This section describes the detailed functioning of the Auction, from the calculation of the bid price to the precreation of the Distributed Validator.

Understanding the Auction formulas

How is the bid price calculated?

The bid price is calculated through the standing bid parameters chosen by the operator at each bid:

• discountRate: our desired profit margin - it's the % discount of the auction bid in relation to expected PoS rewards

• timeInDays: the number of days the operator is willing to operate and stay in a cluster

By bidding, an operator actually pays for a certain number of Validation Credits, which grant the right to run a node as part of a cluster for that same number of days and keep 100% of the PoS rewards.

Below is the equation to determine the VC price, calculated in Auction._calculateDailyVcPrice:

$$P_{VC}(n_{cluster}) = \frac{R_e * (1 - discountRate)}{n_{cluster}}$$

• $P_{VC}(n_{cluster})$ is the price of a Validation Credit for a cluster of size $n$

• $R_e$ is the expected daily PoS rewards of a full Ethereum Validator ($R_e = \frac{32ETH * PoS_{APR}}{365}$)

• $discountRate$ is the desired operator profit margin

• $n_{cluster}$ is the number of nodes in the cluster

From the $P_{VC}$, we can easily deduct the bid price $P_{bid}$ (function Auction._calculateBidPrice):

$$P_{bid} = P_{VC} * timeInDays$$

How is the Auction Score calculated?

The Auction Score determines the final ranking of an operator in the auction. It primarily depends on the validation credit price $P_{VC}$, but slightly moderates this in favor of operators wanting to operate for longer periods of time and those with a better reputation. Implementation in Auction._calculateAuctionScore.

$$A_{score} = P_{VC} * 1.001^{timeInDays} * N_{reputation}$$

• $A_{score}$ is the final Auction Score of an operator's bid

• $N_{reputation}$ is the reputation of the operator (reputation mechanism not yet implemented)

As soon as an operator wins an auction, its bid is collected to mint a number of Validation Credits (VCs) equal to the number of days in their desired operating period.

Note: If an operator's VCs run out, they have the chance to purchase additional validation credits under the conditions of their previous deal: same price, same duration. If they choose not to do so, they are removed from the DV cluster in question and replaced with a new operator, who would have won another auction.

After reading this part, you should now know that:

• The higher your discountRate, the lower your Auction Score

• The higher your timeInDays, the higher your Auction Score

Post-Auction mechanisms

Now that equations behind the auction are clear, let's dive into the post-auction mechanisms, namely the pre-creation of a Distributed Validator.

Wait... Why is it required to pre-create the DVs? Why doesn't the protocol simply create a DV (i.e trigger an auction) once a staker needs one?

First, you have to know that contrary to the creation of a simple Ethereum Validator, a Distributed Validator requires the synchronization of the participating nodes beforehand. Depending on the responsivity of the different operators, it can takes several hours or even days to spin up a Distributed Validator.

Making a staker wait that amount of time before allowing the deposit of ETH on the Beacon Chain is not only pretty mediocre UX, but also massively inefficient. It would require two transactions from the staker instead of one: One to trigger an auction and create a DV, another one to deposit the stake on the Beacon Chain with the created DV's deposit data. The Byzantine protocol is fully non-custodial, so we couldn't make the beacon chain deposit either.

The solution is therefore to pre-create the DVs on the protocol's side, so that every time a staker wants to stake, they just pick up the deposit data of a pending DV, and activate it by depositing 32ETH on the Beacon Chain.

How does pre-creation of Byzantine DVs work?

Pre-creation of Distributed Validator on Byzantine

Byzantine introduced the concept of a Pending DVs Container where a varying number of pre-created DVs is stored and waits to be activated by a staker. This works based on a First In First Out (FIFO) policy: the first pre-created DV, will be the first one to be activated.

As explained on the diagram above, every time an auction is triggered, the first $n$ winners ($n$being the DV cluster size) are selected and have to synchronized each other. They first have to accept the cluster invitation (cluster configuration file is auto-generated by Byzantine), and then run the Distributed Key Generation (DKG) ceremony to create the distributed validator key (a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus). More details about the off-chain DV nodes synchronization can be found here: DV nodes synchronization.

In the meantime, the winning nodes are placed (on-chain) in the first empty slot of the Pending DVs Container, i.e. winners of the first auction are placed in slot 1, winners of the second auction in slot 2, etc.

Thus, a staker wanted to stake 32ETH will directly have the deposit data of a pre-created DV. Stakers will activate the DVs in the order of their creation, i.e. first staker will use the deposit data of DV1, second staker will use the deposit data of DV2, etc.

When is triggered an Auction?

You might wonder which mechanism triggers an auction to allow operators to pre-create a DV.

At the start of the Byzantine protocol, no pre-created clusters exist as no auction has been triggered. The Byzanteam handles the pre-creation of the first DVs (and thus pay the fees for the first auctions run). Once enough bids have been made, the Byzanteam calls the function StrategyModuleManager.preCreateDVs to pre-create the first DVs and allow stakers to activate them.

As soon as a staker activates a DV, it also triggers a new auction to pre-create a new DV for a next staker. Thus, the number of pre-created DVs remains constant in the protocol to ensure a good staking experience.

What happens to the bid paid by the node operators once they win an auction?

Once an operator wins an auction, its bid is immediately transferred from the Escrow contract to a contract which distributes the stakers rewards (not yet implemented). It means it is no longer possible to withdraw the bid from the Escrow contract once the auction is won. Byzantine Finance commits to keep an optimal equilibrum between the stakers DVs demand and the number of pre-created DV waiting for activation.