Agenda
- Development updates
- Testing updates
- and more
Meeting Time: Tuesday, March 10, 2026 at 14:00 UTC (60 minutes)
1 Like
Meeting Summary:
The team discussed development updates for Fossil Breakout 30, including ELNCL fossil testing, FOCIL implementation on top of Amsterdam using Besu, and various technology updates involving Hasa fork boilerplate code and Glamsterdam implementation. Pelle presented research findings on inclusion lists and transaction processing, analyzing different strategies and their impact on bandwidth usage and transaction inclusion rates. The conversation ended with discussions about Kurtosis config and client images status, with plans to share additional configuration information and reconvene in two weeks.
Click to expand detailed summary
Jihoon led a meeting to discuss development and testing updates for Fossil Breakout 30. He reported that ELNCL fossil testing had begun, with the team in contact with STEELTIM to discuss testing approaches, particularly focusing on reference tests. Justin confirmed that work on implementing FOCIL on top of Amsterdam using Besu had started, with a draft PR currently in development, though it remains in early phases and has not yet entered testing.
Jihoon and Justin discussed an EL implementation, with Justin sharing a GitHub link and noting that the implementation might be slightly out of date. Justin confirmed that the SPR would be promoted to an actual implementation. Mehdi provided an update on technology, mentioning that they are merging Hasa fork boilerplate code and planning to add Foster on top of Jese. The team is working on FOCIL implementation on top of Glamsterdam, with one CL and one EL in progress.
Pelle presented research on inclusion lists, focusing on redundancy and the impact of 0-2 slot delays. The analysis used BlockNative data to examine different strategies, including top fee and censorship-only approaches. Pelle found that about 92% of transactions in top fee inclusion lists are wasted bandwidth, with little change after a second slot delay. The research suggested a hybrid approach combining censored and non-censored transactions, with a recommendation to keep the slot delay at zero or maximum one slot.
Jihoon and Pelle Krabbenhoeft discussed the performance of IR building algorithms, noting that 6-8% of transactions are not timely included, though most are eventually included or become invalid. Pelle explained that delayed transactions typically remain in the mempool for extended periods before becoming invalid, and approximately 98% of transactions are included within the next 5 blocks. They discussed the possibility of analyzing common characteristics of delayed transactions and the potential benefits of using archive nodes for further data collection. Jihoon suggested exploring ways to improve same-slot EILs processing by separating BALS propagation from Payload and setting BALS deadlines earlier.
The team discussed the status of Kurtosis config and client images, with Jihoon confirming that while some Kurtosis config exists for Faloo, it’s unclear if it’s still functional, and no Kurtosis config exists for post-Glamsterdam work. Katya inquired about a single source of truth for these configurations, and Jihoon indicated this information would be shared later in the channel. The conversation ended with plans to reconvene in two weeks.
Next Steps:
- Justin: Share the link to the draft PR for Besu FOCIL implementation
- Jihoon: Update the ELs (execution layer specs) by this week, particularly regarding NewPayload V6 versions
- Pelle Krabbenhoeft: Drop the full report in the group chat
- Jihoon: Ask around about providing Pelle access to an archive node
- Katya: Share Kurtosis config for post-Glamsterdam in the channel later
Recording Access:
- Join Recording Session
- Download Transcript (Passcode:
R3h^C3K^) - Download Chat (Passcode:
R3h^C3K^) - Download Audio (Passcode:
R3h^C3K^)
YouTube recording available: https://youtu.be/MJpnyjAsBWQ
Hegotá FOCIL implementation and testing have begun.
Testing Updates
- CL and EL FOCIL testing has been initiated. CL testing will be mostly consist of reference tests and coordination with STEEL is underway for EL testing.
Development Updates
-
Besu has started implementing FOCIL on top of Amsterdam. Justin has a draft PR in early phases, currently at the spec implementation stage.
-
Teku has merged Heze fork boilerplate code, which includes some FOCIL code such as the InclusionList container. Mehdi plans to implement FOCIL progressively.
-
Lodestar is giving finishing touches on ePBS devnet-0. Once it is stablized, they plan to rebase FOCIL atop.
IL Analysis using BlockNative Data
-
Pelle presented mock IL analysis based on BlockNative data. The research aimed to answer three questions: (1) how redundant IL transactions are, (2) how 0–2 slot delays affect redundancy, and (3) how different IL building strategies compare.
-
With the Top Fee IL building strategy, ILs are roughly full, but about 92% of transactions are already included in the next block, essentially wasting bandwidth. Redundancy increases by about 2 percentage after 1-slot delay and another 0.1 percentage after 2-slot delay.
-
With the Censorship-Only strategy, redundancy is about 60%, which increases by 2% and 2.6% after 1-slot and 2-slot delay respectivly. A transaction counts as censored if it was in the mempool for up to 12 seconds before slot N, was fee-eligible, fit in recent blocks, was not replaced, and still was not included by slot N.
-
Pelle recommends a hybrid approach combining both strategies and concludes that 0-slot delay is strongly preferred, and 1-slot delay at worst.
Q: Do you have rough data on how long it takes for the 6–8% of non-redundant transactions to get included?
A: About 98% were included within the next 5 blocks, or eventually became invalid. No alarming patterns were found.
Q: Are there common characteristics for transactions that sit in the mempool, e.g. Tornado Cash interactions?
A: It would require further investigation, ideally with archive node access for state validation. Distinguishing actual censorship from historical data is not clean-cut.
IL Freshness Post-ePBS
- There is an idea to propagate BALs separately from payload and set the BALs deadline much earlier, e.g., 6 seconds into the slot. This would allow IL committee members to update their state earlier and build fresh ILs even when the payload execution is finished late.
Links
1 Like