Agenda
- Development updates
- Spec updates
- Testing updates
- and more
Meeting Time: Tuesday, June 02, 2026 at 13:00 UTC (60 minutes)
Meeting Time: Tuesday, June 02, 2026 at 13:00 UTC (60 minutes)
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.
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.
o65H@2WY)o65H@2WY)o65H@2WY)YouTube recording available: https://youtu.be/bZ3L7E7a5Gw
Hegotá is preparing for its devnet-0.
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.
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.
Q: What is the primary coordination point for FOCIL?
A: The inclusion-list channel in the EthR&D Discord.