EIP-1715: Generalized Version Bits Voting for Consensus Soft and Hard Forks #1715
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sorpaas
changed the title
|
It was my mistake, this probably wasn't proposed for Istanbul. |
|
@sorpaas you can also mark this "Abandoned", but since there were so many discussions about versioning I'd suggest we do merge this. |
adlerjohn
suggested changes
Aug 18, 2019
There was a problem hiding this comment.
I've made a number of change requests that fix formatting and change bits from one to two. This allows for more fine-grained signaling.
|
|
||
| ### Signaling bits | ||
|
|
||
| Ethereum's extraData field are 32-bytes, i.e. a 256-bit value. The field itself should be a RLP list that follows: |
There was a problem hiding this comment.
Suggested change
| Ethereum's extraData field are 32-bytes, i.e. a 256-bit value. The field itself should be a RLP list that follows: | |
| The [extraData](https://github.com/ethereum/wiki/wiki/Default-Extra-Data-Standard) field of Ethereum blocks is a 32-byte (_i.e._, 256-bit) value. The field itself should be a [RLP-encoded](https://github.com/ethereum/wiki/wiki/RLP) list in the following format: |
| Ethereum's extraData field are 32-bytes, i.e. a 256-bit value. The field itself should be a RLP list that follows: | ||
|
|
||
| ``` | ||
| [ version: P, signalingBits: S, clientIdentity: B ] |
There was a problem hiding this comment.
Suggested change
| [ version: P, signalingBits: S, clientIdentity: B ] | |
| [ version: P, signalingBits: S ] |
| [ version: P, signalingBits: S, clientIdentity: B ] | ||
| ``` | ||
|
|
||
| For this EIP, `version` should equal to `1`, and `signalingBits` and `clientIdentity` fulfill the rest of the extraData field as long as it does not exceed the maximum size allowed. This allows us to have way more concurrent signalings and better backward compatibility than Bitcoin. |
There was a problem hiding this comment.
Suggested change
| For this EIP, `version` should equal to `1`, and `signalingBits` and `clientIdentity` fulfill the rest of the extraData field as long as it does not exceed the maximum size allowed. This allows us to have way more concurrent signalings and better backward compatibility than Bitcoin. | |
| For this EIP, `version` should equal to `1`, with `signalingBits` filling the rest of the `extraData` field as long as it does not exceed the maximum size allowed (256 bits). This allows for more concurrent signalings and better backward compatibility than Bitcoin. |
| * **ACTIVE** for all blocks after the grace period conditions have been met. | ||
| * **FAILED** if past the timeout time and LOCKED_IN was not reached. | ||
|
|
||
| In accordance with BIP9, a block's state SHALL never depend on its own extraData; only on that of its ancestors. |
There was a problem hiding this comment.
Suggested change
| In accordance with BIP9, a block's state SHALL never depend on its own extraData; only on that of its ancestors. | |
| In accordance with BIP9, a block's state SHALL never depend on its own `extraData`; only on that of its ancestors. |
|
|
||
| **Best practices from Bitcoin**. [BIP-9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki), which uses version bits mined in each blocks to vote for consensus soft fork has be successfully conducted for several. Its upgraded version, BIP-135, aims to deal with both soft forks and hard forks alike. | ||
|
|
||
| **Potentially faster adoption of new consensus hard fork**. When dealing with emergency consensus hard fork for preventing network attacks, the developer would not need to artificially insert a "hard fork block number" (which must leave enough time for everyone else to upgrade their clients, and then wait for that block). The ETC coin holders and miners collectively decide when the hard fork happens, which potentially could be faster than hard coded block numbers. |
There was a problem hiding this comment.
Suggested change
| **Potentially faster adoption of new consensus hard fork**. When dealing with emergency consensus hard fork for preventing network attacks, the developer would not need to artificially insert a "hard fork block number" (which must leave enough time for everyone else to upgrade their clients, and then wait for that block). The ETC coin holders and miners collectively decide when the hard fork happens, which potentially could be faster than hard coded block numbers. | |
| **Potentially faster adoption of new consensus hard fork**. When dealing with emergency consensus hard fork for preventing network attacks, the developers would not need to artificially insert a "hard fork block number" (which must leave enough time for everyone else to upgrade their clients, and then wait for that block). Miners collectively decide when the hard fork happens, which could potentially be faster than hard coded block numbers. |
|
|
||
| ### Signaling guidelines | ||
|
|
||
| An implementation SHOULD signal '0' on a bit if one of the following holds true: |
There was a problem hiding this comment.
Suggested change
| An implementation SHOULD signal '0' on a bit if one of the following holds true: | |
| An implementation SHOULD signal `0b00` on appropriate bits if one of the following holds true: |
| * the deployment has succeeded (it has become ACTIVE) | ||
| * the deployment has FAILED | ||
|
|
||
| An implementation SHOULD enable the operator to choose (override) whether to signal '0' or '1' on a bit, once its deployment has at least reached the STARTED state. |
There was a problem hiding this comment.
Suggested change
| An implementation SHOULD enable the operator to choose (override) whether to signal '0' or '1' on a bit, once its deployment has at least reached the STARTED state. | |
| An implementation SHOULD enable the operator to choose (override) whether to signal on bits, once its deployment has at least reached the STARTED state. |
|
|
||
| An implementation SHOULD enable the operator to choose (override) whether to signal '0' or '1' on a bit, once its deployment has at least reached the STARTED state. | ||
|
|
||
| A supporting miner SHOULD signal '1' on a bit for which the deployment is LOCKED_IN state so that uptake is visible. However, this has no effect on consensus rules. Once LOCKED_IN, a deployment proceeds to ACTIVE solely based on the configured grace period parameters (see 'Fork deployment parameters' above). |
There was a problem hiding this comment.
Suggested change
| A supporting miner SHOULD signal '1' on a bit for which the deployment is LOCKED_IN state so that uptake is visible. However, this has no effect on consensus rules. Once LOCKED_IN, a deployment proceeds to ACTIVE solely based on the configured grace period parameters (see 'Fork deployment parameters' above). | |
| A supporting miner SHOULD signal `0b11` on bits for which the deployment is LOCKED_IN state so that uptake is visible. However, this has no effect on consensus rules. Once LOCKED_IN, a deployment proceeds to ACTIVE solely based on the configured grace period parameters (see 'Fork deployment parameters' above). |
|
|
||
| A miner SHOULD signal '0' on a bit if they wish to suspend signaling of support for a fork that is DEFINED in their software. | ||
|
|
||
| It is NOT RECOMMENDED to signal '1' for bits where the meaning is undefined (i.e. bits which are unclaimed by proposals). |
There was a problem hiding this comment.
Suggested change
| It is NOT RECOMMENDED to signal '1' for bits where the meaning is undefined (i.e. bits which are unclaimed by proposals). | |
| It is NOT RECOMMENDED to signal non-zero for bits where the meaning is undefined (_i.e._, bits which are unclaimed by proposals). |
|
|
||
| A supporting miner SHOULD signal '1' on a bit for which the deployment is LOCKED_IN state so that uptake is visible. However, this has no effect on consensus rules. Once LOCKED_IN, a deployment proceeds to ACTIVE solely based on the configured grace period parameters (see 'Fork deployment parameters' above). | ||
|
|
||
| A miner SHOULD signal '0' on a bit if they wish to suspend signaling of support for a fork that is DEFINED in their software. |
There was a problem hiding this comment.
Suggested change
| A miner SHOULD signal '0' on a bit if they wish to suspend signaling of support for a fork that is DEFINED in their software. | |
| A miner SHOULD signal `0b00` on bits if they wish to suspend signaling of support for a fork that is DEFINED in their software. |
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was originally submitted as an ECIP (ethereumproject/ECIPs#62) back in 2017. I just saw this Ethereum Magicians (https://ethereum-magicians.org/t/will-we-need-an-eip-to-allow-hashpower-signaling-and-node-operator-signaling/1045/2) thread, in which the Ethereum community also seems to be willing to discuss solutions to hashpower signalings. So submitted an EIP here just in case it's useful.