EIP-7685: General Purpose Execution Layer Requests

[refcell]

Description

EIP-7685 introduces a way of sharing execution layer requests with the consensus layer.

Full inclusion of EIP-7685 on L2 requires batch format changes, gossip format changes, and more.

To support EIP-7685 on L2, the following are needed.

• Infer the block content based on fork, and add the missing attributes.
• Sanity-check in the CL that the EL didn't include any requests. (op-node)
• EL requests need to be persisted, or recomputed, somewhere if we do want to have them. Since the batch-submitter has to be aware of them, for other nodes to replicate them from the batch data.
  • The EL requests could be stored in the op-node until the batch-submitter consumes them.
• The engine API engine_newPayloadV4 is required to build prague blocks, but includes a executionRequests attribute. We'll need to pass an empty list as argument.

References

• Pectra Devnet 5 EIP List
• Proto's list of Pectra EIPs
• Pectra support on the OP Stack tracking issue: OP Stack: Support Pectra (Isthmus) optimism#12435

[tynes]

I don't think we will need any EL requests for anything and should assert that they are empty but still check that they are not None or nil

[emhane]

keen on implementing this spec @meyer9 ?

check out the layout to use here https://specs.optimism.io/protocol/exec-engine.html

can also check out the reth impl of the l1 spec to get a better understanding of the smol difference for L2 which should check that arg executionRequests is always empt list
https://github.com/paradigmxyz/reth/blob/5db01290f877ea4b8762c25a343bbcb6ea053ebb/crates/rpc/rpc-engine-api/src/engine_api.rs#L253-L285

[protolambda]

+1, the gist of Pectra op-stack support I wrote was written at a time when there was more uncertainty whether or not we needed to utilize the Pectra Requests feature for any OP-Stack purposes. Currently, we do not have to.

So I recommend to not change the batch-format, and to make the requests-root part of the block-header (for Pectra compat) but make it implied (root of an always-empty list of requests). Then, when receiving a block from P2P you can assume an empty list of requests. And when building a block, you can assume an empty list of requests. And then there is nothing new to batch-submit. And EL-sync rules can exchange blocks without special changes, and just exchange the block with the empty requests-root. Note that unlike withdrawals, requests are not retained in the execution engine after block execution, and thus also not synced via EL p2p.

The other EIPs, that introduce requests for various L1 beaconchain related things, can all be adapted such that even if the contract exists and emits an event, no request is actually put in the block. This is a very tiny simple diff.