[R4R]support fork id in header; elegant upgrade #53
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.
BEP-89: Visual Fork of Binance Smart Chain
1. Summary
This BEP describes a proposal to enable the chain to display the whole view of validators that on different upcoming forks.
2. Abstract
The four bytes of
Header.Extra[28:32]
will be fulfilled withNEXT_FORK_HASH
. TheNEXT_FORK_HASH
indicates which fork the signer of this block is going to stay on. By analysingN
(N
is the amount of validators) continuous block headers, we are able to know which fork is supported by the majority of validators and exact which validator has not upgraded yet.3. Status
Draft.
4. Motivation
Binance Smart Chain will have some hard forks inevitably in the long run. Binance Smart Chain takes a risk of halt during hard fork once the validators can not reach a consensus. A validator could be slashed if it is not on the canonical fork which could be avoidable if the maintainer received alerts in time. A new protocol should be introduced to enable the chain to display the whole view of validators that on different upcoming forks. Any nodes/validators can decide to upgrade/fork or not accordingly.
5. Specification
5.1 Fork Hash
Fork Hash is introduced in EIP-2124. It is a mechanism that can let ethereum nodes precisely identify whether another node will be useful.
FORK_HASH
. IEEE CRC32 checksum ([4]byte) of the genesis hash and fork blocks numbers that already passed. E.g. Fork Hash for mainnet would be:forkhash₂ = 0x91d1f948 (DAO fork) = CRC32(<genesis-hash> || uint64(1150000) || uint64(1920000))
.FORK_NEXT
. Block number (uint64) of the next upcoming fork, or 0 if no next fork is known.NEXT_FORK_HASH
, whose algorithm is same withFORK_HASH
, butFORK_NEXT
will be included as well if it is not 0.5.2 Vanity
Format of
Header.Extra
:extraVanity
field is customized now, validator can use it to recordNEXT_FORK_HASH
of itself. TheNEXT_FORK_HASH
will only use the last 4 bytes ofextraVanity
.5.3 Clients
Header.Extra
withNEXT_FORK_HASH
during preparing block header.NEXT_FORK_HASH
is different from local.5.4 Backwards Compatibility
6. License
The content is licensed under CC0.