Add EIP-7594 (PeerDAS) related changes

[0x00101010]

[jtraglia]

Hey @0x00101010, we need to create a new fulu spec in the specs directory too:

• https://github.com/ethereum/builder-specs/tree/main/specs

I believe this should be sufficient: fulu_builder.md

And I've noticed inconsistent indention in the deneb spec here (should be 4 space indentation):

• https://github.com/ethereum/builder-specs/blob/1569fc45d43e3ed2bed94ec6788c3f8fa7d2a4b2/specs/deneb/builder.md?plain=1#L37-L42

[0x00101010]

Hey @0x00101010, we need to create a new fulu spec in the specs directory too:

• https://github.com/ethereum/builder-specs/tree/main/specs

I believe this should be sufficient: fulu_builder.md

And I've noticed inconsistent indention in the deneb spec here (should be 4 space indentation):

• https://github.com/ethereum/builder-specs/blob/1569fc45d43e3ed2bed94ec6788c3f8fa7d2a4b2/specs/deneb/builder.md?plain=1#L37-L42

Awesome, done

[tersec]

Maybe it’s time to update this and remove the response body altogether for Fulu – and instead explicitly require the builder to publish the block and blobs? That feels more aligned with actual behaviour, and avoids wasting resources on a response that's often late and unnecessary.

This is reasonable, but the spec should also then explicitly require (spec verb: MUST) the relay/builder system to send out the resulting unblinded block.

[alextes]

my 2ct

1. we always return the response. ofc, with the rule that we only return the response once we're sure there's no way the proposer can actually affect much and equivocate. they're still a bit of a p2p broadcast / propagation boost although speaking for us at least we're already set up for fast propagation through Fiber network. plus, given header request delay + signed header return + block publish and propagate, it's virtually always latency in returning the signed header to us that results in missed slot, its exceedingly rare a header request is delayed too much at the outset, or that a signed header is returned in time but our publish or propagation took so long the slot was missed.
2. i'm not currently aware of any reason to keep the full response besides the small propagation boost. as long as the rule is to only return if our own publish is successful, that is naturally what we optimize for.

[jimmygchen]

Maybe it’s time to update this and remove the response body altogether for Fulu – and instead explicitly require the builder to publish the block and blobs?

Cross posting here for visibility - given we now have EL getBlobs which relies on receiving a block / data column sidecar, it might still be worth returning the revealed payload, so the proposer can help propagate the block too.

[tersec]

Maybe it’s time to update this and remove the response body altogether for Fulu – and instead explicitly require the builder to publish the block and blobs?

Cross posting here for visibility - given we now have EL getBlobs which relies on receiving a block / data column sidecar, it might still be worth returning the revealed payload, so the proposer can help propagate the block too.

I mean, I think that might be a little farcical given:

we always return the response. ofc, with the rule that we only return the response once we're sure there's no way the proposer can actually affect much and equivocate.

Other relay/builder systems behave similarly.

[ralexstokes]

Going to move the issue around changing the getPayload semantics here: https://github.com/ethereum/builder-specs/issues/119

Otherwise, we can go ahead and merge this in soon to have something to work towards as we begin Fusaka development.