Blocks V3: resolve data type - source relationship

[tbenr]

As discussed in #377 and #386, Blocks V3 enforce BNs to produce unblinded content when execution payload is built locally, and return a blinded content only when is built remotely via builder APIs. This is only enforced via API description:

The beacon node must return an unblinded block if it obtains the execution payload from its paired execution node. It must only return a blinded block if it obtains the execution payload header from an MEV relay.

The response header variable communicating what happened is named execution_payload_blinded which is not really tight to how the block has been produced, but rather the data structure sent back to VC. In theory it is possible for BN to blind locally produced blocks.

I see two possible paths here:

1. rename execution_payload_blinded to execution_payload_builder to enforce at schema level the important distinction is the block source rather than the data structure.

2. relax the assumption that blind -> builder and add a new header execution_payload_source: enum['local', 'builder'] there is an inconsistency in field names that is currently resolved by a spec rule saying.

I was initially strongly for 2. but the more I think about this the more the less opinionated I become.

[mcdee]

Is there really much of a requirement to do this? Yes we have a 1:1 relationship for (builder->blinded) and (local->unblinded), but that's on purpose, as you say, and defined in the API documentation. If the 1:1 relationship changes (for example if we have a third way of generating blocks) then the chances are that whatever causes those changes will require a v4 of the endpoint anyway.

[tbenr]

Is there really much of a requirement to do this?

No, but since the topic come up a couple of times, I opened this just in case we feel it worth changing. I was initially in favour of a change, but not that much at the moment.

[g11tech]

i would rather have this relationship be straightfoward in the specs so i am /+1 for this