Tunable genesis time

[djrtwo]

Currently the genesis time is not very tune-able and is instead always at a timestamp where genesis_time % MIN_GENESIS_DELAY == 0. Due to the desire to generally configure testnets at "mainnet" config, MIN_GENESIS_DELAY == 24hrs and thus genesis_time is always at midnight UTC for mainnet configuration.

Depending on who is working on the testnet (e.g. @q9f), this can lead undesirable late nights.

Background

The genesis time is computed such that regardless of when MIN_GENESIS_ACTIVE_VALIDATOR_COUNT is hit, genesis_time is always at the exact same time of day.

genesis_time=eth1_timestamp - eth1_timestamp % MIN_GENESIS_DELAY + 2 * MIN_GENESIS_DELAY

This is so even if the exact day is known the exact time of some day is known so the teams can plan accordingly. (this being a very important feature is probably debatable).

Option 0

Don't change anything and just deal with it.

If @q9f does weekly testnet restarts (under discussion), this will suck for him but be great for our friends in Australia.

Option 1

This option preserves the notion of knowing exactly what time of day genesis will be, but instead allows us to tune that time. It is backwards compatible for networks that use the default configuration values.

It simply takes the previous calculation and adds GENESIS_TIME_OFFSET to the result to tune the precise time of day. A GENESIS_TIME_OFFSET of 0 would result in the same genesis time as in current specs.

genesis_time=(
    eth1_timestamp
    - eth1_timestamp % MIN_GENESIS_DELAY
    + 2 * MIN_GENESIS_DELAY
    + GENESIS_TIME_OFFSET
)

For example, if we use MIN_GENESIS_DELAY = 86400 and GENESIS_TIME_OFFSET = 21600 (6hrs), then genesis time will be at 6am UTC.

Option 2

This option does not preserve knowing exactly what time of day genesis will happen. This instead just uses a fixed offset from the initial eth1 block timestamp at which point genesis conditions were first met.

genesis_time=eth1_timestamp + GENESIS_DELAY

In cases in which MIN_GENESIS_ACTIVE_VALIDATOR_COUNT is hit prior to MIN_GENESIS_TIME - GENESIS_DELAY, genesis will be approximately at MIN_GENESIS_TIME (thus highly predictable on most smaller test/devnet scenarios). The time becomes much less predictable in larger testnets and/or mainnet where the MIN_GENESIS_ACTIVE_VALIDATOR_COUNT is not guaranteed to happen at a certain time.

[q9f]

So, my personal opinion on this as I brought this up. This is low priority and just a cosmetic change.

• 🤷 If we stick to Option 0, we'll be probably fine.
• ✖️ Option 1 is just unnecessarily adding another constant.
• ✔️ I'm personally in favor of Option 2.
  • 📝 It's not much of a difficult change, requires a minor spec version bump though.
  • 🥳 It introduces some randomness and makes launching chains so much more fun.
  • ⏳ It's still very predictable especially when launching testnets.
  • 👶 It significantly reduces complexity of the genesis_time formula.

[paulhauner]

I don't feel strongly, but would lean towards option 2. If we do this, I would suggest doubling MIN_GENESIS_TIME to 48 hrs for mainnet.

Perhaps this is tangential, but I would even advocate for making MIN_GENESIS_TIME a few days to give us plenty of time to test the genesis state and distribute it in binaries.