Config computation in Lighthouse

Good news - the computations of genesis time and ids seem to be working! I created some basic Ephemery infrastructure, took a few different approaches and finally decided on a way to include all the checks and changes into the client as seamlessly as possible, since these are changes that need to happen in the core of the client functionality. The client now loads the genesis 0 files, that are included as any other network, tweaks the important values once the environment is loaded and purges the database if the iteration has been changed, otherwise keeps the database if it already exists. For now it seems I was successful, but I still need to run some Lighthouse tests and most importantly, the functionality once the genesis switches to a new one. For now, the logs seem consistent with the logs that I get with the manual run.

Start of the Network with the config computation.

Comparison of the beacon explorer and the corresponding log.

Genesis state approach

With the new testnet Holesky, clients approached the problems with its large ssz state by adding the possibility of downloading the genesis from a url at runtime. This functionality has currently three limitations, as implemented in Lighthouse:

1. Checksum check - after the genesis is downloaded, its hash is computed and compared with a fixed checksum that is baked in the code.
2. Genesis validators root - to check if the genesis and all the other configuration is correct, the genesis validators root value, also fixed and baked in the code (in the case of downloading the genesis), is used.
3. Server with beacon node API - the url has to lead to a server that runs the node and provides the RESTful API.

I tried to make the checksum and genesis validators root checks optional, which is definitely not a long-term solution - that would be creating the ssz in the code and subsequently computing these values, which could be then used instead of the fixed ones. But since this computation has to be done anyways, it does not make much sense to even download the genesis, except maybe to check if the computation really was correct. Another problem, probably the most important one, is the need for a server. Unlike some other clients, Lighthouse does not accept a .ssz file link, and I do not feel comfortable reworking the whole implementation, that would definitely have to be discussed with the Lighthouse team and the problems with checks would stay anyways. Therefore, since Lighthouse already offers some ssz functionality, I decided to try and take this approach, especially since there would need to be at least two servers by reliable providers long-term and that could get expensive (currently there is just https://checkpointz.bordel.wtf/ as far as I know, which runs on a server that is not strong enough for this job).

EIP

I noticed some inconsistencies in how genesis time is called in the EIP, there were also some other incorrect terms used sometimes that could confuse future Ephemery team contributors, so we discussed these and decided on some changes (1, possibly 2). The EIP has a number now and is moving to the review phase, so hopefully it'll go well!

Plans

Now I'm moving to the implementation of config changes in Reth to make the pair functional. During or after that I'm also going to look into which functionality Lighthouse offers right now regarding the ssz and how to use these for the in-client genesis generation. I've also saved a few points in the code that I've seen that may possibly help with reset implementation later after EPF, but that is the last nice-to-have thing in the process.