Insight: Hard Fork vs Squash Fork vs Re-Genesis

[norswap]

Preserving here a discussion we had about the definitions of these things, which are not entirely obvious:

• Hard Fork — 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).
  • (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.)
• Squash Fork — Just like hard fork but while you retain the old blocks (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.
• Re-Genesis — 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.

[karlfloersch]

Context for why we are defining these terms is that we are determining how future upgrades (specifically the upgrade to v1.0) will be performed. Right now I are most bullish about:

1. Upgrading to v1.0 via a squash fork.
2. Depending on user demand, add the ability to process pre-fork blocks in an archive client.

The benefit of this approach is that we are able to minimize our diff from Geth in v1.0 (design goal for v1.0 is to be upstreamable) but also stay flexible enough to re-introduce full syncing. Note that the logic we need to implement a squash fork in Geth is already being proposed in EIP4444

---

Meta note - @norswap what do you think about changing this discussion to be a thread discussing how we perform our v1.0 upgrade? Alternatively I can start a new discussion for that topic. I recognize that upgrades could be considered 'implementation specific' but I think there's value in having a 'recommended upgrade path' included in the spec.

[norswap]

Both are fine. I've been using discussions as a sort of wiki to build shared knowledge that does not necessarily belong in the spec (or not yet) but it's not the ideal vehicle for that.

[karlfloersch]

Ok then I think we should just convert this issue into a pointed upgrade-to-1.0 discussion.

[norswap]

ported to wiki page: https://github.com/ethereum-optimism/optimistic-specs/wiki/Update-Mechanisms

[mslipper]

We've decided to go for the daisy chain implementation described here: #242. This lets us initialize the bedrock chain at the height of our choosing, while retaining the ability to execute and query historical data.