Implement block producer scheduling

[nathanielhourt]

How are block producers to be scheduled? Via rounds? What happens if all blocks are missed for more than one round? Does the round simply repeat?

Of course all of these questions have been answered before in BTS and Steem, but since none of the EOS producer scheduling code is written yet, I figure we should take a moment to make sure we know exactly how we want this to work, factoring in all the lessons from past experience.

[nathanielhourt]

Paging @bytemaster

[bytemaster]

EOS block producers should be scheduled same way as latest STEEM producers.

One thing I would like to consider is reducing the 128 bit math for virtual time and position with 64 bit math.

21 producers, top 20 by approval voting every round, last 1 selected based on virtual schedule.

A producer who misses a block after not producing for 24 hours is automatically unscheduled by setting their signing key to null. Skip any producers whose signing key is null.

Only other difference from STEEM is that only a single layer of proxy voting will be supported.

[bytemaster]

These fields are used for the Producer scheduling algorithm which uses
* virtual time to ensure that all witnesses are given proportional time
* for producing blocks.
*
* @ref votes is used to determine speed. The @ref virtual_scheduled_time is
* the expected time at which this witness should complete a virtual lap which
* is defined as the position equal to 1000 times MAXVOTES.
*
* virtual_scheduled_time = virtual_last_update + (1000MAXVOTES - virtual_position) / votes
*
* Every time the number of votes changes the virtual_position and virtual_scheduled_time must
* update. There is a global current virtual_scheduled_time which gets updated every time
* a witness is scheduled. To update the virtual_position the following math is performed.
*
* virtual_position = virtual_position + votes * (virtual_current_time - virtual_last_update)
* virtual_last_update = virtual_current_time
* votes += delta_vote
* virtual_scheduled_time = virtual_last_update + (1000MAXVOTES - virtual_position) / votes
*
* @defgroup virtual_time Virtual Time Scheduling
*/
///@{
fc::uint128 virtual_last_update;
fc::uint128 virtual_position;
fc::uint128 virtual_scheduled_time = fc::uint128::max_value();

[nathanielhourt]

Still TODO here:

• When an account approves/unapproves a producer, add/remove that account's stake to that producer's votes
• When an account gains or loses stake, add/remove the gained/lost stake to all producers that account votes for
• Calculate the producer round changes in generate_block and add to block header
• Proxied voting...?

If I'm not mistaken, we can ignore the CreateAccount initial deposit of stake, as a newly created account cannot be voting for anything yet, so we need do no updates until the new account creates a transaction voting for something, at which point it will be handled as usual. The only times the stake will change are TransferToLocked and StartUnlockEos

It could be argued that a newly created producer should automatically have its creator's stake voting for it; however, I don't think this is necessary, and I'm not confident it's even desirable, so for now I will leave newly created producers as having no votes.