add config validity conditions

[djrtwo]

Issue

There are many conditions that are implicit for a configuration of constants to be valid.

To name a few:

• MIN_ATTESTATION_INCLUSION_DELAY > 0
• MAX_DEPOSIT >= MIN_DEPOSIT
• ENTRY_EXIT_DELAY >= SEED_LOOKAHEAD

Proposed implementation

I propose we add an accompanying document on configuration to make these conditions explicit. This will aid in testing/testnets and will help if some party is looking to deploy a different instantiation of the protocol.

[vbuterin]

ENTRY_EXIT_DELAY > SEED_LOOKAHEAD

>=, no?

Also, is that even technically a requirement?

There's probably a pile of constants that need to be nonzero because we're dividing or moduloing by them; SHARD_COUNT and EPOCH_LENGTH come up as trivial examples.

There's also a bunch of divisibility requirements (eg.SHARD_COUNT % EPOCH_LENGTH = 0 is I think a requirement at least if we want things to work out nicely without extra special case code) that we don't need to think about because everything is a power of two, but people making alternate networks might decide to turn into not being a power of two.

A bunch of stuff that gets Merkle-tree'd must be a power of two.

[djrtwo]

>=, no?

yes (edited)

Also, is that even technically a requirement?

You're right it is not technically a requirement, but might be a source of error for validators depending on implementation and/or the helpers provided in the spec. If SEED_LOOKAHEAD > ENTRY_EXIT_DELAY, then although the seed was know SEED_LOOKAHEAD slots ago, the shuffling cannot be predicted until ENTRY_EXIT_DELAY slots ago.

[JustinDrake]

Another approach could be to have "reduced constant sets" for testing, maybe just one to start with. That way all implementers can converge on the same constant set for testing.

[hwwhww]

plus: LATEST_RANDAO_MIXES_LENGTH > MIN_SEED_LOOKAHEAD per #1027

[ralexstokes]

Was chatting w/ @djrtwo and this one came up:

ETH1_FOLLOW_DISTANCE << 24hrs

there is effectively a "dynamic constant" between the time of the Eth2Genesis event and the genesis_time. the range of this duration is between 24 and 48 hours, based on the computation performed in the deposit contract.

the ETH1_FOLLOW_DISTANCE should be no smaller than the minimum of this range to ensure that proposers will be able to submit useful Eth1Data in the early beacon chain blocks. if this invariant does not hold, early proposers will essentially have to coordinate to prevent consensus on the initial latest_eth1_data

[djrtwo]

I'm working on this (finally) :)

[djrtwo]

MIN_SLASHING_PENALTY_QUOTIENT >= WHISTLEBLOWING_REWARD_QUOTIENT to ensure no eth is minted in slash_validator

[ralexstokes]

ran into this one while working on some tests...

SHARD_COUNT >= SLOTS_PER_EPOCH is required to maintain the invariant that every validator is sampled exactly once every epoch to perform an attestation. the math under get_epoch_committee_count seems to break down if there are not enough shards

credits to @protolambda for recognizing this one

[JustinDrake]

MIN_SLASHING_PENALTY_QUOTIENT <= WHISTLEBLOWER_REWARD_QUOTIENT to avoid printing money when slashing

[JustinDrake]

"MAX_EPOCHS_PER_CROSSLINK should be a small constant times SHARD_COUNT // SLOTS_PER_EPOCH"

[ralexstokes]

SLOTS_PER_HISTORICAL_ROOT >= SLOTS_PER_EPOCH

[hwwhww]

I created a spreadsheet of phase 0 configuration: https://docs.google.com/spreadsheets/d/1xKwwjA3QO7k7VuqomsYc_uPeOSAV4VKRGo7m6Pb5TYA/edit?usp=sharing

Comments here or on the spreadsheet are most welcome and appreciated!