Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Consensus protocol upgrade activation mechanism #6429
This issue tracks the code changes needed to facilitate consensus protocol upgrades.
Signaling consensus protocol upgrade features
Consensus protocol upgrade changes are associated with a feature (called a "consensus protocol upgrade feature") recognized by nodeos. Each feature will have an associated 256-bit digest that uniquely identifies it. There are two classes of consensus protocol upgrade features: those that require pre-activation via an intrinsic and those that do not.
A consensus protocol upgrade feature is activated by signaling its activation in the block header through a new block header extension type called the "protocol feature activation" extension. This extension type (which will be discussed in more detail below), includes the 256-bit digests of consensus protocol upgrade features to be activated at the start of that block.
There are constraints on whether a consensus protocol upgrade feature (of either class) can be activated:
Furthermore, a consensus protocol upgrade feature of the class that requires pre-activation has further requirements:
Most consensus protocol upgrade features will likely be of the type that require pre-activation. Consensus protocol upgrade features that do not require pre-activation have the characteristic that any one of the active block producers can initiate the activation of the feature. The other block producers could still ignore that block if they were not ready to accept activation of the feature, but that is a subjective producer policy decision that would have to be coded into the nodeos software that the block producer was running. One type of subjective policy decision that will be formalized as part of this mechanism, however, is to optionally reject activation of features if they occur before a locally specified time known as the "earliest allowed activation time".
Having a type of consensus protocol upgrade feature that requires pre-activation allows the subjective policy decision by each producer to be replaced by an objective policy that runs on the blockchain. A system contract action with strict authorization requirements can use a special intrinsic to pre-activate the feature; and block producers can use, for example, the
However, there is still an important use case for consensus protocol upgrade features that do not require pre-activation. For example, if the community needs to execute a consensus protocol upgrade to change the producer schedule in a situation in which all producers are down and for some reason will not be coming back up, it should be possible for nodes that understand that consensus protocol upgrade feature to accept a block produced by a producer outside of the current producer schedule as long as the block activates the feature and the producer is the appropriately scheduled producer for the given time slot under the new producer schedule. It would not be possible to pre-activate such a consensus protocol upgrade feature in the scenario when all producers are down since no blocks would be produced to execute the action that calls the pre-activation intrinsic.
"Protocol feature activation" block header extension type
This new mechanism also introduces a "protocol feature activation" extension type within block header extensions.
Currently, no extensions are allowed in the block header. This change would allow a single block extension as long as it follows the rules of a well-formed "protocol feature activation".
For a "protocol feature activation" extension to be well-formed it must have a
If further extension types are added in the future, the following constraints should still apply: at most one well-formed "protocol feature activation" extension is allowed in the vector of block extensions, and if a "protocol feature activation" extension is present, it should be the first item in the vector of extensions.
Note that the "activation set" will actually be stored in the
Pre-activating consensus protocol upgrade features
Some consensus protocol upgrade features will require pre-activation and some will not. Either way, it is possible to pre-activate a feature assuming the following conditions hold:
If a feature is successfully pre-activated (this would be initiated by a special privileged intrinsic), then its associated 256-bit digest is added to the end of the "pre-activation sequence".
Activating consensus protocol upgrade features
When computing the next
If this is computing the next
At the start of a block, prior to executing the
Regardless of what vector was passed into the
The producer plugin would need to be modified to pass a vector of feature digests consisting of at least the digests (in order) of the "pre-activation sequence", otherwise it would not be able to start a new block after pre-activation of a feature. However, the producer plugin would be free to add additional digests of consensus protocol upgrade features to the beginning of this vector in order to activate consensus protocol upgrade features that do not require pre-activation and that were not already pre-activated. The set of digests to add would be determined from RPC calls made through the
Checking if a feature is activated
An internal function is necessary to check if a particular feature (identified by digest) is in the "activation set". This function is mostly intended to be used by the native blockchain logic to adjust behavior according to whether a particular consensus protocol upgrade feature has been activated or not. It would also be used to implement a new intrinsic which allows contracts to query whether a feature has been activated or not.