# FOCIL meets Delayed Execution

*by Thomas Thiery, February 10th, 2025*

### Reminder

- [**FOCIL**](https://eips.ethereum.org/EIPS/eip-7805): During `slot n`, inclusion list (IL) committee members build and broacast ILs filled with transactions pending in the public mempool over the consensus layer (CL) peer-to-peer network. All validators monitor and store ILs broadcast by IL committee members. The proposer then builds a full execution payload, and includes the union of transactions across all ILs. During `slot n+1`, attesters check whether the proposed execution payload actually includes the union of all transactions across ILs before casting their votes.
- [**Delayed Execution**](https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677): Attesters, during `slot n+1` only perform **static validation** (”pre-execution) checks before voting for a block instead of fully executing transactions included in the proposer’s payload. The actual execution of transactions is delayed until after the block is initially validated and attested to by the network.

### Issue(s)

In FOCIL, attesters sometimes need to verify ***why*** an IL transaction was excluded from the proposer’s execution payload. There are two simple cases:

1. The proposer’s payload omitted the transaction **because it was invalid** (e.g., failed signature checks or violated protocol rules).
2. The proposer **is censoring** and intentionally excluded a valid transaction from its payload.

In any case, attesters actually need to execute IL transactions missing from the payload to determine whether they should vote for the block (case 1), or not (case 2), which is at odds with delayed execution.

Now let’s dive a bit deeper and review actual scenarios that could be problematic:

- **Incorrect nonce:** A transaction is not valid because of its **nonce** (e.g., nonce too high). For example, consider an EOA with a state indicating that the next valid `nonce` is `2`, and suppose the IL includes two transactions from this EOA:
- `Transaction A` with `nonce 2`
- `Transaction B` with `nonce 3`

In principle, `transaction A` should be executed first, followed by `transaction B`. However, if the proposer constructs the payload by ordering the transactions as `transaction B` (`nonce 3`) followed by `transaction A` (`nonce 2`), `transaction B` will be considered invalid during the execution. In this case, the fault is easily attributable to the builder, and according to the delayed execution logic, `transaction B` will be skipped (i.e., not executed), and the proposer will still have to pay the inclusion cost that was fronted for the transaction.

- **Insufficient balance**: A transaction may also be invalid if the EOA’s balance is too low to cover the required transaction costs. In particular, we could one scenario that’s particularly difficult to solve with FOCIL and delayed execution.
- `Transaction A` is sent by account `0x1` and empties the balance of account `0x2` using account abstraction (AA, see EIP-7702) and send the funds to EOA `0x1`, while `transaction B` is sent by `0x2` but drains funds from `0x1` and sends them to `0x2`. - -
- FOCIL forces the proposer to include both transactions in its payload, otherwise it won’t satisfy the IL conditions and attesters shouldn’t vote for its block.
- However, including both transactions, in any order, will result in an invalid transaction (either `transaction A` or `B` depending on the order). It wouldn’t be fair to make the proposer pay the inclusion costs, since the fault actually lies with the transaction sender who submitted conflicting transactions to the public mempool that were then included in ILs.
- Moreover, assessing whether transactions are valid cannot be done solely with static validation checks. In this case, full execution is required to accurately determine their validity.

### Wat do?

Here are two potential solutions to address the issue:

1. **Selective Full Execution:**

Only perform full execution if an IL transaction is missing from the proposer’s payload; otherwise, proceed normally and delay execution. This approach assumes that a missing IL transaction is a red flag that warrants a deeper, full execution check to verify its validity. However, this method could be lead to griefing attacks—censoring or malicious proposers that intentionally exclude transactions would now also force full execution work and impact the network’s performance.

2. **Cost shifting to transaction senders:**

Inspired by [Monad’s carriage costs](https://x.com/MonadWhisper/status/1851964344369619326), this solution shifts the burden of inclusion costs onto the transaction sender’s reserve balance when insufficient balance issues arise. For instance, if conflicting transactions force the proposer to include both—resulting in one being skipped due to insufficient balance—the extra cost could be charged to the sender of the problematic transactions. This approach protects the proposer from unfair penalties and incentivizes senders to avoid submitting conflicting transactions. Although it adds some complexity to the original delayed execution proposal, it would likely resolve incompatibilities by providing a hybrid model that distributes inclusion costs to either proposers or transaction senders depending on the specific reasons transactions end up being invalid and skipped.