Erigon alpha release 2022.04.02-alpha

Apr 21, 2022

This is the first release of Erigon that contains the code required for transition to POS (Proof Of Stake) via cooperation with one of the CL (Consensus Layer) implementations. It also contains the first upgrade of Erigon 2, as described in the previous post:

Erigon Blog

Erigon 2 - three upgrades

Two flavours of Erigon - going back to Alpha Presently, Erigon is available for the users in two main “flavours”: Beta releases - these have been published roughly every week, but sometimes less frequently. Main objective of these releases has been to stabilise the code (by fixing issues) while continuing adding missing features. It is assumed that subseq…

a year ago · 2 likes · Alex Sharp

This is the TAG.

Main things to know about this release:

You CANNOT upgrade your existing Erigon database that was built by one of the previous beta releases. You need to sync from scratch.
Currently, to build this alpha code, go 1.18 is required. We have a workaround for 1.17, but it is not in this version.
If you are a “casual user”, you do not need to run RPC daemon in a separate process. Instead, you can use the embedded RPC daemon, which is on by default (can be turned off by http false command line flag).
BitTorrent protocol gets involved to download most of the headers and blocks (turned on by default for Ethereum main net, Görli testnet and BSC main net). By default, download rate limit is 8mb/s, and upload rate limit is 4mb/s. These limits can be changed by command line flags torrent.download.rate and torrent.upload.rate. In the current code, BitTorrent DHT is not used. Some number of seeders have been bootstrapped for Ethereum mainnet (in progress for BSC mainnet), but the more nodes join the network, the quicker the download will be for everyone else.
For BitTorrent download to work, port 42069 needs to be open for both TCP and UDP.
BSC mainnet works on this release, but not yet Bor (Polygon).

Plan for further releases

Further releases may become more confusing, at least for some time. Here is an attempt to explain:

Up to now, we were using stable branch to publish beta releases. Out of all PRs made to the devel branch (where most of the current development happens), only some are cherry-picked into stable. These are bug fixes and missing features. This allowed us to keep developing the support for “The merge” as well as Erigon 2 without affecting Erigon users who required relative stability of the beta.

Now we are creating alpha branch, which is going to be used to publish alpha releases. Our intent, similarly to the stable branch, to only cherry-pick into alpha branch bug fixes, missing features (mostly for the POS transition) and substantial optimisations (for example, we know that current version required 6Gb in the heap for Huffman decoding tables, a side effect of an optimisation, and we may make a change to move these 6Gb out of the heap into the virtual memory). At some point before the POS transition we will discontinue what currently is called “Beta” and the current “Alpha” will become de-facto beta.

What will happen after that with the various branches and releases is not clear yet, but the plans will be published as soon as they solidify. Our current goal is to help Erigon users to:

Experience the POS transition functionality and the first part of Erigon 2 (blockchain snapshots).
Gradually migrate their infrastructure before the POS transition, flagging up any issues so they can be fixed.