Ephemery Genesis Implementation in Lighthouse and Reth - Final EPF Update Project summary Ephemery is a testnet that brings a whole new concept, solving many problems that arise with the traditional testnets, such as Goerli or Sepolia. With Ephemery, instead of the network running for several years similarly to mainnet, it gets completely restarted after a set period of time. This process includes the genesis function, which automatically generates all the important genesis information after the client is launched, and the restart function, which ensures that the client gets reset and the previous values get replaced with new values with every new iteration. My contribution to EPF was mainly the implementation of the genesis function in a pair of clients - Lighthouse and Reth. This would allow for users to easily run the clients with Ephemery built-in and get their network set up and running without having to manually set any values regarding the network genesis configuration. Status report Lighthouse PR (WIP) Reth PR (WIP) ✅ Lighthouse - automatic network config generation and basic genesis state download. ✅ Reth - automatic network config generation.

The last update! I can't believe how quickly has the time with EF passed - it feels like a few weeks tops! I'm very grateful I was able to participate in the fellowship, I've learned a lot in that relatively short time, I found stuff I would love to continue doing in the future, I've met new people, with the help of EF I'll be attending another Devconnect after the one in Amsterdam (that I absolutely loved) and I have my name on an EIP - that's some bucket list material! I'll keep it short, sice I'll recapitulate my epf time in the final update, so just shortly - to everyone who made this possible, thank you so much! Genesis state - download, checkpoint sync, generation? The last part of the fellowship was slower for me, as I got busy with university. In the time that I had, I've been investigating even closer how the code around genesis state acquirement works. The main part seems to be separated to two parts - the first one works with state in the more general point of view, it takes information from storage if possible, provides functionality like checkpoint sync if specified by the user using an option, and others. The other part is the genesis state acquirement itself - the state can be included in the binary or, like in the case of Holesky, downloaded using a url to a server supporting Beacon API. The url download option checks the downloaded genesis using ssz file checksum and genesis validators root. There are new additions to the Ephemery EIP, checkpoint sync functionality should now be utilized by default, and the genesis state should be downloaded from another source if the checkpoint is not available. There are two problems that are in need of solutions right now in Lighthouse, if we want to use these tools for Ephemery: Checkpoint sync is only supported when specified by the user using the "checkpoint-sync-url" option at this point, not for known networks - these download the genesis state using a url speified in the code. This requires some more changes of the core functionality code. As the code is written right now, the genesis state is downloaded and checked against the checksum and the genesis validators root even with the checkpoint sync functionality. This is problematic, because these values are constants set in the code and for Ephemery, they vary with each iteration.

Config computation in Reth In the last week's update, I was talking about network config computation. I managed to implement this now in Reth, which, as an execution client, only needs this config to work, so outside of some testing and code clean-up, Ephemery in Reth seems to be working: PR. Lighthouse genesis state I looked into the state generation tool that is used by the Ephemery genesis build script. With the knowledge about the proccess, I looked into how the genesis state and the tooling around it looks like in Lighthouse. I found some functions that could help me with creating a new BeaconState according to some information about the Eth1 block and the execution payload header. These structures would still need to be created, filled with information that is fixed or given in the genesis.json file, and also manually filled with the validators, which need to be in a special format according to Lighthouse and ssz specs. This seems doable, but could still take some time, so I'm going to start working on it and see how much time it takes. There still is the option to temporarily run my own node and download the genesis information from there or to download the ssz from github releases, but both of these would require to quite significantly change the download function or to create another one, so I would prefer to spend the time trying to implement the generation functionality first. Lighthouse and Reth syncing demo Both Lighthouse and Reth can be launched using the "ephemery" option. Basic information about the current iteration is logged for the user.

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 Ephemery network implemented in Lighthouse. Start of the Network with the config computation. The node has been synced. Comparison of the beacon explorer and the corresponding log.

Deep dive into the code - working with the network configuration The main focus during the last two weeks was exploring how exactly Lighthouse processes and further works with the configuration data. My goal is to integrate the concept of Ephemery into the process as seamlessly as possible without rewriting any code that already exists or changing the little tasks that need to be performed in the process of setting Ephemery up and have already been extensively thought out and programmed. There is quite a complex process regarding this part of the code, partly because the clients are written in Rust, which is a compiled language and there is not a lot of space for working with the files directly. I already have some overview about what happens where in the code, so now I started with looking into the codebase even more in depth and I started with the new functionality that came with Holesky implementation - the possibility of downloading the genesis state from a server. I looked into how this downloaded state is stored and that led me to the specific structures, what happens with them when the network is launched for the first time opposed to when the network is launched again, the database already exists and the storage already has some configuration loaded (that we need to check and possibly change after each launch of Ephemery in this case). The goal now is to find the right place where to dive into this storage that contains our genesis and configs, without "reinventing the wheel" in the process. All this exploration caused me to have to go back to the genesis :) with a few ideas about how things work and should work, but now I'm pretty confident that I'm hopefully quite close to some progress in integrating the changes while respecting the already existing infrastructure.

