# Staking on short-lived Testnet Ephemery By [Ladislaus](https://paragraph.com/@ladislaus) · 2023-07-03 --- The barrier to entry for solo-stakers remains a burden for validator decentralisation. Aside from having enough initial collateral, home stakers need to have a basic understanding of their protocol responsibilities. Moreover, they should feel comfortable running their own hardware and node software. An improved user experience for stakers is needed. In order to achieve this goal, it is essential to have **convenient and accessible testing options** throughout the validator lifecycle. ![Staking UX is not just about command line knowledge](https://storage.googleapis.com/papyrus_images/65041c96110741e6d0866806041c60ef9e04ff441397b84a727655f15ac261cc.png) Staking UX is not just about command line knowledge Why testing staking on long-time testnets is undesirable -------------------------------------------------------- Unfortunately, testing staking is neither simple nor intuitive at the moment. Currently available long-time testnets either have a **permissioned validator set** that is controlled by client & testing teams (Sepolia) or happen to be rather old networks, suffering from a large state size, **taking ages to sync** and, weirdly enough, feature non-valueless testnet coins (Goerli). In summary, long-term testnets provide a list of deficiencies for stakers: * **Lack of token supply** (lost coins / empty faucets) * Nothing-at-stake-problem: **node operators disappear** after initial testing → participation rate drops → slots are missed → degraded staking/network UX, e.g. lots of confusion why “attestation effectiveness” is low etc. * Prolonged history leads to a **large state/storage size**. Originally desired testnet properties are lost over time, which is why the network needs to be deprecated at some point. > Side note: upcoming long-time testnet ‘[Holesky](https://github.com/eth-clients/holesky)’ will be supported for ~2-3y starting from September 2023 * * * Why testing staking on short-lived testnets (Ephemery) is desirable ------------------------------------------------------------------- Fortunately, a novel approach to testnets called _Ephemery_ (derived from the word _ephemeral_) is being explored. The main idea is to have a test network that **resets automatically at regular intervals**, with a given set of committed initial validators. After each reset, called `regenesis`, the entire state, including all contracts, is cleared, and any previously distributed coins are returned to the faucets. This network architecture implies numerous benefits. It consists of **one unified network infrastructure**, using the same RPC endpoints (e.g. for checkpoint-sync), clients and block explorers for every new iteration of the testnet. Furthermore, a reliable validator majority ensures chain finality, resulting in a stable testing environment. [![User Avatar](https://storage.googleapis.com/papyrus_images/d51b937ce48ea4e6c2b1abe5545ffd9cf9947df30577fc4b5e55766460e9887e.jpg)](https://twitter.com/TMIYChao) [Mario Havel](https://twitter.com/TMIYChao) [@TMIYChao](https://twitter.com/TMIYChao) [![Twitter Logo](https://paragraph.com/editor/twitter/logo.png)](https://twitter.com/TMIYChao/status/1599728822085046272) Frens, let me introduce you to Automatically Reset Ephemeral Testnet for Ethereum. Unlike a traditional testnet, it periodically rolls back to genesis. Check out the repo and this thread for all the info and resources, help us by becoming a contributor ![🙏](https://abs-0.twimg.com/emoji/v2/72x72/1f64f.png)[ ![](https://storage.googleapis.com/papyrus_images/9a5297dde61ae7fc160ea6409cfc949fe0775c94495632a94edd339febbd4030.jpg) github.com GitHub - taxmeifyoucan/ephemeral-testnet: Resources and project management of Ethereum ephemeral... --------------------------------------------------------------------------------------------------- Resources and project management of Ethereum ephemeral testnet - taxmeifyoucan/ephemeral-testnet ](https://t.co/ObDC9GYqXY) [![Like Icon](https://paragraph.com/editor/twitter/heart.png) 73](https://twitter.com/TMIYChao/status/1599728822085046272)[ 5:34 AM • Dec 5, 2022 ](https://twitter.com/TMIYChao/status/1599728822085046272) Key advantages of Ephemery for stakers -------------------------------------- * Fast sync times (sync EL+CL combo within minutes) * Minimal disk space requirements * Easily obtainable testnet ETH (i.e. liquid faucets) * Stable chain with sufficient finality assurances * SoonTM: out-of-the-box client support (`--network=ephemery`) Use cases --------- Aside from common preparatory testing scenarios that should not involve real money, such as testing the EL:CL:VC & hardware configuration, client updates, [switching to a minority client](https://paragraph.xyz/@ethstaker/execution-client-diversity), migrating signing keys, changing BLS credentials, withdrawals, etc, there are a few use cases which appear particularly suited for Ephemery, e.g.: * “stop-and-go” testing: **bootstrap a node within minutes**, do some testing, power off your node, continue testing days later without having to wait hours for the node to be back in-sync * Test adding a validator to an existing setup (or dozens), which right now is difficult to do given illiquid Goerli faucets, + test running several validators * No requirement for an external drive on a Raspberry Pi 👀 Ephemery under the hood ----------------------- Ephemery **currently resets weekly** (Thursdays, 7 p.m. UTC), although it is intended to extend the reset period to _two_ or potentially _four_ weeks. The reset mechanism presently works script-based. Additionally, Ephemery features an auto-deployment primitive for popular dApps like Uniswap, ENS, 0xSplit, SAFE, and many others ([feel free to add more to the repo](https://github.com/pk910/ephemery-base-contracts)). Most importantly, **implementing the resetting logic natively into client releases** is highly desirable for a lean user experience in the future. This is still a work in progress with this [EIP to follow-up](https://github.com/ethereum/EIPs/pull/6916). Moreover, stakers can enjoy an added benefit given Ephemery's built-in **wallet refunding** mechanism: If a user deposited and ran a validator during the previous Ephemery iteration, they will receive a refund of their deposited amount in their funding wallet starting from (re)genesis. That way, validators can avoid tapping a faucet multiple times by directly re-depositing via [launchpad](https://ephemery.launchpad.remyroy.com/en/). > Note: there is a cap to refunded amounts after regenesis of 3200+0.5 ETH (= 100 validators) Excursus: How regenesis works ----------------------------- Technically, Ephemery uses a **deterministic genesis function**, i.e. a template to calculate the current genesis, based on the time elapsed since the initial genesis (_genesis 0_) and the specified duration of one network iteration (_period_). For more details regarding the **reset function** and **the rolling ChainID** to protect from replay attacks see [this repo](https://github.com/ephemery-testnet) and [the EIP](https://github.com/ethereum/EIPs/pull/6916). ![src: MH](https://storage.googleapis.com/papyrus_images/334eaaa818948fdf32147d0fa45b97bec1e4ecb3819eb69c30c64089d7b5bb6f.png) src: MH How to get involved ------------------- * Get started and [run a node on Ephemery today](https://github.com/ephemery-testnet/ephemery-scripts/blob/master/manual/setup-geku.md)! * Find all necessary tooling to get your validator up and running @ [ephemery.dev](https://www.ephemery.dev) * [Join the matrix server](https://matrix.to/#/#staker-testnet:matrix.org) for discussions and report potential issues. > Note: Ephemery as of now lacks external PBS infrastructure, tooling such as forkmon/ethstats, and a variety of block explorers, etc. Ephemery is still a **work in progress**. Expect further changes to the specifications and feel free to contribute along the way in order to help stakers find the most easy-to-access testing playground. * * * --- *Originally published on [Ladislaus](https://paragraph.com/@ladislaus/staking-on-short-lived-testnet-ephemery)*