Paul Harris

We (teku) load `config_name` first, then preset, that's the order it was previously loaded... just in case anyone is following that ordering... https://github.com/Consensys/teku/pull/7510

After discussion, I've ended up changing teku to no longer load the local `config_name`, and we're defaulting the constants that got moved https://github.com/Consensys/teku/pull/7566 It could potentially hide some 'bad config',...

i wouldn't be against a v2 without the count - its pretty trivial to get the count from an array... I guess that translates to 3 suboption 2 being my...

its non trivial for us to get he timestamp that it arrived, im not sure how practical it would be.... and our 'arrival' time is when we look at it....

i've got a CLI for triggering a block event after validation, but its not on by default because the optimistic flag at that point is basically meaningless..

One option may be - block validated event (new) - after block passes its validation but hasn't been imported - this could just be block root. - block imported event...

Is the key point block propagation, or is the key point processing time from client to client? what are we trying to measure? eg. if we get ``` block: 0x.......

> (I'm still voting for 2 as per the list of suggestions by @dapplion, it makes most sense to me as to be the point at which we are interested...

I agree completely, this isn't really a great way to measure propagation, especially if you want timely data.

If that's what we want, maybe a block_valid with a timestamp that validation completed would suffice, and would need to define the valid term, id probably suggest when it has...