Big release and renaming of Erigon 2.2 & 2.3 into Erigon 3 & 4

Shortly before or after publication of this article, we are also publishing a new release, 2022.10.01, which contains a lot of fixes and improvements, specifically to the handing of Engine API messages (communication with CL - Consensus Layer).

Here are the draft release notes:

In particular, the logging output should now be less confusing.

In the previous release there was an unfortunate flaw that meant that the block snapshot generation was no longer going on, and therefore the blocks would accumulate in MDBX without being converted into snapshots files and cleaned up from the MBDX. The newest release fixes it.

For some users who previously ran one of the flawed version in devel branch (that flaw never got to the released versions), there would be automatic database migration performed, to re-alight the transaction enumeration. When this migration is performed, the block headers and block bodies are truncated up the most recent snapshot, and re-downloaded again, to be inserted with properly aligned numbering.

In the next release, we will update the BitTorrent info hashes for the new block snapshots (doing it now may cause problems with downloading them, as most of the node would not have them generated and not able to seed).

Renaming

To simplify the communication about the planned incompatible upgrades of Erigon, described in the previous post, we decided to rename these upgrades.

From now on, we will call the currently released version Erigon 2 (instead of Erigon 2.1). Since it required full re-sync to go from Erigon 1, it makes sense.

What we previously called Erigon 2.2, will now be called Erigon 3. This upgrade introduces new way of storing and distributing history, as well as increased granularity of history. As mentioned before, it is currently being integrated into the code base. Upgrade from Erigon 2 to Erigon 3 will require full resync, as database layouts are incompatible.

What we previously called Erigon 2.3, will now be called Erigon 4. It introduces new way of storing and distributing state and state commitment. As mentioned before, it is currently being prototyped. Upgrade from Erigon 3 to Erigon 4 will require full resync, though we expect this to be much quicker than before (that is one of the objectives of Erigon 4 after all, to make full resync quicker).

Release versioning

We are also planning to move from calendar-based versioning of our releases to semantic versioning, using 2, 3, and 4 as major versions. This will enable us to ensure smother transition from Erigon 2 to Erigon 3 supporting both versions for some time, allowing users to migrate. However, this will be done a bit later, so not to do all the changes at once.