Some thinking was done around solving for Görli’s “empty faucet” problem (amongst others) as part of the Holešovice project at ETHPrague in June 2022 (winner of “Sustainability” prize).
The concept of “ephemeral” testnets was discussed, and here I share some of my thoughts from those discussions:
I see many pros of having ephemeral testnets, any of which I am happy to expand upon if required:
a) to default-sync should be quick, and require less storage because chain will be short.
b) faucets can be initialised with a gazillion holETH, solving empty faucet problem, in combination with something like komputing/FaucETH.
c) can be initialised with absolute latest L1 codebase, allowing identification of issues sooner rather than later.
d) PoS deposit contract can be auto-deployed at genesis, with pre-deposited Validator keys, to enable the potential for a “clean” post-merge network.
e) genesis config / codebase could be read from previous testnet’s chainstate/Swarm, which could even be governed onchain. This can serve to reduce reliance on e.g. github, in favour of decentralised storage methods.
f) they don’t preclude users from continuing to run them after “official” decommissioning, in case they wish to test longer term features.
g) can serve to create some kind of framework for a “cadence” / “rhythm” to coordinate delivery across the community, e.g. a project can target a release to the testnet launching in December. The duration of the testnets could be divided into agile-like sprints by dev teams, so if the duration were e.g. 28 days, then that’s 4x7day sprints, each sprint 5 on / 2 off (like a “standard” work week). I believe this can prove to be powerful in terms of ecosystem coordination.
h) can work in harmony with long-standing permissionless/permissioned testnets, and indeed provides scope for broader inclusivity in terms of collaboration on base-layer evolution.
Some challenges to this approach however:
i) newly initialised networks would (at first) be without “core” protocols e.g. ENS, GnosisSafe, Maker, Uniswap, Aave, Optimism, Arbitrum, zkSync, Polygon, Livepeer, Swarm, Aragon, ChainLink, Golem (the list goes on and on).
I actually think that this can encourage projects to contribute auto-deploy processes, to make sure that their own protocols are available for others to build on.
This can also serve to greatly improve tooling for local devnets, or for the likes of scaffold-eth i.e. users could pick and choose which protocols they want to have available to use in their dApp, when running yarn chain.
ii) harder for e.g. Infura/Alchemy to support, though perhaps a minor issue given a), as it will be muuch easier to run a node with a few GB of storage.
iii) more complicated to keep track of, which is perhaps also a minor issue, requiring a change in the mental model of “how testnets are done”. Some thoughts on this have already been shared here
Happy to hear of more challenges though, but for now I am bullish on this concept.
To conclude this lengthy post, I believe the prize here is to enable all build environments, whether public testnets or private devnets, to have
-
the absolute latest L1 stuff: merge, verge, surge, purge etc. for users to develop on top of, providing them with early-access to the known benefits of these upgrades, as well as future-proofed foundations for dApps, and
-
all network/L2 protocols, for users to integrate their dApps with, providing them with all the “infrastructure legos” afforded to them by building on the Ethereum network.