# Native Ephemery Genesis in Ethereum Clients

### **Progress**

**Initial project proposal**

Ephemery is a short-lived testnet. The ephemery team is focused on integrating this new-ish network into existing clients and infrastructure.

The periodic resetting of the test network effectively erases the onchain activity that occured during that iteration. This reduces the impact of accumulated network bloat, seen with other testnets, and results in lower resource requirements for testnet users (also conveniently lowering the barrier to entry for running the testnet in the first place).

In particular, the reset feature optimises for short-term validator testing, reducing the burden on longer-running testnets.

Earlier in the programme, I described my intention for the cohort in my [Project Proposal](https://github.com/eth-protocol-fellows/cohort-four/blob/master/projects/native-ephemery-genesis.md): writing client-side integrations for the ephemeral testnet and validating the draft EIP as part of the ephemery team, beginning with Lodestar.

**Status**
- Having joined the matrix chat, I was able to dive into the open ephemery tasks with the ephemery team. My initial exploration of ephemery focused on manual setup and understanding command-line code. After some time, I was able to run ephemery locally with geth-lodestar, and [contribute](https://github.com/ephemery-testnet/ephemery-scripts/pull/10) to the ephemery manual documentation
- pk910 helpfully provided an update on Lodestar and I created a [first Lodestar issue](https://github.com/ChainSafe/lodestar/issues/6050) to open discussion about adding the ephemery network config, genesis and reset functionality
- My [PR](https://github.com/ChainSafe/lodestar/pull/6054) to add the `ephemery` network was merged to Lodestar and released in [v1.12.0](https://github.com/ChainSafe/lodestar/releases/tag/v1.12.0)
- Following discussion with Chainsafe, I opened a [second Lodestar issue](https://github.com/ChainSafe/lodestar/issues/6064) to open a meta-discussion to align on the preferred default behaviour related to checkpoint sync.
- For Lodestar, a genesis state (`genesis.ssz` file) is generated when starting Lodestar in dev mode, and this can be done completely offline as there is no data required like a list of genesis validators. For other networks, the genesis state is not generated, it is:
- initialized from database if it exists,
- downloaded from `checkpointSyncUrl` if set
- or, if not set and no database state, then the state is downloaded from the `genesisFileUrl` defined in network settings or taken from a `--genesisStateFile` if provided by the user
- Earlier in my dev updates I explored the idea of adding an `ephemery` package to Lodestar, to calculate the genesis state from scratch. This is not strictly required, however, since downloading the genesis state from external source is implemented (accepted) for all other networks already. It may provide a useful additional option for [dev] users in the future
- I plan to continue to integrate ephemery into other clients, and I am now following up on pk910's draft work on the [geth](https://github.com/ethereum/go-ethereum) EL client
- My discussions have also created further awareness in client team around the concept of reset. I've been able, in collaboration with Adedamola, to explore the possibilities and constraints for including a native reset mechanism in Lodestar. We understand that it is first important to consider reset via external tooling
- Work on Lodestar has enabled me to validate the [EIP](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6916.md) - now at review stage - to some extent, and propose wording amendments. This validation is ongoing, as more clients are investigated for compatibility with ephemery

**Summary**

In summary, I met my main goal for the programme and commenced work in a number of "stretch" areas. Work on ephemery configs has provided me with an opportunity to familiarise myself with the workings of Ethereum clients, as well as some of the external infrastructure that is used to manage the networks.

The current status of native ephemery integrations, taking into account work from across the ephemery team, is shown in table 1 below.

***Table 1***

### **Next steps**

**Project tasks**
- Add the ephemery network to more client-pairs
- Discussion continues regarding possible improvements to the ephemery specs. For example, it may be beneficial for clients to derive or download the ephemery checksum for comparison, depending on which approach is utilised for obtaining genesis state
- Expand external infrastructure
- Progress EIP

### **Reflections**

**Challenges**
As I set out in my Project Proposal, I expected certain challenges relating to OS and client prerequisites.

In practice, the main challenge I encountered was the steep learning curve, as well as time needed for deep focus work and study; in particular for focusing on Ethereum fundamentals. It took more time than expected to familiarise myself with client implementations, circle back to Ethereum specs, and slowly develop my understanding.

In addition, the ephemery network needs to be added to all clients, requiring - over a longer time period - a reasonable understanding of multiple languages and frameworks.

***Summary of actual challenges***
💻 Mac OS had some impact on manual configuration options for Geth-Lodestar
🕰️ Time taken to understand Ethereum specs
🥷 Wider learning about ssz serialization
🤔 Understanding client codebase from scratch
👽 Evolving client codebase
🖋️ Updates to specs

**Learnings**

I enjoy a steep learning curve, but at times it was hard not to find certain aspects overwhelming - especially at the beginning of the cohort. I take several learnings from my experience:
1. The learning is process is iterative and time-consuming, since client codebases and project specs are constantly evolving. No one knows everything about everything all at the same time. (The AMAs were particularly useful for me as we got to hear from several core devs who experience this as well.)
2. It's worth taking the time to do a deep-dive into Ethereum specs early on in the programme. I found [ethereum.org](https://ethereum.org/en/developers/docs/) provided an excellent intro to various topics, and the [Eth2.0 book](https://eth2book.info/) is a nice resource for moving towards a deeper understanding of how the protocol works.
3. The connections provided by the EPF team are valuable, and helped to reduce the barrier to entry to real dev work. I found the client teams and ephemery mentors to be thorough and supportive during the programme.

**EPF**

I'm grateful to Mario and Josh for their support during the cohort: I feel that the cohort has given me confidence to expand my Ethereum contributions as a core dev. The visibility provided by the fellowship structure definitely helped me with wider context and understanding of Ethereum development processes.

I'd say the fellowship helps devs to:
- Know *where* to start
- Gain *confidence* as a member of the community
- *Validate* project concepts
- Figure out *how* to start
- Connect with mentors who can provide *feedback*
- Work according to a rough *timeline*
- Deliver *meaningful contributions*

In future, it may be useful in the first few weeks of the cohort for participants to have access to more resources / presentations on some of the foundational aspects of Ethereum.

I intend to continue my work on the ephemery project and expand in time to more core dev contributions.