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.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

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, 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.

Statelessness Approaches in Ethereum and Block Producer Requirements

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).
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.

Weak Statelessness (Partial Statelessness) – *“Verifiers stateless, block producers stateful.”*

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).

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

Strong Statelessness (Full Statelessness) – “No node stores full state; all state data is passed around as needed.”

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). 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).
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) 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.

State Expiry (State Rent) – Timed Partial Statelessness

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) 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.

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)	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. FOCIL aims to counter this by ensuring many validators collectively influence each block’s content.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

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
$a$ , tx
$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 + K$ (right) evaluate Block
$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/.

How FOCIL works (a bit more in depth)

- 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.

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). 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:

Bump up significantly gas_limit parameters.
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 – 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.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

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.

So far, one of the things that is increasingly clear is that we might want/need to decouple throughput from local building in order to be able to scale the whole network (See more details in this Includer-Attester separation.
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. 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 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 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:

Receive ILs,
Fetch those transactions (if not already in its mempool)
Execute all transactions (both its own chosen tx and the forced IL tx) in the correct order.
Generate the state witness proofs for the entire block to broadcast to validators.
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.

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.

Ignacio Hagopian

2025/04/02 16:46:56

discuss state-expiry in another section.

I think this preamble section is already large enough. I'm not sure talking about state-expiry in this doc makes much sense.

Carlos Pérez

2025/04/03 07:34:18

Mainly did it as state expiry will be a headache to manage with FOCIL. As it opens attack vectors and more complex thinking on retribution to nodes is required if we aim for an state expiry that can work. More on this in the latest sections of the doc. Happy to remove the intro anyways and assume people understand what we are talking about.

2025/04/02 17:06:18

combined with the fact that IL txs won't need witness anymore (in some stateless scenarios)

Which scenarios are you referring to here?

2025/04/03 07:01:55

I refer to weak statelessness here. As block-producers will be able to re-compute or ditch invalid txs and since we have statelessness still, validators/attesters can just verify ILs without a witness for them.

2025/04/02 17:07:45

The IL-related data

By this you mean a proof of why some potential IL-txs where included, right?

2025/04/04 10:41:55

Nope. I meant IL data like: - Transaction hashes (32 bytes each) - Possibly metadata (e.g. sender address, nonce, gas price) — to resolve mempool conflicts - Maybe some form of signature or attester tag

2025/04/02 17:09:36

This might not be an issue in some countries with up to 1Gbps connections. But it definitely is in others. And goes against the desire of increasing participants and decentralization that ethereum has within its core values.

I would say this is true, depending on how we design some knobs in the protocol for the worst-case scenario. I can't imagine a world where we design FOCIL/Stateless for requiring 1Gbps in the short/medium term.

2025/04/04 10:42:53

Ofc. We go worst-case always!

2025/04/02 17:23:39

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.

I'd say this is a design problem of stateless if that's the case. In any design solution, we can't rely on block builders avoiding worst-case scenarios. Ultimately because the block builder itself can create the block attack, so you don't need FOCIL for that.

2025/04/04 12:09:20

Agree. I was just trying to signal that although this might not end up being an attack. It certainly can evolve into situations where builders are put in a tough spot.

Thomas Thiery

2025/04/08 12:26:40

I think witness size can also explicitly be limited by FOCIL parameters

2025/04/16 10:15:20

How so? If you do that that might affect txs that just touch a ton of state and so require a big witness.

2025/04/03 08:19:37

No node stores full state

it's always puzzling to me, in this case it means users or wallets or dapps need to store the full state and generate witnesses right?

Guillaume Ballet

2025/04/04 09:50:31

they can get that generated for them, or only store enough data to be able to generate the witness. that's O(log(depth)) of whatever they are interested in.

2025/04/07 07:37:51

Anything related to this I should highlight somewhere?

2025/04/08 12:00:36

Ensure every tx included has a correct, up-to-date state witness. Maybe add after this sentence that we need parties to generate up-to-date state witnesses if individual users are not expected to do it themselves?

Julian Ma

2025/04/03 08:19:39

nodes

It does not remove the need for all nodes to store the entire state right? E.g. archive nodes may still want to store the entire state

2025/04/04 09:57:44

Depends on the statelessness flavour. But generally I'd say it never "removes". All nodes can still store whatever they want to.

2025/04/07 06:14:25

Also, that's why it says "reducing or eliminating". LMK if I should further clarify this.

2025/04/07 08:23:35

Eliminating or reducing makes sense, but I think it's valuable to be precise here. It's desirable that some nodes, specifically validators, do not have to store the state anymore, but some other nodes definitely do.

2025/04/03 08:25:27

heavily

I'd also say that statelessness has a big impact on the block producer and attester role whereas FOCIL has a very small impact on the role

2025/04/04 10:00:21

I don't think FOCIL has very small impact. Specially since within a certain statelessness paradigm, the role of the block producer (specially if needs to re-calculate valid witness of invalidated TXs).

2025/04/07 08:35:02

FOCIL does influence the block producer role somewhat but the functionality is almost exactly the same. Honest builder behavior does not change. Dishonest builders may need to do extra work indeed, but that is not because the builder role changes, but that it is enforced now. I would be fine with saying FOCIL influences heavily the block proposer role though since it's a subjective statement. FOCIL barely changes the attester role though. In the worst case, the attesters need to a small extra check. Stateless would heavily influence the attester role in that it does not require storage anymore.

2025/04/16 09:22:11

I think what I tried to say here is that them both change both roles when combined. But sure. I agree. Will clarify

2025/04/03 08:44:02

mobile-phone validators

Then we limit the gas limit to the execution capabilities of mobile-phones. Moreover, it would mean the upload and download bandwidth of the attester would vary greatly as a person takes their mobile phone with them

2025/04/04 10:07:37

To be clear, the fact that it would be possible doesn't mean it would be practical. (Which won't obviously as telcos are restrictive with bandwidth consumption on LTE). This is just showcasing that hardware ceases to be an issue at all for almost all protocols and roles (except block building ofc)

