FOCIL Breakout #35, June 2, 2026

Agenda

  • Development updates
  • Spec updates
  • Testing updates
  • and more

Meeting Time: Tuesday, June 02, 2026 at 13:00 UTC (60 minutes)

GitHub Issue

1 Like

Meeting Summary:

The meeting focused on Fossil Breakout 35, where participants discussed client development, specification changes, and testing updates. Jihoon presented proposed changes to IL validation during syncing and for sidechain operations, introducing a new Payload Status V2 with latest IL-satisfied hash to address potential view divergences between nodes when moving between different chains. The team debated how to handle cases where intermediate payloads are not IL compliant and discussed the challenges of determining chain validity based on information not contained within blocks themselves. Nico raised concerns about the complexity of implementing these changes and questioned the exact problem being addressed, while Justin Florentine requested a condensed explanation of the issue for his team. The group also discussed the need for at least two CLs and two ELs for the upcoming DevNet launch, with participants noting they have sufficient client implementations but await stabilization of GLAM DevNet 5.

Click to expand detailed summary

The meeting began with greetings from Justin Traglia and Jihoon, who requested participants to wait a few more minutes. Leandro and another participant joined via chat messages, but no substantial discussion or decisions were made during this brief exchange.

The team discussed basing client development on GLAM DevNet 5, with Nico confirming they should not use DevNet 4 specs and would rebase the following day. Jihoon indicated they would proceed with DevNet 5 if it stabilizes, otherwise moving to DevNet 6, and noted that waiting for stabilization might cause some delays.

Jihoon discussed IL validation during syncing and for sidechains, proposing a solution where the CL would only pass ILs when synced and follow the heaviest weight during syncing. He introduced a new field called “Payload Status V2” with a “latest IL-satisfied hash” to address potential discrepancies in IL compliance between different nodes. Justin Florentine questioned whether the proposed change was non-controversial, and Jihoon explained that the main concern was ensuring consistent IL compliance views across nodes, particularly when handling intermediate payloads that may not be IL compliant.

Jihoon presented draft spec changes addressing a problem where nodes with different IL views could create split views when moving between chains, potentially leading to canonicalization of non-IL-compliant payloads even with honest validators. The team discussed implementation challenges, particularly around determining chain validity based on information not contained in blocks themselves, and questioned whether the proposed payload status version change was necessary. The discussion concluded with updates on testing, where Felix reported that Nethermind is actively working on Fossil implementation and will run execution-specs and hive tests against it, while the team agreed to revisit DevNet Zero planning once a stabilized GlamDevNet environment is available.

Jihoon confirmed that the Discord channel will be the primary coordination point for now, and agreed to prepare a write-up about handling divergent chains by inclusion state to share with Justin’s team. Nico requested an image of a malicious or censoring node for testing, and Justin offered to have Besu developers review Nico’s existing branch if needed. Jihoon mentioned that Bharat is currently busy with other work but will follow up in a few weeks about preparing BuildWorld to produce IL-compliant payloads for the first step of the project.

Next Steps:

  • Jihoon: Update the Execution API spec with the proposed Payload Status V2 changes (latest IL-satisfied hash field) once the design is finalized.
  • Jihoon: Prepare a write-up explaining the chain divergence issue related to IL compliance (split view between nodes coming from different chains) and share it in the Discord channel for client devs to review and weigh in.
  • Jihoon: Ensure CL and EL specs are ready before Devcon in Bogota (targeting a few weeks out), and revisit Fossil DevNet Zero scope once GlamDevNet is stabilized.
  • Jihoon: Ask Barath again in a few weeks (once GlamDevNet stabilizes) about preparing BuildWorld to produce IL non-compliant payloads for Fossil DevNet Zero testing.
  • Justin Florentine: Monitor the CL specs and Execution API spec branches for incoming changes, and watch the Discord channel for updates.
  • Justin Florentine: Point his team to Jihoon’s upcoming write-up on the IL compliance chain divergence issue and solicit their input.
  • Nico: Share the branch/setup used for testing censoring/malicious node behavior (empty block production) with Justin Florentine or Fabio for Besu to investigate the incorrect error codes when processing non-IL-compliant payloads.
  • Nico: Coordinate with the EL teams to prepare a Kurtosis image with a malicious/censoring node to test the unhappy case before the DevNet launch.

Recording Access:

YouTube recording available: https://youtu.be/bZ3L7E7a5Gw

Hegotá is preparing for its devnet-0.

Development Updates

  • Nethermind: Marc has an implementation that passes all FOCIL tests.

  • As glamsterdam-devnet-4 is sunsetted, people agreed to base hegotá-devnet-0 on glamsterdam-devnet-5. hegotá-devnet-0 will be based on the latest stable Glamsterdam devnet, whichever it turns out to be.

Spec Updates

  • Jihoon walked through two IL validation topics. For syncing, the cleanest approach is to let the CL pass ILs only once it is synced. While syncing, the CL follows the heaviest weight.

  • The harder topic is IL validation across sidechains. When a node on one chain moves to a sidechain through an FCU, it has no IL view of the new branch, so nodes coming from different chains can end up with a split view.

  • To align views, the EL has to consider ILs when validating ACCEPTED payloads.

  • A few follow-up questions are still open, such as what the EL should return when an intermediate payload is not IL-compliant but the tip is compliant, under anomaly situations such as a 51% attack, client bugs, a bad network and so on. More research is ongoing.

Testing Updates

  • Jihoon will ask Bharath to help prepare Buildoor to produce non-IL-compliant payloads for hegotá-devnet-0.

Q: What is the primary coordination point for FOCIL?
A: The inclusion-list channel in the EthR&D Discord.

1 Like