DPOS Rounds debate

Context:

Our goal is to build a decentralized network where a limited number of N delegates will take turn accomplishing jobs submitted by network users. The delegates are elected using DPOS consensus mechanism where users can vote (stake tokens) in rounds.

A round may be started by any user of the network by calling an initalizeRound() function. When implementing such rounds, two approaches come to mind:

Approach 1: Rounds have a fixed length roundLength, but the actual election period is of variable length

Algorithm:

• initializeRound() is called at a block M
• find B such as B % roundLength == 0 and B <= M < B + roundLength
• use B as the start of the round.
• define roundNumber as B / roundLength
• all past blocks in the [B; M-1] interval are considered to be in the round
• all blocks in the [M; B + roundLength - 1] interval constitute the election period of the round -> variable election period

Pros:

• the roundNumber of a block can be computed easily

Cons:

• In most cases, the start of the round is set to be before the actual call of initializeRound() which is confusing
• electionPeriod is of variable length (less economic incentive for people to call initializeRound late in the round ?)
• roundNumbers of active rounds are not garanteed to be contiguous

Approach 2: Rounds have variable length, but the actual election period electionPeriodLength is of fixed length

Algorithm:

• initializeRound() is called at block M
• use M as the start of the round
• define roundNumber using a counter incremented during each round
• all blocks [M; M+electionPeriodLength-1] constitute the election period of the round
• all block from M+electionPeriodLength until the next call of initializeRound() are part of the current round -> variable total round length

Pros:

• start of election period is consistent with call of initializeRound()
• economic incentives are clear, and do not depend of block numbers

Cons:

• Rounds have variable lengths
• Have to scan the blockchain to know the roundNumber of a given block

Our choice

Other similar implementation like Livepeer have chosen approach 1 because of the convienent round numbering that it provides. However, in this project we have chosen approach 2 has we want our users to have strong economic incentive to start new rounds at any point in time.