Feature upgrade

Hard fork feature upgrade process requires all participating nodes to be updated. This certainly requires a lot of coordination. As a result, client implementors regularly gathers together and decide on the next hard fork. A regular hard fork process contains the following steps:

Ethereum is currently adopting a new EIP-centric hard fork process.

Surprisingly, in Ethereum, a hard fork is usually decided on a date, then predice a block number, which then gets written into clients. This has created complications because block time varies, and thus it makes the block number hard to predict. A proposal to fix this is to use block’s timestamp as the factor for hard fork. However, the proposal received push-back from core developers, citing it may be over-engineering, and block timestamp might be gamed by miners.

For controversial features, the hard fork process had used signaling.

Soft fork is a feature upgrade process that does not require all nodes to be updated. This is done by making upgraded nodes execute on a more restrictive set of state transition function than non-upgraded nodes. As long as the upgraded nodes are the majority, new applied restrictions will be followed.

Soft fork usually must require signaling. We need majority of upgraded nodes before the soft fork features are applied, in order to ensure non-upgraded nodes follow the same chain head. What’s more, due to the turing-complete nature of EVM, many restrictions related to state (for example, blacklisting accounts) cannot be implemented as soft forks. Otherwise, denial of service attacks will be possible.

Signaling allows everyone who participate in the coin to vote on whether a particular feature upgrade should happen.