How does EIP-4844 affect the current paradigm where the validator outsources block construction to the builder through a relayer network & mev-boost middleware?

To understand this, we must look at what's new in the consensus objects in EIP-4844:

• Beacon block body contains a new blob_kzg_commitments field
• Execution payload contains signed_blob_transaction and versioned_hash
• Gossip wrapper signed_block_and_blobs_sidecar for coupling block and blobs on p2p

It's important to note that signed_blob_transaction, blob_kzg_commitments and versioned_hash need to be aligned. (i.e., blob matches commitment and commitment matches versioned hashes)

Credit: Protolambda (EIP4844 workshop)

With these new fancy fields, what's the new interaction between builders, relayers, mev-boost and validators?

1.) As we know, the transactions are hidden when a validator commits to a block header. With transactions hidden, validators can't compute blob_kzg_commitments commitments on their own to construct a block body. Therefore, as part of the payload header return, relayers, and mevboost must return the commitments so that validator can successfully construct block body

2.) As the validator signs and submits the blind block, the blind block's body must use the same commitments from earlier. Failing to attach the same commitments will result in a failed block proposal

3.) As the relayer returns the full block for the validator to gossip (the relayer should also gossip), the blobs sidecar should get revealed and returned

Credit: jimmygchen (PR 58)

What are some considerations with this new paradigm?