2025/04/03 08:44:40

but it puts the pressure on block producers

As I argue in my recent post, weak statelessness doesn't actually do this as a block producer could just prune a part of its state tree https://ethresear.ch/t/a-protocol-design-view-on-statelessness/22060

2025/04/04 09:30:00

I am aware that is covered in the strong statelessness document, but these techniques also work in a weak statelessness environment. They are just not required by the protocol, and would be a nice way to transition from one to the next.

2025/04/04 10:09:53

If you prune state you can't construct witness for certain txs that might be IL-included. Forcing you to get delayed in the production of the block (need a 3rd party to serve the state) or otherwise, simply not constructing the block. Sure, we can expire state with certain rules. But that's orthogonal to what I mention here.

2025/04/07 08:39:05

ILs force the builder to behave more like an honest block producer. That means we should first define honest block producer behavior and then say whether the IL forces anything. In weak statelessness honest block producer behavior is defined as holding the state but it's just an assumption and it's unclear whether they would actually do so, even with FOCIL.

2025/04/03 08:47:47

In practice, however, achieving full statelessness is challenging. It pushes the burden of state availability largely to users and the network

This might be the same in weak statelessness right? Again, the protocol cannot rely on that the block producer will keep the state around simply by expecting it

2025/04/04 10:14:09

Why can't it? This is one of the main things that Barnabe's post tackles. If we're outsourcing block production to MEV builders. Why should we even worry on keeping the state? Let's just get witness from them or users/dapps/wallets/3rd parties.

2025/04/07 08:41:42

What part of which Barnabé post is that? My point is mainly that it's not specified who should be responsible for providing the witness. If we say that users should provide the witness, users and wallets should know

2025/04/03 08:48:17

PeerDAS

How does PeerDAS allow for this?

2025/04/04 10:15:43

With PeerDAS we can have confidence on data availability from the actors that actively store all state. Hence, we can more confidently rely on fetching any data required within a timespan that is good enough to allow for block production in time.

2025/04/07 08:44:22

PeerDAS data availability may be a bit overkill to provide a witness. Sampling is necessary because there is too much data to verify its availability by a single validator. For witnesses, that shouldn't be the case so no sampling is necessary so no PeerDAS necessary

