Consensus protocol upgrade to enable protocol feature pre-activation

[arhag]

Background

An intrinsic meant to activate (really "pre-activate" using the nomenclature from #6429) a consensus protocol upgrade feature already exists: activate_feature. However, that intrinsic takes a int64_t argument.

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, is_feature_active, meant to check if a particular consensus protocol upgrade feature already exists. However, it again expects a int64_t argument. Furthermore, this intrinsic is only accessible to privileged contracts, limiting its usefulness, when there is no security reason for this.

Consensus protocol upgrade feature

The goal of this consensus protocol upgrade feature is to introduce two new intrinsics: preactivate_feature and is_feature_activated. The first is a privileged intrinsic which allows a privileged smart contract, e.g. the system contract, to pre-activate (see #6429) a consensus protocol upgrade feature by supplying its 256-bit digest. The second is an intrinsic accessible to all contracts which takes a 256-bit digest and returns true if and only if the digest is found in the "activation set" (see #6429).

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 PREACTIVATE_FEATURE will be use to stand-in for whatever the feature identifier will actually end up being.

[arhag]

This issue depends on #6429 and #6437.

[arhag]

Resolved by #6831.