Create hardfork meta config flags

[5chdn]

For:

• byzantiumTransition
• constantinopleTransition

To simplify the configuration. Duplicate or conflicting transitions should throw a meaningful error, i.e., both constantinopleTransition and eip1283Transition specified.

Stand-alone flags like eip1283Transition should be still available for networks that don't want all of the transitions, i.e., there is no EIP-1234 on Kovan.

[5chdn]

Related to #9972

[sorpaas]

(Repost from another discussion.)

From a pure engineering perspective though, it can break guarantees that a certain transition only means one thing. This is not black and white and we have already broken it before, but I would hope we make the chances as small as possible. Giving a hypothetical example that what grouped transition might break:

1. When Metropolis hard fork comes out, it's planned to include EIP-A, EIP-B, and EIP-C. We then activate those three via grouped transition metropolisTransition on Kovan and some other custom PoA networks.
2. It's then decided that we want to remove EIP-B from the hard fork, and add an additional EIP-D. Apparently we'll need to change metropolisTransition to use this new meaning, but at this time, if any custom chain forgets to update its config, it will break (even though it passes chainspec tests).

My suggestion for dealing with chainspec would be:

1. Add deny_unknown_fields to deserializer! In this way, a newer chainspec cannot be accidentally used in an older parity-ethereum version. If any transition is deprecated/removed, we also ensure that an older chainspec that contains those won't accidentally be loaded on newer parity-ethereum version.
2. Create a "reduced" format that doesn't have eipXXXTransitionfields, but byzantiumTransition, constantinopleTransition, and a config generator that generates chainspec from the "reduced" format.

Geth's approach on chainspec is just to always group mainnet hard fork changes together. So you won't find individual EIP numbers there. This certainly makes configuration easier (and the engineering cost is the same as us). However, the apparent drawback is that you cannot support other networks.

[ghost]

Comment from @karalabe

ethereum/go-ethereum#17675 (comment)

While in general that's not a bad idea, within Geth we kind of always focused on the Ethereum use case and tried to avoid making everything too abstract/flexible. There have been multiple consensus issues in Parity caused by EIPs getting accidentally activated due to their flexible architecture, as well as configuring a Parity node is a nightmare that can lately only be done via custom tooling. Our code mostly assumes that Ethereum hard forks come in progression one after the other and this keeps everything a lot simpler. I of course understand that this puts a bit more burden on teams creating Ethereum forks, but at the end of the day why should the go-ethereum maintainers pay the price of running derivatives based on our code? :)

😂

[adria0]

Closing issue due to its stale state.