FOCIL Breakout #11

[soispoke]

FOCIL Breakout #11, May 20, 2025, 14:00 UTC

Agenda

• Berlin interop, research news and progress
• Kubi's presentation on Relay Inclusion Lists
• Implementation updates

🤖 config

• Duration in minutes : 60
• Recurring meeting : true
• Call series : (e.g Breakout room)
• Occurrence rate : bi-weekly
• Already a Zoom meeting ID : false,
• Already on Ethereum Calendar : false,
• Need YouTube stream links : false,
• display zoom link in invite : true

[jihoonsong]

I'd like to add two more items to agenda.

• Revamping the EIP's overview picture. Quoting @jochem-brouwer:

I have a small suggestion for the EIP, the provided image (in the EIP) shows the timeline for slot N-1 to slot N (in this slot block B gets released), but the text describes the process for slot N to slot N+1 (where B gets released). The timeline does also not match with the text (IL committee members in text have sec 0-8 to broadcast ILs instead of in pic 0-9)

• Reviewing this PR and have it merged. More and more people find the EIP confusing and this PR fixes it.

[poojaranjan]

Stream:

• YouTube
• X

[github-actions]

• Action: Bot processing finished at 2025-05-20 11:08 UTC

Discourse Topic: Title already exists.

• ⚠️ Could not find existing topic ID in mapping for this duplicate title.

Zoom Meeting: Reusing meeting 84265745580 for series '(e.g breakout room)'.

• Zoom Link: https://ethereumfoundation.zoom.us/j/84265745580?pwd=bfFrSkautyZYvMqkX1dl6otyJnoCvy.1

Calendar Event Updated

• Google Calendar
• Facilitator emails not found in issue, skipping email notification.

Telegram Notification

• Updated message for this occurrence to Ethereum Protocol Updates channel

[jihoonsong]

There will be a FOCIL session on June 11th. Confirmed talks are listed below. Anyone working on FOCIL who would like to attend, please send us a DM for the exact time and location.

• FOCIL Implementation Progress by Jihoon
• FOCIL Synergies with Other EIPs (Delayed Execution and Block Access Lists) by Francesco
• FOCIL and Statelessness by Carlos
• zkFOCIL by Benedikt
• FOCIL and the Future Nodes by Barnabe

We also want to highlight an article by Vitalik: A local-node-favoring delta to the scaling roadmap. This article explores the idea of partially stateless nodes, which could facilitate the scaling L1 roadmap. This approach aligns with Validity-Only Partial Statelessness (VOPS), a proposal designed to enable FOCIL in partially stateless environments, potentially achieving a 25x storage reduction.

Research

Relay Inclusion Lists

• Kubi and Michael presented Relay Inclusion Lists (rIL), a proposal that uses relays to improve Ethereum's censorship resistance without introducing protocol changes, significant technical complexity or new trust assumptions. This approach is designed to be compatible with FOCIL from the outset. Additionally, it aims to ensure that block value is not meaningfully reduced, and that builders conforming to rIL do not impose any additional load on proposers.

• In each slot, the relay observes the mempool and ranks transactions according to a deterministic inclusion rule. Once the relay has derived a weighted list of transactions based on their inclusion scores, it constructs the rIL by selecting the highest-ranked transactions until the maximum rIL size is reached. This rIL is then made available to builders via an API endpoint. Each builder must reflect the rIL in their block, and the relay validates whether the block satisfies the IL constraints via execution.

• Currently, two deterministic inclusion rule are proposed.

  • Option 1: Score = (Weighted Waiting Time * Weighted Priority Fee) / (Total Gas Paid per Transaction)
  • Option 2: Score = (Normalized Waiting Time + Normalized Priority Fee) / (Transaction Byte Size)

• Each option evaluates transactions differently with distinct approaches to spam resistance. Option 1 measures score in the unit of block, while Option 2 does so in the unit of networking. Although Option 1 appears concise and elegant, further stakeholder discussion are encouraged.

