# Testnet for stakers This document proposes a new type of testnet dedicated to improving the experience of testing a staking setup. ## Current issues and motivation A staking setup is sensitive from a security and financial perspective. The ideal enter experience for stakers would be to try out their setup on a testnet, make sure it runs smoothly and then just switch to mainnet. This is what [launchpad](https://launchpad.ethereum.org/en/) directly recommends, to practice on testnet first. However, right now the only available public testnet for testing your own validators is Goerli. Sepolia has a permissioned validator set, others are deprecated and spinning up a local testnet is impractical for this usecase. With Goerli being the only option for stakers, the experience of practicing their setup is very limited. There are various issues recognized by community: * Insufficient available amount of Goerli testnet ETH, public faucets are empty * With many validators joining just to test their setup and leaving, there are many missed slots and network might have issues to achieve finality * Goerli is relatively old testnet with a big state and historical data (compared to a fresh network) which limits sync time These issues are not specific to Goerli but any open longer-running testnet would end up in a similar situation. ## Stakers' testnet A solution to this would be a testnet dedicated only to stakers. The way to achieve this is a testnet made up of ephemeral networks, i.e. blockchain which is regulary rolled back to genesis. Genesis can be generated only once and stays the same. The genesis state already includes a deposit contract with 'pre-mined' validators similarly as in [testing](https://github.com/ethpandaops/ethereum-genesis-generator) [tooling](https://github.com/protolambda/merge-genesis-tools) and addresses with funds for faucets. Genesis validators represent the basic validator set needed to run the network. These validators should be operated by multiple trusted entities, similarly to Sepolia. Thanks to permissioned operators, we can also ensure they are running the latest software. On top of the basic (permissioned genesis) validator set, anybody can create deposits using testnet ETH and run their own validators. These validators and any other activity on the testnet are effectively deleted during the regular rollback. The period for ending the ephemeral network and chain rollback could be: * Standard predefined period * e.g. weekly, bi-weekly, monthly, etc * When constant `terminalEpoch` is reached, nodes drop all blocks after the genesis * Pros are easier implementation and regularity * Cons would be potential issues if testnet ETH runs out or network doesn't reach finality while there is still a lot of time left in the rollback period * Automatically adjusted * Rollback can happen sooner based on active validator set approaching finality minimum, small amount of testnet ETH left, etc * `terminalEpoch` is changed to current slot + `n` Testnet 'lifetime', the time left in the current rollback period, should be easily publicly available on the testnet website. Simple countdown showing how much time before the upcoming network reset. This allows stakers to decide whether to wait with their test if the period is short. The ephemeral nature of the testnet optimizes exactly for the use case of testing validator experience: * Big part of validators can leave the network without waiting for withdrawal, finality will be always reached at the moment of rollback * Faucet(s) can be generous with testnet ETH because they will receive it all back once the chain resets * Bigger staking operations can easily try their setup, e.g. running a large number of validators on a single machine * Testing is always fast because sync is quick as database doesn't require lot of storage, state is very small Ephemeral testnet doesn't allow long-running validators or testing contracts. For these kinds of tests, Goerli or Sepolia would be still ideal. This testnet is optimized solely for the experience of practicing staking, making sure your node setup with validators works as expected and enables leaving it shortly afterwards without any harm. ### Potential implementation and challenges Testnet needs to be implemented by all clients. It should be a preconfigured option within client implementations so it can be easily used, e.g. by flag configuration `--network: staking-testnet`. Apart of just adding another network option, clients also need to implement its emphemeral features - mechanism for rollbacks and special handling for network identifiers which normally serve as a security feature but in this case need to work differently. - ChainId might need to change with every network reset - To prevent replay attacks using transactions from previous network histories, testnet would probably need to always change its chainId based on predefined formula. This is opened to discussion as variable chainId might be a big issue for the infrastracture. - ForkID defined by [EIP 2124](https://eips.ethereum.org/EIPS/eip-2124) and the field in [consensus](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#eth2-field) ENR has to be handled so the network is able to peer and stay secure with each reset Even with focus only on validators, some infrastracture providers still have to support the testnet, e.g. explorers and wallets. Implementation has to make it easy for them to support this kind of network without breaking at each rollback. Support from RPC providers for stakers' testnet is not that much needed or expected because users or developers shouldn't interact with the network. Alongside general information and countdown, the testnet landing page should include 'Add network' button for wallets. Users should be also advised to use RPC of their own node as they are going to run it with the validator. Validators joining the network should have a high chance to become a block proposer during relatively short period. The period during which network exists should be long enough to give all (non genesis) validators chance to propose a block. This is an ideal case which is not going to be achieved by default. One alternative to the ephemeral approach would be to tweak consensus parameters, e.g. to leak inactive validators faster and clear the validator set. However this doesn't solve all the issues and not all the consensus options are configurable in clients. The ideal goal is to run network with the same parameters as mainnet so stakers can be sure that once the setup is validated on the testnet, the switch to mainnet should be smooth. ### Resources and acknowledgements [Goerli discussion at Eth Magicians forum](https://ethereum-magicians.org/t/testnet-workgroup-paths-out-of-the-goerli-supply-mess/11453/4) [Comments by Rémy from EthStaker](https://twitter.com/remy_roy/status/1588613245321072643) The idea was originally discussed with Danny Ryan, Paritosh and Holešovice testnet team