Agenda
- Development updates
- Spec updates
- Testing updates
- and more
Meeting Time: Tuesday, July 21, 2026 at 13:00 UTC (60 minutes)
Meeting Time: Tuesday, July 21, 2026 at 13:00 UTC (60 minutes)
The meeting focused on development and specification updates for Fossil Breakout 38. Justin, Jihoon, Nico, and Fabio discussed ongoing implementation work, with Nico reporting that Lodestar is waiting on merges to unstable and is stuck on 7688 changes, while Fabio mentioned testing issues with Amsterdam DevNet 6. The main discussion centered around Jihoon’s question about the block cache parameter in the getCollateralized engine API, particularly whether CL and EL clients always have the same head payload when calling FCU, with concerns raised about timing and payload execution. Jihoon also shared plans to revamp the IL store, including modifications to request-response handling and signed inclusion lists, while noting the need to make these changes compatible with frame transactions. The team discussed the timeline for the first DevNet, with Justin suggesting waiting until the first testnet is upgraded to Amsterdam and noting it’s not scheduled until end of September, though local interop testing between Lodestar and Besu might be possible in about two weeks.
The team held a Fossil Breakout meeting where development and specification updates were planned to be shared. Justin mentioned he was recovering from a cough and would respond to a message later. Jihoon reported making small fixes to the spec and creating corresponding PRs. Nico discussed a recent fix to a max request issue, though he needed to review it further. The meeting was just beginning with Fabio joining and waiting for others to start sharing updates.
The team discussed progress on various development tasks, with Nico reporting they are waiting for merges to unstable before rebasing on DevNet 7. Fabio mentioned testing issues with Amsterdam DevNet 6, and Jihoon confirmed that Yoakam will help with execution testing starting this week. The conversation ended with Jihoon raising a technical question about whether CL and EL clients have the same head payload when calling getCollateralizedList, noting a potential timing difference of 6 seconds for payload and 8 seconds for ILD.
The team discussed concerns about payload execution timing and its impact on fork choice updates (FCU). Nico highlighted that if a new payload call takes longer than two seconds to execute, the FCU might not be called in time, potentially leading to stale results. Fabio explained that in some implementations, the transaction pool doesn’t change when using an outdated block cache, but attempts to return results with best effort. Jihoon noted that further consideration is needed regarding the block cache parameter and its limitations. Additionally, Jihoon mentioned plans to work on revamping the IL store, including modifications to the request-response for inclusion list and potential updates to the enclosure list implementation.
Fabio raised a question about execution specs in Paris regarding the payload building section, specifically whether the initial version of the payload should include only inclusion lists rather than an empty transaction set. Jihoon clarified that the current specification allowing empty payloads might not need updating, as builders can decide when to include enclosureless transactions, and he committed to investigating why the empty payload requirement exists in Paris. The discussion ended with Nico beginning a question about NCSPR and REC-RASP usage by testers, but the transcript ended before Nico’s question was answered.
Jihoon and Nico discussed implementing request-response functionality for proposers and builders, with agreement that testers should not use this feature. They decided to focus implementation on proposals and builders rather than testers, and discussed potential simplifications to the timeliness calculation. The conversation concluded with uncertainty about the DevNet timeline, with Jihoon suggesting a potential revisit in two weeks or end of August.
The team discussed timing for launching local interop testing, with Justin suggesting waiting until the first testnet upgrade to Amsterdam (expected end of September) for stability, though this timeline was deemed too far out. Nico confirmed they could proceed with local testing on Alpha 12 after updating Lodestar and Beso, while Jihoon proposed waiting until the IELTS score gets revamped before making major changes. The group agreed to target a new CL spec release a few days before DevNet 8 (scheduled for the first week of August) and conduct local interop testing shortly after.
#Qr907Yi)#Qr907Yi)#Qr907Yi)YouTube recording available: https://youtu.be/YnOeffvTkPs
FOCIL’s engine API is hashing out its last blocker.
Lodestar is waiting on some Glamsterdam changes to land before it can rebase on glamsterdam-devnet-7.
Besu is on glamsterdam-devnet-6.
Jihoon opened with a question on whether the blockHash parameter in getInclusionList is necessary. If the CL and the EL already share the same view of the head payload when the call is made, the parameter is redundant. What matters is whether the two are always on the same branch.
Nico pointed out that if newPayload runs long, FCU might not have been called by the time getInclusionList arrives, since the 6-second deadline only covers the payload being available, not executed.
Fabio explained that in Besu the transaction pool the inclusion list is drawn from does not change with the blockHash passed in. If the hash does not match the current head, Besu can only warn that the request does not match the chain head and return a best-effort result, which may be stale or contain already-confirmed transactions.
Jihoon concluded he needs to think through more cases. The parameter is meant to point at the head or its parent to provide the freshest IL. He expects this to be the last blocker before the engine API PR can merge.
After the engine APIs, Jihoon plans to revamp the IL store, which should be enough for the first few devnets, and then prioritize making FOCIL compatible with Frame transactions.