There's the next update, and it's late and also combined, exactly as I didn't want it to be! It's also going to be quite short and brief in general, because there was a family/health emergency and I've tried to do my best in the circumstances (EF, if you read this, feel free to lower my payment this time please, because the last few days have been hospitals and scrambled eggs type of brain). Anyways, I tried to pinpoint at least some of the stuff I've been looking into, and back on track as of today! Project proposal presentation I did my presentation in the last session and I feel like it helped me quite a lot. I tried to keep it simple even for people who do not know anything about testnets and how they're represented when you try to use them, so I chose to leave out a lot of details that others can read in my proposal or in the EIP draft. I feel like the presentation went well and hopefully I was able to give everyone a general idea about what's needed for the genesis function to work. Lighthouse code, experimenting I've been going through the Lighthouse code further to see how they solve things in the testnets area. I've been changing stuff, adding stuff, breaking it and fixing it again, in general getting the feel of what's it like to work with big Rust projects in general. Now I'm going to at least make the "easy" park work and then I'll contact a mentor from Lighthouse to discuss how to best incorporate the new code - where to best place it to make it easier for the future contributors, and also how the testing should look like in this case. For now, I'm looking mainly at the reference genesis build implementation and the genesis state creator to see what to do. Also, I'm really looking forward to the next office hours with Michael Sproul, hopefully I'll be able to attend live! Extending the tasks in the issues I extended the tasks in the Lighthouse issue to make them smaller. I'm planning to create a PR now to share the code in the individual phases and tick off some of the first boxes that are ready. I'm also doing the same thing for Reth later.

Instructions for manual node setup Last week, I created Lighthouse&Reth manual node setup instructions. I've tried following the existing instructions before, but these clients have to be launched in a different way than the already tested Teku&Geth. I went through the documantations, the built-in help of clients and also through code, because I did not understand some of the options and had to investigate some of the functionality directly, the code is luckily often described in comments. This research helped me to understand even better what are the inputs and the outputs of clients and how everything works under the hood. The PR included the new instructions and also some small fixes that hopefully made the other two existing instructions a bit clearer. EIP specification reading With the newly gained knowledge, I decided to go through the EIP specs once again. This time, I understand what I'm actually trying to do a bit more and can visualize how can the whole process of genesis generation look. I've been working on a "mindmap" that helps me in sorting out the thoughts before starting with the implementation. Lighthouse testnet code This week, Lighthouse released a new version that includes the Holesky testnet implementation. I've been going through the changed code, which helped me understand where the code for the included testnets is and how it looks like. I've been referencing to the Rust By Example documentation, which helps me to understand some of the more complex or unusual code, as I still am a Rust beginner. For now, I figured out that some of the most relevant folders for the genesis implementation would be common/eth2_config and common/eth2_network_config, so I will start with these and figure out the rest in the process. Predefined networks

This time I have a combined update for weeks 5 & 6. I've been mainly going through the Lighthouse code and docs, figuring out the implementation, which I'm going to try and slowly start on right now after the update, starting with adding Ephemery to other testnets included in the implementation. There are some other details I would like to emphasize from the previous weeks: Planning - going through code, creating issues There are now two issues for each of the clients: Reth and Lighthouse. This opened a communication channel with other contributors to these clients, which was really helpful, as @michaelsproul immediately suggested a possible solution based on additions for the new Holesky testnet. I will look into it further this week, it seems to be quite useful at first sight. For now I've been going through the Lighthouse code, leaving the Reth implementation for later. Project proposal I reworked my project proposal and also made some additions. I already got some great feedback from Mario for the first version before these changes, I've taken these into account and added the finalized proposal to the repository. I've tried to keep the proposal brief and to the point, partly because I feel like it's difficult and mostly inaccurate to plan the implementation into detail, as the process changes all the time according to new findings during the implementation process. Preparations for Lighthouse contributions I took some time to try and do my best following the Lighthouse contribution guide. I did not want to start writing code incorrectly or in an incorrect envorinment, therefore I've been spending some time following the Contributors' guide and the Contributing section in the Lighthouse book.

