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.

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’ 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.

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, 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).

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.

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.

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 and the EIP.

How to get involved

• Get started and run a node on Ephemery today!

• Find all necessary tooling to get your validator up and running @ ephemery.dev

• Join the matrix server 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.