---
# System prepended metadata

title: Final Report

---

# Final Report

This is the final consolidation of what I did and achieved throughtout the Protocol Fellowship!

#### Project Abstract

This project was a research prototype of the latest Fast Confirmation Rule specification in Lighthouse. The primary motivation was to help EF Protocol Consensus Team get a deeper understanding on how FCR works in one of the Consensus Layer Clients (apart from Prysm and Teku as they are already involved with FCR) and help improve the evolving specification.

#### Motivation

We haven't reached the SSF dream yet, and for the meantime FCR is the way to go for. And you should care about it :
* Users and dApps get near-instant confirmation for small value transactions, improving the UX. 
* Under normal synchrony, it still guarantees the block remains on canonical chain
* Reduces risk trade reversals for exchanges that allow optimistic trade upon deposits
* Also useful for PBS, as it provides block builders with an indication of whether the block that they are building upon is likely to be reorged out

#### Status of Project

During the fellowship, I built on the latest FCR spec from scratch in Lighthouse, leveraging tree-states for fast state access and ahead of time Fork Choice update. 

The [implementation](tab:https://github.com/harsh-ps-2003/lighthouse/tree/coreFCR) has :
* FCR commands integrated in Lighthouse CLI
* Backward compatible non-invasive integration via side-tables and hooks without touching DB schema
* Full FFG + LMD-GHOST integration for safety
* Lazy FFG support derivation from head votes, avoiding full attestation scans
* Rigorous reorg-safe parent→child inheritance and DAG-aligned pruning
* Rich Observibility setup that I ran for days to confirm correct working of FCR

Apart from tests, all the success criterias from the roadmap were met! It's a pretty good research prototype.

Unfortunately the PR is not reviewed yet, as Michael is busy shipping Fuskaka. 

#### Results and Benchmarking

The benchmarking setup is good, and the metrics are visualized on Prometheus. I ran the FCR for 2 days max to see how it was performing, and thankfully its quite stable.

* Lighthouse running fork choice at 11.5s means it's already computing which block will be the head before the next slot arrives. This allows FCR to confirm blocks closer to the 11.5s mark rather than waiting for the full 12-second slot to complete. So, an architectural advantage ;)
![image](https://hackmd.io/_uploads/ry5TuG51Wl.png)

* Roughly 1 reorg every ~2.5 hours, stable, so the confirmations that depend on the safe head are reliable
![image](https://hackmd.io/_uploads/HyztDGq1-e.png)
* Throughput stability as Fast Confirmation happens per 12s slot in steady state
![image](https://hackmd.io/_uploads/rkYavzqyZe.png)
* Epoch Boundary Transition
![image](https://hackmd.io/_uploads/H1uNuGcJZe.png)


#### Impact 

There is no direct user impact as now, it being a research project, but we have moved the implementation of FCR forward significantly, given that [Lighthouse is the most prominent Consensus Client in the Ethereum ecosystem](https://clientdiversity.org/). But the mentors were able to understand how FCR is working with Lighthouse architecuture. Also, as we worked on the project, fruitful discussions led to improvement of the alogrithm as well, and the FCR has evolved more!

The spec is still evolving, so some minor things will change later, but overall the progress in terms of understanding how FCR is working in Lighthouse has been great. 

#### Future Work

The official tests are still being worked upon by the authors of FCR, thus they will be added later. I have added some simple tests for CLI and FCR, but FCR tests need to be be made significantly more robust.

Regarding the future of the project, I think Michael (or someone from lighthouse) will take over it. The PRs were in stable branch, so once the review is done, they will have to be rebased to unstable and then released later. Quite a cumbersome process!

#### Feedback

For me, EPF has been magical. After Protocol Studies, actually working on protocol was enlightening! The only sad thing about this experience was that I was not able to attend in-person EthCC and Devconnect due to my hectic academic commitments. Because I was a very comfortable with Rust and did Protocol studies as well, I think EPF was very smooth for me. I am pretty proud of myself for managing so many things together and nearly excelling in all of them. Now it's for the taking up a job upon graduation. I am trying to get into Etherum Foundation, and adjacent VC-backed Etheruem-based companies, but as mostly senior engineers get hired, I don't know whehter I will be getting that. Thankfully, the skills I have developed over the years will make sure I atleast get a solid Web2 job ;)

Also, I really appreciate the mentorship that I recieved. My mentors were really patient (I get confused and ask stupid questions sometimes due to the number of times I need to context switch), helpful and proactive. I am really humbled that I got to work and learn from such smart people. I have learnt a lot from them.

Regarding EPF, I think its pretty well run now given 6 iterations have happened successfully. I don't have any complains as such. One improvement I would suggest is to segregate projects based on their difficulty or time commitment or number of people recommended when proposed by the client teams. I don't think everybody can take EPF as a full-time thing, people have other commitments as well. So, any such segregation that can help in deciding the project would help the upcoming cohort of fellows. 

#### Thanks giving

I really appreciate the time and effort Roberto, Mikhail and Michael put in for mentoring me, and Mario and Josh for organizing it so well. Will miss the weekly standups and Office hours so much (even though I hate meetings). 

#### References for a deeper look :
* [Fast Confirmation Rule](https://arxiv.org/pdf/2405.00549)
* [PEEPanEIP](https://www.youtube.com/watch?v=dZU-Ch22MKY&t)
* [Old Specification]( https://github.com/ethereum/consensus-specs/pull/3339)
* [New Specification](https://github.com/mkalinin/confirmation-rule)
* [Initial Project Proposal](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/Fast_Confirmation_Rule_Lighthouse.md)
* [Detailed Project Proposal](https://hackmd.io/@harsh-ps-2003/SJSOZISVge)
* Benchmarks : 
https://hackmd.io/ZM3vm5dlRJCsbCqR1b10Rg,
https://hackmd.io/MwJ-IP-sQomPWL8_NLImVg, 
https://hackmd.io/Lzhq5AxQQruU-yAwcbcePA, https://hackmd.io/bs3HcV4FSRyZ_eK8hDfiYg, https://hackmd.io/UxOTKEgyRD-N9R4tanEY8w
* [Prysm's Implementataion](https://ethresear.ch/t/fast-confirmation-rule-on-safe-head-in-prysm/22167)
* [Circle Research on FCR](tab:https://www.circle.com/blog/exploring-confirmation-rules-for-ethereum) 
* [The discussion forum for FCR](https://ethresear.ch/t/confirmation-rule-for-ethereum-pos/15454)
* [FCR branch in Lighthouse](tab:https://github.com/harsh-ps-2003/lighthouse/tree/coreFCR)
* [Final Presentation Slides](https://docs.google.com/presentation/d/1Qz9YDLsE8nt0Cl8As3hZdpbmwMCu1iJRXBaqhjW_QDQ/edit?usp=sharing)