Merge 265c96d into 831645e

Author: Marchhill

EIPS/eip-7805.md

@@ -14,7 +14,7 @@ created: 2024-11-01
 
 FOCIL implements a robust mechanism to preserve Ethereum’s censorship resistance properties by guaranteeing timely transaction inclusion.
 
-FOCIL (**Fo**rk-choice enforced **I**nclusion **L**ists) is built in a few simple steps:
+FOCIL (**Fo**rk-**c**hoice enforced **I**nclusion **L**ists) is built in a few simple steps:
 
 - In each slot, a set of validators is selected as inclusion list (IL) committee members. Each member builds and gossips one IL according to their subjective view of the mempool.
 - The proposer and all attesters of the next slot monitor, store and forward available ILs.
@@ -40,7 +40,7 @@ This section outlines the workflow of FOCIL, detailing the roles and responsibil
 - **`Slot N`, `t=0 to 8s`**:
 IL committee members construct their ILs by including transactions pending in the public mempool, and broadcast them over the P2P network after processing the block for `slot N` and confirming it as the head. If no block is received by `t=7s`, they should run `get_head` and build and release their ILs based on the node’s local head.
 
-  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.
+IL committee members may follow different strategies for constructing their ILs as discussed in [IL Building](#il-building).
 
 #### Validators
 
@@ -85,31 +85,37 @@ When validators receive ILs from the P2P network, they perform a series of valid
 
 ### Execution Layer
 
-On the execution layer, the block validity conditions are extended such that, after all of the transactions in the block have been executed, we attempt to execute each valid transaction from ILs that was not present in the block.
-If one of those transactions executes successfully, then the block is invalid.
+On the execution layer, an additional check is introduced for new payloads. After all of the transactions in the payload have been executed, we check whether any transaction from ILs, that is not already present in the payload, could be validly included (i.e. nonce and balance checks pass). If that is the case for any transaction, then an error is returned to the CL. Although the block is valid, the CL will not attest to it.
 
 Let `B` denote the current block.
 Let `S` denote the execution state following the execution of the last transaction in `B`.
+Let `gas_left` be the gas remaining after execution of B.
 
 For each transaction `T` in ILs, perform the following:
 
 1. Check whether `T` is present in `B`. If `T` is present, then jump to the next transaction, else continue with next step.
 
-2. Validate `T` against `S`. 
+2. Check whether `B` has enough remaining gas to execute `T`. If `T.gas` > `gas_left`, then jump to the next transaction, else continue with next step.
+
+3. Validate `T` against `S` by checking the nonce and balance of `T.origin`.
 
   - If `T` is invalid, then continue to the next transaction. 
 
-  - If `T` is valid, terminate process and assert block `B` as invalid.
-
-3. Execute `T` on state `S`. Assert that the execution of `T` fails.
+  - If `T` is valid, terminate process and return an `INVALID_INCLUSION_LIST` error.
 
-If `B` is full, the process terminates. Also note that we do not need to reset the state to `S`, since the only way for a transaction to alter the state is for it to execute successfully, in which case the block is invalid, and so the block will not be applied to the state.
+#### Engine API Changes
 
 We make the following changes to the engine API:
 
-- Add `engine_getInclusionList` endpoint to retrieve an IL from the `ExecutionEngine`
-- 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.
+- Modify `engine_newPayload` endpoint to include a parameter for transactions in ILs determined by the IL committee member. If the IL is not satisfied an `INVALID_INCLUSION_LIST` error must be returned.
+
+The full Engine API changes can be found in the [Execution APIs](https://github.com/ethereum/execution-apis/blob/572c54cd9d003f700bb5a57ce201606adbc8fc1c/src/engine/experimental/eip7805.md) GitHub repository.
+
+#### IL Building
+
+The rules for building ILs are left to the discretion of implementers. For instance, they may select transactions from the public mempool in various ways such as at random, by priority fee, or based on how long they have been pending. The IL has a maximum size of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB` for all of the unserialised transactions.
 
 ### Consensus Layer