Merge 4b95936 into dc71750

Author: Marchhill

EIPS/eip-7805.md

@@ -2,7 +2,7 @@
 eip: 7805
 title: Fork-choice enforced Inclusion Lists (FOCIL)
 description: Allow a committee of validators to force-include a set of transactions in every block
-author: Thomas Thiery (@soispoke) <thomas.thiery@ethereum.org>, Francesco D'Amato <francesco.damato@ethereum.org>, Julian Ma <julian.ma@ethereum.org>, Barnabé Monnot <barnabe.monnot@ethereum.org>, Terence Tsao <ttsao@offchainlabs.com>, Jacob Kaufmann <jacob.kaufmann@ethereum.org>, Jihoon Song <jihoonsong.dev@gmail.com>
+author: Thomas Thiery (@soispoke) <thomas.thiery@ethereum.org>, Francesco D'Amato <francesco.damato@ethereum.org>, Julian Ma <julian.ma@ethereum.org>, Barnabé Monnot <barnabe.monnot@ethereum.org>, Terence Tsao <ttsao@offchainlabs.com>, Jacob Kaufmann <jacob.kaufmann@ethereum.org>, Jihoon Song <jihoonsong.dev@gmail.com>, Marc Harvey-Hill (@Marchhill) <marc.harvey-hill@nethermind.io>
 discussions-to: https://ethereum-magicians.org/t/eip-7805-committee-based-fork-choice-enforced-inclusion-lists-focil/21578
 status: Draft
 type: Standards Track
@@ -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,46 @@ 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`. It takes as an argument the IL committee member id, where the id is a value from `0`-`f` derived from ordering by validator index (i.e. lowest index has id `0`).
+- 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; a diverse set of strategies can strengthen censorship resistance. Transactions from the public mempool could be selected based on several factors such as:
+
+- Time spent pending in the mempool.
+- Priority fee.
+- Byte size: prioritising smaller transactions.
+- Nondeterminism: Introducing randomness can reduce overlap between ILs, leading to a larger IL when they are combined. Note that some overlap is desirable, otherwise the 1 of N honesty assumption would be undermined.
+- Bias: Picking some transactions more often than others in order to further reduce overlap between ILs. This should be done based on committee member id, for example the member with id `a` may be more likely to pick transactions with hashes that start with `a`.
+- The number of times a transaction has been included in reorged payloads.
+
+The IL has a maximum size of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB` for all of the unserialised transactions.
 
 ### Consensus Layer