# FOCIL with Delayed Execution under EPBS (EIP-7732)

This doc summarizes timelines for EIP-7732 and EIP-7805, highlighting pros and cons when combining them together.

### EIP-7732 Timelines:
• t0: Builders submit bids, proposer submits the beacon block
• t3: Beacon attestations submitted
• t6: Execution payload revealed
• t9: Payload attestations submitted

### EIP-7805 Timelines:
• t0: Proposer submits the beacon block
• t3: Beacon attestations submitted
• t8: Inclusion lists submitted
• t9: Inclusion list freeze deadline
• t10: Next slot proposer updates the block with the inclusion list

### Desiderata:
We want to preserve the following desiderata
• The execution payload remains decoupled from the consensus block. If an execution payload is invalid, the beacon block still exists on-chain. Extending this to EIP-7805, even if an inclusion list is not satisfied, the beacon block persists on-chain.
• Execution payload validation occurs between the execution payload reveal time and the next slot’s beacon attestation deadline. Instead of having only 2 seconds to validate the execution and data availability of the block, we gain 9 to 12 seconds to validate execution which also includes blob sidecars.

### Naive Combined Timelines:
We want to ensure that the two desiderata remain intact when both EIPs are implemented together.

• t0: Builders submit bids, proposer submits the beacon block (should satisfy ILs of n-1, example: [FOCIL conditions](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870#textil-conditionality-17))
• t3: Beacon attestations submitted
• t6: Execution payload revealed (should satisfy beacon block of n)
• t8: Inclusion list submitted (should be based on payload of n)
• t9: Payload attestation submitted / Inclusion list freeze deadline
• t10: Builders update bids with the inclusion list, proposer proposes the beacon block

### Observations:
• When the payload reveals at t6, attesters still have 9 seconds to verify that the execution payload satisfies the inclusion list—much more than the 2 seconds we have today. This brings the pipelining benefits of EIP-7732 to EIP-7805.
• When the payload reveals at t6, inclusion list committee members only have 2 seconds to verify the execution payload and submit inclusion lists—less than the 6 seconds they have today. (h/t Julian pointed out that ILs don't necessarily need to be submitted before the payload is revealed. The tradeoff is IL txs may be invalidated more often, but that remains to be seen)
• When the next slot proposer updates the block with the inclusion list, it should still have 1 second to make the update, which is minimal. With EIP-7732, builders will also need to update their bids. Same as today.

### Tradeoffs:
As one can see, the obvious tradeoff at play is that if the payload reveals at t6, we gain the benefits of delayed execution validation, but the inclusion list committee has less time to verify the payload and propose the inclusion list. The inclusion list committee is constrained by reduced time compared to before. There’s no silver lining to this solution unless we adopt one of the following approaches.

1. **Move Inclusion List and Payload Attestation to the Same Time:**
• t0: Builders submit bids, proposer submits the beacon block
• t3: Beacon attestations submitted
• t5: Execution payload revealed*
• t8: Inclusion list and payload attestations submitted
• t9: Inclusion list freeze deadline
• t10: Builders update bids with the inclusion list, proposer proposes the beacon block

*We gain about 1 more second here, but it’s unclear whether that’s enough.

2. **Shift Inclusion List Design from the Same Slot to the Next Slot:** Inclusion lists for slot n should be satisfied in slot n+2:
• t0 (slot n): Builders submit bids, proposer submits the beacon block
• t3 (slot n): Beacon attestations submitted
• t5 (slot n): Execution payload revealed
• t9 (slot n): Payload attestations submitted
• t3 (slot n+1): Inclusion list submitted
• t9 (slot n+1): Inclusion list freeze deadline
• t10 (slot n+1): Next slot proposer updates the block with the inclusion list

### Conclusion:
There’s no silver lining solution to this problem. Pipelining execution verification magnifies benefits but introduces a tradeoff— the inclusion list committee has less time to verify the payload, prepare, and submit inclusion lists. This issue isn’t a blocker for inclusion lists in a delayed execution scheme using EIP-7732, but it’s crucial to understand the problem deeper and carefully consider the best path forward. Above, we propose two possible solutions.