VRF balancing, backfilling mechanism

Current block chain (as of 12/17/2024) has many slots without a single block producer (BP). Then again, many slots have more than a BP allocated. This slows down the chain’s throughput as blocks are not produced deterministically.

Backfilling mechanism should be designed. A simple example mechanism could be allowing previous block VRF losers to produce a block for the next slot (perhaps with a small compensation delay to identify empty slot).

For instance, if slot N+1 is empty, the producer for slot N can create a block for N+1 as well, if it has not produced a block for slot N.

3 Likes

In practice, this approach could implement a waitlist mechanism, where the public keys of VRF losers are added to a VRF-output-ordered list. This list would be maintained by a daemon for a sliding window duration (e.g. an epoch time, 7,200 slots, or less).

If no block is produced within a 1/3 of the slot time, a daemon can approve a block submitted by a block producer (BP) from the waitlist, based on the order of their VRF output (with lower outputs prioritized).

BPs on the waitlist are removed under two conditions:

  1. When they successfully produce a block, as a result of being selected from the waitlist, or they have an assigned slot.
  2. When the sliding time window elapses.

BP behaviour is changed quite a bit with the above approach. Whenever a BP is on the top of the waitlist, it shall produce a block to all following slots and monitor for an empty slot. This creates additional load for the BP.

Even if the waitlist is ordered, BPs on the waitlist might send their block to an empty slot all at once. This may cause load to the network if the waitlist is long.

Next step would be to do the analysis how this would change the chain behaviour and what slot time-window would achieve good enough fill rate for empty slots.

1 Like

A brief security analysis suggests the following enhancements:
- The highest-priority BP on the waitlist is the designated BP for the next empty slot.
- The designated BP is removed from the waitlist after either producing a block or missing the empty slot.
- Other waitlist BPs are prohibited from producing a block for the empty slot.

With the above settings, the incentive for all BPs to send a block to an empty slot is removed. This also eliminates the incentive to interfere with other BPs on the waitlist to produce a block for an empty slot.

1 Like

The designated BP must be included in the chain to verify its validity.

One approach is to maintain the waitlist in the nodes using a Sparse Merkle Tree (SMT), and include the designated BP’s public key as an optional parameter in the consensus state, along with a zk-SNARK proof of its eligibility. The zk-SNARK proof would ensure the following:

  • The designated BP added to the chain is the highest priority in the node local waitlist.
  • The VRF output of the designated BP is below the slot’s VRF threshold.

The use of an SMT allows for slight synchronization differences between nodes, as long as the designated BP is present in the waitlist.

When an empty slot is reached, the block from the designated BP can be accepted and forwarded by other BPs. The designated BP information will be updated in the chain by the creator of the empty block, according to their waitlist. If the designated BP misses the slot, the information will be updated by the next BP, based on their waitlist.