Adrian Sutton

Teku is able to create a block straight away (and even a few slots before the epoch start to allow for clock skew though obviously you don't want to be...

One thing we could do, suggested by SigP is to process the next slot as soon as a block is imported. Probably only do it for the canonical chain and...

We're seeing consistently good performance creating blocks now. There's ongoing performance work under other tickets so will close this one.

The catch here is that sync committees perform duties every slot. It probably makes more sense to add a gauge that reports the number of local validators in the current...

We'll need a way to specify the genesis state (or some state to start generating from). If checkpoint sync is used our anchor state will be from close to chain...

Also in terms of where to put the new service, it probably makes sense to put it in a package alongside `HIstoricalBlockFetcher` in `:beacon:sync`.

We don't actually have a slot to state root mapping in our database so likely can't optimise this for finalized states. Could get state root from the protoarray for non-finalised...

Looks like the specific parameters for activation aren't set in stone yet. We should implement this but it probably needs to be off by default until the parameters are settled.

The EL will already optimise this so I wouldn't try to special case it. If we were going to special case it, we'd be better off skipping the processing of...

There is a slight catch here we need to think through. Currently you can run teku without connecting to an eth1 endpoint at all which is fine pre-merge and quite...