2025/04/16 09:26:06

I think I'll leave it. I mean, this is just things that represent solution paths. Rather than be solutions themseleves.

2025/04/03 08:49:53

accessed for a long period (e.g. ~1 year)

Ress uses a different way of partitioning the state. In my post I use the definition that partial statelessness partitions the state into an active and an inactive set with a state expiry rule. The state expiry rule could be time-based but could also be something else.

2025/04/04 10:16:23

Fair. Unsure if worth diving into it here. At the end this is just an example to showcase a filtering method that is easy to understand. I do agree there might be others that are better.

2025/04/03 08:50:39

full state

Again, this is an assumption. Nothign forces block producers to hold all the state

2025/04/04 09:46:10

They are indeed forced. As otherwise they can't guarantee the data availability needed to generate a proof of state transition that will go together with the block to all stateless validators. Notice this is within a "weak stateless regime" so block producers/builders can only produce "valid blocks" if these carry witness within them.

2025/04/07 08:47:07

They can produce blocks that exclude the transactions for which they do not have a witness. If we want to rely on FOCIL to force block producers to store data, I think we should make that explicit and I'm not sure if it's the correct tool to do so.

2025/04/03 08:51:43

ideal end-state

It may seem obvious but for completeness, it could be worthwhile to state why this is the ideal end-state

2025/04/03 08:52:14

near-total

why near-total, it's just total right?

2025/04/04 10:20:11

I mean. Yes. One of the things I thought was very high-fee txs that economically outbet the censoring risk. But agree it just makes more sense to say "total". Fixed.

2025/04/03 08:58:06

highly improves the capacity of ILs

How does it improve the capacity of ILs? Txs don't need witnesses today and FOCIL size is measured in bytes, not tx count.

2025/04/04 10:38:14

Within a Strong-statelessnes regime. If you pretend that a block builder is capable of assessing whether a tx is valid. You'll need to submit contract code among other data sometimes which can potentially just fill the whole IL capacity with very few txs. But I agree this just doesn't make sense to be added.

2025/04/03 09:17:16

The state diff. The proof itself.

Does this assume a zkEVM? With Verkle trees still the entire block needs to be propagated right and attesters still need to execute it to prove to themselves the block was correctly executed?

2025/04/04 10:40:41

THis doesn't assume any particular statelessness solution. ZKEVMs also still need to propagate the entire block. Attesters can save up the execution, that's true in both cases too IIUC. As the state diff is proven by the state proof or ZKEVM proof and the tx only modifies state at the end. Hence we can save it.

2025/04/03 09:19:54

They can still keep operating as they do today. So this is opt-in.

Statelessness will likely come with a gas limit increase right so this is not completely correct?

2025/04/04 10:45:01

Neither false I'd say. Statelessness doesn't force to increase gas limits but makes it really easy to do. If statelessness exists, and you can't keep up with the increase, you have 2 solutions: - Buy new hardware or bandwidth capabilities. - Move to a stateless client version. In any case, you can keep operating on the way you were previously (unless you're a local builder that doesn't externalize block production). That might be more correct.

2025/04/03 09:26:38

invalid tx (which would put unexecuted data on-chain for “free”, a big no-no)

attesters would just vote against the block so no unexecuted data will ever get on-chain for free

2025/04/03 09:31:40

~4 seconds for block production

4s is a huge amount of time for block production. Builders do so now within a few 100 ms.

2025/04/04 16:06:06

note that this is already the case, the producer has ~4s to produce a block and forward it around the network, and validators have another 4s to vote. this might change if we get delayed state root. Note that there is an extra issue: we might want to reduce the slot time in the future.

2025/04/07 09:15:23

I see your point but the gas limit would have to rise very much before block building time increases 40x. I can't imagine a less than 3x increase in gas limit to 100M would increase block building time by 40x

2025/04/16 10:16:50

Notice that not only building time is affected by this. Propagating a bigger block takes more time. And therefore, it should be build in even less time to help with that. Hence my coment. Should I mention this explicitly?

2025/04/03 09:32:26

with many open questions remaining

I'd say at least FOCIL is fairly well understood :)

2025/04/04 12:27:59

