# Same Slot vs. Next Slot Inclusion List

When deciding on an inclusion list design, a fundamental property to consider is _when_ the inclusion list is enforced from the perspective of the inclusion list sender and its relationship to the builder or proposer obligated to include the ILs via the protocol.

## EIP-7547
In the context of [EIP-7547](https://eips.ethereum.org/EIPS/eip-7547), the proposer itself acts as the inclusion list sender, which controls the inclusion list's release timing. This design enforces inclusion lists for the **Next Slot**.

### Timeline
- **Slot `n-1`**: A user sends a censored transaction.
- **Slot `n`**:
- The proposer releases inclusion list that explicitly references the censored transaction.
- Attesters vote on the inclusion list, acknowledging inclusion list is valid.
- The proposer for slot `n+1` updates their block-building engine with the inclusion lists received in slot `n`.
- **Slot `n+1`**:
- The proposer includes slot `n`'s inclusion list in their block and releases the block.
- Attesters confirm the block, ensuring it correctly incorporates the inclusion list.

From the perspective of the transaction's sender, the transaction submitted in slot `n-1` is ultimately included in slot `n+1`, introducing a **one-slot gap** between proposal and enforcement.

## EIP-7805
In the context of [EIP-7805](https://eips.ethereum.org/EIPS/eip-7805) ([FOCIL](https://ethresear.ch/t/fork-choice-enforced-inclusion-lists-focil-a-simple-committee-based-inclusion-list-proposal/19870)) introduces flexibility in inclusion list design by decoupling the responsibility of sending the inclusion list from the proposer. Instead, a new **inclusion list committee** is responsible for generating and releasing inclusion lists, and under a different time interval than block release interval. This opens up both inclusion list designs: **Same Slot** and **Next Slot**. Below are timelines for each design:

### Same Slot Timeline
- **Slot `n`**:
- The proposer releases a block for slot `n`.
- A user submits a censored transaction during this slot. (The timing of the transaction submission is order-independent relative to the block release)
- The inclusion list committee observes the censored transaction and releases an inclusion list for slot `n`.
- Attesters of `n+1` lock their views on the inclusion lists.
- The inclusion lists for slot `n` becomes available for the slot `n+1` proposer.
- The proposer updates their block-building engine using the inclusion list from slot `n`.
- **Slot `n+1`**:
- The proposer releases the block for slot `n+1`.
- Attesters validate and vote to confirm that the block correctly includes the inclusion list and its transactions.
- **User Experience**:
- From the user’s perspective, the transaction submitted in slot `n` is included in the slot `n+1` block.

### Next Slot Timeline
- **Slot `n`**:
- The proposer releases a block for slot `n`.
- A user submits a censored transaction during this slot. (The order of the transaction submission relative to the block release is independent)
- The inclusion list committee observes the censored transaction and releases an inclusion list for slot `n`.
- **Slot `n+1`**:
- The proposer for slot `n+1` releases a block without the censored transaction
- Attesters vote on the slot `n+1` block.
- During this slot, attesters of `n+2` lock their view on the inclusion list generated in slot `n`.
- The proposer for slot `n+2` updates their block-building engine using the inclusion list from slot `n`.
- **Slot `n+2`**:
- The proposer releases the block for slot `n+2`.
- Attesters validate and vote to confirm that the block correctly incorporates the inclusion list.
- **User Experience**:
- From the user’s perspective, the transaction submitted in slot `n` is ultimately included in the slot `n+2` block.

### **Arguments for Same Slot vs. Next Slot Inclusion Lists**

#### **Same Slot Inclusion Lists: Why They’re Better**
1. **Easy to Reason About**:
- Transactions submitted in slot `n` are enforced in the very next slot (`n+1`).
- Simplifies mental models for users, although many may not care.
2. **Better User Experience**:
- No delay in enforcement gives users confidence that censored transactions are acted on immediately.
3. **Easier to Specify**:
- Consensus spec is more straightforward.
- There’s no need to manage the intricacies of deferring to next slot.
4. **Cleaner Attester Lock Views**:
- Attesters lock their views of slot `n` to enforce for slot `n+1`, rather than delaying enforcement to `n+2` or have `n+1` attesters lock view for inclusion lists of `n`.
#### **Next Slot Inclusion Lists: Why They’re Better**
1. **More Time for Propagation and Block Building**:
- **Inclusion list propagation**:
- With next slot, inclusion lists gain 12 seconds for propagation (up from 5 seconds under same slot).
- This extra time ensures the inclusion list reaches all participants.
- **Block building time**:
- Proposers gain 8 seconds (up from 2 seconds under same slot) to build inclusion lists into blocks.
- This extended window reduces stress on block-building engines.
2. **Simpler Engine API**:
- Instead of introducing a new endpoint to update the proposer with inclusion lists, the existing `fork_choiceUpdated` payload can be overloaded with an `attribute` for inclusion lists.
- This reduces implementation complexity for clients.
3. **Future Compatibility**:
- PeerDAS and ePBS may benefit from more time for inclusion list propagation.

As it currently stands, unless there’s a strong argument for using the next slot inclusion list, the current spec and prototype will default to the same slot design. This approach will remain in place unless proven to be flawed through devnet testing and benchmarking. If anyone has thoughts on why we should switch to the next slot inclusion list design, I’d be very interested in hearing them. Let us know!