payload equivocations and PTC timeliness

The PTC votes on the timeliness of payloads. They do this **before** executing it, that is **before** any return from the engine on a call to newPayload or FCU.

For clients that do not check the blockhash of the execution payload on their own, this could lead to a situation in which the payload is voted to be timely but not having the right hash (the hash promised in the bid, and stated in the envelope, it's not guaranteed to be the RLP hash form the actual payload).

The envelope is signed so there's little surface for this to lead to an attack, but this compounding with the fact that payload equivocation is not penalized, could possibly lead to some weird scenarios.

Say for example the builder sends immediately such an invalid payload, the PTC votes for it being available. The builder also sends very late the actual valid payload.

The next proposer would not have votes to be able to reorg the payload. If he hasn't executed the payload it will build on empty and will get the attestations from attesters that haven't executed the right payload. However, any attesters that did get the right payload will vote against the next proposer.

In principle this is not a big issue because the equivocation should not propagate over gossip given the gossip rules. But it leads to a split view in which a very little stake could split the PTC one way and the attestation another one to create an ex-ante reorg.