Well wasn't saying it's not well understood. Rather there are discussions on followups etc.. See https://meetfocil.eth.limo/#open-problems for instance.

2025/04/08 12:33:59

then i'd way the future of FOCIL :) I don't want people to get the impression that the current design has many open questions remaining (Edited)

2025/04/03 09:35:44

I think this is not a practical concern even though it could happen in theory to some extent by accounting for potentially 5 different ways ILs are constructed per slot. Even then, the builder is chosen by the proposer after the ILs have been constructed, so at the time of sending, a builder (who is not the proposer) does not know it will be the builder. The proposer could do so, but this is unlikely because of PBS.

2025/04/04 12:29:43

I could delete this section ofc. Generally it looks like stateless could help on the identification. But if this doesn't sound like a problem. Identifing it doesn't have any value. Hece I can just remove it.

2025/04/03 09:38:54

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).

This seems to be a problem of strong statelessness that is unrelated to FOCIL

2025/04/04 12:31:51

It depends how you see it. If I wasn't forced to include the tx this would not be a problem for me at all as a builder.

2025/04/07 09:17:12

We shouldn't reason on whether it's a problem for the builder but instead reason whether its a problem for the user to get its transactions included

2025/04/04 09:13:17

potentially lower the hardware requirements to them.

that's one impact but there's another one: block proposers might also have to become state providers

2025/04/04 10:04:44

hmm sure. But i've considered at the end that we need to avoid the discussion of who provides state here (recall what I suggested on settleing the convo on weak vs strong). As otherwise the focus moves to stateless flavour rather than it's connection to FOCIL.

2025/04/07 08:36:07

Could you expand on this a bit? What do you suggest to settle the convo on weak vs strong?

2025/04/04 09:26:44

MUST BE powerful, stateful nodes

we could still keep the current hardware requirements and they would not have to be any more powerful than now for a long time. They only have to be more powerful than whatever a stateless attester would need to be.

2025/04/04 10:11:03

Honestly, the role of block producer is weird to me. Specially considering they all outsource to block builders. They're just entities putting their money at risk for a chance to delegate one of their tasks to a 3rd party which risks nothing.

2025/04/04 15:54:58

Just thought that block builders are the only ones that actually suffer without state-expiry.

portal network would have to scale a lot more, and anyone serving the state would have issues.

2025/04/05 05:37:33

So does this come to say that my thought was correct? unsure I follow

2025/04/04 15:57:07

even then, we need to have fallback, under-powered builders in case the centralized builders collude. This is where the issue might be a bit difficult, because these fallback builders will have to be able to function, either with the whole state, or a fraction of the state.

2025/04/04 16:02:26

the block producer must regenerate a witness for slot N. I

assuming the witness can not be reused somehow. I hope to get an answer on that next week.

2025/04/16 09:57:27

A really small subset of it can only IMO. At least in the 100-300Mgas blocks. Lots of nodes will change from state to state such that you'd need to recompute/update a decent part of the proof such that it's almost as doing it from scratch.

2025/04/04 16:08:24

hat pattern could be flagged as malicious.

that specific one, probably not as this is what 7702 transactions could do iiuc.

2025/04/04 16:25:31

Stateless clients might then treat the transaction as invalid until a new proof is provided.

could this not simply be considered as invalid by the protocol? the proof doesn't verify with the current root, ergo it is invalid.

2025/04/07 05:56:31

Not sure I follow you here.

2025/04/07 08:29:37

typo?

2025/04/08 07:54:58

My spanish wants to come out no matter how much I try to keep it hidden. Fixed!

2025/04/07 08:53:49

Removes the hardware requirements from FOCIL protocol participants.

How do IL committee members know that a transaction accesses the correct state if they don't hold the state themselves? Do they check a witness? If committee members do not know, then an adversary could flood the IL with invalid transactions, leading to FOCIL being ineffective

2025/04/16 09:32:44

