# EIP 6916 - Epermeral Testnet Mentor - [Mario Havel](https://github.com/taxmeifyoucan) Interested Permissioned Fellow - [Harsh Pratap Singh](https://harsh-ps-2003.bearblog.dev/) [Ephemery](https://mirror.xyz/ladislaus.eth/KbQE16HYc0U-_m7ZuAhCBqbyrEyGTThQ9pr_NeMHiVw) is an automatically reset testnet that periodically rolls back to genesis after a set period of time, designed to address common issues faced by long-running testnets. There are multiple benefits for having a short-lived testnet made available directly through existing clients and infrastructure : * The periodic resetting of the test network effectively erases the onchain activity that occured during that iteration, avoiding state bloat issues common in long-running testnets * Ensures availability of testnet funds by returning them to faucets after each reset * Cleans the validator set regularly, preventing inactive validator problems * Keeps the network reasonably small for easy bootstrapping, and lower resource requirements Defined in [EIP-6916](https://eips.ethereum.org/EIPS/eip-6916), Ephemery enables a single testing infrastructure consisting of ephemeral networks with deterministic parameters, where each network iteration is created by a specified function that deterministically generates new genesis states. The reset mechanism is achieved through functions for genesis generation and client reset, with each new genesis being deterministically created based on the original genesis parameters. 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. The Ephemery testnet ensures smooth onboarding of new stakers by addressing limitations of long-lived testnets. Existing persistent testnets (like Holesky or Sepolia) accumulate inactive validators over time, creating long-term ecosystem bloat and synchronization issues due to ever-growing state size. Ephemery solves this by enabling risk-free testing: Stakers can validate confidently knowing their exit won’t leave permanent inactive slots. Periodic resets also eliminate problems like slow sync times from excessive state growth or fund shortages, providing a consistently optimized testing environment. The main goal would be to implement the genesis function in a consensus client, making the implementation work for a bunch of clients one-at-a-time. The stretch goal would be work on reset function. The reset function is not included in the scope of this project during EPF, therefore the user will still need to manually stop and discard the previous genesis. Clients should be able to run Ephemery testnet simply via `--network ephemery` flag. When the testnet flag is provided, we automatically use the hardcoded checkpoint to download the latest genesis state using checkpoint sync feature. If user provides a custom checkpoint sync flag, we override the default option and use the endpoint provided by user. We also include a backup download option pointing to testnet releases which are publicly distributed and trigger this option if the checkpoint state sync fails. If the client includes a feature for generating the genesis, use it to verify parameters in the downloaded state and issue an error if values don’t correspond ### Current State of Implementations Currently, Ephemery is maintained manually and it's usage requires manual setup via external tooling 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. Various [client teams](https://github.com/ephemery-testnet/ephemery-resources/blob/master/client-implementations.md) are already in-process of implementing, and I really love the fact that this project has a very clear goal. The [roadmap](https://github.com/ephemery-testnet/ephemery-resources/issues/1) has very clear directions. We have the [reference build implementations](https://github.com/ephemery-testnet/ephemery-genesis/blob/master/scripts/build-genesis.sh) and [gnesis state creator](https://github.com/protolambda/eth2-testnet-genesis/tree/master) for generating ephemery genesis. Reth, Geth, Lodestar, Lighthouse are still WIP for reset function, while Prysm, Grandine and Nimbus, Nethermind, Erigon, EthereumJS havent even started yet. [Teku and Besu are done!](https://www.youtube.com/watch?time_continue=1&v=Rpg9irPn3jI&embeds_referring_euri=https%3A%2F%2Fwww.perplexity.ai%2F&embeds_referring_origin=https%3A%2F%2Fwww.perplexity.ai&source_ve_path=MjM4NTE) I should communicate with respective contributors to know if they need help with the [genesis reset WIP](https://github.com/sigp/lighthouse/issues/4664). Both [Reth](https://github.com/sigp/lighthouse/issues/4664) and [Lighthouse](https://github.com/sigp/lighthouse/issues/4664) seems to have closed the PR. The implementations are not ready yet, as changes broke some tests, while tests for the Ephemery functionality were not created. I think I can help push things forward. Geth team mentioned : ```! We have discussed this PR within the team. We do not want to be responsible for maintaining an up-to-date definition of the Ephemery network and its genesis parameters (premine, etc.). Since the network is meant to be reset, and genesis configurations are provided by the project at https://github.com/ephemery-testnet/ephemery-genesis, the genesis block doesn't have to be generated by geth. ``` If not, I can work from scratch on Gnesis function for any one of the clients which wants this. ### Tests The simplest things would be to make sure the logs are consistent for both [manual](https://github.com/ephemery-testnet/ephemery-scripts/tree/master/manual) and native ephemery tests. ### Whats Next * Play with ephemery setup locally * Understand the CL codebases and try to figure out how stuff looks like and how to possibly implement the genesis function.