Guidelines for implementing Görli-based testnets

[zah]

This is adding a new markdown file. You can see it here:
https://github.com/ethereum/eth2.0-pm/blob/d22b82381e284471580a7699d6e8a0175d969bf9/interop/deposit_contract_testnets/README.md

[djrtwo]

looks good to me for now.

Merging this at end of day unless there are further comments

[nisdas]

even if we use a pre-populated validator set , we will also correspondingly need to send deposits with those validator's keys. Otherwise we would have differences in the deposit root in our local trie and in the contract. Also the deposit count we get from contract will be different from what we have in our current state. The monitoring of eth1 deposits should be from when the contract is deployed

[GregTheGreek]

We can pre-populate if we agree on a set of validator keys, like we did at interop.

Doing so it would be valuable to perhaps "reserve" a set of keys per client, so those clients can reliably do validator tests.

[zah]

Yes, the initial keys are agreed upon in the sense that both clients load the same genesis state file.

The discrepancy with the data in the contract is a real problem, but our current implementation makes two compromises that seems reasonable for now:

1. It takes into account the number of validators in the genesis state when comparing the validator counts.

2. It monitors the contract only for deposit events. Only the locally computed root is considered valid. Since there is consensus on the latest Eth1 block, the set of deposit events in implicitly agreed upon as well.

[zah]

I like the idea of "reserving" mock keys for the different clients. I think something like this can be described in the README file of each network. For example, we can clarify the number of used mock keys and the suggested assignments (e.g. any discovered mock key with index for which N % 10 == 6 is intended for LodeStar). Please note that it's also possible to discover the number of used mock keys and their indices just by examining the public keys of the validators appearing in the genesis state.

[GregTheGreek]

Please note that it's also possible to discover the number of used mock keys and their indices just by examining the public keys of the validators appearing in the genesis state.

For sure! Just a quick&dirtier solution might be to reserve them... /shrug

[nisdas]

I do like the idea of reserving keys for different clients to facilitate equal participation. However if we proceed having a mock genesis state with pre-populated validators we would need to also set a custom eth1Data for each genesis state that we create. Is there any reason we cant watch deposit events from contract deployment ?

1. It would mirror more closely to how it would work in mainnet.
2. We wouldnt need to implement one off logic just for the purposes of running a multi-client testnet.
3. If we want to pre-populate with our desired validator set, that can be easily done by sending deposits with those keys included. For 64 deposits, it would take less than 2 minutes on Goerli for all of them to be mined.

[zah]

There was a little bit of additional reasoning behind this proposal that I didn't explicitly express.

The ability to start from a trusted genesis file that includes a list of validators and a reference to an Eth1 block is something that each client will have to implement eventually in order to handle the situation where the user has been offline for a period greater than the weak subjectivity period.

In this situation, you'll have to trust everything that you see in a supplied snapshot state. It's better to add additional sanity checks verifying that the Eth1 contract data is consistent with this trusted snapshot, but the compromise for now is to just not enforce these sanity checks.

For me, the most significant simplification from having pre-populated genesis states is not so much about the quick start-up times, but rather about reducing the required management of GoETH funds and their associated private keys.

[nisdas]

Afaik we do have ways to reduce the amount of goETH required and also we should be able to successfully recycle them for each testnet. For the purposes of interop starting from a common genesis state maybe best, we can look at watching deposit events from contract deployment maybe later.