Implementation of the Ephemery testnet genesis function in a new pair of clients, Lighthouse and Reth. Motivation The Ephemery testnet should mainly serve as a tool to ensure a smooth inclusion of new stakers into the ecosystem. Currently, the only possible testing tool for stakers is the Goerli testnet, but leaving the testnet after performing the needed testing may cause issues in the long term due to a large amount of inactive validators, on top of the issues universal for the current testnets with a long lifespan. Ephemery would make it possible to test stakers' setups without the fear of causing issues after leaving the testnet as a validator and switching to the mainnet. Additionaly, problems like too long sync time due to the large state or insufficient funds are also solved by the periodical resets. Project description This project plays a part in improving the Ephemery testnet user experience, making it as easy to use as other currently operating testnets in various clients. The aim of this project is to implement the genesis function in a new pair of clients, Lighthouse and Reth. Currently, Ephemery is maintained manually and its use requires manual setup by the user. This project should contribute to the automatization of Ephemery in the determined clients, allowing them to generate and connect to a newly created genesis. Specification The project will be implemented according to the EIP and the specification. The specification will be validated and possibly improved based on the new discoveries during the implementation process.

There it is, late but still, the 4th update! This week, I was working on the goals I set out in the previous update. Ephemery experiments I was experimenting with running the network on various clients to get an idea about all the technicalities of how running a network looks like in reality. After quite some technical issues with the client, I finally succeeded (in this screenshot with Geth and Teku clients)! My next goal would be setting up the validators, but I am unsure if any of my old computers is up to the challenge of staying on all the time, so I'll have to try and check that. Running the testnet using Geth and Teku, syncing was successful. Team call On Friday, we had a call with the EFP Ephemery team to figure out how we all can contribute and what should our main goals be. I decided to work on the implementation of the Ephemery genesis function in Lighthouse. Ideally, the project should wrap up by implementing this for a whole working pair of clients (possibly with Reth as the execution client). In the meanwhile, I'm going to contribute to the docs with any new useful knowledge.

This development update will be rather uneventful, as I spent a few days not feeling very well and the progress was not as great as I wanted it to be, but I still managed to choose the area of interest and research some of the resources further. My final desicion is working on the Ephemery testnet and the main two reasons are that I like the clarity of the estabilished goals and there also are many implementation based tasks. I love implementing stuff once I overcome this initial "start" phase, so I think I can be useful in the Ephemery team (this is code for I chronically suffer from slow project beginnings :)). I went through the following resources and code: Ephemery resources EIP draft Ephemery Resources repository for general overview Ephemery setup tools Ephemery genesis configuration Ephemery tasks and roadmap shared by Mario in the Matrix channel geth and lodestar WIP implementations Mario's workshop on Ethereum clients

During the last week, I spent my time researching the areas of interest I mentioned in the previous update. The one I liked the most was the research of SSLE and its security. I find cryptography concepts very interesting, so I gave it some time and went through a few articles, some I read in detail and some I just quickly went through. I will link them for future reference: SSLE and SnSLE resources General overview of the problematic on Ethereum.org Secret non-single leader election proposal by Vitalik Whisk: A practical shuffle-based SSLE protocol for Ethereum Whisk code on GitHub Efficient and Universally Composable Single Secret Leader Election from Pairings (paper) Secret Single Leader Election (SSLE) in Eth2 (code) by Vitalik

Hi, this is my first update so I’m going to introduce myself a little bit before I start. My name is Teri (Tereza) and I’m a cybersec/computer science master’s student from the Czech Republic. I’ve been interested in Ethereum for quite some time, I’ve visited a few conferences, hackathons and my bachelor’s thesis was kind of a “baby” version of Ethereum research. I spent Week 0 and Week 1 researching the new division of layers after The Merge, since I haven’t spent a lot of time reading about all the new functionality during the last year and need to familiarize myself with the technicalities to be able to choose the best project for my abilities. I’ve been doing some notes that I’m going to share in a future update. Simultaneously I’ve looked into different implementations of the layers to get used to how the specification looks in the “real world”. I’ve ran into a few challenges during this initial “researching & figuring out the project” phase: It’s difficult to understand the implementation for someone who kind of knows how everything works theoretically but hasn’t seen a lot of Ethereum code. There’s a lot of clients and each of them is in different phases of implementation or research and the code is variously organized and they have different kinds of detailed issues. It’s important to be able to understand already existing complex implementations. I do not have a lot of experience with contributions to open-source code and find it difficult to recognize how to meaningfully contribute, especially as I would prefer a project that I would be able to do alone or with a smaller team that would not require daily coordination and must take into consideration the size of the project, which needs to match the time window and my abilities. I’m trying to come up with an area of interest or a project to research further: I’ve worked in a few languages, with my strongest being C and Python. I’ve been interested in learning Rust and I’ve read some of the documentation and examples even before applying to this cohort, so I think it would be a good choice, although it’s not set and I can also use other languages.