# EPF Update: Weeks 20 & 21

## Metrics
After implementing the FOCIL block building metrics, a bug was discovered where the metrics were only reporting for certain instances and not others. The issue was that we were not checking if an IL was already in the block while checking if the current block being built was following the inclusion list.

This is fine in practice, as you can't replay transactions, so functionally the outcome is the same. However, we need this distinction to properly collect metrics. This check was added, which allowed for more precise metrics collection and fixed the ghost client issues mentioned earlier.

When looking at the logs of the original metrics, it is still unclear why this bug only affected one of the two clients running. It was likely a networking externality, but I am still unsure. It could shed light on a bug related to IL propagation occurring asymmetrically, but for now, it's just a theory.


## Implementation
I attempted to catch Reth up to the head of the main branch, but after solving numerous merge conflicts and testing the new code base in a devnet, the devnet rapidly collapses after 40-ish slots. It turns out there is a bug that was pushed to Reth, so now I am waiting on the upstream issue to get patched before catching my stale branch up to the main branch.

While working on Metrics, I also realized I could improve the best-case IL block building time complexity from $O(n^2)$ to $O(n)$, which will hopefully reduce the block building time by a few milliseconds. Although the worst-case time complexity remains the same, optimizations in the IL building process / IL caching on the CL could help mitigate this issue.

## Testing
Faheel from the EPF reached out to me about testing his implementation, so I helped him get set up with all the right information. He was able to find an error in his implementation and is currently fixing it. Hopefully, he will be ready to start EL interop soon.

I wrapped up my initial testing work this week with all tests passing. I committed them to my EELS PR so that **raxhvl** can put together some automated testing boards for FOCIL.

I also attempted some EELS Hive fixture ingestion testing, but for some reason, only the ethpandaops FOCIL-Reth image works. I need to reach out to find out what I am missing from my build process so that I can test changes before pushing them to the public image.

## Other
FOCIL is holding on for dear life as the decision is made whether to SFI or DFI FOCIL in Glamsterdam. I suffer from contributor bias, but I am severely adamant about getting FOCIL into Glamsterdam. A few months delay won't affect things horrendously, and decentralization and preventing protocol capture of L1 should come before L1 speed improvements.

Ethereum will never be as fast as Solana or X chain. Although it is still important to push Ethereum's performance (which will directly make L2s more competitive), none of it matters if Ethereum is captured, no longer permissionless, and censoring transactions of enemies of Y nation/corporation.

Potuz posted this in the IL discord this week:

> I figured since you already worked out the Beacon API you'll be better than me for the Engine API. I'd like to add a boolean in the return of engine_notifyNewPayload in Glamsterdam. The idea is that the engine would use whatever heuristic they decide to inform the CL that the payload is valid but it's censoring. This anyway needs to be part of FOCIL, so if this has already been done in FOCIL (cc @Jihoon ) then we can probably copy this design. FOCIL makes it part of the protocol how to reply to this boolean, while this that I am proposing is to keep it completely unspecified, both in how the EL sets the boolean and how the CL reacts to it

>I would make it a mandatory boolean in the structure, like what we have for get_payload, but that both the EL and the CL are not forced to use in any way. ePBS does give some good defaults if the EL puts part of the work done on to prepare the IL into this: the same work can be reused. If you would have put a tx in an IL because it's paying more than enough for the last hour and it wasn't included and could have in this block, return 1.
This is far from being a FOCIL replacement so it only makes sense as a desperate measure if FOCIL is not included right away

Which is essentially a poor man's FOCIL that could help fill in the gaps if FOCIL gets DFI'd. To me, this raises red flags as to the readiness of EPBS because, while I am no expert and haven't spent much time on the topic, it sounds like the spec is always growing and never finalized. Meanwhile, FOCIL has a concrete spec and several implementations. All that to say, I'm not sure if it is worth spending time on this, as it seems overly complex for a weak gaurentee and will just add to the wait for FOCIL.

## Next Steps
* Research more testing
* Rebase after Reth fix is merged
* Help Faheel with further Erigon interop (3x EL client interop!)