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 to enable protocol feature pre-activation #6431
An intrinsic meant to activate (really "pre-activate" using the nomenclature from #6429) a consensus protocol upgrade feature already exists:
The mechanism described in #6429 expects a 256-bit SHA256 digest to represent each consensus protocol upgrade feature. That allows using data-driven consensus protocol upgrades so that it becomes possible to specify a particular instance of some special classes of consensus protocol upgrades without actually modifying source code.
For example, one allowed class of data-driven consensus protocol upgrades would be to change the producer schedule to some specified schedule and advance finality to the block in which the consensus protocol upgrade feature was activated. This could allow the community to come to a social consensus regarding how to recover from a catastrophic and permanent failure of more than one-third of current block producers without needing to release a new version of the nodeos software. They would simply distribute a file (perhaps consisting of JSON) conforming to some specification which would describe the consensus protocol upgrade. The digest associated with that consensus protocol upgrade feature could be the SHA256 hash of the serialized form of that data (packed according to the specification).
The above example demonstrates the benefit of having 256 bits to the identify the feature. A light client that only processed block headers would stop if it encountered a digest in the block header for a consensus protocol upgrade feature that it did not understand. If it was a data-driven consensus protocol upgrade and the 256-bit identifier was simply the cryptographic hash of the data describing the consensus protocol upgrade, then the user of the light client could simply download the data describing the consensus protocol upgrade from any source without needing to trust that source as long as they did trust the block producers. If this data was describing a consensus protocol upgrade that was not of the built-in type, i.e. did not require special arbitrary code changes to support the consensus protocol upgrade, the light client could then continue forward without any code changes necessary.
Similarly, there is also an intrinsic,
Consensus protocol upgrade feature
The goal of this consensus protocol upgrade feature is to introduce two new intrinsics:
A new consensus protocol upgrade feature will be added to trigger the changes described in this consensus upgrade proposal. This feature will not require pre-activation because the mechanisms to enable pre-activation are introduced in this consensus protocol upgrade. The actual digest for the feature understood at the blockchain level is to be determined. For the purposes of this proposal the codename