Add EIP: General purpose execution layer requests #8432
Conversation
github-actions
bot
added
c-new
|
✅ All reviewers have approved. |
eth-bot
added
e-consensus
eth-bot
changed the title
eth-bot
changed the title
|
The commit d8dca5c (as a parent of d7acb6a) contains errors. |
|
|
||
| ## Test Cases | ||
|
|
||
| TODO |
There was a problem hiding this comment.
If you use HTML-style comments, the linter will make sure you replace them before going to review.
| TODO | |
| <!-- TODO --> |
|
|
||
| ## Security Considerations | ||
|
|
||
| Needs discussion. |
There was a problem hiding this comment.
| Needs discussion. | |
| Needs discussion. <!-- TODO --> |
| Request = RequestType ++ RequestData | ||
| ``` | ||
|
|
||
| Let `Requests` be the list of all `Request` objects in the block in ascending order by type. |
There was a problem hiding this comment.
ascending meaning by execution order?
There was a problem hiding this comment.
it's ascending order by type. intra type ordering is not defined in this eip
|
|
||
| ### Consensus Layer | ||
|
|
||
| Each proposal may choose how to extend `ExecutionPayload` to include the new EL request. |
There was a problem hiding this comment.
why wouldn't CL format just mirror the EL format?
There was a problem hiding this comment.
I don't really have a preference, it just seems more flexible for the CL to decide how to store the data instead of being forced to put all requests in a requests union type
|
|
||
| Each proposal may choose how to extend `ExecutionPayload` to include the new EL request. | ||
|
|
||
| A additional processing step is be added to `process_execution_payload` to iterate over and process all requests. |
There was a problem hiding this comment.
some things we will want to process before process_execution_payload and some things we will want to process after
iirc none of the current 'requests' are actually addressed inside process_execution_payload
given the validity semantics of the spec, this isn't really material to the structure introduced by this EIP
There was a problem hiding this comment.
okay i will remove this
|
|
||
| #### Header | ||
|
|
||
| Extend the header with a new 32 byte value `RequestsRoot`. |
There was a problem hiding this comment.
Can this be expanded to provide the complete structure of the RLP encoding of the header, along the lines of 4788
On a related note, given we're adding this new field, does this imply that 4844 and 4788 are required EIPs for this in the sense that they have both added new header fields that are prior to requestsRoot in the header field order?
This EIP introduces the generic notion of an EL triggered requests. This is intended to encapsulate many of the request types which are being considered in Prague (and beyond). For example, instead of having individual types in the header, body, execution payload, etc. we can have a single generic
Requestthat encompasses several different types.