--initial-state improvements

I used this amazing feature and it was simply magical to get a teku up to head in less than a minute. congrats.

there could be a couple of things that would make this even more magical

• cache the state in the data dir, once it’s downloaded don’t download another state
• if there is a an already synced chain, disregard the given intial state or something along those lines

it seems that if you give the state from an url, and the argument is still there after restarting the node, it sometimes (all the times?) crashes, probably because the initial state changes as it’s given like --initial-state=http://teku-beacon-archive:5051/teku/v1/beacon/states/finalized

the benefit of adding the initial state argument and leaving it is that you could have a statefulset of tekus that can scale up at a moment’s notice

[ajsutton]

Thanks for reporting this. Definitely worth looking into improving the usability here. There are some interactions with checking the weak subjectivity period which adds some security requirements around this (which is why Teku is currently always downloading the state again and exiting if it doesn’t match) but I suspect they can be handled in a better way without losing security. Will just require a bit of thought.

[tzapu]

the only thing i am worried about is that if the intial-state flag is set and the node restarts (usually after syncing completely) it fails to start. the rest of the potential issues seem like they would happen rarely and, in my head at least, sound like they should be handled manually. From that point of view “What if we only use --initial-state if the database doesn’t yet exist (ie first run) and ignore it afterwards.” sounds perfect to me