Yes. But this is a stateless-mempool issue (which impacts, but it's not directly related to FOCIL).

2025/04/07 09:02:17

There's no reason to consider strong statelessness

I'd say there are at least three reasons: - We can't rely on 2 block builders to store all the state. - IL committee members may need a witness any way to construct their IL so that world is very close to strong statelessness so we may as well do it. - Potentially, we can have larger state growth if we have strong statelessness since we are not constrained anymore by the state size a block producer can be expected to store.

2025/04/07 09:04:30

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).

I'd say block producers and builders are the same entity. It would definitely be good to reduce the barriers to entry for block producers/builders, but the state size currently may not be a big barrier to entry. It could be in the future

2025/04/16 09:52:34

It's clear to me they aren't no? Specially when you see the gas consumed in a local builder block vs. the gas consumed in a mev boost one. They might not have massive hardware requirements differences now. But they will rapidly if we increase throughput.

2025/04/07 09:08:50

IL builders

I think we should still discuss whether this is the case

2025/04/16 09:55:32

2025/04/08 11:55:46

are Ethereum

are (1) Ethereum statelessness

2025/04/08 11:55:59

and Fork-Choice Enforced Inclusion Lists (FOCIL)

and (2) Fork-Choice Enforced Inclusion Lists (FOCIL)

2025/04/08 12:01:58

attesters

don't add attesters here, it's more confusing than helping imo

2025/04/08 12:03:04

weak censorship resistance

weak CR means something else (opposed to strong CR), I would say weak CR properties

2025/04/08 12:09:40

from FOCIL protocol participants.

might not be the case depending on the specific design

2025/04/08 12:11:11

decouples throughput from local block building

ref barnabé's post here instead of later on (Edited)

2025/04/08 12:17:44

I don't agree with this statement, we talked about it quite a bit and here's what I wrote down: * There is no way for includers to check whether mempool txns are valid against the pre-state root. This means includers can force include txns that are invalid against the pre-state root and make the builder do some non-trivial work to * With the current builder market, this means relying on basically 2 entities (2 builders build more than 90% of blocks) to hold the state for everyone else, which sounds a bit crazy * DOS vector: If checking whether a txn is valid or not and/or generating the corresponding witness, builders could be forced to “work” a lot for no reason other than proving txns are invalid. DOS is limited because ILs have a fixed size but could still trigger a lot of wasteful work on builders.

2025/04/08 12:22:57

providing state.

but would could find workarounds right? like asking nodes to keep a buffer of the state for the last N blocks so they can update witnesses even if not fully synced?

2025/04/16 09:54:09

What happens when blocks are 300M gas? You see? It's not the present what worries me and drives this doc. It's that the solutions we put into play don't need to scale linearly with the parameter changes we do in the future. Otherwise, we will need to solve the same problem again in the future.

2025/04/08 12:24:25

Bandwidth

I think we already know bandwidth is the biggest bottleneck

2025/04/16 09:56:29

Not clear. There are valid arguments for hardware being this bottleneck eventually as our tree-based DBs have limits. It's not like a massive SQL database where you can fit almost infinite data without crazy issues.

2025/04/08 12:37:51

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).

the way you describe it, it's not a stateless and FOCIL concern (just a FOCIL one) what might be interesting is talking about strong vs weak statelessness and flooding in either of these cases

A deep analysis of Stateless FOCIL

Introduction

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

More info on how FOCIL works can be found within the hidden section down below, or here: https://meetfocil.eth.limo/.

Statelessness & FOCIL Interactions

Clear symbiotic relationship areas/signs

Statelessness will significantly decrease the hardware requirements on validators

They both contribute to Censorship Resistance and Neutrality.

Stateless-FOCIL would boost Scalability

Strong vs. Weak statelessness for FOCIL

Who holds the state?

Block Builders

Dapps/wallets (Users)

State-as-a-Service (i.e. Portal, third parties)

Friction Points Between Statelessness and FOCIL

Significant decrease on the IL quality

Network Overhead and Bandwidth Consumption

Witness Generation Complexity and Latency

Open FOCIL Problems and the Role of Statelessness

Inclusion List Flooding Attacks

Transaction Validity Windows

Unconditional FOCIL leading to IL-boost markets.

Conclusion

Read more

Untitled

Summary on A short note on PQ-Verkle

A short note on PQ-Verkle

Privacy-preserving & secure web-search