# A deep analysis of Stateless FOCIL

> This doc has been the result of a collaborative effort between:
> Ignacio Hagopian, Guillaume Ballet, Thomas Tiery, Julian Ma and Carlos Perez.


## Introduction

Ethereum’s roadmap includes ambitious proposals aimed at improving scalability, decentralization, and censorship resistance. Two such proposals are **Ethereum statelessness** – eliminating or reducing the need for certain types of nodes (like validators) to store the entire state – and **Fork-Choice Enforced Inclusion Lists (FOCIL)** as defined in [EIP-7805](https://eips.ethereum.org/EIPS/eip-7805), which uses validator committees to enforce the inclusion of certain transactions in blocks. Individually, each approach addresses a different problem: statelessness works arround the **unbounded state growth problem** and node resource requirements, while FOCIL confronts **transaction censorship**. In combination, however, these proposals must peacefully coexist. This document provides an in-depth analysis of how statelessness and FOCIL can **benefit one another** in Ethereum’s evolution, the **requirements** and scenarios each type of statelessness imposes on block producers, and the **friction points** and network overheads that may arise when both mechanisms are active.
We also discuss open problems such as Transaction invalidation, Network overhead, Bandwidth consumption and to assess whether statelessness techniques could help mitigate them.

> The document will assume that all the concepts listed below are known and understood. If you're not convinced you fully understand them, it's suggested to take a look to them.

<details>
<summary><b>Statelessness Approaches in Ethereum and Block Producer Requirements</b></summary>

Ethereum’s push towards “Stateless Ethereum” involves several models that differ in **degree of state storage** and who bears responsibility for providing state data (via *witnesses*, i.e. cryptographic proofs of state, [see more about this here](https://dankradfeist.de/ethereum/2021/06/18/pcs-multiproofs.html)).
One of the major points of contact that FOCIL and stateless have is that **they influence heavily the attester and block proposer roles respectively**. One, can potentially lower the hardware requirements to them. While the other one adds the extra task of ensuring censorship resistance via ILs.
Below we outline the major statelessness approaches – **full vs partial statelessness** – and what each implies for block producers.

</details>

<details><summary><b>
Weak Statelessness (Partial Statelessness) – *“Verifiers stateless, block producers stateful.”*
</b></summary>

> In a weakly stateless design, only block proposers/builders need full access to the global state, while all other nodes can validate blocks **without a local state database** ([Statelessness, state expiry and history expiry](https://ethereum.org/en/roadmap/statelessness/#:~:text=,to%20the%20full%20state%20data)).

Validators verifying a new block are provided with a **witness** (e.g. Merkle/Verkle/ZKVM proof) for each state access in the block, allowing them to update their state root and confirm block validity without storing entire state.

This approach greatly lowers hardware requirements for most nodes (enabling near-instant syncing and even mobile-phone validators), but it **puts the pressure on block producers** to maintain the full latest state in order to execute transactions and **generate witnesses** for their blocks. In practice, weak statelessness presumes a separation of roles (e.g. via proposer-builder separation, PBS) where specialized builders handle the heavy state and witness generation tasks. Block producers under weak statelessness **MUST BE powerful, stateful nodes** (or outsource to such builders), since they need to access any part of state touched by pending transactions to create the necessary proofs
</details>

<details>
<summary><b>Strong Statelessness (Full Statelessness) – “No node stores full state; all state data is passed around as needed.”</b></summary>

Strong statelessness is the ideal end-state (_since we drastically remove the hardware requirements for all consensus and possibly execution participants_) where **no validator or block builder** permanently stores the global state ([Statelessness, state expiry and history expiry](https://ethereum.org/en/roadmap/statelessness/#:~:text=,to%20the%20full%20state%20data)). Instead, **transactions must carry sufficient witness data** (proofs of account/storage values) to allow anyone to validate them against a known state root. Block producers in this model do not need the entire state up-front; they can theoretically rely on the witnesses provided with transactions or obtain needed state bits on demand from a distributed storage network.

In practice, however, achieving full statelessness is challenging. It pushes the burden of state availability largely to **users and the network** – users might need to fetch and attach proofs to their transactions, and block builders might still maintain caches of recently used state or use an on-demand state fetch protocol for efficiency ([Why it’s so important to go stateless | Dankrad Feist](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html#:~:text=,blocks%20requires%20the%20full%20state)).
**Block production requirements:**
Even if no node is required to hold all state all the time, a proposer must ensure that any transaction it includes has a valid, up-to-date witness (otherwise the block will be invalid). This might involve regenerating or updating witnesses if the state has changed since the transaction was formed. Thus, block producers in a strong stateless regime might still perform *just-in-time* state lookups or caching. The expectation is that cryptographic accumulator structures (e.g. [Verkle trees](https://ihagopian.com/posts/anatomy-of-a-verkle-proof)) will make witnesses small and efficient to transmit, and protocols like the **Portal Network** or **PeerDAS** will enable quick retrieval of state data from peers when needed.

> Strong statelessness minimizes permanent storage at the cost of significantly more real-time data retrieval; block builders would need extremely robust networking and possibly **user-provided witnesses** to assemble valid blocks under tight time constraints.
</details>

<details>

<summary><b>State Expiry (State Rent) – Timed Partial Statelessness</b></summary>
Another approach to lighten the state load is **state expiry**, which can be viewed as a form of partial statelessness.

> In state expiry proposals, portions of the state that have not been accessed for a long period (e.g. ~1 year) are pruned from the active state and considered **inactive until “resurrected”**. Nodes then only store the *recently active* state; accessing old state (expired accounts or storage slots) requires a witness or proof to revive that data back into the active set. This is conceptually similar to charging **rent** for state: accounts must pay or be touched periodically to remain active, otherwise their data is dropped and must be brought back with an explicit proof.

**Block producer requirements:** In a state expiry scenario, a block proposer is expected to store at least the **active state** (all accounts/storage not yet expired) and handle normal transactions as usual. However, if a transaction touches expired state, the block producer will need the corresponding proof (witness) for that state portion.

If not, the producer must obtain the historical state data from some external source (such as a distributed storage network or archival node [like for example the Portal Network](https://github.com/ethereum/portal-network-specs)) before including the transaction. This introduces additional overhead in block building – similar to strong statelessness – but only for cold/expired state accesses. In effect, state expiry outsources long-term state storage to off-chain systems or the users, limiting on-chain state size growth while **requiring block builders to handle occasional large proofs** for resurrected data. Block producers would also need to ensure **expired-state transactions pay appropriate fees** (covering the extra cost of witness verification and state revival), as discussed in state rent economics.
</details>

---

In summary, **weak statelessness** keeps block building similar to today (one party with full state) but frees everyone else, whereas **strong statelessness** radically changes block production into an on-demand data retrieval process. **State expiry** lies in between: most blocks only deal with an active subset of state (making block production fast), but once in a while a block must absorb the cost of including a previously expired piece of state via a witness. All these approaches strive to make running a node much easier (reducing persistent storage), at the cost of increasing the **real-time data each block must carry or fetch** (i.e. witnesses). The table below summarizes the block producer requirements in each scenario:

| **Statelessness Mode** | **Who Stores State?** | **Block Producer’s Duty** |
|----------------------------|----------------------------------------|---------------------------------------------------------------------|
| Weak Statelessness | Only block proposer/builder (full state); others stateless ([Statelessness, state expiry and history expiry](https://ethereum.org/en/roadmap/statelessness/#:~:text=,to%20the%20full%20state%20data)) | Have full state locally; execute transactions and generate compact witness for each block. Must be powerful to handle state reads/writes, generate proofs within less than block time and store a growing state. |
| Strong Statelessness | No node stores full state; state accessed via witnesses | Ensure every tx included has a correct, up-to-date state witness. Likely fetch or update state proofs on the fly. Heavy networking to gather any missing state data; essentially stateless block building. |
| State Expiry (Partial) | Nodes store only recent state; older state pruned | Handle most tx from active state normally. For tx touching expired state, obtain or verify the provided witness to update that state. Maintain a mechanism to reintroduce pruned data into active state (with cost). |

## Overview of FOCIL (Fork-Choice Enforced Inclusion Lists, EIP-7805)

FOCIL is a **fork-choice rule modification** that introduces *Inclusion Lists (ILs)* to strengthen Ethereum’s censorship resistance by distributing block content (tx) decisions across a committee of validators (attesters). In today’s Ethereum, a single block proposer (or an MEV builder it outsources to) has total control over which transactions are included in a block. This centralizes power and has led to **oligopolistic block production** – as of late 2024, **two entities were building over 95% of blocks** on Ethereum – and **weak censorship resistance**, [evidenced by some builders excluding _sanctioned_ addresses](https://mevboost.pics/). FOCIL aims to counter this by ensuring *many validators collectively* influence each block’s content.

Illustration of the FOCIL mechanism (per-slot workflow).

- In each slot $n$, an **inclusion list committee** observes the mempool and each member produces a **local inclusion list** of transactions (e.g., containing “tx $\mathbb{a}$, tx $\mathbb{b}$”, etc.).
- These ILs are gossiped on a global network topic. The block producer for slot $n$ collects these ILs and must include the union of all txns across ILs within the block until the block is full.
>The IL aggregate includes all transactions from the committee’s lists (entries 0xa1, 0xb2, 0xc3 in this schematic) and a bitlist of which committee members’ ILs were honored. Attesters for slot $n + \mathbb{K}$ (right) evaluate Block $\mathbb{K}$: if it contains all required IL transactions, they consider the block valid in the fork choice; if not, they withhold attestations. Thus, only a block including the committee’s transactions can become canonical.*

#### More info on how FOCIL works can be found within the hidden section down below, or here: https://meetfocil.eth.limo/.
<details>
<summary><b>How FOCIL works (a bit more in depth)</b></summary>
- In each slot, a random subset of validators is chosen as the **IL committee** (ie., 16 members per slot in current proposal). Throughout slot *N* (while another block is being processed), these committee members independently gather transactions from their local mempool view and build an inclusion list (up to a size limit, ie. 8 KiB per list) of transactions they deem should be included in the next block.
- They broadcast these lists over the p2p network for the other validators to receive. By the time a new proposer is ready to build block $n + \mathbb{K}$, they will have received up to $m$ inclusion lists (one from each committee member).
- The proposer (or an external builder it works with) is **required to include all transactions from all ILs** it has collected, when constructing the block. These transactions can be placed *anywhere in the block* (FOCIL does not dictate ordering) as long as they are included *somewhere*.
>FOCIL even allows *conditional inclusion* (if a transaction from an IL cannot be included (ie. block is full or the tx became invalid), the block can still be accepted under certain conditions).

- Once the proposer includes the IL transactions, it publishes the block. The attesters for that slot will then only cast votes (attestations) for this block if it **satisfies the inclusion list constraints** (i.e. includes all the IL transactions). If a block omits any required transaction, honest attesters will refuse to vote for it, causing it to fail the fork-choice rule and not become canonical. In this way, the fork-choice (what chain is “heaviest” with votes) enforces the inclusion lists.
</details>

# Statelessness & FOCIL Interactions

## Clear symbiotic relationship areas/signs
One of the things that is clear is that Stateless-FOCIL will always be a positive sum game.
There are several reasons to argue about this:

### Statelessness will significantly decrease the hardware requirements on validators
This means we will be able to have more participants within CL.
That, directly translates to more entities who will be able to join the FOCIL protocol and submit ILs.

Stateless-regimes allow for more protocol participants ([à la rainbowstaking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683)). If you can open up the job of a FOCIL includer to people with lower stake, that's democratizing Ethereum staking.

> While this is true, it's also important to remark that FOCIL doesn't require to have thousands of ILs or tons of txs included within each IL to be effective.
>
> In fact, as said by Thomas Thiery:
> "... to me the more ILs (the more txns in ILs to be more precise), the less txn inclusion time, until you do hit a limit
the limit is 1 slot inclusion, and you can't include more txns than there is space for in a block."

So stateless has a double impact here. It allows for:
1. Bump up significantly gas_limit parameters.
2. Removes the hardware requirements from FOCIL protocol participants.

### They both contribute to Censorship Resistance and Neutrality.
This is the most direct area of synergy. FOCIL is explicitly designed to improve censorship resistance: by forcing inclusion lists into blocks via fork-choice, it **ensures no transaction remains censored for long**.
- Statelessness boosts censorship resistance in a more subtle way. First, as noted, it increases the number of possibly independent validators – it is much harder to censor transactions when there are thousands of globally distributed validators who are part of the sampling domain of the protocol, at least one of whom is likely to include any given honest transaction in their IL list.
> The **“1-out-of-N” honesty assumption** of FOCIL **becomes easier to meet with N large**.

- Second, statelessness could enable new **anti-censorship techniques** at the networking layer: for example **resilience against state-based censorship** – if an adversary tries to censor by bloating state or exploiting state load (a form of denial-of-service to price out honest nodes), stateless clients would be immune to state-bloat slowdown since they do not process the entire state for each block. **This means that even under heavy load or attempted state-layer attacks, stateless validators can keep proposing inclusion lists and verifying blocks normally, upholding censorship resistance**.

In summary, statelessness provides a **robust, lightweight validator base** and the technical means to handle additional data, while FOCIL provides the **policy and rule-set** that empower those validators to keep the chain neutral and inclusive.

### Stateless-FOCIL would boost Scalability

Stateless-FOCIL solutions would likely impact scalability in a positive way in some areas. For example:
- Removing the dependency on slow disk I/O for state – validators no longer need to read/write a massive state database each block, which can become a bottleneck as state grows. Instead, they receive a **fixed-size witness** proving the state changes. **This means Ethereum could safely raise gas limits or throughput when most nodes are stateless, without rendering verification too slow.**
- *FOCIL* indirectly assists scalability by ensuring transactions aren’t needlessly delayed by censorship.
More importantly, FOCIL also [**decouples throughput from local block building**](https://ethresear.ch/t/decoupling-throughput-from-local-building/22004) – validators can enforce inclusion of many transactions **even if a builder’s own block would have been smaller**. In a combined scenario, statelessness can help handle the *higher data load* that FOCIL might introduce. For example, if each block now carries an inclusion list (or the full transactions from ILs) and the associated witnesses, stateless clients can verify these larger blocks without storing more data long-term.
- Stateless would allow for significant `gas_limit` increases. Thus opening more space for transactions. This space is more space that builders **might be forced to include more IL transactions** which also contributes to **effectively spend the `gas_target` exhaustively** instead of just wasting it.


## Strong vs. Weak statelessness for FOCIL
One of the biggest debates we've had so far, is trying to identify which is the way to go in the strong vs. weak statelessness dilema.
There are multiple reasons to argue for both.

This writeup won't dive deeply into this. But you can get more info on [this post by Julian](https://ethresear.ch/t/a-protocol-design-view-on-statelessness/22060).

**So far, one of the things that is increasingly clear is that [we might want/need to decouple throughput from local building](https://ethresear.ch/t/decoupling-throughput-from-local-building/22004) in order to be able to scale the whole network** (See more details in [this Includer-Attester separation](https://ethresear.ch/t/towards-attester-includer-separation/21306).
And that, has direct implications on the type of statelessness we want to have.

In particular, **if we pretend to outsource block building to few well-resourced (computationally & bandwidth-wise) entities** and allow them to be the sole blockbuilders, then **there's a clear bias towards weak statelessness where block builders still keep the whole state themseleves.**

>At the same time, this means we need to lower as much as possible the requirements to attesters, includers and any other roles that exist within the Consensus Layer.

There's no reason to consider strong statelessness (which mainly allows lower-resourced builders) nor to prioritize significantly state-expiry.

The question that one might have, is "Should we have a backup plan"?
And for that, we need to ask ourseleves first the following:

### Who holds the state?

It's important to understand that within any stateless scenario, we have only 3 types of actors who can/will hold the state. And how this affects other ethereum sub-protocols like FOCIL.

| Role | Pros | Cons |
|------|------|------|
| **Block Builders** | Naturally incentivized, already centralized | Reinforces MEV builder centralization |
| **Wallets/dApps** | Pushes responsibility to edge, avoids builder bloat | Wallets resist innovation; dApps fragile, under-resourced |
| **State-as-a-Service** (ie. Portal, third parties) | Offloads responsibility; can scale horizontally | Potential for Infura-like centralization; unknown reliability |

#### Block Builders
- This post clearly identifies block builders as the best entity to rely on for holding the state (at least, a big part of it). Specially if we consider initiatives like [Decoupling throughput from local building](https://ethresear.ch/t/decoupling-throughput-from-local-building/22004). It's the easiest and less complex approach but greatly centralizes block producing further. At the same time it incurrs on extra risk of possibly needing a "fallback method". Still, thanks to sub-protocols like FOCIL, we can actually be a bit "safer" in this scenario.

- It's important to notice that in the long-term, **leaving the task to store state to block builders will hit significantly bigger limitations than delegating it on Dapps or users**. As a distributed storage design would definitely scale further and better. Also greatly reducing friction and incentive concerns in other parts of the protocol.
- If we lower the entry barrier for block producers (via strong-statelessness) but they keep delegating block construction to MEV builders, We are actually changing nothing (more block proposers exist but builders at the end are the same ones).

#### Dapps/wallets (Users)
- This would be possibly the "best solution" if we ignore the complexity of bringing it to live. **A distributed way to store and generate witness for txs will always scale far better** than any other alternative.
The problem resides on **protocols that will require "fast/JIT invalid-tx witness recomputation" (Like FOCIL might). And more importantly, who will actually perform this.** As block-builders in this case will need to ask for the witness to someone if they want to do it. Or otherwise we fall into interactive scenarios which are complex to even imagine.
- Even if we were within a strong-stateless regime. **Block builders would likely decide to store some part of the state at minimum to optimize their block building process**. So we could find ourseleves within an scenario where we aim to lower block producer/builder resources. Yet they still decide to
- I think it's hard to see useful/nice dApps nowadays. Imagine if we add to them the burden of also managing all the state proofs/witness generation for each tx..
**Seems crucial to put the ABSOLUTE MINIMAL requirements to dAPPS as they are a scarce resource within the ecosystem. We need to make it easy for them to exist and proliferate.**

#### State-as-a-Service (i.e. Portal, third parties)
- Sadly, decentralized solutions like Portal **migth not be fast enough at providing state**. Thus not making them a valid option to scale horizontally via delegation to other sub-protocols.
- If no one else handles it, **large providers (ie. Infura)** will, leading to **re-centralization**.

> **More careful thought should be put on this idea. So far it doesn't seem to be a viable one as the two main contenders to carry it over are not fast enough or lead to massive centralization.**

---

To conclude, I think one important way to frame this block proposer/builder dilema is:
> **We are stablishing "a minimal set of rules on what data block producers are assumed to hold/have". Such that we can design protocols based on this assumption that touch on possibly unrelated things. Yet can rely on assumptions based on these rules**

## Friction Points Between Statelessness and FOCIL

While the combination of statelessness and FOCIL offers many benefits, there are also important **drawbacks and friction points** to consider. Implementing both simultaneously could introduce new challenges related to transaction validity, data overhead, and system complexity:

### Significant decrease on the IL quality
This is by far the most relevant problem to solve.
This problem arises when any form of statelessness (except partial one, which is unsure if can be called "stateless") and FOCIL are put together.

**The issue: Stateless nodes have serious issues to keep their mempools pruned. While FOCIL relies on the assumption of having a correctly pruned and functioning mempool.**

Currently, in both, strong and weak statelessness flavours, includers would not hold the state that allows them to validate tx correctness (discard invalid txs) unless:
- They come with a witness (Strong statelessness).
- They ask some 3rd party or block builder for the needed witness relative to the tx (Weak statelessness).

Both of these solutions are bad. While the former implies a significant burden in the DevX and UX side of things, the latter greatly centralizes state storaging as well as has the potential to consume huge ammounts of bandwidth and network resources in general.

**Why is this important? Notice an attacker can flood the mempool at no cost, and Includer stateless nodes would have a hard time prunning it, thus leading to ILs full of garbage**.

What does this imply?
- We need to query/validate `nonce` for each tx we receive. And also prune the mempool regularly after each new block.
- We need to query/validate `balance` for each tx we receive. And also prune the mempool regularly after each new block.
- More importantly, **we need to make sure it's not impossible to gather this info without die trying**. (ie. imagine I receive 1M txs that come to my mempool. I'll need to handle a lot of proof verifications or, query a ton of data from a `GOOD_SAMARITAN` **in order to be sure that txs are valid and should make it to my IL**).

### Network Overhead and Bandwidth Consumption
Both statelessness and FOCIL introduce additional data that must be transmitted each block, raising concerns about **bandwidth and storage overhead**. Under statelessness, each block carries a witness (Merkle/Verkle proofs) for the state accessed by its transactions. FOCIL, meanwhile, adds up to $m$ inclusion lists per slot propagating through the network. **If each IL is up to 8 KiB and there are 16 committee members, that’s a theoretical 128 KiB of data broadcast in gossip for the ILs** (not counting overhead for signatures and routing).

In total, the **block data size** and the **per-slot gossip load** both increase. This raises several issues:
- Bandwidth for validators and propagation time: A stateless validator **must download the block body + witness (let’s say ~200KB-3MB depending on the tree/solution)** *plus* **the ILs (another ~ up to 100+ KB)** for each slot. To that, **we still need to account for blob data** (introduced with EIP-4844) which can significantly increase bandwidth requirements, **adding up to ~1 MB per all blobs (as per Pectra update (9 blobs of 128KB))**. If blocks come every 12 seconds, that could significantly up the data rate requirements. Validators with slower internet could struggle, undermining the goal of increasing the number of participants within the consensus.

This image from [pop's post on doubling blob count for Pectra](https://ethresear.ch/t/doubling-the-blob-count-with-gossipsub-v2-0/21893) can help us to see a bit the propagation times we can expect depending on the sent-payload sizes.
And as it can bee seen, it looks slightly concerning how stateless-FOCIL would look.

> One of the next steps will be to run some accurate simulations using [Ethshadow](https://github.com/ethereum/ethshadow) to better estimate for the different stateless solutions (Verkle, Binary etc..) what could we expect from bandwidth/propagation time.

- **Witness sizes in worst-case:** In a pathological scenario, FOCIL might force inclusion of transactions that touch *many distinct state entries*, producing a large combined witness.
A concern is that FOCIL could **override a builder’s optimization** which means that even if a builder might normally avoid including too many state-heavy transactions in one block (to keep the witness small), if the IL forces them in, the block’s witness could blow up. This is a new kind of block size griefing attack to consider under combined stateless+FOCIL operation.

### Witness Generation Complexity and Latency
Within a weak-statelessness scenario, block builders (proposers) acquire the task of generating witnesses too. Under FOCIL, the builder now has an **expanded to-do list within a single block interval**:
1. Receive ILs,
2. Fetch those transactions (if not already in its mempool)
3. Execute all transactions (both its own chosen tx and the forced IL tx) in the correct order.
4. Generate the state witness proofs for the entire block to broadcast to validators.
5. Participate in any DAS-related procedure that needs to happen.

All this must happen in a matter of seconds (in a 12-second slot, ILs might be completed ~8s into the slot, leaving perhaps ~4 seconds for block production). This is **tighter than normal block building**, where a builder could start assembling a block earlier with a known mempool.

This is not an issue now. but if we decided to bump up gas limit to 100M for example, then we could definitely start seeing complex scenarios where ILs force builders to perform more complex and bigger state proofs for their block. Which can lead to tighten a lot the time everyone within the protocol has to carry their duties.

## Open FOCIL Problems and the Role of Statelessness

Stateless Ethereum is **frontier research**, with many open questions remaining. We examine a few known open problems in Stateless-FOCIL design.

### Inclusion List Flooding Attacks
One concern for FOCIL is the possibility of an attacker trying to “flood” the mechanism with junk transactions. For example, a proposer could spam the mempool with transactions that *appear valid* just before the IL committee finalizes their lists, causing many IL entries to be occupied by transactions the proposer controls, and then propose a block that invalidates all those transactions. The result would be that all those IL slots were wasted **and the block still satisfies the IL condition vacuously**.
This is an **ex-post invalidation attack**. The FOCIL design tries to limit the impact by rules like “at most one tx per account per IL” (so one transaction can’t invalidate multiple IL entries).
> Does statelessness help here? Not directly in terms of prevention – this is mainly a game of mempool policy and costs. **However, statelessness could help detection and analysis**: a stateless node that kept all IL transactions’ witnesses **could immediately check in the next block which ones became invalid and why**.
If they notice that, say, a single transaction in the block changed 1000 accounts’ nonces (hence invalidating 1000 IL tx), that pattern could be flagged as malicious. It remains to be seen if there's any other benefit that instead of identification could actually solve something.

### Transaction Validity Windows
A missalignment at the intersection of FOCIL and strong statelessness is **transaction validity over time**. In a strong--stateless environment, a transaction might come with a proof of cold-state (state-revival) that is only valid for a specific state root. If the state changes, the transaction could become invalid or at least the proof is invalid (the transaction might still be executable, but not with the provided proof). Stateless clients might then treat the transaction as invalid until a new proof is provided. This effectively gives transactions a **shelf-life** – they expire in the mempool if not included in a timely manner or updated.

Notice that while this is not an issue of the combination of both, FOCIL could actually help mitigate or worsen the situation:

- Reviving-storage txs contain a proof that is no longer valid for the state that stateless nodes hold. Thus, occupying space within the IL that is wasted. This would be a result of FOCIL enforcing inclusion within 10 slots or so.
- IL flooding gets a new attack-vector which is based on state-revival txs.

### Unconditional FOCIL leading to IL-boost markets.
So far in this document we have been discussing "conditional FOCIL". But there's an "unconditional FOCIL" variant too which was proposed [in this post](https://ethresear.ch/t/unconditional-inclusion-lists/18500).

The main difference between the two approaches is that **conditional FOCIL implies that the proposer/builder only needs to include IL txs in the block if only if the block isn't full and the transactions are still valid.**
On the other side, **unconditional FOCIL reserves space inside a block for IL txs**.

One of the main concerns of Unconditional FOCIL is that it could potentially open an IL-boost market that we obviously don't want to have.

After some discussions, stateless doesn't seem to be of much help here.
> As said by Julian in a discussion related to this topic:
> [..] I don’t believe stateless could help here. **ILs should be designed such that they cannot be outsourced to an IL-Boost market regardless of whether it’s practically difficult to create IL-Boost.** We already have many many validators [..]

So having more validators or lower-stake ones for FOCIL (enabled via stateless + Rainbow staking for instance) doesn't seem to help to mitigate these concerns.

## Conclusion
The combination of Ethereum statelessness and FOCIL represents a potential improvement in the protocol’s evolution, matching **state scalability** with **censorship-resistant block production**. Our analysis shows a clear **symbiosis**: statelessness enables a broader set of validators to participate with minimal hardware, and FOCIL empowers those validators to collectively uphold inclusion and neutrality, counteracting the centralization of MEV-heavy block building. Together, they address two of the hardest problems for Ethereum’s future – the burden of *state growth* and the risk of *censorship/centralization in block proposal*.

It is also clear that they both can combine really well. **As while one allows increasing gas limits, the other make sure blocks are full and decouples local building from throughput.**
> That means bigger blocks, fuller blocks, with censorship-resistance and more participants within CR(Consensus Rules) at the same time.

Combining these systems is not without challenges though. As it can be seen networking, UX, IL quality and other minor topics are still concerns that we have in mind and need to get solutions for.

WRT who holds state and how this affects FOCIL and other sub-protocols, it's hard to say anything. As we're just _guessing_.

One thing is obvious in this topic. And is that if we want immediate scaling, and we want to unleash state growth, we need to be prepared to handle such growth without asking all consensus participants to upgrade hardware.
Ideally, we should lower the entry barrier to the protocol and facilitate the existance of low-requirement roles like Includer, Attester or also, staker.
And the combination of statelessness-FOCIL is a clear example of this.

> After all the considerations, **A hybrid solution that incentivizes supplying state proofs to lower fees.
Or, some form of partial statelessness** could be good 1st paths. Such that we can analyze how it affects the ecosystem and scales without disrupting how the network works atm.