Methodology for Ethereum (testnet) Networks

Thank you so much for the detailed post! I agree that this sort of comprehensive framing has been missing for a while, we might need to work on how we message the testnets.

IMO we do need atleast 3 specific networks:

  1. App dev: this would be sepolia, its stable, has uptime similar to mainnet and easy to get funds
  2. Staking: this used to be holesky and would now become hoodi. This is meant to be large (mainnet sized), but we try to keep it as stable as possible for staking setups
  3. Chaos network: this is where core devs can test taking the network down, non finality, bump gas limits and so on

I think anything on top of these 3 types of network basically adds a lot of co-ordination overhead for what might be unclear gains - some such as 5.dsTestnet do tend to be done via devnets, they just aren’t widely announced and hence lack of recognition of them.

I think one item i might want to push back on is ever-lasting - I think this might be detrimental as the protocol evolves and the testnet stack we support needs to evolve with it. E.g, The parameters chosen on Goerli were fine for 2019, but the testing needs of 2022 forced us to replace it. I imagine the same with future upgrades (beamchain/etc) needing us to relaunch networks setup in a way to facilitate that version of the network.

However I do agree that our testnets might need to be more risk averse, ideally we only break them if we can’t avoid it.

4 Likes