Adding further network configurations to config.yaml

[q9f]

For the preparation of a multi-client testnet launch in the near feature, I would like to propose the augmentation of the config.yaml format as outlined in this repository in configs/ for both client developers and network participants convenience.

The eth2-testnets repository contains examples for Prysm, Nimbus, and Lighthouse. For example, Lighthouse uses five files to define a testnet:

• a boot ENR file
• a deposit contract file
• a deploy block file
• the genesis state dump
• the actual beacon chain configuration

Given the example above, I would propose the following additions to the config.yaml format:

• DEPOSIT_CONTRACT_ADDRESS (required) - the deposit contract address on the eth1 chain (already implemented in this repository)
• DEPOSIT_CONTRACT_BLOCK (optional) - the deploy block of the deposit contract to ease eth2 clients with synchronization
• BOOT_NODE_RECORDS (optional) - a list of ethereum node records serving as boot nodes for the specified network

In general, from the experience of managing eth1 networks, especially managing boot node records together with the chain configuration has always proved to be very convenient.

I understand, however, that there may be a desire to separate transition-specification from actual network-specification. Therefore, I'm opening this ticket to have a place for discussion. I'm happy to champion such a change (preview) if desired and supported by the client teams.

Also, it would be nice if all eth2 clients would work towards native support of reading such YML files to easily have the ability to play around with multi-client testnets in future. Thanks for reading. :pray:

[djrtwo]

I'd like to standardize this. I'm a bit torn on adding it to the same file or making a separate network config file.

It seems like boot node records should not make it into the spec repo, and live only in the testnets repo and other production repos.

I'll err on the side of simplicity and say we add them to the main config, but do not include actual records here. Maybe leave it as an empty list in the sample configs found in the specs repo

[zah]

FWIW, these are precisely the data items shared in the eth2-testnets repo.

One thing that has changed since the testnet metadata spec was written is that most teams can now support ENR records and these make more sense as bootstrap records instead of the MultiAddreeses suggested there.

[zah]

The use of multiple files in the testnet metadata spec was informed from the actual implementation of the standard. In the long-term, most clients should receive these configuration parameters on the command line (e.g. --state-snapshot, --bootstrap-nodes, etc). Placing the individual bits in plain old text files makes it easy to automate the client with simple shell scripts (extracting data from an YAML file may be more painful in such a context). We can surely mandate that each client should be able to read a standardized network.yaml file, but this only adds an additional mandatory component that is not needed yet (an YAML parser).

[q9f]

I see. Apparently, most of the values will not change anyways for most networks and the majority of clients decided to hard-code these constants for the sake of performance gains.

So, given that, future network configuration files could assume a mainnet.yaml as base line and only configure variables that are different to mainnet.

Closing this for now, the specs should stay this way.