Jim McDonald

@rolfyone would the point that the item (thinking block, here) finished P2P validation and is passed on for processing a suitable point at which the event could be generated? As...

I mentioned this before, but I really don't think that the events output is the right place to contain this information. It would require some sort of continuous instrumentation from...

> The most immediate usecase is researches measuring block propagation through networks to inform EIP-4844 params. This isn't the main purpose of the events stream, though. If we're trying to...

> when a node see a new block / blob (gossip verified) This was the original intention of the block event. > when a node imports a block (fully validated)...

> Broadly, I think the lesson learned from the past is that this is an excellent endpoint to be "lenient in what you accept and strict in what you send"...

> I think it's directly counterproductive for tooling to require specific values to be present unless they need them for their own functionality. This point applies to both VC-like consumers...

I don't think we will be able to obtain perfect equivalence, not least because there are lots of values output by various beacon nodes for future forks and specific features...

> even simple things like renaming spec constants does make this challenging to achieve.... > > In testnets we didnt have 'required' fields defined and no clients seemed to have...