Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consensus protocol upgrade to enable protocol feature pre-activation #6431

Closed
arhag opened this issue Dec 4, 2018 · 2 comments

Comments

Projects
None yet
1 participant
@arhag
Copy link
Contributor

commented Dec 4, 2018

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 comment has been minimized.

Copy link
Contributor Author

commented Feb 13, 2019

This issue depends on #6429 and #6437.

@arhag

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

Resolved by #6831.

@arhag arhag closed this Mar 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.