search

ethereum / execution-apis

Collection of APIs provided by Ethereum execution layer clients
Creative Commons Zero v1.0 Universal
908 stars 352 forks source link

Added engine_getPayloadV4 and engine_newPayloadV4 for Prague (EIP-7002) #528

Closed lucassaldanha closed 3 months ago

lucassaldanha commented 4 months ago

EIP-7002 has been confirmed for Prague and it requires changes in the ExecutionPayload leading us to ExecutionPayloadV4. This also impacts two Engine API methods, leading us to engine_getPayloadV4 and engine_newPayloadV4.

Please note that Prague will also have EIP-6110 that also introduce new fields to ExeuctionPayload. I noticed that @mkalinin has already an experimental spec for the changes here.

I am not sure what is the best way to consolidate those changes. We can either merge the changes related to EIP-7002 first, and later consolidate the changes from eip6110.md, or I can integrate eip6110.md changes into this PR. Let me know what is the best approach.

This is my first PR on this repo so I apologize if I missed anything in the process.

PS.: due to the size of the blobs field in the examples, we can't see the diff for src/engine/openrpc/methods/payload.yaml online.

lucassaldanha commented 3 months ago

Maybe try a single blob instead of 3?

Done. I have updated the examples with a single blob in each method.

lucassaldanha commented 3 months ago

Is it possible to omit them or shorten them significantly?

This is something to consider as well. But it might make the example an invalid object. I guess this depends on what we expect from the example (do we want it to be a valid object).

mkalinin commented 3 months ago

OpenRPC page wasn’t lagging with 3 blobs, tho we will have more of them every time a new version of getPayload method is created so reducing the example to a single blob makes sense to me. Not having a diff on GH is annoying too but I think we can deal with this complexity for the next few times, there should not be many changes in the future as Ethereum is ossifying 🔜 (don’t quote me on that).

lucassaldanha commented 3 months ago

I agree that we might need to look into a better way of handling the blobs as we add more and more versions. But I think this should be handled in a separate PR.

I took a quick look into how OpenRPC page loads the example data and it is smart enough not to push the whole content to the blobs to the DOM (it only adds 10k characters for each). And you can only copy the full content to clipboard. So even though the browser still needs to download the whole content, it prevents the page to getting too slow.

Reducing the number of blobs in each example to 1 per list results in a smaller footprint then before so at least we are not making things worse :)

lightclient commented 3 months ago

Sorry I didn't realize we already had the blobs in the cancun example. It would be great to improve this eventually, it's a lot of data to throw into text areas. But I don't see it as blocking now.