Add block v3 endpoint

[jimmygchen]

Description

Add v3 block endpoint, beacon API spec here: ethereum/beacon-APIs#339

This has been included in dencun-devnet-8 spec.

[eserilev]

if no one else is working on this, I'd love to pick this one up

[realbigsean]

I don't think anyone's working on it, feel free to pick it up!

[eserilev]

I've been digging into get_payload and some of the upstream logic over the last 2-3 days

i have a really ugly branch that creates a new "v3 path" starting at produce_block_with_verification all the way down to get_payload. The things i did there were unspeakable and that branch should probably never make it out of my local git repo 😅

theres some cleanup I could do with that new v3 path that might make it more palatable, but it still requires duplicating a significant amount of existing logic

I did get quite comfortable with the full flow and now I'm sort of starting over. The biggest issue I'm having is that everything depends on the Payload: <AbstractExecPayload> generic type parameter, which is either FullPayload or BlindedPayload.

I thought about creating some other Payload struct that also implements the AbstractExecPayload trait. This new struct can either be Full or Blinded depending on what eventually happens down the line in get_payload

Theres some issues with this, as getting this new Payload struct to correctly implement the relevant traits while also being potentially a full or blinded payload is a bit... interesting. still investigating if this is a viable path or not.

theres maybe also a way to remove the generic type param from the get payload flow... or maybe create a new type thats a bit more flexible? I'll put some thought into that.

If anyone here has feedback, or maybe a general idea I could explore let me know. Also, I noticed the devnet-8 tag on the issue. I'm not sure how big of a blocker this new endpoint is for devnet-8. If theres a hard deadline for this endpoint please let me know. Thanks!

[michaelsproul]

@eserilev I think removing the Payload type parameter sounds like the most viable option. The method could return an enum with either Blinded or Full, and then the caller can handle packing that into a block (and returning that on the HTTP endpoint)

[michaelsproul]

There may be some problem with this though, I haven't had a chance to look at your branch

[jimmygchen]

Hi @eserilev I've removed the deneb-devnet-8 label, we're still working on client interop testing, so this isn't really blocking us ☺️ .

cc @realbigsean

[eserilev]

I've left some comments in #4629

If anyone has a chance to take a look at my comments and/or my current progress that would be nice. I think I've found the most viable path forward here.

[jimmygchen]

Completed in #4629 🎉 Thank you @eserilev