---
# System prepended metadata

title: EPF Cohort 4 - Final Dev Update

---

## Project Summary

During the EPF, I built a project for fuzzing the Ethereum network. This idea was suggested by [Fredrik](https://github.com/fredriksvantes), and being passionate about security and blockchain, it immediately captured my interest.

> Create new fuzzers for software in order to find potential vulnerabilities, or improve on existing fuzzing frameworks. Networking in particular is an area where this could see some improvements on, but clients on the execution layer and consensus layer could also benefit from additional fuzzing.

Fredrik pointed the importance of fuzzing the Ethereum network.

Fuzzing is a technique used to test the robustness of a computer program by sending it incorrect and valid data in order to trigger unusual behaviour. I have chosen to focus on fuzzing the Ethereum network, and more specifically on the devp2p protocols implemented by Ethereum execution clients.

To be able the fuzzing of the Ethereum network, I had to deepen my knowledge in two specific areas:

- Fuzzing: I consulted various resources such as book, videos, articles and research papers.

- The Ethereum network: I mainly used the devp2p specifications as a reference resource, reading them regularly, sometimes several times a week and even every day in some weeks. I also consulted Hive tests and Geth codebase.

Initially, I had opted for the Rust language to develop the fuzzers and the Reth project to interact with the Ethereum network, rather than implementing the devp2p specifications myself. However, as time went by, I noticed certain lacks in Reth, while Geth had all the functionality I was looking for, as well as solid documentation and useful tools.

So I've gone from Rust and Reth to Go and Geth!

I modified the Geth client, developed fuzzers and integrated them. To communicate with other implementations of the Ethereum network, I used Kurtosis.

Kurtosis was extremely useful in my day-to-day works. It's easy to use (even though I've sometimes messed up my Kurtosis setup with 'strange' tests and manipulations to discover vulnerabilities). It's regularly updated, and the support is reactive. I'd like to thank the Kurtosis team for their outstanding work, and I'm honoured to be listed on their [homepage](https://kurtosis.com).

## Status report 

I'm happy that my project is working properly, it can now connect to the Ethereum network and perform fuzzing on messages.

For communication on the Ethereum network, which is made up of several sub-protocols, I made modifications to Geth devp2p tool for the devp2p and rlpx protocols. For the other protocols, I used Geth full implementation directly.

I developed various fuzzers, mainly mutation fuzzers, and integrated them into the Ethereum network messages. In addition, I wrote scripts for the boofuzz fuzzer (work still in progress).

In the course of fuzzing and testing, I identified over 30 bugs on the various Ethereum execution clients. I've reported issues in projects repositories. Although most of these issues were minor, only a few were resolved due to the heavy amount of work the teams had to do.

I also discovered a security vulnerability in one of the execution client, which was validated by Ethereum's bug bounty program and the client's team. Unfortunately, I can't give specific details.

In addition, I have spotted a lots of bugs, tracks and strange behaviour on several clients, which I am currently exploring for possible security vulnerabilities. For the moment, these details are not public.

## Future of the project

The project will require constant updating as the Ethereum specifications and network evolve. Although I've been able to make significant progress, identifying bugs and a security vulnerability, there's still a lot of work to be done and improvements to be made to the project.

Here is a non-exhaustive list of possible improvements to the project:

- Supporting all the messages on the Ethereum network, as some are currently missing.
- Developing more complex fuzzers and integrating other fuzzers.
- Improve project automation and integrate a user-friendly interface.
- Integrate machine learning techniques pre and post fuzzing for more accurate results.

The project requires considerable investment, but it offers significant potential for improving Ethereum's security, especially given that the network is one of the least tested part.

Personally, I've enjoyed working on this project, and I want to contribute more to Ethereum's security. That's why I've decided to continue contributing to the project even after EPF is over.

## Self evaluation

My experience at EPF was extremely enriching.

As someone who is passionate about security and blockchain, I had the opportunity to work on a project involving these two fields. This experience marked my first experience of an open source environment, a exciting transition after working mainly on private projects.

Technically, I made significant progress. I acquired new programming skills, learning about Rust and Go. I've deepened my knowledge of Ethereum, diving into fuzzing, the Ethereum network, the devp2p specifications and the Geth codebase.

I'm both satisfied with the results of the project and the discoveries made, but also dissatisfied with the amount of work still to be done and the potential security vulnerabilities yet to be discovered.

There's a feeling that I could have added more functionality to the project. I spent a lot of time on manual research, trying to exploit the bugs and behaviours detected through fuzzing. However, it was precisely this approach that enabled me to find a security vulnerability. 

## Feedback about the epf

My experience has been exceptional.

The EPF is remarkably well organised, with regular weekly meetings and a very active Discord channel. You never feel lost, surrounded by exceptional talent who share their progress every week. It's been a very stimulating experience.

As well as the talented fellows, who are a constant source of inspiration, the mentors have also played a crucial role. My mentors, in particular, were very responsive and provided high quality feedback. Although some feedback may mention that mentors can sometimes be busy, I haven't encountered this problem, and I think this can be an opportunity to develop our autonomy.

The weekly AMA sessions have also been extremely appreciated. They offered an opportunity to learn many things about the backgrounds, working methods and work of the core contributors. Each fellow had the opportunity to ask questions, and each received answers.

All this was efficiently managed and organised by Mario and Josh. A github repository held all the information. Communications and announcements were handled in a dedicated discord channel, and meetings were held every week at the same time on Mondays and Tuesdays, with some exceptions.

I also received very detailed feedback from Mario on my project proposal, which helped me to understand the project better and to orientate myself correctly in my work.

All the fellows were invited to the DevConnect in Istanbul, with flights and accommodation covered!

As for the negative points, after thinking long and hard, I really can't find any. Perhaps we could consider taking the already positive points and improving them even further ?

## Thanks 

A big thank you to Mario and Josh, the EPF organisers, for their perfect organisation!

Many thanks also to Fredrik and Marius the mentors who helped me a lot with their feedback and the AMAs.

Thank you to all the mentors of the fellowship and the core contributors for their help and the AMAs and to all the fellows it was a great pleasure to follow your progress and it inspired me greatly.

Thanks also to the whole Kurtosis team for their tools, which helped me a lot.