Update EIP-7805: expand on EL changes #9381
Conversation
Marchhill
commented
Feb 19, 2025
•
Marchhill
commented
- Add Engine API changes from Add initial FOCIL spec execution-apis#609
- Clarify IL building process is unspecified in EL section
- Correct statements about block being invalid if IL not satisfied
- Clarify some details of EL / engine API changes
github-actions
bot
added
c-update
File
|
EIPS/eip-7805.md
Outdated
|
|
||
| #### IL Building | ||
|
|
||
| The IL should be built using the following rules: |
There was a problem hiding this comment.
Actually we don't impose IL ordering rules. Some clients may prefer to pick transactions based on priority fee while others may choose different heuristic algorithms. We expect more diverse approaches on IL construction would foster censorship resistance.
There was a problem hiding this comment.
Makes sense, I moved the previous section on IL building to here and added a bit about it being optional. This section seems like a more suitable place for it
Co-authored-by: JihoonSong <jihoonsong@users.noreply.github.com>
EIPS/eip-7805.md
Outdated
|
|
||
| #### IL Building | ||
|
|
||
| By default, ILs are built by selecting raw transactions from the public mempool, ordered by priority fees, up to the IL’s maximum size in bytes of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB` per IL. Additional rules can be optionally applied to maximize censorship resistance, such as prioritizing valid transactions that have been pending in the mempool the longest. Implementations are free to choose their own ordering rules. |
There was a problem hiding this comment.
There is no default rule. While ordering and selecting transactions by priority fee is probably the most anticipated strategy, it should remain as optional, too.
There was a problem hiding this comment.
This was moved from elsewhere in the EIP but maybe should be changed
There was a problem hiding this comment.
Regarding adding this to the EIP, I want to ask other people's opinions. cc @soispoke @terencechain
There was a problem hiding this comment.
previously it was here: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7805.md#il-committee-members
There was a problem hiding this comment.
Ah, right, my bad. I prefer to keep it as is and have only engine API changes. I think that gives us better readability.
There was a problem hiding this comment.
imo it's nice to have it here so the EL changes are contained in this section, easier to know what needs to be implemented. You think having an extra section here is bad for readability?
There was a problem hiding this comment.
From the big picture perspective, yes. The original version provides a guidance on how IL committee members could construct their ILs when a reader reads the role of IL committee member. This change removes it and hence brings ambiguity compared to before.
There was a problem hiding this comment.
I made a change to mention IL building in that earlier section but then expand on it in the EL section, wdyt?
There was a problem hiding this comment.
I've left comments on nit and suggestion. I wanted to focus a little bit more on delivering possible strategies.
|
The commit 3053382 (as a parent of 0793ca2) contains errors. |
| - Modify `engine_newPayload` endpoint to include a parameter for transactions in ILs determined by the proposer | ||
| - Modify `engine_forkchoiceUpdated` endpoint to include a field in the payload attributes for transactions in ILs determined by the proposer | ||
| - Add `engine_getInclusionListV1` endpoint to retrieve an IL from the `ExecutionEngine`. | ||
| - Add `engine_updatePayloadWithInclusionListV1` endpoint to update a payload with the IL that should be used to build the block. This takes as an argument an 8 byte `payloadId` of the ongoing payload build process, along with the IL itself. |
There was a problem hiding this comment.
| - Add `engine_updatePayloadWithInclusionListV1` endpoint to update a payload with the IL that should be used to build the block. This takes as an argument an 8 byte `payloadId` of the ongoing payload build process, along with the IL itself. | |
| - Add `engine_updatePayloadWithInclusionListV1` endpoint to update a payload with the IL that should be used to build the block. This takes as an argument an 8 bytes `payloadId` of the ongoing payload build process, along with the IL itself. |
|
|
||
| #### IL Building | ||
|
|
||
| The rules for building ILs are left up to the implementers discretion. Possible strategies include randomly choosing from the transaction pool, ordering by priority fee, time spent pending in the mempool, etc. |
There was a problem hiding this comment.
| The rules for building ILs are left up to the implementers discretion. Possible strategies include randomly choosing from the transaction pool, ordering by priority fee, time spent pending in the mempool, etc. | |
| The rules for building ILs are left to the discretion of implementers. For instance, they may select raw transactions from the public mempool in various ways such as at random, by priority fee, or based on how long they have been pending. This process continues until the IL reaches its maximum size of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB`. |
