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.
Last updated
This section describes the detailed functioning of the Auction, from the calculation of the bid price to the precreation of the Distributed Validator.
Last updated
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:
is the price of a Validation Credit for a cluster of size
is the expected daily PoS rewards of a full Ethereum Validator ()
is the desired operator profit margin
is the number of nodes in the cluster
From the , we can easily deduct the bid price (function Auction._calculateBidPrice):
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
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.
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.
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.
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.
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.
The Auction Score determines the final ranking of an operator in the auction. It primarily depends on the validation credit price , 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.
is the final Auction Score of an operator's bid
is the reputation of the operator (reputation mechanism not yet implemented)
As explained on the diagram above, every time an auction is triggered, the first winners (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: .