• The size of the rIL is another important parameter. It shouldn’t meaningfully affect block value, so that relays providing the rIL can remain competitive. To put it another way, the more widely the rIL is adopted by relays, the larger the rIL size they can support.

• In the future, we could support Multi-Relay Inclusion Lists, allowing multiple relays to collaboratively build a shared inclusion list that uniformly applies across participating relays. This approach would reduce redundancy for builders, as they wouldn’t need to build separate blocks for different relays with different inclusion rules. Additionally, the rIL could be extended to support blob transactions and accommodate larger sizes.

Q: When building the rILs, can relays prioritize certain transactions, inadvertently introducing new centralization risks?
A: There are two main approaches to prevent it. One is to keep the inclusion rule very simple, leaving little room for discretion. Second is Multi-relay inclusion lists, where individual relays have a lot less power to skew the rIL into a direction that they prefer.

Q: Supporting blob transactions in the rIL is beneficial, but their size and the additional latency they introduce may hinder adoption.
A: Optimistic V3 for relays could make blob rILs feasible. It allows builders to submit headers without full payloads, enabling them to update bids with low latency, without needing to shuffle the entire payload. With Optimistic V3 live, block size would no longer affect bidding latency, thereby addressing the primary obstacle to adopting blob rILs.

Q: Why doesn’t Option 1 include transaction size as an input, whereas Option 2 does? Isn’t transaction size important not only for optimization but also to prevent IL flooding, where a single very large transaction could occupy the entire list?
A: It boils down to determining the expected bottleneck in practice: either networking constraints (related to transaction size) or block space constraints (measured in gas). The goal is to maximize efficiency based on whichever resource proves most limited. Adjusting scores by gas indirectly favors smaller transactions, assuming they generally use less gas, but it’s less explicit than using byte size to prevent large transactions from monopolizing the inclusion list. We don't have a final intuition yet on which approach is optimal. A hybrid approach might also be possible, potentially adjusting by both gas and size or applying thresholds to prevent the clogging attack while maximizing utility.

Q: What will happen to Relay Inclusion Lists if FOCIL makes it to the mainnet?
A: Relay Inclusion Lists would then be deprecated.

Q: How do we ensure relays apply the inclusion rule correctly?
A: The relay is a trusted party and the rIL is publicly accessible via an API endpoint. If a relay were to misbehave, proposers and builders can opt out of using that relay. Such misconduct would result in significant reputational damage, which relays strive to avoid. Additionally, Multi-Relay Inclusion Lists significantly mitigate this risk by limiting the discretion available to individual relays.

Development

There is a pending PR that resolves ambiguity of the EIP. Marc and other reviewers will address comments and merge this PR shortly.

Testing Updates

• EL testing has opened a draft PR to the execution specs. It needs to be rebased onto the Osaka fork and requires handling a quite amount of boilerplate. A PR for the execution spec tests will be opened in few days. Once ready, we’ll be able to generate fixtures and test them against Reth or Geth before introducing the fixtures to other clients.

• CL testing has been addressing some missing pieces in the spec. After the spec is completed, we'll resume adding more tests. The test fixtures will provide the inclusion list as a file for CL clients to consume it. The goal is to ship this work in the next consensus spec release, which is scheduled in two weeks.

Mempool Visualization

• The backend is almost ready and Mercy has shared a screenshot of the frontend WIP. Later, they will integrate the backend with the frontend.

Miscellaneous

• We received feedback indicating a discrepancy between the overview diagram in the EIP and its accompanying text. The diagram illustrates the situation between slot N-1 and slot N, whereas the text describes the scenario between slot N and slot N+1. This issue will be addressed shortly.

Links

• A local-node-favoring delta to the scaling roadmap
• Validity-Only Partial Statelessness (VOPS)
• Relay Inclusion Lists
• Relay Inclusion Lists Slides
• txpool-viz