DAWN-497 ⁃ Producer Feature Upgrade Voting

[bytemaster]

Any block producer can propose a "new feature upgrade" ("soft fork") and assign it a name and earliest effective date.

Any producer may cast a vote in 4 states:

1. for
2. neutral
3. against
4. ? (needs to be clarified)

In addition to voting, a producer may also indicate whether or not they are running code that supports the new feature. (It is possible for you as a producer to vote against it but run a node that supports it so as not to fork the network, or be unscheduled, if the vote goes against you.)

If the feature upgrade has acceptance by 2/3 +1 (i.e. 15/21) active block producers as of the earliest effective date, then it will take effect. If it does not have acceptance by the earliest effective date, then the feature upgrade proposal fails and can be removed.

After the upgrade effective date, any block producer who has not set the flag that they are running compatible code will automatically be unscheduled from the producer queue effective at the time of the upgrade.

The feature upgrade changes do not take effect until the start of the first round consisting of producers with 100% support of the feature. This will likely be about 2 minutes after the "effective date" which gives a chance to update the active set of producers and to have it confirmed by the prior set of producers.

Checks for "feature upgrades" should be implemented on the chain_controller as "has_feature(X)"

Inspiration taken from Steem's implementation. This includes some one-time code executed at the time all producers support the change (eg, to reformat / recalculate data).

Nodes that do not have a defined implementation for a feature upgrade should voluntarily shutdown; they should have upgraded in time.

Note that upgrades are not "sequential" they are "feature" based.

(Also note that we should not be calling them "forks" they are "upgrades" that don't create forks.)

[blockone-syncclient]

➤ Corey Lederer commented:

This probably needs to become an epic with associated actionable tickets

[brianjohnson5972]

@wanderingbort or @heifner this is over a year old, I am guessing it is OBE based on the plethora of rewrites since then. Suggestions?

[brianjohnson5972]

The code has gone through many iterations of refactoring since this was written, so it no longer is relevant.