Add ephemery testnet flag

[atkinsonholly]

What type of PR is this?
Feature

What does this PR do? Why is it needed?

Ephemery is a new kind of testnet which is intended for short term testing use cases. It automatically resets back to genesis after every given period which enables reclaiming faucet funds, clearing validator set and keeping small state. There is ongoing effort to implement ephemery natively within clients.

Which issues(s) does this PR fix?

Addition of the ephemery testnet flag, #15357. This PR is similar to the addition of previous testnests (hoodi, holesky) with some differences, described below.

Latest release
Latest config.yaml

Other notes for review

1. Ephemery version increments every period. There is some discussion potentially needed regarding what parameters should live in testnet_ephemery_config.go and what's appropriate for config/params/config.go.
2. Since the ephemery release will be different every period, there is no sha256 verification check currently included in the test (see WORKSPACE).
3. This PR doesn't tackle automatic network reset, which can be addressed in a separate PR.

Acknowledgements

• I have read CONTRIBUTING.md.
• I have included a uniquely named changelog fragment file.
• I have added a description to this PR with sufficient context for reviewers to understand this PR.

[CLAassistant]

All committers have signed the CLA.

[prestonvanloon]

This will need to be pinned to a specific commit and the sha256 or integrity must be provided.

[prestonvanloon]

Seeing your commentary:

Since the ephemery release will be different every period, there is no sha256 verification check currently included in the test (see WORKSPACE).

This PR will not be accepted without a pinned commit and sha256. Prysm builds and testing MUST be reproducible. There is also a strong desire that changes in external repositories do not suddenly break all PRs in Prysm CI.

[atkinsonholly]

Thanks for the review @prestonvanloon. I understand, and of course that makes sense. I am wondering how we can approach this given the dynamic ephemery config - do you have any suggestions?

[atkinsonholly]

Would you be comfortable with the test being pinned to a specific release and testnet_ephemery_config.go remaining as it is?

[prestonvanloon]

@atkinsonholly Yes, if the dependency is pinned to a specific release/commit with the sha/integrity then it can be merged.

How often do you expect that these config values will need to be updated?

It might be better to communicate to operators to use --chain-config-file=metadata/config.yaml and --genesis-state=metadata/genesis.ssz with the latest values rather than updating prysm code itself. If your interval is really small, I am worried that prysm's unpredictable release schedule could be a potential issue. It looks like the rollback interval is 28 days and Prysm has multiple periods in time where a release wasn't made for more than 28 days. Especially around mainnet fork time when changes are moving slowly during testing. You'd also need to communicate minimum Prysm versions for operators to use in the next testnet restart.

Not saying this isn't possible to merge, but seems like it could have some pain points.

[atkinsonholly]

Yes, 28 days.

The config itself shouldn't need to be updated more than for any other testnet, since the iteration is calculated within. However, if I understand correctly the way the repo works, it's then the testfile that compares this config to the upstream version and verifies the integrity.

Couple of initial thoughts we could explore, let me know if either of these might be an acceptable way forward:
A. Compare the config to upstream sha256 (published somewhere) for the 'latest' official ephemery release i.e. every period
B. Try to fix a datetime in the testfile, or otherwise override the iteration number in the testfile only, so we can test integrity against a specific release

[prestonvanloon]

I discussed this offline with ethpandaops folks. I support the effort to have a static config for ephemery. As I understand it, the config is constant, but the MIN_GENESIS_TIME is re-configured at start up with the current interval.

I've read the EIP-6916 too. As far as the reset function, I think this is not viable for Prysm and operators should perform a manual db wipe and client restart to pick up the new interval. Such behavior is not impossible to implement in Prysm, but it is additional complexity risk and maintenance burden for functionality that will never be used on mainnet.

Since the initial config is not changed, we should be able to merge this PR with the pinned release/commit and sha values for the http_archive.

Please also see that the test is complaining that the config values do not match the upstream repo.

    assertions.go:39: handlers_test.go:203 Values are not equal, want: 175 (int), got: 176 (int)
    --- FAIL: TestGetSpec/PERIOD (0.00s)
        handlers_test.go:581: Incorrect key: PERIOD