Proposal: Predictable Ethereum Testnet Lifecycle

Thanks for summarizing the discussion!

Chiming in with a few thoughts from the perspective of application developers:

  1. There was a LOT of friction in migrating recently from Kovan/Rinkeby/Ropsten to Goerli as was recommended for post-Merge testing. It’s a lot more complicated than redeploying contracts - state and dependencies on state all need to be sequenced and migrated to minimize breaking environments.
  2. There is a lot of value to the demand and mainnet-likeness of Goerli we’re seeing right now. Composability, liquidity, traffic volumes, decentralized/permissionless validator sets all make for a mainnet-like environment which is great for testing and iterating pre-mainnet.
  3. There is a lot of value to having a long term testnet where state can accrue, as opposed to ones that reset every few years. This builds on points (1) and (2) but you both lose a lot of value when migrating and there’s a lot of overhead.

Would recommend as a v0 we explore a way to make Goerli more sustainable long term. One such step, as discussed, would be increasing the supply of gEth. I’m sure more community members (Alchemy included) would step in to help the long term viability of this network and not put the whole load on the EF. If we’re unable to mitigate supply side issues in a reasonable manner then perhaps we can try to identify paradigms that might be better suited to long lived testnets. I understand there’s a certain burden on client/protocol development imposed here, but there’s also a large, and increasing (with ethereum adoption) burden on the application layer as well.

Thoughts?

1 Like

Are you saying two more years on Goerli is not enough?

My point is, providing a fixed schedule gives the entire ecosystem more time to plan and coordinate. If you are on Goerli now, you will need to prepare for your next migration in 2024. That gives Goerli a total lifespan of 6 years which is really long for an Ethereum testnet.

Taking a step back, what would it look like to have an indefinitely long lived testnet? I think that would solve a lot of the problems mentioned in (1) and (2) in the first post above.

Update: after EL teams also the CL teams indicated we should not recover Goerli and instead prepare the community for a testnet deprecation and encourage applications to migrate to either Sepolia now directly, or to Holesovice end of next year.

As far as I am concerned, only permissioned network saves us.Now the Goerli test network is permissionless with POS.POS consensus depend on the “Stake”, and the Stake is the punishment of the dishonest participates.If the “Punishment” is useless and ez to get, pos strategy broke down.Although there is a good case of permisionless test network, such as Ropsten.But that is POW, “work” power is a punishment of dishonest miner, and he can use the work power to make money in other chains.What’s worse, even there is no malicious, some normal can make network stuck.To be honest, I deposit 64 goerli befor and want to have a try of beacon chain.I deposit to be an validator but then I find it’s too late then go to bed, so I turned them off and have never validated. Assume if there exist a lot of curious fomo users like me,maybe 40%, the network is over.

Is there a world where Sepolia and/or Holesovice have longer shelf lives than 2-3 yrs? This is going to be a major developer UX issue if teams have to migrate testnets every few years.

Not sure why it should be a major UX issue - it has always been stated that testnets should be considered ephemeral.

1 Like

While I appreciate all of the support invested in testnets I wouldn’t necessarily say the UX can’t be improved still, especially from an application dev perspective :slight_smile:

Not having to migrate testnets would be a huge improvement.

Discussed the proposal with the EthStaker community today.

2 Likes

This ephemeral testnet project intends to automatically restart after a short period of time, probably a few weeks. In this context, it could take of some load from testnets with long lifecycle so it might be easier to support them even longer. Also, the reset mechanism, once it is properly specified and implemented, could help with predetermined sunset of newly launched networks.

3 Likes

Why is this the case though? Because If I’m developing on many of the other chains, there’s just 1 testnet for devs, and its always available, it’s easy to get gas/native tokens, and its always the place to go to develop applications.

  • Polygon: Mumbai
  • Avalanche: Fuji
  • Solana: Devnet
  • BSC: BSC Testnet

I’d like to echo the sentiments from @noam. From an application perspective, having to migrate to a new network every few years is a large burden on both developers and application/infra owners.

As Ethereum continues to grow and gain adoption and more developers, I feel more focus should be placed on DX (developer experience)

Right now, here is what IMO is the best developer experience regarding testnets:

  • There should be one, and only one testnet for developers. This network shouldn’t ever change (or not for a very long time)
  • Network should run on POA so its not dependant on stake or community validators, & have the ability to mint lots of ETH (or infinite). There should always be 0 demand for OTC testnet ETH
  • This testnet should have all the major applications & infra (alchemy, opensea, chainlink, the graph etc)
  • Network clients should be upgradeable over time rather than spinning up a new testnet

Right now it’s really hard to get gETH, and gas prices can spike which means what little ETH devs have gets chewed up. I feel with these issues more and more devs will likely turn to L2’s and other EVM chains to develop their applications (Polygon, BSC, Avalanche Fuji etc). We recently had to turn off our ETH faucet due to someone getting around our security measures and taking it to sell it OTC

Simple: so that people don’t start treating testnets like mainnets. Görli ether, for example, is sold OTC. If Görli was expected to be deprecated in one year, it would lose its speculative value.

DApps should aspire to work with any EVM-compatible chain. See ERC-1820: Pseudo-introspection Registry Contract for how this could be done. For example, a chain-agnostic Uniswap would check to see if there’s already a router deployed, and if not, request that users send ether to the predetermined address and subsequently deploy the predetermined contract.

In summary: ephemeral testnets encourage best practices.

1 Like

All of them launched less than 5 years ago and they are not facing the issues we are facing with high-load, long-standing testnets.

That’s exactly what we are addressing by predictably deprecating testnets.

thanks @q9f and @Pandapip1 , points understood. We (Chainlink Labs) are internally discussing plans to move all Chainlink services to Sepolia

1 Like

Scheduled Holesovice launch for September 15, 2023.

Considering something like the Graph (or other indexer services), which service would you recommend? As most of the apps will only be on the “application test net” (aka Sepolia) the data that should be tested for indexing is there, but if you want to have a “Mainnet like” environment to test reorgs and similar cases the “validator test net” (aka Goerli) would be more fitting.

Another way would be to test indexing in “prod” (so Mainnet) as it is “only” reading state.

On a general note I have to say that the communication around this is quite confusing as the Ethereum Website doesn’t link any of this and it is currently only visible on GitHub.

2 Likes

Good point. I updated the website.

1 Like

Hi I know this is is to propose a Holesky and LTS testnets so maybe people will be interested in a relevant proposal but with a major different consideration: dApps.

I am proposing a longer term support for testnets that suit dApps, L2s and smart contracts that depend on other smart contracts: