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

[R4R]support fork id in header; elegant upgrade #53

Merged
merged 2 commits into from
Jan 11, 2021
Merged

Conversation

unclezoro
Copy link
Collaborator

@unclezoro unclezoro commented Dec 8, 2020

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 with NEXT_FORK_HASH. The NEXT_FORK_HASH indicates which fork the signer of this block is going to stay on. By analysing N (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 with FORK_HASH, but FORK_NEXT will be included as well if it is not 0.

5.2 Vanity

Format of Header.Extra:

|   32 bytes       |       20 * N bytes      |   65 bytes     |
|   extraVanity    |   validatorSetBytes     |   extraSeal    |

extraVanity field is customized now, validator can use it to record NEXT_FORK_HASH of itself. The NEXT_FORK_HASH will only use the last 4 bytes of extraVanity.

5.3 Clients

  • For validator. It will fill in Header.Extra with NEXT_FORK_HASH during preparing block header.
  • For witness. It will log a warning message if the majority NEXT_FORK_HASH is different from local.
  • For light client. No impact.

5.4 Backwards Compatibility

  • This BEP itself is not a hardfork one, it breaks nothing of consensus.
  • Downstream service is completely compatible with this BEP.

6. License

The content is licensed under CC0.

@unclezoro unclezoro changed the title [WIP]support fork id in header; elegant upgrade [R4R]support fork id in header; elegant upgrade Dec 8, 2020
return cpy
}

func (s *Snapshot) isMajorityFork(header *types.Header, forkHash string) bool {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

header *types.Header seems useless here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed.

yutianwu
yutianwu previously approved these changes Jan 11, 2021
ally++
}
}
return ally > len(s.RecentForkHashes)/2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to ensure if the length of s.RecentForkHashes is closed to the length of current validatorset?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated.

@unclezoro unclezoro merged commit 9fedf19 into master Jan 11, 2021
@unclezoro unclezoro deleted the elegant_upgrade branch January 18, 2021 12:26
@unclezoro unclezoro mentioned this pull request Jan 19, 2021
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants