-
Notifications
You must be signed in to change notification settings - Fork 36
Update Mechanisms
Originally from this GitHub discussion
The rules change at a given block (arbitrarily, you can in theory even change the whole state), but the history & the historical state remains. You retain the ability to execute old forks (i.e. changes are an if in the code that depend on the block number).
Hard forks are historically opposed to "soft fork" where nodes implement a new behaviour compatible with the old behaviour. This is not the distinction we're aiming at here.
Just like hard fork but while you retain the old blocks (they are still there in Geth’s database), you lose the ability to re-execute them (i.e. the old behaviour is now longer part of the node’s code). Basically just initializing Geth with a DB that's already full of blocks.
As the name implies, it’s a new genesis, so no historical blocks are retained, and the old behaviour is no longer part of the node’s code. This option can be interesting if you wanted to completely change/transform the state when you change the rules, which can be painful to encode in the node’s logic.
Discussions on the topic are ongoing, but there is a strong consensus that we do not want another re-genesis (like we did for the EVM equivalence update).
Contrasting hard forks and squash forks:
- A hard fork makes the code bigger and more complex as the legacy behaviour can't be removed, only gated by conditions on the current block number
- This goes against one of our design objectives, which is to minimize the diff between L2 geth and L1 geth. (*)
- A squash fork loses the ability to execute historical blocks, which means a trusted state snapshot for the start of the squash fork needs to be provided.
(*) This is valuable because we want to update L2 geth to integrate L1 geth changes, to remain as close to mainnet behaviour as possible. This is further amplified by the fact that our new fault proof system will compile L2 geth to bytecode that will be executable on-chain.
Squash forks are currently considered to be the privileged option.